David Campbell (campbell@gear.torque.net)
Sat, 29 May 1999 10:42:05 +0800
Date sent: Fri, 28 May 1999 20:21:29 +0200 (CEST)
From: Timo Felbinger <timof@uranos.quantum.physik.uni-potsdam.de>
Send reply to: Timo.Felbinger@quantum.physik.uni-potsdam.de
To: campbell@torque.net
Subject: bug report: ppa.c or parallel port driver
>
> Hi,
>
> 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_disconnect(host_no);
> ppa_connect(host_no, CONNECT_NORMAL);
>
> retv = 2; /* Failed */
>
> w_ctr(ppb, 0xe);
> if ((r_str(ppb) & 0x08) == 0x08)
> ^-------returns 0x7e. good(?).
> retv--;
>
> w_ctr(ppb, 0xc);
> if ((r_str(ppb) & 0x08) == 0x00)
> ^-------returns 0x7e, too. not good.
> retv--;
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
happened.
> 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.
David Campbell
=======================================================
campbell@torque.net
"This is not an office, rather Hell with fluorescent lighting"
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- 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