usb_id segfaulting on 2.6.23

usb_id segfaulting on 2.6.23

[Daniel Drake]

Hi,

Since upgrading to 2.6.23, usb_id is segfaulting when dealing with my 
input devices. I'm using udev-116. I can get an instant segfault simply 
by replugging my keyboard.

I have dug around a bit. The segfault happens inside usb_id, see the 
"fallback" section.

It reaches here:
		dbg("No USB vendor information available\n");
		sprintf(vendor_str,"0000");

then a few lines later:

		set_str(vendor_str,usb_vendor, sizeof(vendor_str) - 1);

usb_vendor is NULL. set_str does various string manipulations with this 
NULL pointer which causes the segfault.

I suggest fixing this by replacing the sprintf line with:
	usb_vendor = "0000";

The same bug exists a few lines below with the USB model handling.


Now for what actually caused the change in behaviour: the devpath passed 
to usb_id has changed between 2.6.22 and 2.6.23.

In 2.6.22, it was /class/input/input4/event2 and I would get this output:

> # /lib/udev/usb_id /class/input/input4/event2
> Microsoft_Microsoft_Keyboard_with_Fingerprint_Reader_{3A1B506A-BB77-444C-851B-C424997B2763}
> ID_VENDOR=Microsoft
> ID_MODEL=Microsoft_Keyboard_with_Fingerprint_Reader
> ID_REVISION\x0100
> ID_SERIAL=Microsoft_Microsoft_Keyboard_with_Fingerprint_Reader_{3A1B506A-BB77-444C-851B-C424997B2763}
> ID_SERIAL_SHORT={3A1B506A-BB77-444C-851B-C424997B2763}
> ID_TYPE=hid
> ID_BUS=usb

In 2.6.23 the devpath now provided to usb_id is 
/devices/pci0000:00/0000:00:02.0/usb2/2-2/2-2:1.0/input/input13/event2

After applying my segfault fixes I get the following from usb_id:
> # /lib/udev/usb_id /devices/pci0000:00/0000:00:02.0/usb2/2-2/2-21.0/input/input13/event2
> 0000_0000

Why has the devpath changed? Is this a kernel bug for breaking userspace 
compat? Or should usb_id just be adapted to be able to handle both types 
of devpath?

Thanks!
Daniel


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: usb_id segfaulting on 2.6.23

[Kay Sievers]

On 10/15/07, Daniel Drake <dsd@gentoo.org> wrote:
> Since upgrading to 2.6.23, usb_id is segfaulting when dealing with my
> input devices. I'm using udev-116. I can get an instant segfault simply
> by replugging my keyboard.
>
> I have dug around a bit. The segfault happens inside usb_id, see the
> "fallback" section.
>
> It reaches here:
>                 dbg("No USB vendor information available\n");
>                 sprintf(vendor_str,"0000");
>
> then a few lines later:
>
>                 set_str(vendor_str,usb_vendor, sizeof(vendor_str) - 1);
>
> usb_vendor is NULL. set_str does various string manipulations with this
> NULL pointer which causes the segfault.
>
> I suggest fixing this by replacing the sprintf line with:
>         usb_vendor = "0000";

That's clearly a silly bug in usb_id. We should never return any 0000
values and just fail completely instead. No idea why such crap is in
there, it needs to be removed.

> The same bug exists a few lines below with the USB model handling.

I'll go fix up the mess here. Thanks for debugging this.

> Now for what actually caused the change in behaviour: the devpath passed
> to usb_id has changed between 2.6.22 and 2.6.23.
>
> In 2.6.22, it was /class/input/input4/event2 and I would get this output:
>
> > # /lib/udev/usb_id /class/input/input4/event2
> > Microsoft_Microsoft_Keyboard_with_Fingerprint_Reader_{3A1B506A-BB77-444C-851B-C424997B2763}
> > ID_VENDOR=Microsoft
> > ID_MODEL=Microsoft_Keyboard_with_Fingerprint_Reader
> > ID_REVISION\x0100
> > ID_SERIAL=Microsoft_Microsoft_Keyboard_with_Fingerprint_Reader_{3A1B506A-BB77-444C-851B-C424997B2763}
> > ID_SERIAL_SHORT={3A1B506A-BB77-444C-851B-C424997B2763}
> > ID_TYPE=hid
> > ID_BUS=usb
>
> In 2.6.23 the devpath now provided to usb_id is
> /devices/pci0000:00/0000:00:02.0/usb2/2-2/2-2:1.0/input/input13/event2
>
> After applying my segfault fixes I get the following from usb_id:
> > # /lib/udev/usb_id /devices/pci0000:00/0000:00:02.0/usb2/2-2/2-21.0/input/input13/event2
> > 0000_0000
>
> Why has the devpath changed? Is this a kernel bug for breaking userspace
> compat? Or should usb_id just be adapted to be able to handle both types
> of devpath?

