Fajar A. Nugraha wrote:
On Wed, Feb 18, 2009 at 7:43 PM, Mark Johnson <[email protected]> wrote:
Assuming it hangs at the above, adding nosmp should allow
the machine to boot.. Assuming it does, we'll have to start
looking at why...
Whoa, you totally nailed it!
Adding nosmp DOES allow the machine to boot!
At least now we know where to start looking for the problem :)
if it stuck at a driver trying to attach, you can add
a disable-<drivername> to the -B line to skip over that
driver to see if the system will boot without that driver
(like you did with qlc).
Here's the weird part. Even though I booted with disable-qlc=true,
booting with "-v" shows numerous error message about "Unable to
install/attach driver 'qlc".
http://pastebin.com/f2c6f465c
Probably just a side effect of the disable..
And now, another weird part: booting xen kernel, with nosmp, but
WITHOUT "disable-qlc=true", WORKS!
http://pastebin.com/f40c861b9
Yeah, I see that qlc attaches fine too
qlc0 is /p...@0,0/pci8086,2...@5/pci103c,1...@0
PCIE-device: pci103c,1...@0,1, qlc1
qlc1 is /p...@0,0/pci8086,2...@5/pci103c,1...@0,1
Can you do a
mdb -k
[0]> ::interrupts
[0]> $q
and see if anything is sharing the interrupt with qlc?
Is this enough, or do you still need the output of "findstack" to find
which driver is trying to attach?
Yeah, I'd like to see what driver is causing it.
As a comparison, on normal kernel (snv_99+), disable-qlc=true is
enough to allow the system to boot. So I'm guessing there's a serious
bug, most likely on qlc driver, which manifests on this particular
hardware configuration (HP blade, QLogic Corp. ISP2432-based 4Gb Fibre
Channel to PCI Express HBA (rev 02)). It works perfectly on snv_98.
Might be another device which is interacting with qlc due
to sharing interrupt... On Xen, the interrupts are routed
differently so different devices share different interrupts.
I'm guessing it's a USB driver which is the actual culprit.
MRJ
Regards,
Fajar
_______________________________________________
xen-discuss mailing list
[email protected]
