Bug#644174: ACPI I/O resource conflicts with ACPI region SMBI
On Thu, Dec 22, 2011 at 8:52 PM, Sarah Sharp
<sarah.a.sharp@linux.intel.com> 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@gmail.com> 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@vger.kernel.org, cc-ing Sarah Sharp
>> > <sarah.a.sharp@linux.intel.com> 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
Reply to: