Re: ACPI I/O resource conflicts with ACPI region SMBI

Re: ACPI I/O resource conflicts with ACPI region SMBI

[Sarah Sharp]

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.

> 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.

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.

> 3.2.0-rc4-amd64 refuse to boot as soon as I plug my mouse to USB 3.0
> port (screenshot at [2]). USB 2.0 and no mouse still boot fine.
> 
> I am attaching dmesg from a kernel boot, when mouse is attached to USB
> 2.0 port (see [3]).
> 
> I think I'll revert to 2.6.39-bpo.2-amd64 because kernel does not
> seems to like my video card. When I suspend/resume, screen is
> displayed on screen Ctrl+Shift+F8, while pointer stays on
> Ctrl+Shift+F7. I can type fine from Ctrl+Shift+F7, since I can see
> results on Ctrl+Shift+F8. I'll try to compile the nvidia kernel and
> see if suspend/resume works.
> 
> 
> Refs:
> [1] http://bugs.debian.org/644174
> [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644174#64
> [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644174#69

Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ACPI I/O resource conflicts with ACPI region SMBI

[Mathieu Malaterre]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ACPI I/O resource conflicts with ACPI region SMBI

[Sarah Sharp]

On Wed, Dec 28, 2011 at 06:11:14PM +0100, Mathieu Malaterre wrote:
> 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:
> >> 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.

Please try a USB hub as well.  It's possible the BIOS is trying to read
from the flash drive (which is what I assume you mean by USB key).

> >> 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.

Yeah, don't try to blacklist xhci-hcd.  It's not useful.

> > 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 ?

The log messages seem to indicate that it's either an ACPI or a BIOS
issue.  I really can't suggest any other tests without some input from
the ACPI folks.  The best solution I can suggest is not boot with a USB
device plugged into your USB 3.0 port.

Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ACPI I/O resource conflicts with ACPI region SMBI

[Jonathan Nieder]

Quick side question:

Sarah Sharp wrote:

> Yeah, don't try to blacklist xhci-hcd.  It's not useful.

How else do you suggest that people figure out whether symptoms are
produced by the xhci-hcd driver or something else?  However, I agree
that it's not useful _any more_, since Mathieu tried that test
already.

[...]
> The log messages seem to indicate that it's either an ACPI or a BIOS
> issue.  I really can't suggest any other tests without some input from
> the ACPI folks.  The best solution I can suggest is not boot with a USB
> device plugged into your USB 3.0 port.

Hm.  Mathieu, is it possible to suspend-to-disk ("echo disk >/sys/power/state")
and resume with a USB device plugged into the USB 3.0 port?

Please also attach output from "acpidump" after a successful boot.

Can you reproduce this when booting in recovery mode with
i915.modeset=0 appended to the kernel command line?

Thanks,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html