Hi, 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 mac-fdisk.
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 often. 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 tonight.) Feel free to ask me more info if you need additional details. LdS > From: Ethan Benson <[EMAIL PROTECTED]> > Date: Sun, 11 Nov 2001 17:12:56 -0900 > To: debian-powerpc@lists.debian.org > Subject: Re: installation success using 3.0.16 on iBook Dual USB / HOWTO > Resent-From: debian-powerpc@lists.debian.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 > again. > > perhaps all that cruft has something to do with it? though i don't see how... > > -- > Ethan Benson > http://www.alaska.net/~erbenson/ >
