Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 30 Dec 1998 01:48:00 +0100
From:      sthaug@nethelp.no
To:        nsouch@teaser.fr
Cc:        freebsd-current@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG
Subject:   Re: Request fo help with Zip Drive on vpo0 in -current]
Message-ID:  <26784.914978880@verdi.nethelp.no>
In-Reply-To: Your message of "Mon, 28 Dec 1998 18:02:32 %2B0000"
References:  <19981228180232.58123@breizh.prism.uvsq.fr>

next in thread | previous in thread | raw e-mail | index | archive | help
> >Parallel ZIP doesn't work here, using sources CVSupped today (Dec 28th).
> >Perhaps the cause isn't in the ppc/ppbus/vpo code; the problem
> >I see is that da0 isn't initialized, so I think that scbus0 doesn't
> >get attached to vpo0 for some reason. Some parts of the CAM code
> >have changed in the last month...
> >
> >These are my kernel config lines related to the parallel bus:
> >
> >controller      scbus0                  # Lo necesita el ZIP paralelo.
> >device          da0                     # Y esto también.
> >controller      ppbus0                  # Bus paralelo
> >controller      vpo0    at ppbus?       # ZIP paralelo
> >device          nlpt0   at ppbus?       # Impresora
> >controller      ppc0    at isa? port ? tty irq 7 flags 0x04
...
> >After that, there is no mention to any "da" device.

I had the same problem when I tried to use a ZIP drive (bought more than
a year ago but never used before). The interface was detected as

vpo0: <Iomega VPI0 Parallel to SCSI interface> on ppbus 0

but no da device showed up.

> First, try to set your bootflags to 0x3 to force PS2/NIBBLE mode and see
> if it works. Then try 0x1.
> 
> Secondly, set 0x44 to your bootflags to force your chipset generic and
> avoid NS chips detection code execution.

What finally made it work for me was: EPP mode in the BIOS, and

controller	ppc0	at isa? port ? tty irq 7

in the kernel config. Ie. no flags at all. With this setup, my Zip drive
is detected as

da1 at vpo0 bus 0 target 6 lun 0
da1: <IOMEGA ZIP 100 D.06> Removable Direct Access SCSI-2 device 
da1: 196608 512 byte sectors: 64H 32S/T 96C

(the size printout is non-standard, more on this below).

During my testing of this, I attempted to use CAMDEBUG, with

options		CAMDEBUG
options		"CAM_DEBUG_BUS=-1"
options		"CAM_DEBUG_TARGET=-1"
options		"CAM_DEBUG_LUN=-1"
options		"CAM_DEBUG_FLAGS=CAM_DEBUG_INFOřCAM_DEBUG_TRACEřCAM_DEBUG_CDB"

in the kernel config. With these options and "normal" parallel port mode
in the BIOS (no EPP), the Zip drive is detected as:

da1 at vpo0 bus 0 target 6 lun 0
da1: <  > Fixed Direct Access SCSI-0 device 
da1: 1 0 byte sectors: 0H 0S/T 0C

and the 0 byte sector size leads to a divide by zero and corresponding
panic at dadone() line 1290 in sys/cam/scsi/scsi_da.c:

			snprintf(announce_buf, sizeof(announce_buf),
				"%ldMB (%d %d byte sectors: %dH %dS/T %dC)",
				dp->sectors / ((1024L * 1024L) / dp->secsize),
				dp->sectors, dp->secsize, dp->heads,
				dp->secs_per_track, dp->cylinders);

I removed the MB printout and the corresponding calculation to avoid the
divide by zero and continue testing.

Maybe the sector size should be forced to 1 if it is detected as zero,
to avoid the divide by zero panic?

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?26784.914978880>