Using the Fedora Rawhide kernel RPM "2.6.27-0.238.rc2.fc10.i686"
(kernel-2.6.27-0.238.rc2.fc10.i686), I'm seeing suspend to ram
failures. The suspend seems to go OK, but then I just get endless:
usb 5-1: uhci_result_common: failed with status 440000
messages, with occasional flickers of something else being printed
(perhaps). The machine is otherwise unresponsive.
J
On Wednesday, 20 of August 2008, Jeremy Fitzhardinge wrote:
> Using the Fedora Rawhide kernel RPM "2.6.27-0.238.rc2.fc10.i686"
> (kernel-2.6.27-0.238.rc2.fc10.i686), I'm seeing suspend to ram
> failures. The suspend seems to go OK, but then I just get endless:
>
> usb 5-1: uhci_result_common: failed with status 440000
>
> messages, with occasional flickers of something else being printed
> (perhaps). The machine is otherwise unresponsive.
I haven't seen anything like this so far with 2.6.27-rc. No idea what might
have caused that to happen.
Thanks,
Rafael
On Wed, 20 Aug 2008, Jeremy Fitzhardinge wrote:
> Using the Fedora Rawhide kernel RPM "2.6.27-0.238.rc2.fc10.i686"
> (kernel-2.6.27-0.238.rc2.fc10.i686), I'm seeing suspend to ram
> failures. The suspend seems to go OK, but then I just get endless:
>
> usb 5-1: uhci_result_common: failed with status 440000
>
> messages, with occasional flickers of something else being printed
> (perhaps). The machine is otherwise unresponsive.
You could comment out that error message in order to see what else is
in the log. It is located in drivers/usb/host/uhci-q.c in the
uhci_result_common() function.
You could try running -rc3 instead of -rc2, although that probably
won't make much difference.
What USB devices do you have on the failing system? In particular,
what is 5-1? If you unplug it before suspending, does the problem go
away? (It certainly should!)
Alan Stern
Alan Stern wrote:
> On Wed, 20 Aug 2008, Jeremy Fitzhardinge wrote:
>
>
>> Using the Fedora Rawhide kernel RPM "2.6.27-0.238.rc2.fc10.i686"
>> (kernel-2.6.27-0.238.rc2.fc10.i686), I'm seeing suspend to ram
>> failures. The suspend seems to go OK, but then I just get endless:
>>
>> usb 5-1: uhci_result_common: failed with status 440000
>>
>> messages, with occasional flickers of something else being printed
>> (perhaps). The machine is otherwise unresponsive.
>>
>
> You could comment out that error message in order to see what else is
> in the log. It is located in drivers/usb/host/uhci-q.c in the
> uhci_result_common() function.
>
> You could try running -rc3 instead of -rc2, although that probably
> won't make much difference.
>
> What USB devices do you have on the failing system? In particular,
> what is 5-1? If you unplug it before suspending, does the problem go
> away? (It certainly should!)
>
>
No external usb devices. There are three internal USB devices:
Bluetooth, a Sierra CDMA modem thingy and a fingerprint reader.
$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 003: ID 0483:2016 SGS Thomson Microelectronics
Fingerprint Reader
Bus 005 Device 002: ID 0a5c:2110 Broadcom Corp. Bluetooth Controller
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 003: ID 1199:0218 Sierra Wireless, Inc. MC5720 Wireless Modem
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
The rfkill switch "unplugs" the two wireless devices, so I'll try that
before suspending next time (if I remember).
J
On Wed, 20 Aug 2008, Jeremy Fitzhardinge wrote:
> Alan Stern wrote:
> > On Wed, 20 Aug 2008, Jeremy Fitzhardinge wrote:
> >
> >
> >> Using the Fedora Rawhide kernel RPM "2.6.27-0.238.rc2.fc10.i686"
> >> (kernel-2.6.27-0.238.rc2.fc10.i686), I'm seeing suspend to ram
> >> failures. The suspend seems to go OK, but then I just get endless:
> >>
> >> usb 5-1: uhci_result_common: failed with status 440000
> >>
> >> messages, with occasional flickers of something else being printed
> >> (perhaps). The machine is otherwise unresponsive.
> >>
> >
> > You could comment out that error message in order to see what else is
> > in the log. It is located in drivers/usb/host/uhci-q.c in the
> > uhci_result_common() function.
> >
> > You could try running -rc3 instead of -rc2, although that probably
> > won't make much difference.
> >
> > What USB devices do you have on the failing system? In particular,
> > what is 5-1? If you unplug it before suspending, does the problem go
> > away? (It certainly should!)
> >
> >
>
> No external usb devices. There are three internal USB devices:
> Bluetooth, a Sierra CDMA modem thingy and a fingerprint reader.
>
> $ lsusb
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 005 Device 003: ID 0483:2016 SGS Thomson Microelectronics
> Fingerprint Reader
> Bus 005 Device 002: ID 0a5c:2110 Broadcom Corp. Bluetooth Controller
> Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 003 Device 003: ID 1199:0218 Sierra Wireless, Inc. MC5720 Wireless Modem
> Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
>
> The rfkill switch "unplugs" the two wireless devices, so I'll try that
> before suspending next time (if I remember).
Obviously 5-1 is either the Bluetooth controller or the fingerprint
reader. It's understandable that either one of them might have
problems with a suspend/resume cycle, but the kernel ought to be able
to recover by itself.
It would help to see the USB debugging log (without all those useless
uhci_result_common messages).
Alan Stern
On Wed, 20 Aug 2008, Jeremy Fitzhardinge wrote:
> Alan Stern wrote:
> > On Wed, 20 Aug 2008, Jeremy Fitzhardinge wrote:
> >
> >
> >> Using the Fedora Rawhide kernel RPM "2.6.27-0.238.rc2.fc10.i686"
> >> (kernel-2.6.27-0.238.rc2.fc10.i686), I'm seeing suspend to ram
> >> failures. The suspend seems to go OK, but then I just get endless:
> >>
> >> usb 5-1: uhci_result_common: failed with status 440000
> >>
> >> messages, with occasional flickers of something else being printed
> >> (perhaps). The machine is otherwise unresponsive.
> >>
> >
> > You could comment out that error message in order to see what else is
> > in the log. It is located in drivers/usb/host/uhci-q.c in the
> > uhci_result_common() function.
> >
> > You could try running -rc3 instead of -rc2, although that probably
> > won't make much difference.
> >
> > What USB devices do you have on the failing system? In particular,
> > what is 5-1? If you unplug it before suspending, does the problem go
> > away? (It certainly should!)
> >
> >
>
> No external usb devices. There are three internal USB devices:
> Bluetooth, a Sierra CDMA modem thingy and a fingerprint reader.
>
> $ lsusb
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 005 Device 003: ID 0483:2016 SGS Thomson Microelectronics
> Fingerprint Reader
> Bus 005 Device 002: ID 0a5c:2110 Broadcom Corp. Bluetooth Controller
> Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 003 Device 003: ID 1199:0218 Sierra Wireless, Inc. MC5720 Wireless Modem
> Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
>
> The rfkill switch "unplugs" the two wireless devices, so I'll try that
> before suspending next time (if I remember).
Is this still a problem?
Is this related to other Bluetooth suspend/resume regressions in
2.6.27?
Alan Stern
Alan Stern wrote:
> On Wed, 20 Aug 2008, Jeremy Fitzhardinge wrote:
>
>
>> Alan Stern wrote:
>>
>>> On Wed, 20 Aug 2008, Jeremy Fitzhardinge wrote:
>>>
>>>
>>>
>>>> Using the Fedora Rawhide kernel RPM "2.6.27-0.238.rc2.fc10.i686"
>>>> (kernel-2.6.27-0.238.rc2.fc10.i686), I'm seeing suspend to ram
>>>> failures. The suspend seems to go OK, but then I just get endless:
>>>>
>>>> usb 5-1: uhci_result_common: failed with status 440000
>>>>
>>>> messages, with occasional flickers of something else being printed
>>>> (perhaps). The machine is otherwise unresponsive.
>>>>
>>>>
>>> You could comment out that error message in order to see what else is
>>> in the log. It is located in drivers/usb/host/uhci-q.c in the
>>> uhci_result_common() function.
>>>
>>> You could try running -rc3 instead of -rc2, although that probably
>>> won't make much difference.
>>>
>>> What USB devices do you have on the failing system? In particular,
>>> what is 5-1? If you unplug it before suspending, does the problem go
>>> away? (It certainly should!)
>>>
>>>
>>>
>> No external usb devices. There are three internal USB devices:
>> Bluetooth, a Sierra CDMA modem thingy and a fingerprint reader.
>>
>> $ lsusb
>> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>> Bus 005 Device 003: ID 0483:2016 SGS Thomson Microelectronics
>> Fingerprint Reader
>> Bus 005 Device 002: ID 0a5c:2110 Broadcom Corp. Bluetooth Controller
>> Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
>> Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
>> Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
>> Bus 003 Device 003: ID 1199:0218 Sierra Wireless, Inc. MC5720 Wireless Modem
>> Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
>>
>> The rfkill switch "unplugs" the two wireless devices, so I'll try that
>> before suspending next time (if I remember).
>>
>
> Is this still a problem?
>
I haven't seen it lately, but it was fairly erratic anyway. It happened
a few times in quick succession, and then it all worked fine. The
rawhide kernels are getting fairly old (I guess RH is still trying to
pull its infrastructure together), so I'm running a fairly recent
self-compiled kernel. Will report anything I see.
> Is this related to other Bluetooth suspend/resume regressions in
> 2.6.27?
>
I'm not sure if its BT or Sierra wireless related.
J
Am Mittwoch 27 August 2008 23:36:30 schrieb Jeremy Fitzhardinge:
> > Is this still a problem?
> > ?
>
> I haven't seen it lately, but it was fairly erratic anyway. ?It happened
> a few times in quick succession, and then it all worked fine. ?The
> rawhide kernels are getting fairly old (I guess RH is still trying to
> pull its infrastructure together), so I'm running a fairly recent
> self-compiled kernel. ?Will report anything I see.
>
> > Is this related to other Bluetooth suspend/resume regressions in
> > 2.6.27?
> > ?
>
> I'm not sure if its BT or Sierra wireless related.
The attached patch is reported to make the problem go away for
a user of btusb. He might be able to use it for narrowing down causes.
Regards
Oliver