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: