Floppy detection probems with 6.2
I am installing FreeBSD 6.2/amd64 on a Supermicro P8SCT however the install kernel refuses to attach the floppy (it returns ENOMEM). If I boot the same kernel without the mfsroot image it sees it fine so. I am trying to find out more information about what memory is being used, etc.. Does anyone have a suggestion how I can do this? Thanks. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpMTyuwn03Vc.pgp Description: PGP signature
Re: a simple patch to enable RFC2640 for /usr/libexec/ftpd
On Tue, 2007-04-17 at 10:37 +0300, Nikos Vassiliadis wrote: > On Monday 16 April 2007 21:24, Zhang Weiwu wrote: > > Pieter de Goeje 写道: > > > I think your patch looks good, however there have been some changes to > > > ftpd > > > since 6.1. Also, since lukemftp is imported from NetBSD, you might want > > > to > > > contact the original author so future imports won't discard this new > > > feature. > > > > > Original author of lukemftp? I never used that software before, but > > would be glad to try as next option and see if I can patch that too. > > lukemftp is the former name of tnftp, which is known in > FreeBSD as the native ftp client and server. So it would > be better to send your pathes directly to them, Luke Mewburn > or the NetBSD project. > > http://freshmeat.net/projects/tnftp/ > Okay, now I got it, so /usr/libexec/ftpd is simply /usr/libexec/lukemftpd's copy or reconfigured version. I'll reach tnftp team. I read from their webpage that they have implemented RFC 2389 themselves. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
PR conf/107453 still pending
The PR conf/107453 (calendar.judaic is out of date) is still pending. I submitted the patch to correct this bug back in January. It is just a replacement of an ASCII text file and should not affect the operation of the OS. Could some one with the commit bit please look at this and commit it? Also, I just noticed there is an error in the PR description. The description says "CE calendar year 2003". That should read "CE calendar year 2007" Thanks Josef -- Josef Grosch | Another day closer to a | FreeBSD 6.2 [EMAIL PROTECTED] | Micro$oft free world | Berkeley, Ca. pgps2c5Q6HQyK.pgp Description: PGP signature
Re: a simple patch to enable RFC2640 for /usr/libexec/ftpd
Zhang Weiwu wrote: On Tue, 2007-04-17 at 10:37 +0300, Nikos Vassiliadis wrote: On Monday 16 April 2007 21:24, Zhang Weiwu wrote: Pieter de Goeje 写道: I think your patch looks good, however there have been some changes to ftpd since 6.1. Also, since lukemftp is imported from NetBSD, you might want to contact the original author so future imports won't discard this new feature. Original author of lukemftp? I never used that software before, but would be glad to try as next option and see if I can patch that too. lukemftp is the former name of tnftp, which is known in FreeBSD as the native ftp client and server. So it would be better to send your pathes directly to them, Luke Mewburn or the NetBSD project. http://freshmeat.net/projects/tnftp/ Okay, now I got it, so /usr/libexec/ftpd is simply /usr/libexec/lukemftpd's copy or reconfigured version. This is not correct. We have lukemftpd in the src/contrib directory but it is not activated by default. The standard ftpd found in usr/libexec is the traditional FreeBSD ftpd. It is not imported from somewhere else. I'll reach tnftp team. I read from their webpage that they have implemented RFC 2389 themselves. Yar Tikhiy is our ftpd maintainer. I've put him into the cc line of this email. He may not be subscribed to this mailing list. -- Andre ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
PR conf/107453 still pending
The PR conf/107453 (calendar.judaic is out of date) is still pending. I submitted the patch to correct this bug back in January. It is just a replacement of an ASCII text file and should not affect the operation of the OS. Could some one with the commit bit please look at this and commit it? Also, I just noticed there is an error in the PR description. The description says "CE calendar year 2003". That should read "CE calendar year 2007" Thanks Josef -- Josef Grosch | Another day closer to a | FreeBSD 6.2 [EMAIL PROTECTED] | Micro$oft free world | Berkeley, Ca. pgpyqs2ywlxtO.pgp Description: PGP signature
Re: Floppy detection probems with 6.2
In message: <[EMAIL PROTECTED]> "Daniel O'Connor" <[EMAIL PROTECTED]> writes: : I am installing FreeBSD 6.2/amd64 on a Supermicro P8SCT however the install : kernel refuses to attach the floppy (it returns ENOMEM). If I boot the same : kernel without the mfsroot image it sees it fine so. : : I am trying to find out more information about what memory is being used, : etc.. Does anyone have a suggestion how I can do this? Maybe we've come to the point in time that we need to do PIO for floppies when we can't allocate enough memory for their DMA at boot. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFI: Ethernet driver ported from Linux
On Mon, Apr 09, 2007 at 10:23:00PM -0600, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Alan Garfield <[EMAIL PROTECTED]> writes: > : I'd like to port/re-write this driver for FreeBSD but I cannot find > : enough documentation and examples of a basic Ethernet driver for > : FreeBSD. (if_wlan and if_ef look like good candidates but if_clone and > : the miibus confuse me a bit and there isn't any clear docs on them) > : > : Can someone point me in the direction of an example or the relevant man > : pages I should be reading to help with this. > : > : The device driver for Linux seems quite simple. > : > : Any help would be gratefully appreciated. > > In addition to the other advise, you might also look at if_ed.c. It > is a little complicated since it talks to real hardware, and that > hardware is, ummm, a little icky. That little thing Alan is writing a driver for should be simpler and clearer than the ed(4) hw, so Alan's driver will be a source of knowledge itself when it's complete. :-) It can be a good companion for if_edsc, as the latter doesn't work with hardware at all and fails to illustrate some important points due to that. -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
GSoC project community intro and sync
Hi, hackers. I'm working on 'Generic input device layer' GSoC2007 project (http://wiki.freebsd.org/SummerOfCode2007). This mail is actually to introduce my ideas and to synchronize it with current community efforts. --Intro-- The project addresses input devices handling and multiplexing. The proposal with raw design is located at http://wiki.freebsd.org/GenericInputDeviceLayer. It also includes current state overview. In brief, the proposal suggests to implement input handling via usermode drivers stacks. Usermode stage is handled by usermode drivers framework. The device class specific data is specified by 'exporters'. --Sync-- I would like to get info from everyone, who may take similar efforts in FreeBSD input handling. I'm aware of * newpsm framework * KGI/KII * vtc(4) was mentioned, but its code seems to do nothing from my project thesis perspective. Or I've missed something? Maybe we will find some optimal design that will unify our efforts. --Generic input handling ... even more generic layer-- I will appreciate any ideas from people, who may find the usermode drivers approach useful for their projects. Any useful discussion may result in some more generic design, that will fit more needs. E.g. one of generalization ways is to allow exporters to specify drivers interface. P.S. please 'reply all', so that all CC'd people receive their copy. Thanks, - Maxim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: GSoC project community intro and sync
On Apr 17, 2007, at 10:21 AM, thIOretic wrote: I would like to get info from everyone, who may take similar efforts in FreeBSD input handling. I'm aware of * newpsm framework * KGI/KII * vtc(4) was mentioned, but its code seems to do nothing from my project thesis perspective. Or I've missed something? As for vtc(4): I've not been working on input devices because of the lack of a generic layer. Note that vtc(4) deals with the low-level console as much as it deals with user-visible terminals, so from that point of view, a user space stack will not address the need for having console input when there's no (functional) user space -- this includes early boot, the kernel debugger and single-user mode. I therefore doubt that it will sufficiently (or at all) solve problems we already have. Also, while multiplexing is an important feature I think that de- multiplexing is important too. With USB and multi-head or multiple graphics cards it's conceptually easy to turn a PC into a multi- user workstation, having multiple independent terminals. This implies that input devices need to be tied to output devices, which together form one or more terminals. In short: We do need a generic input framework, but I think we need it in the kernel, not in user space. I also think that a generic input layer should be capable of handling both focussed and non- focussed input devices to lay the foundation for configurations that do not include keyboards. -- Marcel Moolenaar [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: GSoC project community intro and sync
On Apr 17, 2007, at 3:17 PM, Maxim Zhuravlev wrote: 2007/4/17, Marcel Moolenaar <[EMAIL PROTECTED]>: Thanks for detailed useful reply. As for vtc(4): I've not been working on input devices because of the lack of a generic layer. Note that vtc(4) deals with the low-level console as much as it deals with user-visible terminals, so from that point of view, a user space stack will not address the need for having console input when there's no (functional) user space -- this includes early boot, the kernel debugger and single-user mode. I therefore doubt that it will sufficiently (or at all) solve problems we already have. Yup. That's what I'm thinking about right now. One of possible decisions is to move stacking into the kernel and have an optional usermode part 'stacked' through a 2 'stub' drivers. That's a possibility. I think it's reasonable to not provide a fully-fledged stack when there's no user space. For example, while i18n and l10n are important, I think that an english-only or a Latin-only fallback mode makes matters simpler in case of an emergency. The user interacting with the boot process or working in single user mode is not an average user and can be expected to adjust to the more limited fallback mode. The question becomes to what extend the stack would live in kernel space and to what extend there will be duplication or control from user space. Also, while multiplexing is an important feature I think that de- multiplexing is important too. I guess, demux can be done by 'top' driver or by drivers layout. There are several ways, that have little impact on the total design. Unfortunately, this goes beyond just input-stack only. A terminal consists typically of input and output devices and can even include audio devices for the historical beeps, keyclicks and other audible cues. There needs to be a higher entity, like vtc(4), that manages terminals and that will be in control of bundling devices into a functional terminal. This would imply that any logic to control the bundling would be part of that higher entity and not of the input stack itself. This would significantly alter the design of the input stack if the design of the input stack incorporates such control (as I think is the case here). Not to worry, I'm going to ask you to change your design :-) Just think of it as food for thought. -- Marcel Moolenaar [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: GSoC project community intro and sync
2007/4/17, Marcel Moolenaar <[EMAIL PROTECTED]>: Thanks for detailed useful reply. As for vtc(4): I've not been working on input devices because of the lack of a generic layer. Note that vtc(4) deals with the low-level console as much as it deals with user-visible terminals, so from that point of view, a user space stack will not address the need for having console input when there's no (functional) user space -- this includes early boot, the kernel debugger and single-user mode. I therefore doubt that it will sufficiently (or at all) solve problems we already have. Yup. That's what I'm thinking about right now. One of possible decisions is to move stacking into the kernel and have an optional usermode part 'stacked' through a 2 'stub' drivers. Also, while multiplexing is an important feature I think that de- multiplexing is important too. I guess, demux can be done by 'top' driver or by drivers layout. There are several ways, that have little impact on the total design. Thanks, - Maxim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFI: Ethernet driver ported from Linux
On Tue, 2007-04-17 at 21:16 +0400, Yar Tikhiy wrote: > > In addition to the other advise, you might also look at if_ed.c. It > > is a little complicated since it talks to real hardware, and that > > hardware is, ummm, a little icky. > > That little thing Alan is writing a driver for should be simpler > and clearer than the ed(4) hw, so Alan's driver will be a source > of knowledge itself when it's complete. :-) It can be a good > companion for if_edsc, as the latter doesn't work with hardware at > all and fails to illustrate some important points due to that. Thanks for your comments. :) I just wish I could figure out what all this rtrequest/arp stuff was about so I could finish it. :) If anyone wants to look at the code just pop me an email. It's based on a GPL driver (although there isn't anything really left of it other than #defines and a few comments, the code is all new) so I don't know how/if I can get it added to FreeBSD HEAD. Anyway, back to figuring out arp. UGH! -A. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PR conf/107453 still pending
> The PR conf/107453 (calendar.judaic is out of date) is still pending. I > submitted the patch to correct this bug back in January. It is just a > replacement of an ASCII text file and should not affect the operation of > the OS. Could some one with the commit bit please look at this and commit > it? Hi Josef, I applied the patch to -current ages ago, but noticed some minor problems with it and mailed you to ask if you could check my corrections before I merged it to 6.X, but I never got a reply. I wonder if you could check the version in -current, and I'll merge the change once I hear it is OK from you. David. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mbuf and IP frame lengths
On Mon, Apr 16, 2007 at 05:14:06PM +1000, Alan Garfield wrote: > Hi all! > > A question, is it ok to just say pass an entire rx buffer of your > ethernet device up the chain and let the ip stack figure out the frame > size. > > I have a device that can only ever receive 255 bytes of data, I receive > this data from a buffer in the PRS. On an interrupt I read this data out > of the PRS buffer into a local buffer, which I then :- > > > eh = mtod(m, struct ether_header *); > > // Copy buf into mbuf Please use plain C comments for the sake of style(9) if you want your driver to be a good example. > bcopy(buf + 1, (char *)eh, FIFO_SIZE - 1); See below. > > // Set the header length > m->m_pkthdr.len = m->m_len = FIFO_SIZE - 1; Ditto. > JNET_UNLOCK(sc); > (*ifp->if_input)(ifp, m); > JNET_LOCK(sc); > > > FIFO_SIZE = 256, minus 1 for a control character in the device (which > handily keeps under the 256 frame size). The constant 1 there is worth a symbolic name. E.g.: /* The offset of an actual Ethernet frame into the FIFO */ #define FRAME_OFFSET1 /* XXX is frame size fixed? */ #define FRAME_SIZE (FIFO_SIZE - FRAME_OFFSET) > The interface is working just fine, but I'm not sure if I'm completely > correct in the way I'm doing this. AFAIK it's OK to pass a longer mbuf chain. E.g., real Ethernet has a limit on minimum frame size, which is 46 bytes of payload plus a header and an FCS, and Ethernet II encapsulation doesn't specify payload size; but it doesn't mean that you can't send an IPv4 packet with less than 26 bytes of IP payload over Ethernet. My only reservation is that less data could be copied from the device memory if the driver knew the actual frame size, but your device might have no such notion at all, relying on the upper layer, such as IP, to specify accurate data size. > I've tried casting the buffer to struct ip* to get ip->ip_len but I > always get a "dereferencing pointer to incomplete type" error (don't > exactly know why). Perhaps it's because your driver doesn't include all IP related headers. But in fact it shouldn't try to analyze IP headers because that isn't its job. -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: GSoC project community intro and sync
Hi, My input in this regard is: 1) The new stack must be detach safe. I.E. no race conditions at detatch. 2) The stack must be able to take an arbitrary mutex, that is provided by the low level device driver, and not just Giant. --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
