Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 7 Jul 2012 22:19:40 +0400
From: Vasily Kulikov <>
Subject: Re: status of 2.6.32-based kernel


On Sat, Jul 07, 2012 at 06:34 +0400, Solar Designer wrote:
> On Fri, Jul 06, 2012 at 11:50:03PM +0400, Vasily Kulikov wrote:
> > The kernel successfully boots under Ubuntu userspace (initrd, etc.).
> > The last problem is booting the kernel under Owl userspace.  Under x86
> > and x86_64 it panics, in a bit different ways.  Both panics are related
> > to EVENT_TRACE feature.  Both call stacks show event_trace_init().
> > Tried both ISO (x86 and x86_64) and installed systems (only x86).
> Well, this means that the kernel is buggy (that specific kernel image at
> least), regardless of userland.  I wonder if the problem is also
> triggerable on OpenVZ's

Yes, I've tried OpenVZ's patch + OpenVZ's config with a single change:
CONFIG_SCSI_PMCRAID=n.  It panics in almost the same way (in the same
kernel_init function).

The change is needed because gcc fails with an error message:

  CC [M]  drivers/scsi/pmcraid.o
In file included from drivers/scsi/pmcraid.c:57:0:
drivers/scsi/pmcraid.h:611:8: error: duplicate member 'sense_buffer'

It might be too pedantic behaviour of gcc 4.7.  Probably gcc 4.7 is a
cause of the panic too.

> > I have a problem identifying the real root of the problem.  Either the
> > kernel is not buildable or it builds but panics with the same
> > event_trace_init() in the call stack.
> Have you recorded that stack trace?  Is there an Oops?  If so, have you
> tried looking at the faulting instruction and matching it against the
> source code?

It is an effort to execute bytes at .rodata:

	EIP is at .LC311+0x7737/0x189e3
	call trace:
	c0a7f9ff kernel_init+0xe9
	c0a7f816 kernel_ini+0x0
	EIP c0955014

EIP is in .rodata, c0a7f9ff is an address at do_initcalls() of
do_one_initcall(*call) call.

> > Looks like I should go with EVENT_TRACE=n and patch 3-5 source files to
> > be buildable.
> What setting do upstreams (OpenVZ, Red Hat) use for this?  "=y" I guess?


> If so, do they avoid the panics somehow - lack the bug in the kernel or
> lack a property of the userland that triggers the bug?

I'm confused -- the bug is triggered before any userland interaction.
However, it boots OK as a part of Ubuntu initrd :-\  Tried to recompile
it several times with minor changes (DRM_NOUVEAU=n because of Xorg-stage


Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.