Robert Watson wrote: >>It means that the disk has processed the write request (interrupt seen), >>but that the system (the bio_taskqueue) hasn't been able to get the >>result returned to the kernel. >> >>Your disk is not involved in this problem since it has done its part, >>but the rest of the system is either busy with something else, or there >>are bugs lurking that prohibits the bio_taskqueue from running. >> >>Either way its a WARNING not a FAILURE :) > > > I'm still a bit skeptical that the task queue is at fault -- I run my > notebook with continuous measurement of the latency to schedule tasks, > generating a warning for any latency > .5 seconds, and the only time I > ever see that sort of latency is during the boot process when ACPI has > scheduled a task to run, but the task queue thread has not yet been > allowed to run: Right, the timeout is 5 secs. I havn't looked into how the taskqueues are handled recently, but in case of ATA read/writes it is the bio_taskqueue handled by geom thats in use not the catchall ones, does your timing cover that as well? There are several explanations for what happens: 1. the bio_taskqueue is not pushing requests through. 2. the disks takes long to respond and uses almost all of the 5 secs 3. timeouts are not working and fireing at random. I cannot reproduce the symptoms on any of my HW no matter how hard I hit it, and I dont really belive in items 2 and 3 above, however I've been proven wrong before :) -- -SørenReceived on Wed Nov 10 2004 - 08:41:32 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:21 UTC