Both of which I'd classify as bugs. I recently submitted a few patches
that fix some of the idiotic or bad error handling in the 2.4 SCSI
layer. Although they didn't completely fix some of the problems, it
did highlight some of the problem areas.
> On the other hand, the reason this has not
> happend just shows us, that it is not trivial to find a second person which
> understands hardware's error behaviour.
Or people with broken hardware don't report that the error paths are
broken; they just fix their hardware.
I have a Syquest 270MB drive here. Bought from new, but it has never
worked 100% properly. It mostly complains about media errors and the
like. After several rounds with Syquest, I lost faith in it. However,
I still have it. Why?
I keep test filesystems on the cartridges. Perfect when I want to run
some tests that could well take out a filesystem, or when I want to test
out the SCSI error handling. That's how I found that the 2.4 SCSI error
handling code has the possibility to eat disks alive when it encounters
Would extra API's have helped find this? Would it have made the driver
more stable? Would it have caught the bug in my SCSI driver that caused
it not to request sense on error and therefore throw the SCSI subsystem
into a never-ending loop? The answers are: no, no, no.
Would testing with broken hardware have found this? Would it make the
driver more stable? Yes, and yes.
IMO, driver stability comes with testing and review by people who know
both the hardware _and_ who know the kernel API inside out. There seems
to be a lack the latter, and a lack of people with broken hardware for
So next time when your hard disk develops media errors, or your network
card starts corrupting data, think about whether it would be a useful
test device to someone. (Obviously not if its completely 100% dead.)
-- Russell King (email@example.com) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/