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