Re: new panic (was: Re: "busy buffer problem" panics)

[Andrew Atrens <atrens@xxxxxxxxxxxxxxxxxx>]

Matthew Dillon wrote:
 
>     It can't be line 119 of linux_util.c, that's in the middle of a
>     comment
>     if you are using the patch I posted.  If you are not using the patch
>     I posted then you need to try the patch.
> 
>     I've included it again below.  This one also contains some linprocfs
>     fixes in addition to the original linux_util.c patch.  Make sure you
>     are running a kernel with this patch and see if it panics... if it
>     does, get a another core dump and backtrace (and hopefully it won't
>     list a line number that is in the middle of a comment).

:) Yah, I re-updated my sources and lost the patch. Since it panicked both
with and without the patch I was thinking I'd ship you version 1 first ...

Version 2 will take about 1 1/2 hours. I need to -

  1. Patch and rebuild my kernel
  2. Reboot and panic the system
  3. Reboot again (same kernel) fsck and savecore
  4. Reboot again (working kernel) and fsck

Each fsck cycle takes almost 20 minutes.
Rebooting with the broken kernel (not counting the fsck) takes about
5 minutes. This is because my SATA controller has started showing up -

atapci0: <SiI 3112 SATA controller> port 0xa400-0xa40f,0xa000-0xa003,0x9c00-0x9c07,0x9800-0x9803,0x9400-0x9407 mem 0xe5801000-0xe58011ff irq 10 at device 11.0 on pci1

and then after a couple of minutes of hanging I get a message about a ghost drive -

ata2: at 0x9400 on atapci0

I guess I should just open the case and pull the jumper that enables
this controller since I'm _not_ using it, and it is slowing down the boot. :)

The reason I need step 3 is pretty bizarre - when I boot
with a working kernel savecore doesn't find anything to save - so
I don't get a vmcore to analyse :( :(

Not sure why this is.

The reason I need to do a full fsck is that the vmcores are too big
to fit in /var/crash, so they go in /usr/crash (and /usr is pretty
big) ;)


Andrew.