> From: Michael Schmitz <[EMAIL PROTECTED]> > Date: Mon, 12 Nov 2001 10:54:36 +0100 (CET) > To: Laurent de Segur <[EMAIL PROTECTED]> > 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 > >
