Re: Kernel Panic with mac-fdisk: It's reproducible...
> From: Michael Schmitz <schmitz@opal.biophys.uni-duesseldorf.de>
> Date: Mon, 12 Nov 2001 10:54:36 +0100 (CET)
> To: Laurent de Segur <ldesegur@mac.com>
> Cc: <debian-powerpc@lists.debian.org>
> Subject: Re: Kernel Panic with mac-fdisk: It's reproducible...
>
>> 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.
>
> Now does this happen on other architectures as well (with Mac partitions),
> or other partition table formats?
>
I'll try to check on some x86 early this week. I don't have an ETA for that.
I'll do my best. My server farm and *tops are mostly Macs (running Debian.)
>> 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.
>
> What time to usleep() seems enough to prevent this from happening? I'll
> add a short sleep in mac-fdisk as a workaround while this is being fixed
> on the kernel side.
>
The sleeps are already in write_partition_map() (partition.c if memory
serves well), one of 2, the other of 4. I doubled these values prior to
recompiling pdisk last night and this workaround seemed ok for the faster
cpu machines. This is strange as I thought that the sleep time was
independent of cpu speed, and the last task should finish earlier on faster
machines. Weird.
Of course, I can not guarantee that it won't crash anymore. It just doesn't
easily anymore. BTW, you may want to lower these values to reproduce easily
on your system.
>> vector:0 at pc=c0039d14, lr = c0039d14
>> msr = 9032, sp cbdd1db0 [cbdd1cf8]
>> current cbdd0000, pid=1222, comm = readmap
>
> That's mostly chinese for me without being fed through some ksymoops like
> tool (or your System.map; what's near c0039d14 in System.map?)
>
Michael, that's mostly Chinese for me even with the tool ;-)
Here are the two address in my System.map braketing the lr:
c0039c38 T invalidate_bdev
c0039db8 T __invalidate_buffers
Let me know if you need anything.
Thanks a lot,
LdS
> Michael
>
>
Reply to: