mrd@sun.soe.clarkson.edu (Michael DeCorte) (06/13/89)
Hello, I hope someone can help me with a problem I have been having. I am modifying a tape driver for V68 (Motorola's SysV.3 for 680x0's). After reading the code I am left with a few questions. The code uses disjointio but I can't find any docs on it. as best as I can tell I you pass it an memory location of an object the size of the object and an array that gets filled up with the real address for each fragment of the object. But I don't know if there are any side affects. I assume that it will pull in any pages that aren't in real memory off of disk but does it lock them? If it does how do they get unlocked? You see I can't find any place where the memory pages are getting locked or unlocked. If disjointio doesn't do the locking who does? I have some ATT docs that say dma_breakup can do it but these same doecs say "If your device has special hardware for performing scatter-gather transfers you should not use this routine." Well I have scatter-gather transfers and if my guess is correct using dma_breakup will give me a very large penalty. "Writing a Unix device driver" says I should use vslock and vsunlock but I don't have these routines. (I checked with nm). So if you know what disjointio does or how to lock or unlock page or what manual/book/whatever documents this stuff please drop be a note. thanks -- Michael DeCorte // (215)546-0497 // 2300 Naudain St. "H", Phil, PA 19146 Internet: mrd@sun.soe.clarkson.edu // Bitnet: mrd@clutx.bitnet --------------------------------------------------------------------------- Clarkson Archive Server // commands = help, index, send, path archive-server@sun.soe.clarkson.edu archive-server%sun.soe.clarkson.edu@omnigate.bitnet dumb1!dumb2!dumb3!smart!sun.soe.clarkson.edu!archive-server ---------------------------------------------------------------------------
jcg@tree.UUCP (John Gonnerman) (06/14/89)
In article <MRD.89Jun12135314@sun.soe.clarkson.edu>, mrd@sun.soe.clarkson.edu (Michael DeCorte) writes: > I hope someone can help me with a problem I have been having. I am > modifying a tape driver for V68 (Motorola's SysV.3 for 680x0's). [discussion of unclear docs...] I, too, have a device-driver problem on a Motorola system running SysV/68. I have a Xylogics XY772 tape drive controller which runs a Cipher-compatible tape drive for a Motorola 8400E. The device driver provided by the vendor was written for Release 2 Unix, which does not have virtual memory. After the VAR's programmers were done with it, it worked...sort of. The system has problems with the drive...if you try to do a tape operation while the tape is being processed already, the first program becomes locked in the device driver. The process won't die, not even for kill -9, and in turn causes problems when you shut down, since the process is tying up a file system. The tape drive becomes totally inaccessible at this point, thus necessitating a reboot and fsck. The problems, it appears, don't come from the VAR's work, though...Xylogics sent us a copy of the "new" device driver, complete with a new ROM. The device driver code is nearly identical to the version our VAR came up with. We would like to trust Xylogics, and run the new driver and ROM, but we spent so much time down installing the first driver that we are a bit leary of doing that again. Does anyone have experience with this card and device driver? Any help would be appreciated. -- __ | -- John C. Gonnerman -- \__/ __ | ..!ucbvax!pasteur!ames!pacbell!sactoh0!tree!jcg \__/ \__/ | \__ | "THIS is the Age of Magic!"
jcg@tree.UUCP (John Gonnerman) (06/27/89)
In a mail message, ...!texbell!moray!siswat!buck (A. Lester Buck) writes:
I obviously can't tell you where your driver bug is, but I can give you
a pointer in debugging it yourself. The driver is clearly hung
"fast" asleep, sleeping for some interrupt that never comes and at
a priority level that is sufficient to block the receipt of signals
from other processes.
Since you have complete source (it sounds like), you can use the
output of the "ps" command (full listing) which gives the WCHAN
that the process is sleeping for. This is the address that something
in the kernel has to do a wakeup() on to get things moving again.
This is (almost always) a kernel address inside the driver. Just
add a bunch of kernel printf's to the driver so it spits out the
address it is sleeping on before each sleep() in the driver, wait
for a hang, and run ps to find out where the problem is.
The "bug" is probably that the writer said "Oh, that interrupt
will ALWAYS happen, so I don't need a watch-dog timer going to
awaken me if I miss it." Sure....
(I TRIED to mail this... but got it back with a note that site moray
does not exist. So much for R)eply. So, I am posting it, both to
thank Mr. Buck and for the edification of those like me that need this.)
THANX! I needed that help! Yes, we have full source code, but I am not a
kernel hacker. Applications and Administration is hard enough. Yours is the
first reply I have received, and should be very helpful.
--
__ | -- John C. Gonnerman --
\__/ __ | ..!ucbvax!pasteur!ames!pacbell!sactoh0!tree!jcg
\__/ \__/ |
\__ | "THIS is the Age of Magic!"