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.