It's fine, "input" uses the unified sysfs tree now. If you don't
configure CONFIG_SYSFS_DEPRECATED, you will have all devices in
/sys/devices instead of spreaded around in several places. Usb_id must
be fixed, the kernel is fine.

Thanks,
Kay

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: usb_id segfaulting on 2.6.23

[Kay Sievers]

On 10/15/07, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On 10/15/07, Daniel Drake <dsd@gentoo.org> wrote:
> > Since upgrading to 2.6.23, usb_id is segfaulting when dealing with my
> > input devices. I'm using udev-116. I can get an instant segfault simply
> > by replugging my keyboard.
> >
> > I have dug around a bit. The segfault happens inside usb_id, see the
> > "fallback" section.
> >
> > It reaches here:
> >                 dbg("No USB vendor information available\n");
> >                 sprintf(vendor_str,"0000");
> >
> > then a few lines later:
> >
> >                 set_str(vendor_str,usb_vendor, sizeof(vendor_str) - 1);
> >
> > usb_vendor is NULL. set_str does various string manipulations with this
> > NULL pointer which causes the segfault.
> >
> > I suggest fixing this by replacing the sprintf line with:
> >         usb_vendor = "0000";
>
> That's clearly a silly bug in usb_id. We should never return any 0000
> values and just fail completely instead. No idea why such crap is in
> there, it needs to be removed.
>
> > The same bug exists a few lines below with the USB model handling.
>
> I'll go fix up the mess here. Thanks for debugging this.
>
> > Now for what actually caused the change in behaviour: the devpath passed
> > to usb_id has changed between 2.6.22 and 2.6.23.
> >
> > In 2.6.22, it was /class/input/input4/event2 and I would get this output:
> >
> > > # /lib/udev/usb_id /class/input/input4/event2
> > > Microsoft_Microsoft_Keyboard_with_Fingerprint_Reader_{3A1B506A-BB77-444C-851B-C424997B2763}
> > > ID_VENDOR=Microsoft
> > > ID_MODEL=Microsoft_Keyboard_with_Fingerprint_Reader
> > > ID_REVISION\x0100
> > > ID_SERIAL=Microsoft_Microsoft_Keyboard_with_Fingerprint_Reader_{3A1B506A-BB77-444C-851B-C424997B2763}
> > > ID_SERIAL_SHORT={3A1B506A-BB77-444C-851B-C424997B2763}
> > > ID_TYPE=hid
> > > ID_BUS=usb
> >
> > In 2.6.23 the devpath now provided to usb_id is
> > /devices/pci0000:00/0000:00:02.0/usb2/2-2/2-2:1.0/input/input13/event2
> >
> > After applying my segfault fixes I get the following from usb_id:
> > > # /lib/udev/usb_id /devices/pci0000:00/0000:00:02.0/usb2/2-2/2-21.0/input/input13/event2
> > > 0000_0000

Hmm, works fine here with my USB keyboard. Can you provide the output of:
  udevinfo -a -p <devpath>
for the failing setup?

Thanks,
Kay

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: usb_id segfaulting on 2.6.23

[Daniel Drake]

Kay Sievers wrote:
> Hmm, works fine here with my USB keyboard. Can you provide the output of:
>   udevinfo -a -p <devpath>
> for the failing setup?


# udevinfo -a -p 
/devices/pci0000:00/0000:00:02.0/usb2/2-2/2-2:1.0/input/input2/event2

Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

   looking at device 
