On Wed, 2009-09-30 at 08:08 -0700, David Woodhouse wrote: > On Wed, 2009-09-30 at 16:32 +0200, Arnaud Patard wrote: > > > > Andrew Patterson <andrew.patterson@...> writes: > > > > > > > > Hi Dave, > > > > > > I am getting MCAs on my ia-64 system (an hp rx8640) using 2.6.31. A > > > bisection showed that your patch, > > > db8be50c4307dac2b37305fc59c8dc0f978d09ea, seems to be to blame. I > > > haven't done any more investigation yet other than to revert the > > patch > > > which makes the problem go away. > > > > After bisecting, I found out too that this change broke my arm > > machine. With it, the serial console output is stopping at > > 'done. Booting the kernel'. Reverting cures the issue. > > This patch wasn't supposed to be that exciting. All it does is shift the > existing code to shut down USB controllers so that it runs a little > earlier -- it's now a PCI _header_ quirk, instead of a PCI _final_ > quirk. So it runs when we first detect the devices. > > I suspect that on IA64 and ARM, these functions are using some kernel > infrastructure that isn't yet set up. Can someone catch the actual crash > (you'll need an early console, or a debugger) so we can work out > precisely what's going wrong? An MCA brings down our system immediately, so console output won't help much. Our MCA analyzer is complaining about accessing a memory hole consistently at the same address. I am going to try adding some trace code. Note that our low-end ia-64 boxes don't have this problem. > > Just working out which of the four ([uoex]hci) quirks which is causing > the problem might be helpful. > -- Andrew Patterson Hewlett-Packard -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
