Date: Thu, 29 May 1997 03:05:24 -0400 (EDT) From: tom@tomqnx.com (Tom Torrance at home) To: hackers@freebsd.org Subject: HP 6020 Problems Message-ID: <m0wWzH2-000A4IC@TomQNX.tomqnx.com>
next in thread | raw e-mail | index | archive | help
Jordon's original announcement for Release 2.2.1 stated that the HP 6020
was supported, so I went and bought one. It doesn't work properly as a WORM
device for me, so I hacked the driver to allow myself to burn CDs with it.
THis is a REALLY crude hack, but it works well enough to allow me to
fulfill my objective. I offer it here only so that someone who really
knows what they are doing can use the information I have gathered to
implement the necessary support properly. Driver code is far beyond me.
My machine is an old 486DX2-66 with an AHA2740A controller with the Fast SCSI II
system disk and the HP6020 on it - surely overkill for the job with the
HP 6020, which has a 1 MB I/O buffer in it.
Among other kernel options, I have BOUNCE_BUFFERS for my QIC-02/QIC-150,
plus AHC_TAGENABLE, AHC_ALLOW_MEMIO and AHC_SCBPAGING_ENABLE. I don't know
how many I/Os the software allows, but the controller firmware allows up
to 32 outstanding tagged or 2 non-tagged I/O commands per device to a
maximum of 255 for the controller. Four (4) SCB's are allocated to the
controller at boot probe time.
In any case, the 1 MB buffer soaks up a lot of I/O very quickly at the
beginning of the job, that takes quite a while to complete. Because the
SCSI_NOSLEEP flag was being set, I was getting 'oops, not queued' messages
and the job would fail. I was also getting the same messages
when reading a CD with the 'find' command. The simple solution was to remove
the setting of SCSI_NOSLEEP, which as far as I can tell serves no useful
purpose.
Note that when running the 'burncd' script, the dd command fails at the
end of the copy, presumeably because of the extremely long time required
for outstanding output to complete, allowing the 'close' to proceed to
completion. This does not affect the quality of the CD produced, which seems
quite perfect.
Although I got 'burncd' to function for me, more or less, attempting to
execute 'cd-write 1.2' to master a CD locks up the entire systemi,
after the initializing disk info message. I have no
idea what is causing that, which also happens with the un-modified
driver. Having to power off a system to get it going again is not nice.
I hope that this info helps!
Regards,
Tom
------------------------CUT HERE------------------------------------------
*** worm.c.orig Mon May 26 19:04:51 1997
--- worm.c Thu May 29 01:24:36 1997
***************
*** 196,202 ****
rf4100_finalize_track, rf4100_finalize_disk
},
{
! "HP", "4020i",
hp4020i_prepare_disk, hp4020i_prepare_track,
hp4020i_finalize_track, hp4020i_finalize_disk
},
--- 196,202 ----
rf4100_finalize_track, rf4100_finalize_disk
},
{
! "HP", "6020",
hp4020i_prepare_disk, hp4020i_prepare_track,
hp4020i_finalize_track, hp4020i_finalize_disk
},
***************
*** 369,375 ****
0,
100000,
bp,
! flags | SCSI_NOSLEEP) == SUCCESSFULLY_QUEUED) {
if (worm->dkunit >= 0) { /* Cloned from od.c, possibly with same mistakes. :) */
dk_xfer[worm->dkunit]++;
dk_seek[worm->dkunit] = 1; /* single track */
--- 369,375 ----
0,
100000,
bp,
! flags) == SUCCESSFULLY_QUEUED) {
if (worm->dkunit >= 0) { /* Cloned from od.c, possibly with same mistakes. :) */
dk_xfer[worm->dkunit]++;
dk_seek[worm->dkunit] = 1; /* single track */
---------------------------------CUT HERE-------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0wWzH2-000A4IC>