Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Am Mittwoch, 13. April 2005 08:55 schrieben Sie: > On Tue, 2005-04-12 at 18:47 +0200, Philipp Reisner wrote: > > Do you compiled the kernel by yourself, or is it a vendor kernel ? > > It is a self compiled vanilla kernel. Preemption, APM, ACPI and the > usual error suspects are not enabled in this kernel. > > > When you reproduce the OOPS, does it always happen in > > recalc_sigpending_tsk ? > > I only have one documented trace so far. Maybe I'll be able to reproduce > it this week again. > > > Have you already checked if the machine is okay ? Memtest86 etc... > > The memory is out of question. The system runs fine when it is primary > and no second node is up. The crashes only happen with a secondary node > involved. > > > Basically the call trace seems to be ok, only the > > blk_plug_device line is there a bit strange. But so far so good... > > The other strange thing is that there is no process name!!! > > > > -> These two facts point to the assumption that the current pointer > > was not valid in recalc_sigpending_tsk(). But this is only > > an educated guess. > > To know for real I would need the ./kernel/signal.c file > > compiled with your settings and compiler but > > the "-c" replaced with "-gstabs+ -S". > > I'm not sure how to do that. > Just do a `gcc -gstabs+ -S signal.c` ? Compile your kernel whith "make bzImage V=1" and capture the line where it compiles signal.c. The replace "-c" with "-gstabs+ -S" and "signal.o" with "signal.S" and run that line. Then send me the resulting "signal.S" file. > > > BTW, do you have any strange things enabled ? Maybe kernel-preemption ? > > The only thing that might differ from other kernels is the stack size. > "Use 4Kb for kernel stacks instead of 8Kb" > CONFIG_4KSTACKS=y > Well, I guess this could it be !! We have strange things on top of the stack, the stack trace is extremely long. Yes please retry with an 8kb kernel stack instead. Please try the 8KB stack first, it is much less effort than the signal.S path... > > PS: Is there anyone on the list who has the same XFS+DRBD crashes ? > > I know of at least one person who has the same crashes with xfs and > drbd, also only when syncing with a secondary node. He is currently > running kernel 2.6.11 and drbd 0.7.11 > http://lists.linbit.com/pipermail/drbd-user/2004-December/002380.html > There is no trace, whatsoever. -Philipp -- : Dipl-Ing Philipp Reisner Tel +43-1-8178292-50 : : LINBIT Information Technologies GmbH Fax +43-1-8178292-82 : : Schönbrunnerstr 244, 1120 Vienna, Austria http://www.linbit.com :