From dclark at engr.scu.edu Wed Oct 8 07:21:35 2008 From: dclark at engr.scu.edu (Dorr H. Clark) Date: Wed Oct 8 07:21:43 2008 Subject: Driver crash with cardbus & auto-configuration Message-ID: Driver crash with cardbus & auto-configuration: This situation was encountered when trying to use a laptop with cardbus CIS for the COEN284 "UNIX Kernel Internals" class at SCU. The corruption was discovered after applying a patch to allow the cardbus CIS to be parsed (see BUG #115623 ). After a reboot of the laptop (DELL latitude CPx), the auto-configuration process of the cardbus XIRCOM RBEM56G provoked a crash. The root cause of the crash is the corruption of the malloc storage itself. The corruption happened in the auto-configuration process. As the kernel is probing various possible devices, one call corrupts memory, & it was found that bce_probe() is the culprit. The code causing the crash in the 'bce' driver is only to allow a debug printf, and therefore can be safely removed. The explanation of the corruption is as follows: while probing for child, we normally allocate and deallocate the softc structure of the corresponding driver. In this auto-configuration case, the 'sio' driver was probed prior to the 'bce' driver and the sio driver was allocating the original 'softc' memory. The softc is set with size of 812 bytes (the sio softc data struct), and the dev->flags is set with DF_EXTERNALSOFTC. This flag makes sure that the softc is not deallocated, and the following probe re-uses the same softc. However, when the bce_probe gets executed, it re-interprets the softc data structure into a 'struct bce_softc' of size 8852 and then scribbles beyond the end of the original allocation corrupting memory. While we encountered this issue with 7.0, it appears that this is an issue in the latest version and also could be a problem in the 6.3 release. A recommended patch for this problem is offered below. Charles Bransi Engineer Dorr H. Clark Advisor Graduate School of Engineering Santa Clara University Santa Clara, CA http://www.cse.scu.edu/~dclark/coen_284_FreeBSD/driver_crash.txt The change is the following: --- if_bce_orig.c 2008-07-30 21:47:15.000000000 -0700 +++ if_bce.c 2008-08-01 21:02:52.000000000 -0700 @@ -394,27 +394,17 @@ bce_probe(device_t dev) { struct bce_type *t; - struct bce_softc *sc; char *descbuf; u16 vid = 0, did = 0, svid = 0, sdid = 0; t = bce_devs; - sc = device_get_softc(dev); - bzero(sc, sizeof(struct bce_softc)); - sc->bce_unit = device_get_unit(dev); - sc->bce_dev = dev; - /* Get the data for the device to be probed. */ vid = pci_get_vendor(dev); did = pci_get_device(dev); svid = pci_get_subvendor(dev); sdid = pci_get_subdevice(dev); - DBPRINT(sc, BCE_VERBOSE_LOAD, - "%s(); VID = 0x%04X, DID = 0x%04X, SVID = 0x%04X, " - "SDID = 0x%04X\n", __FUNCTION__, vid, did, svid, sdid); - /* Look through the list of known devices for a match. */ while(t->bce_name != NULL) { From imp at bsdimp.com Wed Oct 8 08:10:23 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Wed Oct 8 08:10:36 2008 Subject: Driver crash with cardbus & auto-configuration In-Reply-To: References: Message-ID: <20081008.020952.1525699914.imp@bsdimp.com> Sorry to top post, but this is really a bug in sio, and should be fixed there. I've added some comments to the driver, but didn't fix it since that's a little trickier than I'd thought when I dove in... Warner In message: "Dorr H. Clark" writes: : : Driver crash with cardbus & auto-configuration: : : This situation was encountered when trying to use a laptop with : cardbus CIS for the COEN284 "UNIX Kernel Internals" class at SCU. : : The corruption was discovered after applying a patch to allow : the cardbus CIS to be parsed (see BUG #115623 ). After a reboot of : the laptop (DELL latitude CPx), the auto-configuration process of : the cardbus XIRCOM RBEM56G provoked a crash. : : The root cause of the crash is the corruption of the malloc storage : itself. The corruption happened in the auto-configuration process. : As the kernel is probing various possible devices, one call : corrupts memory, & it was found that bce_probe() is the culprit. : The code causing the crash in the 'bce' driver is only to allow : a debug printf, and therefore can be safely removed. : : The explanation of the corruption is as follows: while : probing for child, we normally allocate and deallocate the : softc structure of the corresponding driver. In this : auto-configuration case, the 'sio' driver was probed prior : to the 'bce' driver and the sio driver was allocating the original : 'softc' memory. The softc is set with size of 812 bytes : (the sio softc data struct), and the dev->flags is set with : DF_EXTERNALSOFTC. This flag makes sure that the softc is not : deallocated, and the following probe re-uses the same softc. : However, when the bce_probe gets executed, it re-interprets : the softc data structure into a 'struct bce_softc' of size 8852 : and then scribbles beyond the end of the original allocation : corrupting memory. : : While we encountered this issue with 7.0, it appears that this : is an issue in the latest version and also could be a problem in : the 6.3 release. : : A recommended patch for this problem is offered below. : : Charles Bransi : Engineer : : Dorr H. Clark : Advisor : : Graduate School of Engineering : Santa Clara University : Santa Clara, CA : : http://www.cse.scu.edu/~dclark/coen_284_FreeBSD/driver_crash.txt : : The change is the following: : : --- if_bce_orig.c 2008-07-30 21:47:15.000000000 -0700 : +++ if_bce.c 2008-08-01 21:02:52.000000000 -0700 : @@ -394,27 +394,17 @@ : bce_probe(device_t dev) : { : struct bce_type *t; : - struct bce_softc *sc; : char *descbuf; : u16 vid = 0, did = 0, svid = 0, sdid = 0; : : t = bce_devs; : : - sc = device_get_softc(dev); : - bzero(sc, sizeof(struct bce_softc)); : - sc->bce_unit = device_get_unit(dev); : - sc->bce_dev = dev; : - : /* Get the data for the device to be probed. */ : vid = pci_get_vendor(dev); : did = pci_get_device(dev); : svid = pci_get_subvendor(dev); : sdid = pci_get_subdevice(dev); : : - DBPRINT(sc, BCE_VERBOSE_LOAD, : - "%s(); VID = 0x%04X, DID = 0x%04X, SVID = 0x%04X, " : - "SDID = 0x%04X\n", __FUNCTION__, vid, did, svid, sdid); : - : /* Look through the list of known devices for a match. */ : while(t->bce_name != NULL) { : : : : _______________________________________________ : freebsd-drivers@freebsd.org mailing list : http://lists.freebsd.org/mailman/listinfo/freebsd-drivers : To unsubscribe, send any mail to "freebsd-drivers-unsubscribe@freebsd.org" : : From dclark at engr.scu.edu Wed Oct 8 08:24:15 2008 From: dclark at engr.scu.edu (Dorr H. Clark) Date: Wed Oct 8 08:24:21 2008 Subject: Driver crash with cardbus & auto-configuration In-Reply-To: <20081008.020952.1525699914.imp@bsdimp.com> Message-ID: Hi Warner- Good to know we're not the only ones to run into this issue. Do you have a bug number for the problem? -dhc On Wed, 8 Oct 2008, M. Warner Losh wrote: > Sorry to top post, but this is really a bug in sio, and should be > fixed there. I've added some comments to the driver, but didn't fix > it since that's a little trickier than I'd thought when I dove in... > > Warner > > In message: > "Dorr H. Clark" writes: > : > : Driver crash with cardbus & auto-configuration: > : > : This situation was encountered when trying to use a laptop with > : cardbus CIS for the COEN284 "UNIX Kernel Internals" class at SCU. > : > : The corruption was discovered after applying a patch to allow > : the cardbus CIS to be parsed (see BUG #115623 ). After a reboot of > : the laptop (DELL latitude CPx), the auto-configuration process of > : the cardbus XIRCOM RBEM56G provoked a crash. > : > : The root cause of the crash is the corruption of the malloc storage > : itself. The corruption happened in the auto-configuration process. > : As the kernel is probing various possible devices, one call > : corrupts memory, & it was found that bce_probe() is the culprit. > : The code causing the crash in the 'bce' driver is only to allow > : a debug printf, and therefore can be safely removed. > : > : The explanation of the corruption is as follows: while > : probing for child, we normally allocate and deallocate the > : softc structure of the corresponding driver. In this > : auto-configuration case, the 'sio' driver was probed prior > : to the 'bce' driver and the sio driver was allocating the original > : 'softc' memory. The softc is set with size of 812 bytes > : (the sio softc data struct), and the dev->flags is set with > : DF_EXTERNALSOFTC. This flag makes sure that the softc is not > : deallocated, and the following probe re-uses the same softc. > : However, when the bce_probe gets executed, it re-interprets > : the softc data structure into a 'struct bce_softc' of size 8852 > : and then scribbles beyond the end of the original allocation > : corrupting memory. > : > : While we encountered this issue with 7.0, it appears that this > : is an issue in the latest version and also could be a problem in > : the 6.3 release. > : > : A recommended patch for this problem is offered below. > : > : Charles Bransi > : Engineer > : > : Dorr H. Clark > : Advisor > : > : Graduate School of Engineering > : Santa Clara University > : Santa Clara, CA > : > : http://www.cse.scu.edu/~dclark/coen_284_FreeBSD/driver_crash.txt > : > : The change is the following: > : > : --- if_bce_orig.c 2008-07-30 21:47:15.000000000 -0700 > : +++ if_bce.c 2008-08-01 21:02:52.000000000 -0700 > : @@ -394,27 +394,17 @@ > : bce_probe(device_t dev) > : { > : struct bce_type *t; > : - struct bce_softc *sc; > : char *descbuf; > : u16 vid = 0, did = 0, svid = 0, sdid = 0; > : > : t = bce_devs; > : > : - sc = device_get_softc(dev); > : - bzero(sc, sizeof(struct bce_softc)); > : - sc->bce_unit = device_get_unit(dev); > : - sc->bce_dev = dev; > : - > : /* Get the data for the device to be probed. */ > : vid = pci_get_vendor(dev); > : did = pci_get_device(dev); > : svid = pci_get_subvendor(dev); > : sdid = pci_get_subdevice(dev); > : > : - DBPRINT(sc, BCE_VERBOSE_LOAD, > : - "%s(); VID = 0x%04X, DID = 0x%04X, SVID = 0x%04X, " > : - "SDID = 0x%04X\n", __FUNCTION__, vid, did, svid, sdid); > : - > : /* Look through the list of known devices for a match. */ > : while(t->bce_name != NULL) { > : > : > : > : _______________________________________________ > : freebsd-drivers@freebsd.org mailing list > : http://lists.freebsd.org/mailman/listinfo/freebsd-drivers > : To unsubscribe, send any mail to "freebsd-drivers-unsubscribe@freebsd.org" > : > : > From free.dvig at gmail.com Sun Oct 12 14:52:38 2008 From: free.dvig at gmail.com (Aleksandr Litvinov) Date: Sun Oct 12 14:52:45 2008 Subject: Realtek network driver Message-ID: <65f70ae30810120726p14dcf5f3m3284ffa1e506e261@mail.gmail.com> Hi, Let's ask. Why in cvsweb existing a two drivers for network interface realtek: rl & re? They can be united? What objective reasons prevent to make? -- -- Good Luck. -- Litvinov Aleksandr. From unixmania at gmail.com Sun Oct 12 15:36:56 2008 From: unixmania at gmail.com (Carlos A. M. dos Santos) Date: Sun Oct 12 15:37:02 2008 Subject: Realtek network driver In-Reply-To: <65f70ae30810120726p14dcf5f3m3284ffa1e506e261@mail.gmail.com> References: <65f70ae30810120726p14dcf5f3m3284ffa1e506e261@mail.gmail.com> Message-ID: On Sun, Oct 12, 2008 at 12:26 PM, Aleksandr Litvinov wrote: > Hi, > Let's ask. Why in cvsweb existing a two drivers for network interface > realtek: rl & re? They can be united? What objective reasons prevent > to make? The drivers are for different card/chipset models. Please see man if_rl man if_re Summary: rl -- RealTek 8129/8139 Fast Ethernet device driver re -- RealTek 8139C+/8169/816xS/811xS/8101E PCI/PCIe Ethernet adapter driver -- cd /usr/ports/sysutils/life make clean From imp at bsdimp.com Sun Oct 12 22:34:02 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Sun Oct 12 22:34:08 2008 Subject: Realtek network driver In-Reply-To: References: <65f70ae30810120726p14dcf5f3m3284ffa1e506e261@mail.gmail.com> Message-ID: <20081012.163350.-1625872236.imp@bsdimp.com> In message: "Carlos A. M. dos Santos" writes: : On Sun, Oct 12, 2008 at 12:26 PM, Aleksandr Litvinov : wrote: : > Hi, : > Let's ask. Why in cvsweb existing a two drivers for network interface : > realtek: rl & re? They can be united? What objective reasons prevent : > to make? : : The drivers are for different card/chipset models. Please see : : man if_rl : man if_re : : Summary: : : rl -- RealTek 8129/8139 Fast Ethernet device driver : re -- RealTek 8139C+/8169/816xS/811xS/8101E PCI/PCIe Ethernet : adapter driver The simpler driver was for a device that was fairly low end for its time, so needed a lot of quirks and workarounds. The higher end driver for re eliminates those quirks and uses more of the hardware functions. There's some code shared between the two drivers. Warner From bu7cher at yandex.ru Wed Oct 15 12:31:57 2008 From: bu7cher at yandex.ru (Andrey V. Elsukov) Date: Wed Oct 15 12:32:04 2008 Subject: Realtek network driver In-Reply-To: <65f70ae30810120726p14dcf5f3m3284ffa1e506e261@mail.gmail.com> References: <65f70ae30810120726p14dcf5f3m3284ffa1e506e261@mail.gmail.com> Message-ID: <48F5E29B.3030609@yandex.ru> Aleksandr Litvinov wrote: > Hi, > Let's ask. Why in cvsweb existing a two drivers for network interface > realtek: rl & re? They can be united? What objective reasons prevent > to make? There is some explanations: http://lists.freebsd.org/pipermail/freebsd-stable/2008-July/043522.html -- WBR, Andrey V. Elsukov From free.dvig at gmail.com Thu Oct 16 03:11:02 2008 From: free.dvig at gmail.com (Aleksandr Litvinov) Date: Thu Oct 16 03:11:09 2008 Subject: =?koi8-r?b?79TXxdQ6IFJlYWx0ZWsgbmV0d29yayBkcml2ZXI=?= In-Reply-To: <48F5E29B.3030609@yandex.ru> References: <65f70ae30810120726p14dcf5f3m3284ffa1e506e261@mail.gmail.com> <48F5E29B.3030609@yandex.ru> Message-ID: <65f70ae30810152011t65efa4efqefce3631eb2d1950@mail.gmail.com> Thank for informations. 2008/10/15, Andrey V. Elsukov : > Aleksandr Litvinov wrote: >> Hi, >> Let's ask. Why in cvsweb existing a two drivers for network interface >> realtek: rl & re? They can be united? What objective reasons prevent >> to make? > > There is some explanations: > http://lists.freebsd.org/pipermail/freebsd-stable/2008-July/043522.html > > -- > WBR, Andrey V. Elsukov > -- -- Good Luck. -- Litvinov Aleksandr. From asmodai at in-nomine.org Thu Oct 16 15:06:32 2008 From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven) Date: Thu Oct 16 15:06:38 2008 Subject: [Info required] PC Architecture In-Reply-To: References: Message-ID: <20081016144813.GY98121@nexus.in-nomine.org> -On [20081016 16:43], Srinivas (mboxindia@gmail.com) wrote: >I have a theoretical understanding of the PC architecture and the >details but have no idea of how things go under the hood(for a real >computer). http://www.amazon.com/dp/0123706068/ - Computer Organization and Design: The Hardware/Software Interface by Patterson and Hennessy http://www.amazon.com/dp/0131485210/ - Structured Computer Organization by Tanenbaum That should answer most, if not all, of your questions on that subject. -- Jeroen Ruigrok van der Werven / asmodai ????? ?????? ??? ?? ?????? http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Seek not death in the error of your life: and pull not upon yourselves destruction with the works of your hands... From mboxindia at gmail.com Thu Oct 16 15:12:57 2008 From: mboxindia at gmail.com (Srinivas) Date: Thu Oct 16 15:13:03 2008 Subject: [Info required] PC Architecture Message-ID: Hello, I have a theoretical understanding of the PC architecture and the details but have no idea of how things go under the hood(for a real computer). I think it would be very useful for me(as well as beginners) to know how things work real-time. Even though it is not a correct mailing list, I am posting this because you guys are the real hackers and know a lot about how things work inside. I would like to know about the following. Plz add anything which you think will be helpful for the beginners. 1. Schematic diagrams of motherboards 2. How a bios detects various kinds of buses 3. How bios and os detects the different devices present in the system and what are their capabilities 4. How interrupts are routed inside 5. Groups where we can communicate related information I searched a lot in the internet but I am not able to find a good place or info that gives the detailed information. Thanks, Srinivas From a.smith at ukgrid.net Thu Oct 16 17:34:37 2008 From: a.smith at ukgrid.net (andys) Date: Thu Oct 16 17:34:43 2008 Subject: mpt errors QUEUE FULL EVENT, freebsd 7.0 on dell 1950 Message-ID: Hi, Im seeing repeated errors relating to the mpt driver in my messages file on FreeBSD 7.0-RELEASE-p5. The server is a dell 1950. The error is: kernel: mpt0: QUEUE FULL EVENT: Bus 0x00 Target 0x08 Depth 122 The hardware info from pciconf is: hdr=0x00 vendor = 'Intel Corporation' device = '82801IB/IR/IH (ICH9 Family) 2 port Serial ATA Storage Controller 2' class = mass storage subclass = ATA mpt0@pci0:5:0:0: class=0x010000 card=0x1f0e1028 chip=0x00581000 rev=0x08 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' device = 'SAS 3000 series, 8-port with 1068E -StorPort' class = mass storage subclass = SCSI Im not sure how you upgrade drivers in freebsd, but I believe mpt is in the kernel so I have tried upgrading using freebsd-update which took me to release p5 but I still have the same problem. Can anyone help? thanks alot! Andy. From delphij at delphij.net Thu Oct 16 18:52:33 2008 From: delphij at delphij.net (Xin LI) Date: Thu Oct 16 18:52:41 2008 Subject: mpt errors QUEUE FULL EVENT, freebsd 7.0 on dell 1950 In-Reply-To: References: Message-ID: <48F78D65.4080600@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 andys wrote: > Hi, > > Im seeing repeated errors relating to the mpt driver in my messages > file on FreeBSD 7.0-RELEASE-p5. The server is a dell 1950. The error is: > kernel: mpt0: QUEUE FULL EVENT: Bus 0x00 Target 0x08 Depth 122 > The hardware info from pciconf is: > hdr=0x00 > vendor = 'Intel Corporation' > device = '82801IB/IR/IH (ICH9 Family) 2 port Serial ATA Storage > Controller 2' > class = mass storage > subclass = ATA > mpt0@pci0:5:0:0: class=0x010000 card=0x1f0e1028 chip=0x00581000 > rev=0x08 hdr=0x00 > vendor = 'LSI Logic (Was: Symbios Logic, NCR)' > device = 'SAS 3000 series, 8-port with 1068E -StorPort' > class = mass storage > subclass = SCSI > Im not sure how you upgrade drivers in freebsd, but I believe mpt is in > the kernel so I have tried upgrading using freebsd-update which took me > to release p5 but I still have the same problem. > Can anyone help? > thanks alot! > Andy. As a workaround I think you can do 'camcontrol tags -N 120 da0' (repeat for all disks connected through mpt)? There are rumors saying that this was caused by some firmware issue and one need to update firmwares of his hard disk, but I have not tested it myself. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkj3jWUACgkQi+vbBBjt66DiYACgiRm1V07TijHRCTXsWjkoizDO J30AoJHihzows7GwlgMY26J3UkTUBHSX =4VFt -----END PGP SIGNATURE----- From alfred at freebsd.org Sat Oct 18 01:07:20 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Sat Oct 18 01:07:26 2008 Subject: [Info required] PC Architecture In-Reply-To: <20081016144813.GY98121@nexus.in-nomine.org> References: <20081016144813.GY98121@nexus.in-nomine.org> Message-ID: <20081018004900.GB5651@elvis.mu.org> * Jeroen Ruigrok van der Werven [081016 08:06] wrote: > -On [20081016 16:43], Srinivas (mboxindia@gmail.com) wrote: > >I have a theoretical understanding of the PC architecture and the > >details but have no idea of how things go under the hood(for a real > >computer). > > http://www.amazon.com/dp/0123706068/ - Computer Organization and Design: The > Hardware/Software Interface by Patterson and Hennessy > > http://www.amazon.com/dp/0131485210/ - Structured Computer Organization by > Tanenbaum > > That should answer most, if not all, of your questions on that subject. I also REALLY like: The 8088 Project Book http://www.amazon.com/8088-Project-Book-Robert-Grossblatt/dp/0830631712 Although this isn't a real PC, it will give a nice start in case more technical stuff it too much too soon. From sandiegobiker at gmail.com Sun Oct 19 14:49:32 2008 From: sandiegobiker at gmail.com (Len Gross) Date: Sun Oct 19 14:49:39 2008 Subject: Polling and Sleep in a Driver Message-ID: <27cb3ada0810190720u2cc84097w2ed6425bc6ee8d3f@mail.gmail.com> I have a MAC protocol written using Netgraph. It runs in userland and uses a simple poll, sleep loop. It has proved that the algorithms are correct, but the sleeps are not regular/accurate enough for my purposes. (I have pushed Hz up quite a bit with no real effect) If I were to implement the algorithms within a driver would the sleeps still suffer from the same "non real-time" behaviour I see in userland? Thanks in advance. -- Len From imp at bsdimp.com Sun Oct 19 17:55:18 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Sun Oct 19 17:55:25 2008 Subject: Polling and Sleep in a Driver In-Reply-To: <27cb3ada0810190720u2cc84097w2ed6425bc6ee8d3f@mail.gmail.com> References: <27cb3ada0810190720u2cc84097w2ed6425bc6ee8d3f@mail.gmail.com> Message-ID: <20081019.115515.-1350513661.imp@bsdimp.com> In message: <27cb3ada0810190720u2cc84097w2ed6425bc6ee8d3f@mail.gmail.com> "Len Gross" writes: : I have a MAC protocol written using Netgraph. It runs in userland : and uses a simple poll, sleep loop. It has proved that the algorithms : are correct, but the sleeps are not regular/accurate enough for my : purposes. (I have pushed Hz up quite a bit with no real effect) This surprises me. I've seen big effects going from 100Hz to 1000Hz. : If I were to implement the algorithms within a driver would the sleeps : still suffer from the same "non real-time" behaviour I see in : userland? Well, it depends on what you are seeing. How accurate a sleep do you need? I've discovered that 2 / HZ is a good lower bound for sleep inaccuracy in the kernel. Often times this won't matter. You may be able to push the bounds with some clever hacks, but it still won't get you below 1/Hz w/o some other interrupt source that can clock a higher res timer. Warner From sandiegobiker at gmail.com Sun Oct 19 19:28:35 2008 From: sandiegobiker at gmail.com (Len Gross) Date: Sun Oct 19 19:28:42 2008 Subject: Polling and Sleep in a Driver Message-ID: <27cb3ada0810191228y2cf4ba5end071263f6d2f93df@mail.gmail.com> Warner, Thanks so much for your response. This is really a case where I'm a bit over my head! I thought on a a "busy" machine, there was a fundamental "no uppper bound" on the wait on a sleep; independent of the Hz? Not real-time blah, blah, ...... I am trying to understand if a driver "sleep" gets special attention (i.e higher "priority") so that I see less slop in the timing. Of course, I could hack up a driver and try some tests, but wanted some advice before diving into that pool. Thanks again. -- Len From sandiegobiker at gmail.com Sun Oct 19 19:32:00 2008 From: sandiegobiker at gmail.com (Len Gross) Date: Sun Oct 19 19:32:15 2008 Subject: Polling and Sleep in a Driver Message-ID: <27cb3ada0810191231v3f1fc510tf152c70b658a78a1@mail.gmail.com> Warner, Thanks so much for your response. This is really a case where I'm a bit over my head! I thought on a a "busy" machine, there was a fundamental "no uppper bound" on the wait on a sleep; independent of the Hz? Not real-time blah, blah, ...... I am trying to understand if a driver "sleep" gets special attention (i.e higher "priority") so that I see less slop in the timing. Of course, I could hack up a driver and try some tests, but wanted some advice before diving into that pool. Thanks again. -- Len From a.smith at ukgrid.net Mon Oct 20 14:01:27 2008 From: a.smith at ukgrid.net (andys) Date: Mon Oct 20 14:01:35 2008 Subject: mpt errors QUEUE FULL EVENT, freebsd 7.0 on dell 1950 In-Reply-To: <48F78D65.4080600@delphij.net> References: <48F78D65.4080600@delphij.net> Message-ID: Thanks for the reply, Ill feed back when Im able to get the latest firmware installed and tested, Andy. From alfred at freebsd.org Mon Oct 20 17:40:51 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Mon Oct 20 17:40:58 2008 Subject: Polling and Sleep in a Driver In-Reply-To: <27cb3ada0810190720u2cc84097w2ed6425bc6ee8d3f@mail.gmail.com> References: <27cb3ada0810190720u2cc84097w2ed6425bc6ee8d3f@mail.gmail.com> Message-ID: <20081020174051.GM22503@elvis.mu.org> * Len Gross [081019 07:49] wrote: > I have a MAC protocol written using Netgraph. It runs in userland > and uses a simple poll, sleep loop. It has proved that the algorithms > are correct, but the sleeps are not regular/accurate enough for my > purposes. (I have pushed Hz up quite a bit with no real effect) > > If I were to implement the algorithms within a driver would the sleeps > still suffer from the same "non real-time" behaviour I see in > userland? > > Thanks in advance. Try hooking hardclock(), just be careful. -Alfred From alfred at freebsd.org Mon Oct 20 17:42:03 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Mon Oct 20 17:42:09 2008 Subject: Polling and Sleep in a Driver In-Reply-To: <27cb3ada0810191228y2cf4ba5end071263f6d2f93df@mail.gmail.com> References: <27cb3ada0810191228y2cf4ba5end071263f6d2f93df@mail.gmail.com> Message-ID: <20081020174203.GN22503@elvis.mu.org> * Len Gross [081019 12:28] wrote: > Warner, > > Thanks so much for your response. This is really a case where I'm a > bit over my head! > > I thought on a a "busy" machine, there was a fundamental "no uppper > bound" on the wait on a sleep; independent of the Hz? Not real-time > blah, blah, ...... > > I am trying to understand if a driver "sleep" gets special attention > (i.e higher "priority") so that I see less slop in the timing. > > Of course, I could hack up a driver and try some tests, but wanted > some advice before diving into that pool. > > Thanks again. Yes, you should see less slop in a driver because the ithread priority will be much higher than userland. The reason your userland is getting jitter is because other things may be running before it is based on priority. -Alfred From ndenev at gmail.com Tue Oct 21 14:45:44 2008 From: ndenev at gmail.com (Nikolay Denev) Date: Tue Oct 21 14:45:55 2008 Subject: Moschip USB Ethernet support Message-ID: <2CF947E1-C13C-4CAE-82B8-59C7ADD59387@gmail.com> Hi, Moship seem to have BSD licensed FreeBSD drivers for their hardware on their site : http://www.moschip.com/html/download_drivers.html Any reason these are not included in the tree? -- Regards, Nikolay Denev From mboxindia at gmail.com Wed Oct 22 06:46:56 2008 From: mboxindia at gmail.com (Srinivas) Date: Wed Oct 22 06:47:03 2008 Subject: [Info] Device detection Message-ID: Hello, I have been very curious about how devices are detected in a system under FreeBSD ... AFAIK, root_bus is added during system startup through "SI_SUB_DRIVERS" subsystem of SYSINIT mechanism. After that how the buses are detected and added and how the devices under each bus are detected and added to the kernel. Could someone plz explain or point out a link which has the explanation. Thanks for your time, Srinivas From raykinsella78 at gmail.com Fri Oct 31 09:21:11 2008 From: raykinsella78 at gmail.com (Ray Kinsella) Date: Fri Oct 31 09:21:18 2008 Subject: PMCStat and KGMon on 6.2 Message-ID: <584ec6bb0810310854na4da67eud9b95ad35c14942e@mail.gmail.com> Has anyone had any success profiling kernel objects on FreeBSD 6.2 ? I have tried using the PMCStat and kgmon to profile loadable kernel objects with no sucess, to get a handle on the source of a performance bottleneck. PMCStat supports profiling ko's in 7.0 but not 6.2, Kgmon suggests that profiling kernel objects should be possible in 6.2, but I have had no success with it. Any documentation I have seen suggests compiling the sources straight into the kernel rather than using ko's to profile, but unfortunately this is not possible. Has anyone had any luck profiling ko's in 6.2. Thanks Ray Kinsella