| Summary: | HAL sometimes doesn't emit udi-removed signals | ||
|---|---|---|---|
| Product: | hal | Reporter: | Dan Williams <dcbw> |
| Component: | hald | Assignee: | Danny Kukawka <danny.kukawka> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | kay, mark, stern |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
HAL log showing "Error removing device" message
udev log showing tty removal events udev device add/remove log for 2.6.29-0.258.rc8.git2.fc11 |
||
|
Description
Dan Williams
2009-03-16 20:26:29 UTC
Created attachment 23947 [details]
HAL log showing "Error removing device" message
Created attachment 23948 [details]
udev log showing tty removal events
Can you please provide full lshal output before you remove the card? Without lshal output: Looks as if the problem is may the sysfs_path. On the ADD event it's e.g.: /sys/devices/pci0000:00/0000:00:1e.0/0000:02:01.0/0000:03:00.0/usb2/2-1/2-1:1.0/ttyUSB0/tty/ttyUSB0 But on the REMOVE event it's: /sys/2-1:1.0/ttyUSB0/tty/ttyUSB0 That's why HAL can't remove the device from the device list, there is simply no device in the store with this sysfs_path. Is this maybe a UDEV or kernel issue? Looks like a kernel bug. The parent usb_device is no longer available while the usb_interface, which is normally a child of the usb_device, and the class devices, which are childs of the usb_interface, are removed. Such events must never happen, they must all start with with a full path starting with "/devices/...": UEVENT[1237261056.182478] remove /2-1:1.0/ttyUSB0/tty/ttyUSB0 (tty) Seems like a bug in the kernel usb cleanup logic. What kernel version is it? And can this e reproduced with a current vanilla kernel.org kernel? Kernel was Fedora rawhide 2.6.29-0.176.rc6.git5.fc11.i686.PAE. Will re-test with 2.6.29-0.258.rc8.git2.fc11.PAE. udev-139-2.fc11.i586 BTW note that (so far) this only happens if the 3G device is *active* at the time it's removed; ie NetworkManager has started PPP on one of the ttys. I can't reproduce the issue if the device is dormant and nothing is using the ttys when yanking the card. (In reply to comment #9) > note that (so far) this only happens if the 3G device is *active* at the time > it's removed; ie NetworkManager has started PPP on one of the ttys. I can't > reproduce the issue if the device is dormant and nothing is using the ttys when > yanking the card. Which fits into the expected refcounting/cleanup bug, that the active tty device does not pin the entire parent chain, but for some reason, the usb_interface can disconnect from its parent, the usb_device, during the removal processing. Behavior still present with 2.6.29-0.258.rc8.git2.fc11.PAE; I get udev events like: UDEV [....] remove /2-1:1.0/ttyUSB3 (usb-serial) UDEV_LOG=3 ACTION=remove DEVPATH=/2-1:1.0/ttyUSB3 SUBSYSTEM=usb-serial SEQNUM=1267 Oddly, I get *duplicate* udev remove events emitted (with the same sequence #). Log attached; look for the dupes. Created attachment 23999 [details]
udev device add/remove log for 2.6.29-0.258.rc8.git2.fc11
For example: UEVENT[1237394963.457798] remove /2-1:1.0/ttyUSB0/tty/ttyUSB0 (tty) UDEV_LOG=3 ACTION=remove DEVPATH=/2-1:1.0/ttyUSB0/tty/ttyUSB0 SUBSYSTEM=tty SEQNUM=1260 MAJOR=188 MINOR=0 <lots of other stuff> UDEV [1237394964.427524] remove /2-1:1.0/ttyUSB0/tty/ttyUSB0 (tty) UDEV_LOG=3 ACTION=remove DEVPATH=/2-1:1.0/ttyUSB0/tty/ttyUSB0 SUBSYSTEM=tty SEQNUM=1260 DEVNAME=/dev/ttyUSB0 MAJOR=188 MINOR=0 I wonder what's up with that...? :) (In reply to comment #13) > UEVENT[1237394963.457798] remove /2-1:1.0/ttyUSB0/tty/ttyUSB0 (tty) ... > UDEV [1237394964.427524] remove /2-1:1.0/ttyUSB0/tty/ttyUSB0 (tty) ... It's this: $ /sbin/udevadm monitor monitor will print the received events for: UDEV the event which udev sends out after rule processing UEVENT the kernel uevent --kernel, --udev can be used to see only one of them. The output of both events is useful to see the timing, the time it takes to finish an event, and the reordering of udev because of parallel execution. Alan, any idea? We see for a 3G USB-modem, in case it is busy/active and we disconnect it, broken DEVPATH uevents like: UEVENT[1237394963.457798] remove /2-1:1.0/ttyUSB0/tty/ttyUSB0 (tty) The usb_interface seems to "disconnect" from the parent usb_device before the childs are handled. Follow-up: Alan posted some patches that fix refcounting and tty destruction in drivers/usb/serial/usb-serial.c that fix the issue. Definitely a kernel bug. (In reply to comment #16) > Follow-up: Alan posted some patches that fix refcounting and tty destruction in > drivers/usb/serial/usb-serial.c that fix the issue. Definitely a kernel bug. > Can someone point me to these patches please. I'm seeing this behaviour on a Pocket PC pda. FWIW, now fixed in 2.6.27.23 and 2.6.29.3 as well. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.