Re: 2.6.22-git17 boot failure

[Jeremy Fitzhardinge <jeremy@goop.org>]

Tilman Schmidt wrote:
> To answer that, I have reproduced the effect with kernel 2.6.23-rc1 with
> netconsole compiled in. I'm attaching both captures, for CONFIG_XEN=y
> (unsuccessful) as well CONFIG_XEN=n (successful).
>
> The first noticeable difference is that the nonzero timestamps starting
> after the line "Detected 3197.059 MHz processor" are much bigger with XEN -
> but perhaps that's expected.
>   

Not at all.  None of the Xen time machinery should be coming into play.

> More to the point, everything from:
>
>   SCSI subsystem initialized
>
> on is completely missing, including all the [S/P]ATA, SCSI, parport, AGP,
> USB, Firewire, RTC and of course ext3 messages. Only the "device-mapper"
> line still appears.

I'm flat out confused.  The only CONFIG_XEN dependencies in the kernel are:

   1. head.S and entry.S, which enable completely no-op pieces of code
      when not running under Xen
   2. The vdso code, which shouldn't play a role here
   3. The whole of arch/i386/xen/, which doesn't get enabled unless you
      run under Xen

There's flat out no way that your kernel would be booting if any of the
Xen code were actually being run, since it would fall over very quickly
without the hypervisor being present.  And anyway, the message "Booting
paravirtualized kernel on bare hardware" tells us we're not using the
Xen code.

How much of this is modules?  Is the initrd probing for scsi/sata? 
Maybe the the vdso change is having an effect.

Ooh, wait.  Do you have an old version of the Xen patches in place,
perhaps?  Does drivers/block/Makefile have:

obj-$(CONFIG_XEN_BLKDEV_FRONTEND)	+= xen-blkfront.o

(vs := xen-blkfront.o)  Not that it should have any effect on scsi drivers.

Could you do a before and after booting with initcall_debug=1?

Thanks,
    J