write access to dos partition hangs system completely

[David Schultz]

On Sun, Jun 15, 2003, Andreas Klemm wrote:
> FreeBSD titan.klemm.apsfilter.org 5.1-RC FreeBSD 5.1-RC #0: Sun Jun  1 14:21:32 CEST 2003     root at titan.klemm.apsfilter.org:/usr/src/sys/i386/compile/TITAN5  i386
> 
> When I mount my dos partition read write and copy
> some data to it it immediately freezes the system.
[...]
> da0: Attempt to query device size failed: NOT READY, Medium not present
> (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 
> (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error
> (da0:umass-sim0:0:0:0): SCSI Status: Check Condition
> (da0:umass-sim0:0:0:0): NOT READY asc:3a,0
> (da0:umass-sim0:0:0:0): Medium not present
> (da0:umass-sim0:0:0:0): Unretryable error
> Opened disk da0 -> 6
> (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 
> (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error
> (da0:umass-sim0:0:0:0): SCSI Status: Check Condition
> (da0:umass-sim0:0:0:0): NOT READY asc:3a,0
> (da0:umass-sim0:0:0:0): Medium not present
> (da0:umass-sim0:0:0:0): Unretryable error
> Opened disk da0 -> 6
> Mounting root from ufs:/dev/ad2s2a
> ad0: hard error cmd=read fsbn 115471868 of 115471868-115471871 status=51 error=40
> pid 640 (squid), uid 65534: exited on signal 6
> pid 674 (squid), uid 65534: exited on signal 6
> pid 676 (squid), uid 65534: exited on signal 6
> pid 678 (squid), uid 65534: exited on signal 6
> pid 680 (squid), uid 65534: exited on signal 6
> ad0: hard error cmd=read fsbn 115471868 of 115471868-115471871 status=51 error=40
> ad0: hard error cmd=read fsbn 115471871 status=51 error=40
> ad0: hard error cmd=read fsbn 115471868 of 115471868-115471871 status=51 error=40
> ad0: hard error cmd=read fsbn 115471871 status=51 error=40

I don't know which of these devices your DOS partition is on, but
the root problem seems to be the hardware.  That said, msdosfs
does hang when a write error occurs, so that may be your problem.
(It gets into a loop in which it retries forever.)  I submitted
kern/37035 regarding this over a year ago, although I don't know
to what extent the original problem or the trivial patch I posted
still apply to 5.X.