linux-kernel - Re: [linux-usb-devel] on the system with companion host controller, error -71 returns

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <46CA9C49.2070109@miraclelinux.com>
Date:	Tue, 21 Aug 2007 17:03:21 +0900
From:	Kiyoshi Sasaki <ksasaki@...aclelinux.com>
To:	linux-usb-devel@...ts.sourceforge.net
CC:	linux-kernel@...r.kernel.org
Subject: Re: [linux-usb-devel] on the system with companion host controller,
 error -71 returns

attaching dmesgs.

-- 

Kiyoshi Sasaki <ksasaki@...aclelinux.com>

> Hello,
> 
> I see below errors in dmesg on ICH6/ICH7 machine:
> 
> usb 1-1: device not accepting address 2, error -71
> or
> usb 1-1: device descriptor read/all, error -71
> 
> I'm trying to debug it, but by now I can't make it.
> Can you give me your help ?
> 
> ----
> 
> On ICH6/ICH7, in case load sequence is uhci first and ehci second,
> each controller is initialized/registered in usb_add_hcd() like below.
> 
> uhci_hcd 0000:00:1d.0: UHCI Host Controller
> uhci_hcd 0000:00:1d.1: UHCI Host Controller
> uhci_hcd 0000:00:1d.2: UHCI Host Controller
> uhci_hcd 0000:00:1d.3: UHCI Host Controller
> ehci_hcd 0000:00:1d.7: EHCI Host Controller
> 
> And on ehci_hcd turn, usb_add_hcd() calls ehci_run() to start ehci.
> In ehci_run(), it sets Configure Flag (CF) to 1 for enabling full
> USB 2.0 functionality.
> 
> static int ehci_run (struct usb_hcd *hcd)
> {
> ...
>         /*
>          * Start, enabling full USB 2.0 functionality ... usb 1.1 devices
>          * are explicitly handed to companion controller(s), so no TT is
>          * involved with the root hub.  (Except where one is integrated,
>          * and there's no companion controller unless maybe for USB OTG.)
>          */
>         hcd->state = HC_STATE_RUNNING;
>         writel (FLAG_CF, &ehci->regs->configured_flag);
> ...
> }
> 
> On the other hand, uhci tries to get device information using
> hub_set_address() and usb_get_device_descriptor().
> These functions send URB, and URB is processed like below.
> This is done asynchronously.
> 
> - uhci_irq()
>   - uhci_scan_schedule()
>     - uhci_scan_qh()
>       - uhci_result_common()
>         - uhci_map_status()
> 
> uhci_map_status() checks td_status. And the flag is TD_CTRL_STALLED
> |TD_CTRL_CRCTIMEO, and return with error.
> So, hub_set_address() and usb_get_device_descriptor() return -71.
> 
> After some debugging, I found if hub_set_address() and
> usb_get_device_descriptor() is called before CF becomes 1,
> no error returns. Conversely, if these are called even just after
> CF becomes 1, error -71 returns.
> CF becomes 1 means "writel (FLAG_CF, &ehci->regs->configured_flag)".
> 
> To avoid this error, my silly idea is
> 
> 1) before set CF to 1, wait some asynchronous uhci processing
> 2) load ehci first and uhci second
> 
> But for 1), simple msleep() will not work well, and need to
> control khubd and so on, so this seems not smart.
> 
> 
> Do you have any idea to fix this issue ?
> 

View attachment "dmesg_1" of type "text/plain" (6679 bytes)

View attachment "dmesg_2" of type "text/plain" (6082 bytes)