linux-kernel - Re: System hang in quirk_usb_handoff

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] [day] [month] [year] [list]

Date:	Tue, 30 Dec 2008 01:30:38 +0100
From:	Kai Ruhnau <kai@...getaschen.dyndns.org>
To:	Robert Hancock <hancockr@...w.ca>
CC:	linux-kernel@...r.kernel.org
Subject: Re: System hang in quirk_usb_handoff_ohci

Robert Hancock wrote:
> Kai Ruhnau wrote:
>> Hi,
>>
>> Some days ago, I reported a reproducible hang during boot. The
>> information around was quite vague and so I took the liberty to further
>> dig into the the call stack of pci_init and found the exact place where
>> the initialization locks.
>> But first the symptoms (those are improved as well):
>>
>> If I turn on or restart my computer and try to boot without my
>> intervention, the system always hangs during boot, the last output being
>> the io scheduler registration. However, if I press a key at any time
>> after the BIOS (for example manual choosing  the grub entry or during
>> the kernel messages) the system happily boots normally.
>>
>> After a little printk debugging, it turns out, that
>> quirk_usb_handoff_ohci will hang when applied to my first USB OHCI pci
>> device. I have marked the offending line in the following snippet (line
>> 186 in the original---the second writel)
>>
>> ============ (startint at line 182 inn pci-quirks.c)
>> [...]
>>     u32 control = readl(base + OHCI_CONTROL);
>>     if (control & OHCI_CTRL_IR) {
>>         int wait_time = 500; /* arbitrary; 5 seconds */
>>         writel(OHCI_INTR_OC, base + OHCI_INTRENABLE);
>>
>>        // The next line might hang
>>
>>         writel(OHCI_OCR, base + OHCI_CMDSTATUS);
>>         while (wait_time > 0 &&
>>                 readl(base + OHCI_CONTROL) & OHCI_CTRL_IR) {
>>             wait_time -= 10;
>>             msleep(10);
>>         }
>> [...]
>> =========
>>
>> The lspci output for the device is
>>
>> 00:13.0 0c03: 1002:4387 (prog-if 10 [OHCI])
>>         Subsystem: 1462:7326                      Flags: bus master,
>> 66MHz, medium devsel, latency 64, IRQ 16
>>         Memory at fdffe000 (32-bit, non-prefetchable) [size=4K]  
>>         Kernel driver in use: ohci_hcd                           
>>         Kernel modules: ohci-hcd                                 
>> My system is a
>>
>> Linux  2.6.28-gentoo #12 SMP PREEMPT Mon Dec 29 21:01:04 CET 2008 x86_64
>> Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz GenuineIntel GNU/Linux
>>
>> Thanks for your time.
>
> It's most likely a BIOS bug, it somehow blows up when we tell it to
> give up control of the USB controller (the BIOS will control it
> initially to handle USB keyboard/mouse support). Is there an update
> available?

I just checked, but sadly there is none and I can't expect one: An OEM
manufacturer, the BIOS clearly states to be only for this manufacturer
and the sold "operating system" (Vista...) does not have this problem.
Sounds like out of luck.

Thank you anyway for identifying.

Best regards
Kai

-- 
This signature is left as an exercise for the reader.

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