linux-kernel - bug in DH77EB spurious reboot quirk handling (drivers/usb/host/xhci.c)

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

Message-ID: <5192b1cb.LascK3gsSDL181fc%jpmg@eng.cam.ac.uk>
Date:	Tue, 14 May 2013 22:51:07 +0100
From:	Patrick Gosling <jpmg@....cam.ac.uk>
To:	linux-kernel@...r.kernel.org
Subject: bug in DH77EB spurious reboot quirk handling
 (drivers/usb/host/xhci.c)

There is a known bios problem with Intel DH77EB motherboards, described
here: <http://lkml.indiana.edu/hypermail/linux/kernel/1209.2/00222.html>

I have such a board, and am running the 3.8.0-ish kernel distributed
in the ubuntu 13.04 linux-image-3.8.0-19-generic package.  I apologise
for not having (yet) tried a more vanilla kernel source;  I will do
so imminently.

However, the ubuntu kernel includes the patch described in the url above,
and I can see no obvious reason why it should fail to have effect.

Observably, the patch didn't work on my machine - attempts to power the
machine off, while wake-on-lan was supported, would result in a spurious
reboot.

In attempting to identify the problem, I added (among some debugging
prints), an msleep(1000) immediately after the usb_disable_xhci_ports()
call in drivers/usb/host/xhci.c .

This fixed the problem;  I am now running a kernel whose only change is
the insertion of that "msleep(1000);".  The machine now powers off 
correctly.

This leads me to suspect that (possibly because the machine is quite fast
at shutting down), there is a timing issue with this quirk fix.

I don't think that just adding a 1s sleep is very satisfactory, however.

I could try tweaking the duration of the sleep downwards until it
stopped working, but this would seem likely to result in finding that
"it _usually_ works", which isn't at all satisfactory. 

I wonder if anyone has any ideas as to what one might want to wait
for, to ensure that the disabling of the xhci ports has actually taken
effect, before continuing the shutdown ...

With best wishes,

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