On 19/07/08 06:16, Arjan van de Ven wrote:
quoted text
> On Sat, 19 Jul 2008 05:51:44 +0100
> Simon Arlott <simon@fire.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.

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

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

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

quoted text
> (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