> "mount /dir/file -r -t iso9660 -o loop /mnt" will lockup 2.1.95
> everytime.
>
> Dual P166, 64Mb, no IDE. AHA1542C (no devices turned on), ASUS-SC875
> ultra-wide, two disks and a CD-R. /dir is /dev/sdb6.
>
> Patched to scan for NCR53c8xx before AHA1542 but it locks up on stock
> 2.1.95 as well. Added kernel trace patches, at the hang it shows :-
>
<snipped>
> bread+<10/90>
> getblk+<13/344>
> get_hash_table+<10/70>
> find_buffer+<f/58>
> init_buffer+<f/4c>
> ll_rw_block+<13/190>
> make_request+<13/598>
> add_request+<13/290>
> nlm_program+<b37b/f038>
> bmap+<d/34>
> ext2_bmap+<13/238>
> bread+<10/90>
> getblk+<13/344>
> get_hash_table+<10/70>
> find_buffer+<f/58>
> init_buffer+<f/4c>
> ll_rw_block+<13/190>
> make_request+<13/598>
>
> No disk response after that, switch VT works, sysrq works, no commands
> work.
Just my 0.02 French Francs:
Looking at the trace dump that looks like a recursive call to bread that
probably did lock some SMP lock against itself, it seems to me that the
system locked up without having sent any request to the SCSI sub-system.
So, I would be very surprised if the lock-up is related to the ncr53c8xx
driver or the generic SCSI code. The culprit seems likely the loop device
driver that, by design, may trigger such kind of recursion.
Gerard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu