From owner-freebsd-hackers Mon Jun 5 18:50:52 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA19792 for hackers-outgoing; Mon, 5 Jun 1995 18:50:52 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id SAA19784 for ; Mon, 5 Jun 1995 18:50:48 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id SAA24857; Mon, 5 Jun 1995 18:50:13 -0700 From: "Rodney W. Grimes" Message-Id: <199506060150.SAA24857@gndrsh.aac.dev.com> Subject: Re: kernel page fault while doing tar to /dev/rft0 To: steve2@genesis.tiac.net (Steve Gerakines) Date: Mon, 5 Jun 1995 18:50:13 -0700 (PDT) Cc: hackers@freebsd.org In-Reply-To: <199506060122.VAA23834@genesis.tiac.net> from "Steve Gerakines" at Jun 5, 95 09:22:44 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3403 Sender: hackers-owner@freebsd.org Precedence: bulk > > > > > I can visually see that this patch would be wrong, [...] > > > > Shit. Is anybody going to spend me a floppy tape drive? I'm sick > > > of being held responsible of code i couldn't even test... sigh. > > Joerg is right-- the block of code should be changed: > > *** fd.c.orig Mon Jun 5 21:10:41 1995 > --- fd.c Mon Jun 5 21:11:02 1995 > *************** > *** 1013,1019 **** First off, this must be against a very old version of fd.c, this snip of code start at line 1080 now! > fd = &fd_data[fdu]; > fdc = fd->fdc; > fdcu = fdc->fdcu; > - fdblk = 128 << (fd->ft->secsize); > > #if NFT > 0 > if (FDTYPE(minor(bp->b_dev)) & F_TAPE_TYPE) { > --- 1013,1018 ---- > *************** > *** 1031,1036 **** > --- 1030,1037 ---- > goto bad; > } > #endif > + fdblk = 128 << (fd->ft->secsize); > + Still will crash some ones system if they get to here with out a ft device since ft will be null!! Now maybe the open code stops them from getting here, I am not sure :-(. > if (!(bp->b_flags & B_FORMAT)) { > if ((fdu >= NFD) || (bp->b_blkno < 0)) { > printf( > How come fdblk size is coming from the ft structure, but is used in non ft code??? See line 1108, 1118, and 1120. Perhaps the real bug fix here is that fdblk should bd from fd->secsize???? > The reason being that fd->ft gets initialized at the bottom of the fdopen() > routine, which for tape drives is never reached. Not too complex. I > didn't realize that ftstrategy() was no longer being reached at all. The > code still should be tested but it looks right. Fails my visial, this patch has been rejected for inclusion at this point in time :-(. > > Jordan, I would like to request a ``floppy tape'' drive for the test > > engineering lab at accurate automation. I can pick one up wholesale, > > or you can send me an old piece of junk you have around there (I > > seem to recall one or two of them just laying in the back room on > > the shelf). > > If you run across any refurbished Colorado 350 drives or someone is looking > to unload one please let me know. I'd like to add support for the newer > drives but it is becoming apparent that it's impossible unless I have one > around to bang on. (I can add the code according to the specs but it's > really a nightmare when things go wrong.) I just called in my order for the lowest cost Colorado they had (the 250 is what I ended up with). But you can get the upgrade kit for a 250 to a 350 via a EPROM change. If you will upgrade to 2.0.5 current I will sell you one of the upgrades at cost, contact me via private email. > > We can't get this stuff working as the only person very seriously involved > > with the code is still running 1.1.5.1 :-(. > > Works great! :-) I'm going to pick up the 2.0.5 CD so I should be in the > present soon. But if you continue to wait until we ship the CDROM's to upgrade then you can't be the point of support for the driver for each new release since you are behind the bits we are trying to get working. This problem has now been solved, the FreeBSD tests labs will shortly have the 250MB version of the drive, and I will probably pick up the 350MB upgrade so that I can test both versions by simply changing proms. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD