Re: use_generic and usb probing
on 03/04/2011 13:46 Andriy Gapon said the following: Mostly out of curiosity (but not only because of that) I wonder why the use_generic flag and two probing passes are needed in USB driver probing code. That is, why the standard approach of using different probing return values (e.g. BUS_PROBE_DEFAULT, BUS_PROBE_GENERIC, etc) wouldn't work here. I couldn't find any historic reason for this, so I am assuming that this is a kludge to work-around inconsistent return values in various USB newbus probe routines. Please see here my attempt at cleaning up the basics: http://people.freebsd.org/~avg/usb-use_generic.diff Reviews and testing are welcome. P.S. A side-effect of this patch is removal of a minor annoyance in a form of the following message: Unknown USB device: vendor product bus The message is produced by devd almost any time anything is connected via USB thanks to (1) a nomatch USB entry in the default devd.conf; (2) use_generic=0 probing pass in USB. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: use_generic and usb probing
On Tuesday 05 April 2011 13:06:22 Andriy Gapon wrote: on 03/04/2011 13:46 Andriy Gapon said the following: Mostly out of curiosity (but not only because of that) I wonder why the use_generic flag and two probing passes are needed in USB driver probing code. That is, why the standard approach of using different probing return values (e.g. BUS_PROBE_DEFAULT, BUS_PROBE_GENERIC, etc) wouldn't work here. I couldn't find any historic reason for this, so I am assuming that this is a kludge to work-around inconsistent return values in various USB newbus probe routines. Please see here my attempt at cleaning up the basics: http://people.freebsd.org/~avg/usb-use_generic.diff Reviews and testing are welcome. P.S. A side-effect of this patch is removal of a minor annoyance in a form of the following message: Unknown USB device: vendor product bus The message is produced by devd almost any time anything is connected via USB thanks to (1) a nomatch USB entry in the default devd.conf; (2) use_generic=0 probing pass in USB. Hi, In the initial USB stack design drivers are supposed to either report match or non-match. The reason for this is that sometimes parameters are passed on from the probe to the attach via the USB attach args. See usbd_lookup_id_by_uaa(). When multiple drivers are probed and match, the information presented by the usb_attach_arg's can get messed up with regard to the attaching driver. It would be better if the newbus could support a probing priority argument! --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Any success stories for HAST + ZFS?
On Mon, 4 Apr 2011 11:08:16 -0700 Freddie Cash wrote: FC On Sat, Apr 2, 2011 at 1:44 AM, Pawel Jakub Dawidek p...@freebsd.org wrote: I just committed a fix for a problem that might look like a deadlock. With trociny@ patch and my last fix (to GEOM GATE and hastd) do you still have any issues? FC Just to confirm, this is commit r220264, 220265, 220266 to -CURRENT? Yes, r220264 and 220266. As it is stated in the commit log MFC is planned after 1 week. -- Mikolaj Golub ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: use_generic and usb probing
on 05/04/2011 14:21 Hans Petter Selasky said the following: On Tuesday 05 April 2011 13:06:22 Andriy Gapon wrote: on 03/04/2011 13:46 Andriy Gapon said the following: Mostly out of curiosity (but not only because of that) I wonder why the use_generic flag and two probing passes are needed in USB driver probing code. That is, why the standard approach of using different probing return values (e.g. BUS_PROBE_DEFAULT, BUS_PROBE_GENERIC, etc) wouldn't work here. I couldn't find any historic reason for this, so I am assuming that this is a kludge to work-around inconsistent return values in various USB newbus probe routines. Please see here my attempt at cleaning up the basics: http://people.freebsd.org/~avg/usb-use_generic.diff Reviews and testing are welcome. P.S. A side-effect of this patch is removal of a minor annoyance in a form of the following message: Unknown USB device: vendor product bus The message is produced by devd almost any time anything is connected via USB thanks to (1) a nomatch USB entry in the default devd.conf; (2) use_generic=0 probing pass in USB. Hi, In the initial USB stack design drivers are supposed to either report match or non-match. The reason for this is that sometimes parameters are passed on from the probe to the attach via the USB attach args. See usbd_lookup_id_by_uaa(). When multiple drivers are probed and match, the information presented by the usb_attach_arg's can get messed up with regard to the attaching driver. It would be better if the newbus could support a probing priority argument! I believe that newbus already supports ordering of children on a bus. BTW, does USB have to pass anything from probe to attach? Duplicate lookup is of course not very nice, but duplicate probing pass is not nice either. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: use_generic and usb probing
On Tuesday 05 April 2011 14:50:43 Andriy Gapon wrote: I believe that newbus already supports ordering of children on a bus. BTW, does USB have to pass anything from probe to attach? Mostly only the driver info field. To avoid duplicate lookups. Duplicate lookup is of course not very nice, but duplicate probing pass is not nice either. This can all be avoided if the bus-drivers are sorted correctly before probing! --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: use_generic and usb probing
on 05/04/2011 15:55 Hans Petter Selasky said the following: On Tuesday 05 April 2011 14:50:43 Andriy Gapon wrote: I believe that newbus already supports ordering of children on a bus. BTW, does USB have to pass anything from probe to attach? Mostly only the driver info field. To avoid duplicate lookups. Duplicate lookup is of course not very nice, but duplicate probing pass is not nice either. This can all be avoided if the bus-drivers are sorted correctly before probing! Well, I think that that's what probe priorities actually for. I also think that typically ivars should be set by a bus driver. So maybe it's not such a good idea to pass data from probe to attach via ivars in child drivers. But I could be mistaken about that. Practically speaking, you most likely don't have to worry about that for drivers that return BUS_PROBE_SPECIFIC (=0) from their probe methods. And there is only a few generic drivers that can be handled on a case by case basis. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Any success stories for HAST + ZFS?
On Tue, Apr 5, 2011 at 5:05 AM, Mikolaj Golub troc...@freebsd.org wrote: On Mon, 4 Apr 2011 11:08:16 -0700 Freddie Cash wrote: FC On Sat, Apr 2, 2011 at 1:44 AM, Pawel Jakub Dawidek p...@freebsd.org wrote: I just committed a fix for a problem that might look like a deadlock. With trociny@ patch and my last fix (to GEOM GATE and hastd) do you still have any issues? FC Just to confirm, this is commit r220264, 220265, 220266 to -CURRENT? Yes, r220264 and 220266. As it is stated in the commit log MFC is planned after 1 week. Okay. I'll keep an eye out next week for the MFC of those patches to hit -STABLE, and do an upgrade/test cycle after that point. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: KGDB stack traces in the kernel.
On 4/4/11 6:04 PM, Justin Hibbits wrote: On Apr 4, 2011, at 6:57 PM, Julian Elischer wrote: is there anyone here with enough gdb/kgdb source experience to know what we would need to put on the stack at fork_exit() to make it stop when it gets there? not only is it annoying but it slows down debugging because kgdb and the ddd front end ask for stacks a LOT. sometimes it actually just hangs as the stack goes into a loop and never ends. I had a quick look but didn't spot how gdb decides it has reached the end of a stack. Julian From my experience, it checks for a NULL stack chain pointer. Once that reaches NULL, it's the end of the stack. - Justin I'll try adding NULL when we build the intial stack up. :-) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: KGDB stack traces in the kernel.
On Tue, Apr 5, 2011 at 1:33 PM, Julian Elischer jul...@freebsd.org wrote: On 4/4/11 6:04 PM, Justin Hibbits wrote: On Apr 4, 2011, at 6:57 PM, Julian Elischer wrote: is there anyone here with enough gdb/kgdb source experience to know what we would need to put on the stack at fork_exit() to make it stop when it gets there? not only is it annoying but it slows down debugging because kgdb and the ddd front end ask for stacks a LOT. sometimes it actually just hangs as the stack goes into a loop and never ends. I had a quick look but didn't spot how gdb decides it has reached the end of a stack. Julian From my experience, it checks for a NULL stack chain pointer. Once that reaches NULL, it's the end of the stack. - Justin I'll try adding NULL when we build the intial stack up. :-) What does ddb do? It always seems to get this stuff correct. Navdeep ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: KGDB stack traces in the kernel.
On 4/5/11 1:35 PM, Navdeep Parhar wrote: On Tue, Apr 5, 2011 at 1:33 PM, Julian Elischerjul...@freebsd.org wrote: On 4/4/11 6:04 PM, Justin Hibbits wrote: On Apr 4, 2011, at 6:57 PM, Julian Elischer wrote: is there anyone here with enough gdb/kgdb source experience to know what we would need to put on the stack at fork_exit() to make it stop when it gets there? not only is it annoying but it slows down debugging because kgdb and the ddd front end ask for stacks a LOT. sometimes it actually just hangs as the stack goes into a loop and never ends. I had a quick look but didn't spot how gdb decides it has reached the end of a stack. Julian From my experience, it checks for a NULL stack chain pointer. Once that reaches NULL, it's the end of the stack. - Justin I'll try adding NULL when we build the intial stack up. :-) What does ddb do? It always seems to get this stuff correct. Navdeep it has all sorts of special code that knows the intricacies of freebsd's stack. (k)gdb only knows more generic stuff. hmmm set 0 into the saved ebp bit that didn't help.. I'll play a bit more ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
kernel thread creation cleanup
I was just looking in the thread creation code after most of a decade NOT looking at it.. boy we really need to go through there with a broom.. the cobwebs are getting thick. Like we always call the code to put an upcall, even though we don't have upcalls any more, and we always create an trap frame on the stack even when we are making kernel threads that don't need it, actually, come to think of it DOES fork even need it? (need to go look) and we go through the fork trampoline even when we are doing kthread creation and could just as well go directly to the final function directly. (All of the above on amd64).. May be slighly different on other hardware, though much of it is encoded in MI code so probably not. This came from looking to see if I could somehow munge the stack to convince kgdb to damn well stop at that point (still failed. if anyone has ideas... :-) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
