Matthew Vanecek (mev0003@unt.edu)
Fri, 17 Sep 1999 00:11:04 -0500
grant@torque.net wrote:
>
> Also, while I'm not up to date on David's version of the driver (I have
> a different driver based on the new ppSCSI framework), I may be able to
> answer your question.
>
Hadn't heard about that one. Is it an alternative to ppa? Or something
in the 2.3.x kernels...
> > I *think* I fixed it. Or at least figured out why it's not releasing.
> > In ppa_connect, I added a 'flag = 0;' (line 529), and compiled and
> > loaded the module, and voila!
>
> What you've done is to force the driver to connect in non-EPP mode,
> regardless of what mode the driver thinks it is in. While the patch
> probably works for you, this is clearly not the correct solution.
>
You're right, of course, and I don't mean to put it forward as a fix.
But hopefully it's a step in the direction of finding out why it doesn't
work. Plus, it's a record of what I've done in trying to track down my
problem here, and maybe someone else can help?
>
> > I don't know yet why 1) CONNECT_EPP_MAYBE is defined to 1, and 2) What
> > the ports mean in the ppa_*_pulses (e.g., what line they go to, what
> > that line means to the Zip drive, etc). Is that information readily
> > available somewhere?
>
> I don't fully understand David's mode selection code - he's trying to
> allow you to disable EPP probing (which is exactly what you need to do,
> apparently) when you compile the module. David doesn't seem to like
> command line parameters.
>
> We (David and I) have some fuzzy documentation from Iomega. The connect
> and disconnect functions issue the 'secret knocks' that the device
> requires to switch from pass-through to its adapter mode. Basically,
> the control lines are wiggled in a particular sequence while a specific
> (mode dependent) value is held on the data lines.
>
> > But with "flag=0" (I guess I could just change CONNECT_EPP_MAYBE),
> > printing and zip-ing simultaneously works. Could this be indicative of
> > a more subtle problem?
>
> Yes - your parallel port is behaving oddly. Even though it is set to
> EPP mode, it is not communicating with the device in the EPP protocol.
> There's probably an additional secret knock required to get it to go
> into true EPP mode.
>
> With your hack, or just changing CONNECT_EPP_MAYBE (yes, I think it's
> a pretty bizarre name), the driver is probably talking to your ZIP in
> SPP or PS/2 mode. I imagine that performance sucks ...
>
It seems to be specific to the Asus P5A, I guess. David said once that
he had an Asus at home, but it seems he has run into more pressing
priorities (paying rent, maybe? ;) ).
What's strange is that my BIOS doesn't offer an SPP mode, yet here I am
evidently making talk in SPP mode. Not sure how that works.
Another thing, which may or may not be related. I've been advised in
the past to do something like "echo mode=1 > /proc/parport/0/hardware".
I've tried echoing various values, based on educated guesses from
reading the code, but no matter what I echo to /proc/parport/0/hardware,
nothing changes. I also try echoing to /proc/scsi/ppa/2 various values,
1,2,3,4,5, but while they change the Mode, it doesn't seem to affect
anything, either with my hack or with the original. Is that right?
Below is a diff, with only the flag=0, and not my extra printks, just
for reference. Also, the output from dmesg showing my hack vs. the
original. My hack is the first set of messages, and the original is the
stock ppa.o. I'm not sure where to go from here, but obviously my hack
isn't an acceptable fix. Any ideas?
---------------------------------------BEGIN HERE--------------------
--- ppa.c.1st Thu Sep 16 11:12:58 1999
+++ ppa.c Thu Sep 16 23:46:34 1999
@@ -522,6 +522,9 @@
ppa_c_pulse(ppb, 0);
ppa_c_pulse(ppb, 0x3c);
ppa_c_pulse(ppb, 0x20);
+
+ flag = 0;
+
if ((flag == CONNECT_EPP_MAYBE) &&
IN_EPP_MODE(ppa_hosts[host_no].mode))
ppa_c_pulse(ppb, 0xcf);
------------------------------------------END-------------------------
---------------------BEGIN DMESG--------------------------------------
ppa: Version 2.03 (for Linux 2.2.x)
ppa: Found device at ID 6, Attempting to use EPP 32 bit
ppa: Found device at ID 6, Attempting to use PS/2
ppa: Communication established with ID 6 using PS/2
scsi2 : Iomega VPI0 (ppa) interface
scsi : 3 hosts.
Vendor: IOMEGA Model: ZIP 100 Rev: D.08
Type: Direct-Access ANSI SCSI revision: 02
Detected scsi removable disk c2b0t6u0 at scsi2, channel 0, id 6, lun 0
SCSI device sdb: hdwr sector= 512 bytes. Sectors= 196608 [96 MB] [0.1
GB]
sdb: Write Protect is off
/dev/sd/c2b0t6u0: p4
Releasing ppa0
scsi : 2 hosts.
ppa: Version 2.03 (for Linux 2.2.x)
ppa: Found device at ID 6, Attempting to use EPP 32 bit
ppa: Communication established with ID 6 using EPP 32 bit
scsi2 : Iomega VPI0 (ppa) interface
scsi : 3 hosts.
Vendor: IOMEGA Model: ZIP 100 Rev: D.08
Type: Direct-Access ANSI SCSI revision: 02
Detected scsi removable disk c2b0t6u0 at scsi2, channel 0, id 6, lun 0
SCSI device sdb: hdwr sector= 512 bytes. Sectors= 196608 [96 MB] [0.1
GB]
sdb: Write Protect is off
/dev/sd/c2b0t6u0: p4
--------------------------------------END DMESG-------------------------
Ok, I'm out of breath...
-- Matthew Vanecek Course of Study: http://www.unt.edu/bcis Visit my Website at http://people.unt.edu/~mev0003 For answers type: perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);' ***************************************************************** For 93 million miles, there is nothing between the sun and my shadow except me. I'm always getting in the way of something...-- 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 17 Sep 1999 - 01:13:53 EDT