> > 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