On Thu, Dec 22, 2011 at 8:52 PM, Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx> wrote: > On Thu, Dec 22, 2011 at 04:18:56PM +0100, Mathieu Malaterre wrote: >> On Fri, Dec 16, 2011 at 11:27 AM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: >> > - Please test a v3.2 release candidate from experimental. The only >> > packages from outside squeeze that should be needed for this, aside >> > from the kernel image itself, are linux-base and initramfs-tools. >> > >> > - If it reproduces the problem, please blacklist the xhci_hcd >> > module by writing >> > >> > blacklist xhci_hcd >> > >> > to a file /etc/modprobe.d/mm-blacklist-xhci.conf, run >> > >> > update-initramfs -u -k all >> > >> > and reboot to try again without USB 3.0 support. If we're very >> > lucky, this will work around the problem. In that case, please >> > write a summary of the problem to upstream >> > (linux-usb@xxxxxxxxxxxxxxx, cc-ing Sarah Sharp >> > <sarah.a.sharp@xxxxxxxxxxxxxxx> and either me or this bug log so we >> > can track the resulting discussion). Be sure to include: >> > >> > - steps to reproduce the problem >> > - symptoms, and how they differ from what you expected >> > - ways to avoid triggering the problem (maybe some USB ports >> > trigger it and others don't? etc) >> > - full "dmesg" output from booting, and a photo of the screen >> > after reproducing the problem (ideally by running "modprobe >> > xhci_hcd" in the very same run of Linux), as attachments >> > - which kernel versions you've tested, and what happened with each >> > - a link to this bug log for the full story >> > - any other weird symptoms or observations >> >> System: Dell System Vostro 3750 / Portable Computer >> >> Ok. So I am running: 3.2.0-rc4-amd64 from debian experimental. >> >> No mouse plugged to USB 2.0/3.0 interface: boot is fine >> Mouse plugged to USB 2.0 interface: boot is fine >> Mouse plugged to USB 3.0 interface: boot simply stops > > Does the boot stop when you have a non-HID USB device plugged into the > USB 3.0 port (e.g. hub or flash drive or USB speaker)? It could be an > issue with a buggy BIOS trying to use the mouse and keyboard (HID > devices) attached to the USB 3.0 host. Perhaps it changes the ACPI > tables when it tries to use the USB 3.0 host controller, and > accidentally overlaps the regions? But if your keyboard and mouse were > under USB 2.0, maybe it will only map in the USB 2.0 host controller. I tried booting kernel 3.0.2 (debian/unstable 3.2.0-rc4-amd64) with a USB key plugged into USB 3.0 and was stuck again. So I can confirm that with a normal USB key (non-HID) plugged in USB 3.0 port, makes the kernel refuse to boot. After a normal boot, key appears as : [ 158.736727] usb 3-2: new high-speed USB device number 2 using xhci_hcd [ 158.755680] xhci_hcd 0000:03:00.0: WARN: short transfer on control ep [ 158.756522] xhci_hcd 0000:03:00.0: WARN: short transfer on control ep [ 158.757426] xhci_hcd 0000:03:00.0: WARN: short transfer on control ep [ 158.758299] xhci_hcd 0000:03:00.0: WARN: short transfer on control ep [ 158.758698] usb 3-2: New USB device found, idVendor=0951, idProduct=160f [ 158.758708] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 158.758714] usb 3-2: Product: DT Mini Slim [ 158.758719] usb 3-2: Manufacturer: Kingston [ 158.758723] usb 3-2: SerialNumber: 0019E06B07B5F9A1879A0D15 [ 158.760294] scsi7 : usb-storage 3-2:1.0 [ 159.760670] scsi 7:0:0:0: Direct-Access Kingston DT Mini Slim 1.00 PQ: 0 ANSI: 2 [ 159.763089] sd 7:0:0:0: Attached scsi generic sg2 type 0 [ 159.763655] sd 7:0:0:0: [sdb] 15654848 512-byte logical blocks: (8.01 GB/7.46 GiB) [ 159.763834] sd 7:0:0:0: [sdb] Write Protect is off [ 159.763841] sd 7:0:0:0: [sdb] Mode Sense: 16 0f 09 51 [ 159.764012] sd 7:0:0:0: [sdb] Incomplete mode parameter data [ 159.764019] sd 7:0:0:0: [sdb] Assuming drive cache: write through [ 159.765193] sd 7:0:0:0: [sdb] Incomplete mode parameter data [ 159.765200] sd 7:0:0:0: [sdb] Assuming drive cache: write through [ 159.765778] sdb: sdb1 [ 159.766855] sd 7:0:0:0: [sdb] Incomplete mode parameter data [ 159.766865] sd 7:0:0:0: [sdb] Assuming drive cache: write through [ 159.766875] sd 7:0:0:0: [sdb] Attached SCSI removable disk >> As suggested by Jonathan N. [1] here is what I did next: >> >> $ cat /etc/modprobe.d/mm-blacklist-xhci.conf >> blacklist xhci_hcd >> $ update-initramfs -u -k all >> $ sudo reboot > > Were you blacklisting xhci only because of the "xhci_hcd 0000:03:00.0: > WARN: Stalled endpoint" messages? Because those messages are harmless, > and don't mean anything is *wrong* with the host controller. I simply blindly follow the suggestion. > Even if there's no xHCI driver loaded, it seems that ACPI is noticing > the conflict between the PCI registers and another region. So unloading > the xHCI driver won't help your system boot. You'd need to get a fix > into the ACPI subsystem to work around the conflict. I don't think any > xHCI driver modification can help here. Is there a way to check if bug is related to ACPI or rather USB 3.0 ? Thanks again, -- Mathieu -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
