linux-kernel - Re: [patch 0/3] fastboot patches series 1

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: <20080718221630.2809abbd@infradead.org>
Date:	Fri, 18 Jul 2008 22:16:30 -0700
From:	Arjan van de Ven <arjan@...radead.org>
To:	Simon Arlott <simon@...e.lp0.eu>
Cc:	linux-kernel@...r.kernel.org, mingo@...e.hu, dwalker@...sta.com
Subject: Re: [patch 0/3] fastboot patches series 1

On Sat, 19 Jul 2008 05:51:44 +0100
Simon Arlott <simon@...e.lp0.eu> wrote:

> 
> This is a great idea... I was thinking about trying to run usb 
> initialisation in parallel because it takes so long. It would be more 
> useful to run usb init in parallel with ide/sata on my system, since
> they both take a while to run (I realise /dev/sd* will be in a
> unstable order).
> 
> Unfortunately this patch set has the opposite effect on my system...
> something appears to be going badly wrong (logs attached). The mouse 
> pointer was really erratic so I reconnected it (by turning the hub in 
> my display off/on)... that took a while:

is this repeatable? and was it repeatedly stable before?


> 
> Strangely, when this output appeared:
> [    1.370693] ehci_hcd 0000:00:02.1: USB 2.0 started, EHCI 1.00,
> driver 10 Dec 2004
> 
> I didn't see anything else until the next screenful of output, but
> the log shows this output before that:
> [    4.683674] usb usb1: default language 0x0409
> [    7.548621] usb usb1: uevent
> 
> There was another long pause with no output but I can't see where
> from reading back the log. The timestamps are a bit confused too,
> jumping +/-10s.

looks like you have a timing problem.. can you try booting with "notsc"
and see if that fixes it?


One possible theory is that we now run on both cpus and if they're out
of sync timewise, things like delays suddenly are shorter than expected
if time jumps around....

can you also post a dmesg of a successful boot?

(and I'm supposed to give you a hard time for using a proprietary
module, but something is clearly going wrong before it's even loaded so
for now I'll just ignore that ;-)
--
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/