David Campbell (email@example.com)
Sat, 29 May 1999 10:42:05 +0800
Date sent: Fri, 28 May 1999 20:21:29 +0200 (CEST)
From: Timo Felbinger <firstname.lastname@example.org>
Send reply to: Timo.Felbinger@quantum.physik.uni-potsdam.de
Subject: bug report: ppa.c or parallel port driver
> when upgrading a Linux kernel from 2.0.36 to 2.2.9, my parallel
> port ZIP drive stopped working.
> I narrowed down the error to a failure of the second handshake
> in ppa_init():
I appreciate the info.
> ppa_connect(host_no, CONNECT_NORMAL);
> retv = 2; /* Failed */
> w_ctr(ppb, 0xe);
> if ((r_str(ppb) & 0x08) == 0x08)
> ^-------returns 0x7e. good(?).
> w_ctr(ppb, 0xc);
> if ((r_str(ppb) & 0x08) == 0x00)
> ^-------returns 0x7e, too. not good.
This would appear to be in violation of the Iomega technical manual
OR the CPU is too fast for the hardware (not the first time this has
> This occurs on a dual PII/333 (both with and without SMP)
> The problem goes away when commenting out the last step in
> the "chain of speed", ie ECPPS2 seems to work while ECPEPP
> fails. The ZIP drive is reported as
> may 28 20:27:56 mnemosyne kernel: ppa: version 2.03 (for linux 2.2.x)
> may 28 20:27:56 mnemosyne kernel: ppa: found device at id 6, attempting to use epp 32 bit
> may 28 20:27:56 mnemosyne kernel: ppa: communication established with id 6 using epp 32 bit
> may 28 20:27:56 mnemosyne kernel: scsi1 : iomega vpi0 (ppa) interface
> may 28 20:27:56 mnemosyne kernel: scsi : 2 hosts.
> may 28 20:27:56 mnemosyne kernel: vendor: iomega model: zip 100 rev: j.03
> may 28 20:27:56 mnemosyne kernel: type: direct-access ansi scsi revision: 02
> may 28 20:27:56 mnemosyne kernel: detected scsi removable disk sdb at scsi1, channel 0, id 6, lun 0
> may 28 20:27:56 mnemosyne kernel: scsi device sdb: hdwr sector= 512 bytes. sectors= 196608 [96 mb] [0.1 gb]
> may 28 20:27:56 mnemosyne kernel: sdb: write protect is on
> may 28 20:27:56 mnemosyne kernel: sdb: sdb1
> Here, the bytes read from the port were 0x0e and 0x06.
*slap face with hand*
I just remembered something about ECP that *could* possibly cause
what we are seeing. When using ECP (not ECP+EPP) the status an
control registers are mapped to base+0x400. Perhaps the IO chipset is
enforcing this for EPP+ECP. Also ECP+EPP has never been formally
defined by any document (other than chipset specific datasheets).
> I don't know enough about parports and ZIPs to decide whether this
> is a problem with ppa.c or whether the capabilities of the parport
> where incorrectly detected.
It is more a ZIP drive / chipset issue.
> Please let me know if you need any additional information.
I will once I sort out another problem.
"This is not an office, rather Hell with fluorescent lighting"
-- To unsubscribe, send mail to: email@example.com --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2.0b3 on Fri 28 May 1999 - 22:44:07 EDT