https://bugzilla.novell.com/show_bug.cgi?id=413842
User jbeulich@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=413842#c6
--- Comment #6 from Jan Beulich 2008-08-04 01:48:32 MDT ---
I'd definitely like to see a native boot's /var/log/boot.msg.
Apart from that, since the b44 driver isn't being used, I agree that the mem=1G
workaround is unlikely to help here.
The module list supplied, however, indicates quite a number of modules that
could be candidates - the primary candidate would obviously be the driver that
loads last before the hang (the second of the logs you attached appears to
indicate that's the mpt* group of modules, but that otoh seems inconsistent
with the order of modules in the module list you supplied, which suggests those
modules get loaded from initrd). The next best candidates would be all other
drivers sharing the IRQ with this one. Finally, further suspects are iTCO_wdt,
dcdbas, bnx2, i5000_edac, shpchp, megaraid_sas. I realize particularly the last
as well as the mpt* group may be required to boot the system fully, but since
it isn't getting this far, suppressing them should be fine for our purposes.
And yes, black listing the drivers in question ought to be one method of
suppressing their loading, except when they're loaded from initrd. In that
latter case, you may need to temporarily alter INITRD_MODULES in
/etc/sysconfig/kernel or rename/move away the driver files from
/lib/modules/<version>/kernel/ and then force initrd-xen to be rebuilt. But
perhaps trying the post-initrd modules first would already give enough
information.
Btw., please also append "loglvl=all guest_loglvl=all" to your Xen command
line, and you might be able to overcome the missing-lines-at-the-end problem by
using the (debug-only!) Xen option "sync_console".
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.