Tim Waugh (firstname.lastname@example.org)
Sun, 5 Sep 1999 23:11:19 +0100 (GMT)
On Sat, 4 Sep 1999, Matthew Vanecek wrote:
> I've written about this before, but no resolution was ever reached.
> It's a continuing problem.
I still know about your problem, but haven't had time to go back over your
mails and hunt for clues. David Campbell was maintaining the Zip drive
driver, but he doesn't seem to be answering his mail at the moment.
The nature of the problem suggests that the Zip hardware itself is still
latching the port lines even though we don't want it to, which is a
problem with the Zip drive driver in that it should be telling the drive
to let go but it doesn't (or something goes wrong). So the problem most
likely lies in ppa.c.
It isn't a problem in the sharing mechanism of parport, since that would
exhibit different symptoms (i.e. /proc/.../devices would always say +ppa).
Basically, what it boils down to is that you'll have to cumulatively
mutilate the Zip driver so that it does less and less, and find out at
which point things start working. Hopefully, the last piece of code to be
commented out will give us enough information to fix the problem.
Since loading the driver is enough to trigger the problem, we just have to
hack at the initialisation sequence. We need to trace through the code
and see where it goes. The idea is to iteratively stop it short, so that
it doesn't quite finish. The awkward thing is that we need to be a bit
careful that we don't wreck any of the hardware: if we are driving the
data lines at the same time as the Zip drive is, that's bad.
It's a little difficult to do remotely, and I don't have an Asus
motherboard here. But I think this is the only way the problem will get
I will be busy next week, but hopefully I'll get time to look at it after
-- 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 Sun 05 Sep 1999 - 18:25:16 EDT