Re: Kernel Panic with mac-fdisk: It's reproducible...
Michael,
Oki doki. I'll try to do all of that as soon as I get back tonight.
Heigh-Ho, Heigh-Ho, It's work from home I go.
LdS
> From: Michael Schmitz <schmitz@mail.biophys.uni-duesseldorf.de>
> Date: Mon, 12 Nov 2001 15:27:29 +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...
>
>>> 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.)
>
> Thanks; I'll wait for that.
>
>>> 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.
>
> The sleep should be CPU speed independent indeed. But it shouldn't ever be
> necessary. Neither should the first sync (BLKRRPART invalidates the device
> thereby flushing all data to disk first). I really wonder what these
> sleep()s are meant for.
>
> Please try another thing: move the close_device() after the second
> sync/sleep pair. Or double each sync(). If we go the voodo path, we may as
> well go all the way ;-)
>
>> 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.
>
> I'll take them out for starters.
>
>>>> 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
>
> That's a good clue. Now I need you to "objdump -d
> --start-address=0xc0039c38 vmlinux " your kernel image and post the
> section up to and a few lines beyond the PC value.
>
> Michael
>
>
Reply to: