[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 7 Jul 2012 22:19:40 +0400
From: Vasily Kulikov <segoon@...nwall.com>
To: owl-dev@...ts.openwall.com
Subject: Re: status of 2.6.32-based kernel
Solar,
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?
Yes.
> 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
panic).
--
Vasily
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
