Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757492Ab1DHQE1 (ORCPT ); Fri, 8 Apr 2011 12:04:27 -0400 Received: from mail-fx0-f46.google.com ([209.85.161.46]:56808 "EHLO mail-fx0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752557Ab1DHQEZ convert rfc822-to-8bit (ORCPT ); Fri, 8 Apr 2011 12:04:25 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=hPaT3OLOgHlgvbqE8NFy6sIDohaNs+o4iQ+56JS9fg0zevFKmk30omyodIsK/7+U2Z fwvMHcS0bPcvHyW6xtdB95rOf4c6S93DZTJ5H5e1APjJEMr82fRu8oCXKACdI3APP+zB MK8nQrZNyWTOWUDwXFDkB0p5q58sjL+pw2/4I= MIME-Version: 1.0 In-Reply-To: References: Date: Fri, 8 Apr 2011 18:04:04 +0200 Message-ID: Subject: Re: Endless print of uhci_result_common: failed with status 440000 From: Zdenek Kabelac To: Alan Stern Cc: USB list , Linux Kernel Mailing List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5129 Lines: 121 2011/4/8 Zdenek Kabelac : > 2011/4/8 Zdenek Kabelac : >> 2011/4/8 Alan Stern : >>> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/