Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!usc!howland.reston.ans.net!noc.near.net!ceylon!genesis!steve2 From: steve2@genesis.nred.ma.us (Steve Gerakines) Newsgroups: comp.os.386bsd.development Subject: Re: QIC 80 driver Message-ID: <C8snr3.BK4@genesis.nred.ma.us> Date: 18 Jun 93 01:49:49 GMT References: <740187774snz@maxwell.demon.co.uk> Organization: Genesis Public Access Unix +1 508 664 0149 Lines: 72 In article <740187774snz@maxwell.demon.co.uk> David@maxwell.demon.co.uk writes: >I downloaded the QIC 80 driver from hrd769.brooks.af.mil:/pub/alpha and >successfully installed it in 386bsd (with patchkit 0.2.3 applied previously). >I rebuilt the kernal (no errors) and rebooted. Great! So long as the patchkit has an accurate timer for DELAY() and possibly fixes to reduce interrupt latency, this configuration should be fine. >After seeing my only floppy I got the following messages (I commented out >the tape command debug line in ft.c) >tape_start start >tape_recal start >tape_recal end >tape_recal end >qic_status has dead drive ... st3 = $28 >qic_status has dead drive ... st3 = $28 >qic_status has dead drive ... st3 = $28 So far this is normal. In the attach routine, the drive enable commands for Colorado drives are tried first. Seeing that this failed, the driver goes on and tries the mountain enable commands. >tape_recal start >tape_recal start >tape_recal end >tape_recal end >qic_status returned $01 >tape_status got $0001 >tape_end start >tape_recal start >tape_recal end >tape_end end The driver received a status code from the tape drive. Since it was enabled using the mountain commands, it is assumed to be a Mountain type drive. >fd0: drives 0: 1.44M, 2: Summit tape at 0x3f0 irq 6 drq 2 on isa (This is how the attach line should normally appear with debug messages turned off.) >My config file has nfs commented out along with the scsi drivers and devices >if that's important. Shouldn't matter really. The driver depends only on the floppy controller. >I next tarred the contents of a directory and attempted to list the tape using >"tar tv". This seemed to list the tape and then hung. I can give further >details if anyone is interested. I am definitely interested. Yours is the first (and only!) status report that I've received. Unfortunately I really need much more feedback to make the driver stable for everyone. How far along did you get when you read back the tape? Does it hang every time? If you could send me the debug listing up to where the hang takes place it would be helpful. I suspect I have a race condition in the read routine, where the driver top sleeps waiting for the read bottom, but the bottom is in the middle of ending. You might want to scan the driver and search for debug messages that I have commented out. (There are places where debug messages appear so frequently that it causes the driver to "miss" a block and have to rewind.) Thanks, - Steve steve2@genesis.nred.ma.us