'/devices/pci0000:00/0000:00:02.0/usb2/2-2/2-2:1.0/input/input2/event2':
     KERNEL="event2"
     SUBSYSTEM="input"
     DRIVER=""
     ATTR{dev}="13:66"

   looking at parent device 
'/devices/pci0000:00/0000:00:02.0/usb2/2-2/2-2:1.0/input/input2':
     KERNELS="input2"
     SUBSYSTEMS="input"
     DRIVERS=""
 
ATTRS{modalias}="input:b0003v045Ep00BBe0111-e0,1,11,14,k71,72,73,74,75,77,79,7A,7B,7C,7D,7E,7F,80,81,82,83,84,85,86,87,88,89,8A,B7,B8,B9,BA,BB,BC,BD,BE,BF,C0,C1,C2,F0,raml0,1,2,8,sfw"
     ATTRS{uniq}="_3A1B506A-BB77-444C-851B-C424997B2763_"
     ATTRS{phys}="usb-0000:00:02.0-2/input0"

   looking at parent device 
'/devices/pci0000:00/0000:00:02.0/usb2/2-2/2-2:1.0/input':
     KERNELS="input"
     SUBSYSTEMS=""
     DRIVERS=""

   looking at parent device 
'/devices/pci0000:00/0000:00:02.0/usb2/2-2/2-2:1.0':
     KERNELS="2-2:1.0"
     SUBSYSTEMS="usb"
     DRIVERS="usbhid"
     ATTRS{modalias}="usb:v045Ep00BBd0100dc00dsc00dp00ic03isc01ip01"
     ATTRS{bInterfaceProtocol}="01"
     ATTRS{bInterfaceSubClass}="01"
     ATTRS{bInterfaceClass}="03"
     ATTRS{bNumEndpoints}="01"
     ATTRS{bAlternateSetting}=" 0"
     ATTRS{bInterfaceNumber}="00"

   looking at parent device '/devices/pci0000:00/0000:00:02.0/usb2/2-2':
     KERNELS="2-2"
     SUBSYSTEMS="usb"
     DRIVERS="usb"
     ATTRS{dev}="189:129"

   looking at parent device '/devices/pci0000:00/0000:00:02.0/usb2':
     KERNELS="usb2"
     SUBSYSTEMS="usb"
     DRIVERS="usb"
     ATTRS{dev}="189:128"

   looking at parent device '/devices/pci0000:00/0000:00:02.0':
     KERNELS="0000:00:02.0"
     SUBSYSTEMS="pci"
     DRIVERS="ohci_hcd"
     ATTRS{msi_bus}=""
     ATTRS{broken_parity_status}="0"
     ATTRS{enable}="1"
 
ATTRS{modalias}="pci:v000010DEd0000036Csv0000147Bsd00001C25bc0Csc03i10"
     ATTRS{local_cpus}="ffffffff"
     ATTRS{irq}="23"
     ATTRS{class}="0x0c0310"
     ATTRS{subsystem_device}="0x1c25"
     ATTRS{subsystem_vendor}="0x147b"
     ATTRS{device}="0x036c"
     ATTRS{vendor}="0x10de"

   looking at parent device '/devices/pci0000:00':
     KERNELS="pci0000:00"
     SUBSYSTEMS=""
     DRIVERS=""
     ATTRS{uevent}=""


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: usb_id segfaulting on 2.6.23

[Kay Sievers]

On 10/15/07, Daniel Drake <dsd@gentoo.org> wrote:
> Kay Sievers wrote:
> > Hmm, works fine here with my USB keyboard. Can you provide the output of:
> >   udevinfo -a -p <devpath>
> > for the failing setup?
>
> # udevinfo -a -p
> /devices/pci0000:00/0000:00:02.0/usb2/2-2/2-2:1.0/input/input2/event2
>
> Udevinfo starts with the device specified by the devpath and then
> walks up the chain of parent devices. It prints for every device
> found, all possible attributes in the udev rules key format.
> A rule to match, can be composed by the attributes of the device
> and the attributes from one single parent device.
>
>    looking at device
> '/devices/pci0000:00/0000:00:02.0/usb2/2-2/2-2:1.0/input/input2/event2':
>      KERNEL="event2"
>      SUBSYSTEM="input"
>      DRIVER=""
>      ATTR{dev}="13:66"
>
>    looking at parent device
> '/devices/pci0000:00/0000:00:02.0/usb2/2-2/2-2:1.0/input/input2':
>      KERNELS="input2"
>      SUBSYSTEMS="input"
>      DRIVERS=""
>
> ATTRS{modalias}="input:b0003v045Ep00BBe0111-e0,1,11,14,k71,72,73,74,75,77,79,7A,7B,7C,7D,7E,7F,80,81,82,83,84,85,86,87,88,89,8A,B7,B8,B9,BA,BB,BC,BD,BE,BF,C0,C1,C2,F0,raml0,1,2,8,sfw"
>      ATTRS{uniq}="_3A1B506A-BB77-444C-851B-C424997B2763_"
>      ATTRS{phys}="usb-0000:00:02.0-2/input0"
>
>    looking at parent device
> '/devices/pci0000:00/0000:00:02.0/usb2/2-2/2-2:1.0/input':
>      KERNELS="input"
>      SUBSYSTEMS=""
>      DRIVERS=""
>
>    looking at parent device
> '/devices/pci0000:00/0000:00:02.0/usb2/2-2/2-2:1.0':
>      KERNELS="2-2:1.0"
>      SUBSYSTEMS="usb"
>      DRIVERS="usbhid"
>      ATTRS{modalias}="usb:v045Ep00BBd0100dc00dsc00dp00ic03isc01ip01"
>      ATTRS{bInterfaceProtocol}="01"
>      ATTRS{bInterfaceSubClass}="01"
>      ATTRS{bInterfaceClass}="03"
>      ATTRS{bNumEndpoints}="01"
>      ATTRS{bAlternateSetting}=" 0"
>      ATTRS{bInterfaceNumber}="00"
>
>    looking at parent device '/devices/pci0000:00/0000:00:02.0/usb2/2-2':
>      KERNELS="2-2"
>      SUBSYSTEMS="usb"
>      DRIVERS="usb"
>      ATTRS{dev}="189:129"
>
>    looking at parent device '/devices/pci0000:00/0000:00:02.0/usb2':
>      KERNELS="usb2"
>      SUBSYSTEMS="usb"
>      DRIVERS="usb"
>      ATTRS{dev}="189:128"
>
>    looking at parent device '/devices/pci0000:00/0000:00:02.0':
>      KERNELS="0000:00:02.0"
>      SUBSYSTEMS="pci"
>      DRIVERS="ohci_hcd"
>      ATTRS{msi_bus}=""
>      ATTRS{broken_parity_status}="0"
>      ATTRS{enable}="1"
>
> ATTRS{modalias}="pci:v000010DEd0000036Csv0000147Bsd00001C25bc0Csc03i10"
>      ATTRS{local_cpus}="ffffffff"
>      ATTRS{irq}="23"
>      ATTRS{class}="0x0c0310"
>      ATTRS{subsystem_device}="0x1c25"
>      ATTRS{subsystem_vendor}="0x147b"
>      ATTRS{device}="0x036c"
>      ATTRS{vendor}="0x10de"
>
>    looking at parent device '/devices/pci0000:00':
>      KERNELS="pci0000:00"
>      SUBSYSTEMS=""
>      DRIVERS=""
>      ATTRS{uevent}=""

Strange, seems some attributes are not catched by udev. What does
"udevinfo" print for the working setup? Do you see the missing
attributes there?

Kay

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: usb_id segfaulting on 2.6.23

[Kay Sievers]

On 10/15/07, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On 10/15/07, Daniel Drake <dsd@gentoo.org> wrote:
> > Since upgrading to 2.6.23, usb_id is segfaulting when dealing with my
> > input devices. I'm using udev-116. I can get an instant segfault simply
> > by replugging my keyboard.
> >
> > I have dug around a bit. The segfault happens inside usb_id, see the
> > "fallback" section.
> >
> > It reaches here:
> >                 dbg("No USB vendor information available\n");
> >                 sprintf(vendor_str,"0000");
> >
> > then a few lines later:
> >
> >                 set_str(vendor_str,usb_vendor, sizeof(vendor_str) - 1);
> >
> > usb_vendor is NULL. set_str does various string manipulations with this
> > NULL pointer which causes the segfault.
> >
> > I suggest fixing this by replacing the sprintf line with:
> >         usb_vendor = "0000";
>
> That's clearly a silly bug in usb_id. We should never return any 0000
> values and just fail completely instead.

