Date: Mon, 5 Jun 1995 18:50:13 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com> To: steve2@genesis.tiac.net (Steve Gerakines) Cc: hackers@freebsd.org Subject: Re: kernel page fault while doing tar to /dev/rft0 Message-ID: <199506060150.SAA24857@gndrsh.aac.dev.com> In-Reply-To: <199506060122.VAA23834@genesis.tiac.net> from "Steve Gerakines" at Jun 5, 95 09:22:44 pm
next in thread | previous in thread | raw e-mail | index | archive | help
>
> > > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506060150.SAA24857>