Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
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` ? > > 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 > 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 > > -philipp > > [...] Another Question would be: Is there anyone on the LIST where DRBD+XFS works fine in a production environment? sebastian