Kernel Panic with mac-fdisk: It's reproducible...
This kernel panic happens on fast hardware just after the second sync()
following the ioctl() as Ethan wrote previously. I can reproduce the kernel
panic on two of my QuickSilver G4 dual 800 most of the time with vanilla
I wrote a little test case that reproduces this kernel panic most of the
time. the code doesn't need to write. Just read the partition map, sync +
reread it again = crash :-( Very basic.
On my slower machines (iBook, TiBook and my G4 Cube), it happens either
sometimes or all the time by lowering the sleep time before re-reading the
partition map. So as machine speed increase, it's doomed to happen more
The backtrace for your reading pleasure:
vector:0 at pc=c0039d14, lr = c0039d14
msr = 9032, sp cbdd1db0 [cbdd1cf8]
current cbdd0000, pid=1222, comm = readmap
This is under the latest kernel from benh's tree (2.4.15-pre2 as for
Feel free to ask me more info if you need additional details.
> From: Ethan Benson <firstname.lastname@example.org>
> Date: Sun, 11 Nov 2001 17:12:56 -0900
> To: email@example.com
> Subject: Re: installation success using 3.0.16 on iBook Dual USB / HOWTO
> Resent-From: firstname.lastname@example.org
> On Sun, Nov 11, 2001 at 09:37:26AM -0700, Tom Rini wrote:
>> So what happens exactly? Can you reproduce this on something and decode
>> the oops? Looking in 2.4.15-pre2 I don't see the mac partition table
>> stuffs not doing something the msdos ones do..
> enter the `w' command to commit a new partition table
> mac-fdisk writes out the new one, synced the disk
> mac-fdisk calls the reread ioctl
> kernel panics (sometimes)
> i cannot reproduce this sorry, the only time ive seen it personally
> was when partitioning a silver G4 i was setting up for someone, and i
> obviously cannot and will not destroy the installed debian system
> there in an attempt to reproduce this.
> one other note that just occured to me, i could only reproduce the
> problem on that G4 *once* and that one time was when i obliterated the
> crufty partition table containing all the macos crap, all subsequent
> partition tables were free of any driver cruft, only pure linux
> partitions and an Apple_Bootstrap. when setting it up i intentionally
> tried writing a few new tables just to see, could never reproduce it
> perhaps all that cruft has something to do with it? though i don't see how...
> Ethan Benson