I've removed the 0000 logic entirely, and we fail if we are unable to
retrieve the information we are looking for.

Now we only need to know what goes wrong with your keyboard. :)

Thanks again for the debugging,
Kay

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: usb_id segfaulting on 2.6.23

[Daniel Drake]

Sorry for the delayed response. I was away from this computer for a 
while, and I wanted to get a decent amount of info before we continue.

Kay Sievers wrote:
> Strange, seems some attributes are not catched by udev. What does
> "udevinfo" print for the working setup? Do you see the missing
> attributes there?

You're referring to idVendor, idProduct, etc. Actually, those attributes 
don't even exist in sysfs(!!) which must be the root of the problem.

So, I bisected the kernel. Ready for a strange result?
First bad commit is 296699de: Introduce CONFIG_SUSPEND for 
suspend-to-Ram and standby

On this system, I always disable suspend/hibernate/etc support, and 
continued to do so throughout the bisection. This lead me to the above 
result.

On a kernel tree with HEAD as 296699de, I see the bug (no idVendor, etc) 
when CONFIG_SUSPEND=n (my normal setup). However, if I set 
CONFIG_SUSPEND=y, the missing USB sysfs attributes show up!

On 2.6.24-rc1-git14, the same is true. CONFIG_SUSPEND=n, no idVendor 
nodes, udev usb_id crashes on boot. CONFIG_SUSPEND=y, idVendor and 
friends are back, udev behaves as normal.

I know you have experience working with sysfs/kobject internals, do you 
have any suggestions or thoughts before I take this to LKML?

Thanks!
Daniel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: usb_id segfaulting on 2.6.23

[Kay Sievers]

On Tue, 2007-11-06 at 00:42 +0000, Daniel Drake wrote:
> Kay Sievers wrote:
> > Strange, seems some attributes are not catched by udev. What does
> > "udevinfo" print for the working setup? Do you see the missing
> > attributes there?
> 
> You're referring to idVendor, idProduct, etc. Actually, those attributes 
> don't even exist in sysfs(!!) which must be the root of the problem.
> 
> So, I bisected the kernel. Ready for a strange result?
> First bad commit is 296699de: Introduce CONFIG_SUSPEND for 
> suspend-to-Ram and standby
> 
> On this system, I always disable suspend/hibernate/etc support, and 
> continued to do so throughout the bisection. This lead me to the above 
> result.
> 
> On a kernel tree with HEAD as 296699de, I see the bug (no idVendor, etc) 
> when CONFIG_SUSPEND=n (my normal setup). However, if I set 
> CONFIG_SUSPEND=y, the missing USB sysfs attributes show up!
> 
> On 2.6.24-rc1-git14, the same is true. CONFIG_SUSPEND=n, no idVendor 
> nodes, udev usb_id crashes on boot. CONFIG_SUSPEND=y, idVendor and 
> friends are back, udev behaves as normal.

I fixes usb_id in the meantime not to crash, but that's a different
story.

> I know you have experience working with sysfs/kobject internals, do you 
> have any suggestions or thoughts before I take this to LKML?

Oh, great, it was a complete mystery what was going wrong, maybe this is
pointing in the right direction. We got more than one report for this
bug.

Maybe Oliver or Alan have an idea, what could go wrong with the USB
attributes depending on CONFIG_SUSPEND, I don't expect a driver core
issue here.

Thanks Daniel for the debugging,
Kay


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: usb_id segfaulting on 2.6.23

[Oliver Neukum]

