linux-kernel - Re: 2.6.22-git17 boot failure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <46A51079.5030006@goop.org>
Date:	Mon, 23 Jul 2007 13:32:57 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Tilman Schmidt <tilman@...p.cc>
CC:	LKML <linux-kernel@...r.kernel.org>, andi@...stfloor.org,
	nix.or.die@...glemail.com, Roland McGrath <roland@...hat.com>
Subject: Re: 2.6.22-git17 boot failure

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/