Hi, I met the following problem: whenever I plug an Aardvark I2C/SPI host adapter (see http://www.totalphase.com/products/aardvark_i2cspi/) into a USB slot, the X server crashes. Almost always it crashes so that the X server process ceased with no signs of disaster (I mean, nothing is in logs) but the machine doesn't accept any input from keyboard or mouse. I still can log via network and reboot the machine in order to unlock the console. When I log in via network after such a crash, I see no X running. This device doesn't need a kernel space driver to operate, libusb is the only thing that is needed. The problem doesn't seem to happen with other USB devices. (Although I remember some crashes when I connected my cell phone, it was quite a while ago. since that time I upgraded xorg-x11). Here are some more details: 1. black ~ # uname -a Linux black 2.6.30.7-alb #2 SMP Sat Sep 19 05:16:03 MSD 2009 x86_64 Dual Core AMD Opteron(tm) Processor 285 AuthenticAMD GNU/Linux 2. black ~ # lspci 00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3) 00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3) 00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2) 00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2) 00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3) 00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio Controller (rev a2) 00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2) 00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) 00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) 00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2) 00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3) 00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 00:19.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:19.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:19.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:19.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 0a:00.0 VGA compatible controller: nVidia Corporation G71GL [Quadro FX 3500] (rev a1) 40:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12) 40:01.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC (rev 01) 40:02.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12) 40:02.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC (rev 01) 61:06.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 07) 61:06.1 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 07) 80:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3) 80:01.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3) 3. The crash happens with either USB port (and either USB host) 4. I see the crash with X running alone, without clients. Of course, the crash happens in a more usual situation where some desktop environment is running and X is started with a desktop manager (I use Gnome). 5. I can't attribute the crash to any video driver. I tried the following: - x11-drivers/nvidia-drivers-180.60 (the latest stable): At the moment of crash kernel complains: " IRQ 19/nvidia: IRQF_DISABLED is not guaranteed on shared IRQs". If I use gdm, with about 50% probability the X server is restarted (otherwise it hangs). - x11-drivers/nvidia-drivers-185.18.31 (the latest masked ~amd64): Crashes silently. If I use gdm, it manages to restart the X server - x11-drivers/xf86-video-vesa (and the kernel vesa framebuffer driver, the nvidia framebuffer driver is not loaded): X server crashes silently; if I use gdm, it cannot restart the server. 6. black ~ # cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 0: 49 0 0 0 IO-APIC-edge timer 1: 0 2 30 15607 IO-APIC-edge i8042 4: 0 0 0 11 IO-APIC-edge serial 6: 0 0 0 6 IO-APIC-edge floppy 7: 1 0 0 0 IO-APIC-edge 8: 0 0 0 1 IO-APIC-edge rtc0 9: 0 0 0 0 IO-APIC-fasteoi acpi 12: 0 2 91 27315 IO-APIC-edge i8042 14: 0 1 32 32387 IO-APIC-edge ide0 15: 0 0 0 0 IO-APIC-edge ide1 19: 0 10 94 396360 IO-APIC-fasteoi nvidia 20: 0 0 0 4 IO-APIC-fasteoi ehci_hcd:usb1 21: 0 2 23 8351 IO-APIC-fasteoi eth0 22: 0 0 0 669 IO-APIC-fasteoi sata_nv, NVidia CK804 23: 0 3 71 27864 IO-APIC-fasteoi sata_nv, ohci_hcd:usb2 30: 0 0 0 45 IO-APIC-fasteoi ioc0 31: 0 0 0 207 IO-APIC-fasteoi ioc1 NMI: 0 0 0 0 Non-maskable interrupts LOC: 330829 209014 143253 151629 Local timer interrupts SPU: 0 0 0 0 Spurious interrupts RES: 38518 38221 24586 18939 Rescheduling interrupts CAL: 195 318 325 173 Function call interrupts TLB: 980 2571 1122 1948 TLB shootdowns TRM: 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 Threshold APIC interrupts ERR: 1 MIS: 0 7. No surprise, if I stop haldaemon, the crash doesn't occur. 8. The device is new and fully functional under Windows. If important, I can tell the hw version (I don't have it handy). The fw version is 3.50 (the latest). I don't know, what else info to supply (surely, I will attach my emerge --info and xorg.conf). I am assigning this bug a normal priority despite formally it is critical. Reproducible: Always Steps to Reproduce: 1. run X 2. plug an Aardvark I2C/SPI host adapter into a spare USB port Actual Results: Machine become not responsive Expected Results: No end-user visible changes in X server.
Created attachment 204563 [details] emerge --info
Created attachment 204565 [details] My xorg.conf
Created attachment 204566 [details] /etc/hal/fdi/policy/10-xinput-configuration.fdi
Created attachment 204568 [details] Xorg.0.log with vesa framebuffer
Created attachment 204570 [details] dmesg with several insertions/removal of the I2C host adapter recorded
As xorg-x11 is just a meta, change summary to the version (with revision) of xorg server you're using. Attach logs of hald.
Created attachment 204626 [details] Output of /usr/sbin/hald --daemon=no --verbose=yes where removal and then insertion of the Aardvark adapter is recorded
(In reply to comment #6) > As xorg-x11 is just a meta, change summary to the version (with revision) > of xorg server you're using. > Attach logs of hald. Done. x11-base/xorg-server-1.5.3-r6 is the latest stable at the moment. Also the hw version of Aardvark adapter is 3.00, if that matter.
Comment on attachment 204626 [details] Output of /usr/sbin/hald --daemon=no --verbose=yes where removal and then insertion of the Aardvark adapter is recorded Removing starts on 21:26:36.405 and insertion starts on 21:26:51.667
Interestingly, without the Aardvark adapter lshal produces its output. When the adapter is plugged in, lshal aborts with message: process 8639: arguments to dbus_message_new_method_call() were incorrect, assertion "_dbus_check_is_valid_path (path)" failed in file dbus-message.c line 1074. This is normally a bug in some application using the D-Bus library. D-Bus not built with -rdynamic so unable to print a backtrace Aborted I am using sys-apps/hal-0.5.11-r9 (the latest stable to the moment). I will attach lsusb -v output and the output of lshal without Aardvark adapter.
Created attachment 204635 [details] Output of lshal with Aardvark adapter unplugged (see comment #10).
Created attachment 204636 [details] Output of lsusb -v
The invalid path mentioned in comment #10 is '/org/freedesktop/Hal/devices/usb_device_403_e0d0_TPCFWdA/'. With this information available, I dare to attribute this bug to interaction between sys-apps/hal-0.5.11-r9 and sys-apps/dbus-1.2.3-r1. Updated the 'Summary' and 'Component' fields. I will try to understand what's wrong with this path.
Well, the problem is a trailing slash in dbus path supplied by hal. The corresponding piece of code in dbus (dbus-marshal-validate.c) is: if ((end - last_slash) < 2 && len > 1) return FALSE; /* trailing slash not allowed unless the string is "/" */ If such a path has come, dbus will kill the process it is linked with.
Well, I see the reason: Serial number of the device contains a slash (even worse, this slash is in trailing position!). This leads to a malformed (by dbus rules) path supplied by hal. This in turn crash any receptor of the dbus message, be it xorg-server or lshal.
The bug is not present in sys-apps/hal-0.5.13-r2, '/' is replaced with '_' and this trick removes the crash. The probability to meet '/' in the trailing position is more than 1%. The probability of meeting '/' anywhere in the serial number string is much higher (difficult to estimate because more significant digits might not span the whole set of values). The latter (when '/' is in the middle of serial number) perhaps won't cause immediate crash (at least, not in this piece of code) but sooner or later the things will go wrong. Perhaps not only serial numbers of usb devices but other strings are affected. I suggest to mask ~sys-apps/hal-0.5.11. I updated summary once more. I also escalated severity since this bug must affect many users (see previous paragraph) and can cause cryptic crashes and loss of data.
I also have taken a short look onto USB specification (2.0 and 3.0) and found nothing which would limit characters in the serial number string descriptor, per the specification it is an arbitrary UTF-16 string. That is slashes within a serial number are pretty valid.
Wow, thanks for the detailed debugging information explaining this problem. Good that the upcoming stable version includes a solution.
Closing as duplicate of stabilization bug. *** This bug has been marked as a duplicate of bug 287380 ***
