Date: Wed, 25 Feb 1998 14:24:28 -0700 From: "Justin T. Gibbs" <gibbs@plutotech.com> To: Karl Denninger <karl@mcs.net> Cc: "Justin T. Gibbs" <gibbs@plutotech.com>, hackers@FreeBSD.ORG Subject: Re: SCSI Sense ASC 11, ASCQ 0x0c - Unrecovered read errors Message-ID: <199802252127.OAA26422@pluto.plutotech.com> In-Reply-To: Your message of "Wed, 25 Feb 1998 15:10:42 CST." <19980225151042.07314@mcs.net>
next in thread | previous in thread | raw e-mail | index | archive | help
>> If the system is not properly dealing with EIO conditions, that is >> certainly a bug, but your suggested fix is not a correct solution. > >This condition, right now, causes a *HANG* if it happens on *DATA FILES*. > >Not a panic, not an error return, not termination of the offending process. >A hard system crash which requires a RESET to recover from. Was it really necessary to quote the entire message to make this point? If the system is hanging, it is definitely a bug. I'll add it to the list of other VFS bugs Ken and I are planning to look at. We are playing around quite a bit with hot swap and error recovery and we've been finding that in many cases the SCSI code cleans up and reports errors correctly, but other kernel subsystems do not. For instance, you often cannot "umount -f" a disk with dirty buffers that had a catastrophic I/O error even though that error was properly reported all the way down to the application. >-- >Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin >http://www.mcs.net/ | T1's from $600 monthly to FULL DS-3 Service > | NEW! K56Flex support on ALL modems >Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS >Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802252127.OAA26422>