[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48817FE3.7020907@simon.arlott.org.uk>
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)
Powered by blists - more mailing lists