Am Dienstag 06 November 2007 schrieb Kay Sievers:
> On Tue, 2007-11-06 at 00:42 +0000, Daniel Drake wrote:
> > Kay Sievers wrote:
> > > Strange, seems some attributes are not catched by udev. What does
> > > "udevinfo" print for the working setup? Do you see the missing
> > > attributes there?
> > 
> > You're referring to idVendor, idProduct, etc. Actually, those attributes 
> > don't even exist in sysfs(!!) which must be the root of the problem.
> > 
> > So, I bisected the kernel. Ready for a strange result?
> > First bad commit is 296699de: Introduce CONFIG_SUSPEND for 
> > suspend-to-Ram and standby
> > 
> > On this system, I always disable suspend/hibernate/etc support, and 
> > continued to do so throughout the bisection. This lead me to the above 
> > result.
> > 
> > On a kernel tree with HEAD as 296699de, I see the bug (no idVendor, etc) 
> > when CONFIG_SUSPEND=n (my normal setup). However, if I set 
> > CONFIG_SUSPEND=y, the missing USB sysfs attributes show up!
> > 
> > On 2.6.24-rc1-git14, the same is true. CONFIG_SUSPEND=n, no idVendor 
> > nodes, udev usb_id crashes on boot. CONFIG_SUSPEND=y, idVendor and 
> > friends are back, udev behaves as normal.
> 
> I fixes usb_id in the meantime not to crash, but that's a different
> story.
> 
> > I know you have experience working with sysfs/kobject internals, do you 
> > have any suggestions or thoughts before I take this to LKML?
> 
> Oh, great, it was a complete mystery what was going wrong, maybe this is
> pointing in the right direction. We got more than one report for this
> bug.
> 
> Maybe Oliver or Alan have an idea, what could go wrong with the USB
> attributes depending on CONFIG_SUSPEND, I don't expect a driver core
> issue here.

Is bcdDevice present without CONFIG_SUSPEND? Which attributes are
present?

	Regards
		Oliver



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: usb_id segfaulting on 2.6.23

[Daniel Drake]

Oliver Neukum wrote:
> Is bcdDevice present without CONFIG_SUSPEND? Which attributes are
> present?

Without CONFIG_SUSPEND, the contents of my 
/sys/devices/pci0000:00/0000:00:02.0/usb2/2-10/ are as follows:

2-10:1.0
dev
driver
subsystem
uevent
usb_device

The missing attributes are:

authorized
bcdDevice
bConfigurationValue
bDeviceClass
bDeviceProtocol
bDeviceSubClass
bmAttributes
bMaxPacketSize0
bMaxPower
bNumConfigurations
bNumInterfaces
busnum
configuration
descriptors
devnum
ep_00
idProduct
idVendor
manufacturer
maxchild
power
product
quirks
speed
urbnum
usb_endpoint
version

Daniel


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: usb_id segfaulting on 2.6.23

[Oliver Neukum]

Am Dienstag 06 November 2007 schrieb Daniel Drake:
> Oliver Neukum wrote:
> > Is bcdDevice present without CONFIG_SUSPEND? Which attributes are
> > present?

Looks like a failure in drivers/usb/core/sysfs.c::usb_create_sysfs_dev_files()
Can you put printks there to show where it fails?
I am trying to replicate this, but the compilation will take some time.

	Regards
		Oliver

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: usb_id segfaulting on 2.6.23

[Oliver Neukum]

Am Dienstag 06 November 2007 schrieb Daniel Drake:
> Oliver Neukum wrote:
> > Is bcdDevice present without CONFIG_SUSPEND? Which attributes are
> > present?
> 
> Without CONFIG_SUSPEND, the contents of my 
> /sys/devices/pci0000:00/0000:00:02.0/usb2/2-10/ are as follows:

Can you please provide your full .config?

	Regards
		Oliver

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: usb_id segfaulting on 2.6.23

[Daniel Drake]

Oliver Neukum wrote:
> Am Dienstag 06 November 2007 schrieb Daniel Drake:
>> Oliver Neukum wrote:
>>> Is bcdDevice present without CONFIG_SUSPEND? Which attributes are
>>> present?
> 
> Looks like a failure in drivers/usb/core/sysfs.c::usb_create_sysfs_dev_files()
> Can you put printks there to show where it fails?

Done. It fails here:

	retval = add_power_attributes(dev);
	if (retval)
		goto error;

add_power_attributes returns -2.

Digging further, inside add_power_attributes(), the first call to 
sysfs_add_file_to_group() returns -2. The second one is therefore not 
attempted.

Daniel


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: usb_id segfaulting on 2.6.23

[Alan Stern]

On Tue, 6 Nov 2007, Daniel Drake wrote:

