One error report stated that a MO drive with a vfat
fs based on 2048 byte sectors can be mounted and read
but any significant write causes a system lockup. I
have been able to replicate this behaviour. Luckily
Alt-SysRq-P did work. Pressing this sequence multiple
times gave similar addresses. Rebooting the machine
and rerunning the experiment multiple time gave
addresses in the same area.
The EIP resolved most often to cont_prepare_write() in
fs/buffer. A disassembly suggests line 1802 in buffer.c
[2.4.3ac11]. That is around a memset() between
__block_prepare_write() and __block_commit_write() calls
within the while loop. Most other addresses were within
the same while loop. Perhaps someone with expertize
in this area may like to examine that loop.
Details: I modified the "scsi_debug" adapter driver to look
like it had one 2048 byte block MO drive connected to it.
The driver uses 8 MB of RAM to simulate a storage device.
[For anyone who wants to run similar experiments, I have
placed the driver at www.torque.net/sg/p/scsi_debug_mo.tgz ].
The sequence of commands that lead up to the failure was:
$ modprobe scsi_debug
$ cat /proc/scsi/scsi # "optical" device should be there
$ fdisk -ul /dev/sdb # should see 3 partitions
$ mkdosfs -S 2048 /dev/sdb3
$ mount /dev/sdb3 /mnt/extra
$ cd /mnt/extra
$ touch t # worked ok
$ cp /boot/vml-2.2.18 u # system locks up
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/