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 <[EMAIL PROTECTED]> > Date: Mon, 12 Nov 2001 15:27:29 +0100 (CET) > To: Laurent de Segur <[EMAIL PROTECTED]> > 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 > >