> Oliver Neukum wrote:
> > Am Dienstag 06 November 2007 schrieb Daniel Drake:
> >> Oliver Neukum wrote:
> >>> Is bcdDevice present without CONFIG_SUSPEND? Which attributes are
> >>> present?
> > 
> > Looks like a failure in drivers/usb/core/sysfs.c::usb_create_sysfs_dev_files()
> > Can you put printks there to show where it fails?
> 
> Done. It fails here:
> 
> 	retval = add_power_attributes(dev);
> 	if (retval)
> 		goto error;
> 
> add_power_attributes returns -2.
> 
> Digging further, inside add_power_attributes(), the first call to 
> sysfs_add_file_to_group() returns -2. The second one is therefore not 
> attempted.

Ah, okay.  This is a known problem, a configuration-related issue.  
The PM core doesn't create a device's /sys/.../power subdirectory
unless CONFIG_PM_SLEEP is set.  In fact it should be created whenever
CONFIG_PM is set.

I haven't had time to write a patch for this yet.  Do you want to try?

Alan Stern


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: usb_id segfaulting on 2.6.23

[Alan Stern]

On Tue, 6 Nov 2007, Daniel Drake wrote:

> Oliver Neukum wrote:
> > Is bcdDevice present without CONFIG_SUSPEND? Which attributes are
> > present?
> 
> Without CONFIG_SUSPEND, the contents of my 
> /sys/devices/pci0000:00/0000:00:02.0/usb2/2-10/ are as follows:
> 
> 2-10:1.0
> dev
> driver
> subsystem
> uevent
> usb_device
> 
> The missing attributes are:
> 
> authorized
> bcdDevice
> bConfigurationValue
> bDeviceClass
> bDeviceProtocol
> bDeviceSubClass
> bmAttributes
> bMaxPacketSize0
> bMaxPower
> bNumConfigurations
> bNumInterfaces
> busnum
> configuration
> descriptors
> devnum
> ep_00
> idProduct
> idVendor
> manufacturer
> maxchild
> power
> product
> quirks
> speed
> urbnum
> usb_endpoint
> version

Can you post a dmesg log showing what happens when a USB device is 
plugged into a kernel with CONFIG_USB_DEBUG enabled and 
CONFIG_USB_SUSPEND disabled?

Also, you might want to experiment on your own to trace the flow of 
control.  Here's what _should_ happen when a new USB device is 
detected:

	In hub.c, usb_new_device() calls device_add(&udev->dev).

	In generic.c, generic_probe() is called to bind to the new
	device.

	generic_probe() calls usb_create_sysfs_dev_files() in
	sysfs.c.

	usb_create_sysfs_dev_files() does a whole bunch of
	sysfs_create_group() and related function calls.

	The rest is handled by the sysfs core.

Maybe you can find out at which stage things go wrong.

Alan Stern


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: usb_id segfaulting on 2.6.23

[Daniel Drake]

