Re: Kernel Panic with mac-fdisk: More Info

[Laurent de Segur <ldesegur@mac.com>]

Michael,

Forget about my non-sense with the x86 crap. R3 and R4 are pointing to valid
strings. I forgot about offsetting values by one when reading addis/addi
opcodes as I was getting tired. I just needed a good night sleep.

I've increased substantially the number of sync() (a dozen with small loops
in betweens.) Same crash. So, my guess is: sync() won't solve it.
Independently from this, it came to a point last night where I couldn't
reproduce this. I had to reinstall macos and then rerun mac-fdisk to get to
the bug again. Now I get it again. Painful experience. This makes me believe
that it must be some timing issue.

Now that I know what the code looks like (thanks to you), I will give you
the extra info as soon as I run it again (this evening.) Sorry about the
delay.

One thing I would like to know: can I drop into the 'mon' and set a break
point in the kernel code, then restart and trace when I hit the break point?
Does kernel trace works on PPC? I'll stfw for these info, but if you can
give me a quick pointer, I'll read and study that.

Thanks again for your help,

LdS

> From: Michael Schmitz <schmitz@opal.biophys.uni-duesseldorf.de>
> Date: Tue, 13 Nov 2001 12:20:07 +0100 (CET)
> To: Laurent de Segur <ldesegur@mac.com>
> Cc: <debian-powerpc@lists.debian.org>
> Subject: Re: Kernel Panic with mac-fdisk: More Info
> Resent-From: debian-powerpc@lists.debian.org
> Resent-Date: Tue, 13 Nov 2001 03:20:27 -0800 (PST)
> 
>> The crash always happens with lr pointing to c0039d14 so apparently the test
>> at c0039cf0 fails and the kernel is trying to tell me something (printk)
>> except that I don't see it (no flush?). Apparently the message is still for
>> x86 (ead is a x86 right?).
> 
> Maybe you don't see it because BUG() maps to calling both printk and
> xmon.. That would mean we hit a buffer head that has just been unmapped
> from under us. Turn that BUG() into a call to printk and panic instead...
> 
> My guess is it crashes on the next line (buffer_dirty(bh))... what's in
> r31?