linux-kernel - Re: Endless print of uhci_result_common: failed with status 440000

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BANLkTikJ_mW5DFooGypNB_1MTHXKP9vi2A@mail.gmail.com>
Date:	Fri, 8 Apr 2011 18:04:04 +0200
From:	Zdenek Kabelac <zdenek.kabelac@...il.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	USB list <linux-usb@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Endless print of uhci_result_common: failed with status 440000

2011/4/8 Zdenek Kabelac <zdenek.kabelac@...il.com>:
> 2011/4/8 Zdenek Kabelac <zdenek.kabelac@...il.com>:
>> 2011/4/8 Alan Stern <stern@...land.harvard.edu>:
>>> On Fri, 8 Apr 2011, Zdenek Kabelac wrote:
>>>
>>>> Hi
>>>>
>>>> While debugging resume problem with Intel HW I've been hitting problem
>>>> with endless print of  usb 1.1 error message on my T61.
>>>> (See my other similar post
>>>> http://marc.info/?l=linux-kernel&m=130221292724436&w=2)
>>>
>>> This is essentially the same problem.
>>>
>>>> This time the problem is generated by Bluetooth device.
>>>>
>>>> Often just only several messages are printed - and then machine
>>>> suspend - so the log usually contains only several such message - if
>>>> at all - however today with debugging and serial console logging -
>>>> I've seen several times - that suspend resulted in endless unbreakable
>>>> loop.
>>>>
>>>> As a workaround - one could just disable BT device:
>>>> "echo disable >/proc/acpi/ibm/bluetooth"
>>>
>>> ...
>>>
>>>> Googling it - seems it's common issue of this BT chipset - but I think
>>>> is should not cause suspend deadlock ??
>>>
>>> Are you sure anything is deadlocked?  What happens if you disable
>>> CONFIG_USB_DEBUG?
>>>
>>
>>
>> Ok - I've disabled this config option - now kernel writes this:
>> (when I keep bt device enabled)
>>
>> usb 3-1: USB disconnect, device number 2
>> btusb_bulk_complete: hci0 urb ffff88012b94ca50 failed to resubmit (19)
>> btusb_intr_complete: hci0 urb ffff88012b94c000 failed to resubmit (19)
>> btusb_bulk_complete: hci0 urb ffff88012b94c948 failed to resubmit (19)
>> btusb_send_frame: hci0 urb ffff880113dd0528 submission failed
>> ------------[ cut here ]------------
>> WARNING: at lib/debugobjects.c:262 debug_print_object+0x7c/0x8d()
>> Hardware name: 6464CTO
>> ODEBUG: free active (active state 0) object type: timer_list hint:
>> hci_cmd_timer+0x0/0x46 [bluetooth]
>> Modules linked in: hidp ip6table_filter
>> systemd[1]: Service bluetooth.target is not needed anymore. Stopping.
>>  ip6_tables ebtable_nat ebtables xt_CHECKSUM iptable_mangle tun bridge
>> ipv6 stp llc sunrpc rfcomm acpi_cpufreq freq_table mperf bnep
>> xt_physdev ipt_MASQUERADE iptable_nat nf_nat snd_hda_codec_analog arc4
>> iwl3945 snd_hda_intel snd_hda_codec snd_hwdep r852 snd_seq sm_common
>> snd_seq_device microcode btusb nand iwl_legacy nand_ids r592 nand_ecc
>> memstick mtd snd_pcm mac80211 i2c_i801 joydev iTCO_wdt bluetooth
>> iTCO_vendor_support cfg80211 thinkpad_acpi e1000e snd_timer rfkill
>> snd_page_alloc wmi snd soundcore virtio_net kvm_intel kvm uinput
>> sdhci_pci yenta_socket sdhci mmc_core i915 drm_kms_helper drm
>> i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan]
>> Pid: 21, comm: khubd Not tainted 2.6.39-0.rc2.git0.0.fc16.x86_64 #1
>
>
> ooops - different kernel - I'll need another reboot.
> (But anyway probably interested as well)
>


So now I've retested again with my own kernel build - where I've
disable USB_DEBUG.
It's somewhat harder to hit the problem - but 2 times I've ended with
laptop - which
sent this into  '/var/log/messages'

[   53.851937] btusb_intr_complete: hci0 urb ffff88011735c300 failed
to resubmit (19)
[   53.855223] btusb_bulk_complete: hci0 urb ffff88011735c540 failed
to resubmit (19)
[   53.867211] btusb_bulk_complete: hci0 urb ffff88011735c9c0 failed
to resubmit (19)
[   53.875279] btusb_send_frame: hci0 urb ffff880117204d80 submission failed
[   54.127633] systemd[1]: Service bluetooth.target is not needed
anymore. Stopping.

These are the last lines catched by serial console:

[   53.340232] usb 1-1: new full speed USB device number 4 using uhci_hcd
[   53.505588] usb 1-1: New USB device found, idVendor=0a5c, idProduct=2110
[   53.513035] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[   53.520876] usb 1-1: Product: BCM2045B
[   53.524775] usb 1-1: Manufacturer: Broadcom Corp
[   53.846908] usb 1-1: USB disconnect, device number 4
[   53.851937] btusb_intr_complete: hci0 urb ffff88011735c300 failed
to resubmit (19)
[   53.855223] btusb_bulk_complete: hci0 urb ffff88011735c540 failed
to resubmit (19)
[   53.867211] btusb_bulk_complete: hci0 urb ffff88011735c9c0 failed
to resubmit (19)
[   53.875279] btusb_send_frame: hci0 urb ffff880117204d80 submission failed
[   54.127633] systemd[1]: Service bluetooth.target is not needed
anymore. Stopping.
[   54.205292] PM: Syncing filesystems ... done.
[   54.216056] PM: Preparing system for mem sleep

And system was 'dead' - (Moon sign on laptop was already blinking at
this moment)

I've strong believe - it's the moment  where USB_DEBUG version was
printing those lines in endless loop.
(Or let say it this way:   More then few minutes loop  - as maybe it
will end within a week - but I don't have that much time to wait ;))

Seems like Fedora rawhide kernel with KObject debugging gives here
valuable hint ??

Zdenek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/