[-- Attachment #1: Type: text/plain, Size: 408 bytes --]

Alan Stern wrote:
> Ah, okay.  This is a known problem, a configuration-related issue.  
> The PM core doesn't create a device's /sys/.../power subdirectory
> unless CONFIG_PM_SLEEP is set.  In fact it should be created whenever
> CONFIG_PM is set.
> 
> I haven't had time to write a patch for this yet.  Do you want to try?

OK. Any comments on this before I sent it to the proper channels?

Thanks,
Daniel

[-- Attachment #2: power-sysfs.patch --]
[-- Type: text/plain, Size: 2450 bytes --]


From: Daniel Drake <dsd@gentoo.org>

Index: linux-2.6.24-rc1-git14/drivers/base/core.c
===================================================================
--- linux-2.6.24-rc1-git14.orig/drivers/base/core.c
+++ linux-2.6.24-rc1-git14/drivers/base/core.c
@@ -770,6 +770,9 @@ int device_add(struct device *dev)
 	error = device_add_attrs(dev);
 	if (error)
 		goto AttrsError;
+	error = dpm_sysfs_add(dev);
+	if (error)
+		goto PMsysfsError;
 	error = device_pm_add(dev);
 	if (error)
 		goto PMError;
@@ -797,11 +800,13 @@ int device_add(struct device *dev)
 	return error;
  BusError:
 	device_pm_remove(dev);
- PMError:
+ PMsysfsError:
 	if (dev->bus)
 		blocking_notifier_call_chain(&dev->bus->bus_notifier,
 					     BUS_NOTIFY_DEL_DEVICE, dev);
 	device_remove_attrs(dev);
+ PMError:
+	dpm_sysfs_remove(dev);
  AttrsError:
 	device_remove_class_symlinks(dev);
  SymlinkError:
Index: linux-2.6.24-rc1-git14/drivers/base/power/Makefile
===================================================================
--- linux-2.6.24-rc1-git14.orig/drivers/base/power/Makefile
+++ linux-2.6.24-rc1-git14/drivers/base/power/Makefile
@@ -1,5 +1,6 @@
 obj-y			:= shutdown.o
-obj-$(CONFIG_PM_SLEEP)	+= main.o sysfs.o
+obj-$(CONFIG_PM)	+= sysfs.o
+obj-$(CONFIG_PM_SLEEP)	+= main.o
 obj-$(CONFIG_PM_TRACE)	+= trace.o
 
 ifeq ($(CONFIG_DEBUG_DRIVER),y)
Index: linux-2.6.24-rc1-git14/drivers/base/power/power.h
===================================================================
--- linux-2.6.24-rc1-git14.orig/drivers/base/power/power.h
+++ linux-2.6.24-rc1-git14/drivers/base/power/power.h
@@ -21,6 +21,22 @@ static inline struct device * to_device(
 extern int device_pm_add(struct device *);
 extern void device_pm_remove(struct device *);
 
+#else /* CONFIG_PM_SLEEP */
+
+
+static inline int device_pm_add(struct device * dev)
+{
+	return 0;
+}
+static inline void device_pm_remove(struct device * dev)
+{
+
+}
+
+#endif
+
+#ifdef CONFIG_PM
+
 /*
  * sysfs.c
  */
@@ -28,16 +44,16 @@ extern void device_pm_remove(struct devi
 extern int dpm_sysfs_add(struct device *);
 extern void dpm_sysfs_remove(struct device *);
 
-#else /* CONFIG_PM_SLEEP */
-
+#else /* CONFIG_PM */
 
-static inline int device_pm_add(struct device * dev)
+static inline int dpm_sysfs_add(struct device * dev)
 {
 	return 0;
 }
-static inline void device_pm_remove(struct device * dev)
+static inline void dpm_sysfs_remove(struct device * dev)
 {
 
 }
 
-#endif
+#endif /* CONFIG_PM */
+

[-- Attachment #3: Type: text/plain, Size: 314 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 226 bytes --]

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: usb_id segfaulting on 2.6.23

[Daniel Drake]

Daniel Drake wrote:
> Alan Stern wrote:
>> Ah, okay.  This is a known problem, a configuration-related issue.  
>> The PM core doesn't create a device's /sys/.../power subdirectory
>> unless CONFIG_PM_SLEEP is set.  In fact it should be created whenever
>> CONFIG_PM is set.
>>
>> I haven't had time to write a patch for this yet.  Do you want to try?
> 
> OK. Any comments on this before I sent it to the proper channels?

Missed a hunk where I remove the existing dpm_sysfs_add() call from 
drivers/base/power/main.c but you get the idea.. although I'm 
increasingly unsure if this is the right approach.

Daniel


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: usb_id segfaulting on 2.6.23

[Greg KH]

On Tue, Nov 06, 2007 at 05:54:14PM +0000, Daniel Drake wrote:
> Daniel Drake wrote:
>> Alan Stern wrote:
>>> Ah, okay.  This is a known problem, a configuration-related issue.  The 
>>> PM core doesn't create a device's /sys/.../power subdirectory
>>> unless CONFIG_PM_SLEEP is set.  In fact it should be created whenever
>>> CONFIG_PM is set.
>>>
>>> I haven't had time to write a patch for this yet.  Do you want to try?
>> OK. Any comments on this before I sent it to the proper channels?
>
> Missed a hunk where I remove the existing dpm_sysfs_add() call from 
> drivers/base/power/main.c but you get the idea.. although I'm increasingly 
> unsure if this is the right approach.

It looks like a sane fix to me, as long as all of the different config
combinations work properly.

thanks,

greg k-h

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel