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]

Date:	Sat, 19 Jul 2008 06:47:15 +0100
From:	Simon Arlott <simon@...e.lp0.eu>
To:	Arjan van de Ven <arjan@...radead.org>
CC:	linux-kernel@...r.kernel.org, mingo@...e.hu, dwalker@...sta.com
Subject: Re: [patch 0/3] fastboot patches series 1

On 19/07/08 06:16, Arjan van de Ven wrote:
> 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?
> 

Yes it's always been stable before. It's as if it's polling the mouse 
too infrequently.

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

It doesn't.

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

The TSC should be in sync on both CPUs by that stage:
[    0.000000] TSC calibrated against PM_TIMER
[    0.109983] checking TSC synchronization [CPU#0 -> CPU#1]: passed.
[    0.183971] checking TSC synchronization [CPU#0 -> CPU#2]: passed.
[    0.257960] checking TSC synchronization [CPU#0 -> CPU#3]: passed.
[    0.332923] checking TSC synchronization [CPU#0 -> CPU#4]: passed.
[    0.405937] checking TSC synchronization [CPU#0 -> CPU#5]: passed.
[    0.478926] checking TSC synchronization [CPU#0 -> CPU#6]: passed.
[    0.551902] checking TSC synchronization [CPU#0 -> CPU#7]: passed.

> can you also post a dmesg of a successful boot?
> 

The "before" output is a successful boot without the patches. I've 
included the post-startup in "before" this time.

> (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 ;-)

I've yet to get around to avoiding that, ati/radeonhd just cause the 
display to turn off... I can avoid loading it if required, but X 
performance suffers badly.

-- 
Simon Arlott



View attachment "dmesg-after-fastboot-2" of type "text/plain" (117719 bytes)

View attachment "dmesg-before-fastboot-2" of type "text/plain" (115297 bytes)