Matthew Vanecek (mev0003@unt.edu)
Mon, 06 Sep 1999 08:52:59 -0500
Tim Waugh wrote:
>
> 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.
>
> Hi Matthew,
>
> 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.
That was my guess, but in my case, it's only a guess. ;) I've two Zip
drives, and both worked on other hardware as expected, both with Linux
and with NT. Both are ppa.
>
> 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.
>
I'll read through the ppa.c as I have time this week, and try to figure
out what's happening. My problem is, I know *how* to program C,
theoretically and logically, but don't know enough practical C
functions yet to program effectively. IOW, I could write you a killer
flow chart, and fill in some of the code, but not much code. I'm
working on it, though. :)
> 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
> fixed.
>
> I will be busy next week, but hopefully I'll get time to look at it after
> that.
Some pointers on debugging kernel modules would be good. I'll poke
around on the Web a little, too. I'm not sure I'm experienced enough to
merit diving into Kernel Drivers book, but I can use a debugger fairly
well.
Hopefully all this will help more people than just me.
-- 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 Mon 06 Sep 1999 - 09:55:48 EDT