Re: [PARPORT] parport irq handler v7 test w/ 3 pp devices

Boszormenyi Zoltan (
Mon, 21 Sep 1998 10:56:51 +0100

At 09.17 1998.09.21. +0100, David Campbell wrote:
>> The result in one sentence: No warnings, no data loss.

Hip hip! :)

>> 2. As I said before the PHd is a very slow device and using it makes
>> my Linux box slow as well. Even changing VCs are slow.
>> I use the pd driver always with nice=1. I tried some cluster setting
>> as well such as the default (64), 32, 16, 1. My machine's responsiveness
>> weren't better. What can I do to achieve what I want? Maybe put some
>> schedule(); in the pd driver? Where? Grant, can you suggest some points?
>> :)
>I will stay out of this one... All I can say is that schedule() in the
wrong spot
>can cause a kernel panic (if called from within any interrupt, software
>or hardware).

I know and I don't want to mess with it myself.

And two things I forgot:

1. When I use only the PHd or the PHd and the ZIP at the same time,
the machine's responsiveness is very bad. But it is much better
when printing comes in. Strange.

2. All of you said before that "ECP is evil". I saw in the sources
that parport can detect the irq if the port is set to ECP. I tried it
and it really detected irq 7 but it said to set it through
/proc/parport/0/irq. Ok, I figured that it may be an experimental
feature. But I was surprised very much when the printer and the
PHd were actually working! Setting the parallel port to ECP
confused my printer and the PHd so much with the previous(*) parport
version that I had to turn them off and on, sometimes I had to reboot
and set the port back to EPP. So the parallel port mode changing is
working reliably. More hip hip hooray! :)

(*) I haven't tried ECP for ages. I used EPP almost always.

Zoltan Boszormenyi

-- To unsubscribe, send mail to: --
-- with the single word "unsubscribe" in the body of the message. --

This archive was generated by hypermail 2.0b3 on Wed 30 Dec 1998 - 10:18:20 EST