On 17-Apr-2002 Terry Lambert wrote: >> What was consistent thru all test was, that the disk operates quite >> some time until the error occures the first time. After that, it is not >> possible to access the disk in UDMA-Mode any more, regardeless *which* >> UDMA-Mode it is. 'Quite some time' means approx. 50% of /usr/ports in >> the above mentioned 'test'. >> >> After the first switch to PIO4, I umounted the filesystem and switched >> back to UDMA33 for instance - I couldn't even *mount* the filesystem >> again! >> >> But w/o Tagged Queuing the disk operates flawlessly, so I'm a bit in >> doubt, if the errors with WD-disks have the same source... but may be. > > My hunch, which is why I suggested decreasing the number of > tags seen by the driver, is that the tagged queues are over > used, and this locks the disk up. My best guess is an off-by-one > or an exceptional condition handler that was not an issue until > recently, because of a FreeBSD interrupt architecture change > having nothing to do with the driver itself (i.e. the reason it > only happens under load, and didn't happen under the same load, > before).
Terry, we've had threaded interrupt handlers for over a year and a half now. If the had really broken things in this basic a fashion we wouldn't have made it this far with running systems. Your hypothesis about something busted in the tagged queueing code seems sound but blaiming this on interrupt threads doesn't make much sense to me. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message