tech-embed archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Stuck in biowait() again....



Hello all,

I have a strange situation occuring where it looks like biowait() is waiting for a buffer that never gets loaded via strategy(). I have looked over the archives and found some similiar situations. I found an old bug reference #3694/Kern that could explain my situation. What is the status of that bug?

Here is my situation:

I am building a diskless kernel on the evbarm platform. I am trying to debug a simple polled mode disk driver for a flash device. The driver is basically functional. The driver is implemented using a worker thread that is woken up by strategy() when new requests arrive. The worker thread processes all the requests on the queue, calling biodone() as needed and goes back to sleep. This appears to be working fine. Basic read/write operations seem to be working. I can mount a MSDOS filesystem from the device and walk through the directory tree. I can create and delete files. The problem first appeared when I starting using "cat" to read files larger than one block (512 bytes).

I can read small files (<512 bytes) perfectly. When trying to read a 513 byte file "cat" gets stuck inside biowait() in tsleep(). I added debugging to trace the buffer requests through each biowait(), biodone() and strategy() call. It looks like the buffer that biowait() is waiting for was never loaded into the cache. Every buffer request I receive via strategy() I see processed in the worker thread. I can not find a strategy() call for the buffer that causes the sleep in biowait()!

I must be missing something. This is my first netbsd block driver so maybe I am filling the buffer requests incorrectly? Are there other response fields in the buffer struct that I need to set? I set in b_bcount, b_resid, b_error and b_flags. What exactly are the rules on responding to the buffer requests? (I based my driver on a combination of the memory (md) and floppy (fd) drivers.)

Any help is greatly appreciated,

Sean



Home | Main Index | Thread Index | Old Index