Re: Kernel Panic with mac-fdisk: More Info

[Michael Schmitz <schmitz@mail.biophys.uni-duesseldorf.de>]

> I tried putting up to 5 sync() and even moving the close_partition() call at
> the end (making a total of 10 sync()). It still crashes but less frequently
> with this mod.

Another idea: increase the sync delay or number of syncs before the ioctl.

> Find below the disasm of the whole function as you asked.


Mapping to this section of invalidate_bdev():

			write_lock(&hash_table_lock);
			/* All buffers in the lru lists are mapped */
			if (!buffer_mapped(bh))
			        BUG();			<-- here
			if (buffer_dirty(bh))		<-- or here
			        printk("invalidate: dirty buffer\n");
			if (!atomic_read(&bh->b_count)) {
			        if (destroy_dirty_buffers || !buffer_dirty(bh)) {
			                remove_inode_queue(bh);
			        }
			} else
			        printk("invalidate: busy buffer\n");

> The crash always happens with lr pointing to c0039d14 so apparently the test
> at c0039cf0 fails and the kernel is trying to tell me something (printk)
> except that I don't see it (no flush?). Apparently the message is still for
> x86 (ead is a x86 right?).

Maybe you don't see it because BUG() maps to calling both printk and
xmon.. That would mean we hit a buffer head that has just been unmapped
from under us. Turn that BUG() into a call to printk and panic instead...

My guess is it crashes on the next line (buffer_dirty(bh))... what's in
r31?

	Michael