2.4.18-pre/rc broke PLIP
[sent to Tim Waugh and Marcelo previously, but of course I managed to put a typo in the cc: to lkml]
Someone (sorry I forgot who) reported having problems with PLIP in recent kernels. I've done some testing and can confirm that PLIP worked up to 2.4.17 but broke in 2.4.18-pre/rc. The only thing PLIP does is put "plip0: transmit timeout(1,87)" messages in the kernel log.
After a lot of testing I've narrowed it down to the following hunk in the 2.4.18-rc4 patch:
drivers/parport/parport_pc.c +1 -1
@@ -2212,7 +2233,7 @@ }memcpy (ops, &parport_pc_ops,sizeof (struct parport_operations )); priv->ctr =0xc ; - priv->ctr_writable =0xff ; + priv->ctr_writable = ~0x10 ; priv->ecr =0 ; priv->fifo_depth =0 ; priv->dma_buf =0 ;
If I back this hunk out, PLIP starts working again.
Is this fix sufficient or is there something else that need fixing?
/Mikael
Quoted 21 lines · Mikael Pettersson
Someone (sorry I forgot who) reported having problems with PLIP in recent kernels. I've done some testing and can confirm that PLIP worked up to 2.4.17 but broke in 2.4.18-pre/rc. The only thing PLIP does is put "plip0: transmit
timeout(1,87)" messages in the kernel log.After a lot of testing I've narrowed it down to the following hunk in the 2.4.18-rc4 patch:
drivers/parport/parport_pc.c +1
-1@@ -2212,7 +2233,7 @@ }memcpy (ops, &parport_pc_ops,sizeof (struct parport_operations )); priv->ctr =0xc ; - priv->ctr_writable =0xff ; + priv->ctr_writable = ~0x10 ; priv->ecr =0 ; priv->fifo_depth =0 ; priv->dma_buf =0 ;
Quoted 2 lines
If I back this hunk out, PLIP starts working again.
Is this fix sufficient or is there something else that need fixing?
I'm still looking at this, trying to figure out what they were trying to
do here... but I note the same code in parport_gsc.c was NOT changed. Putting it back makes it work for me, but the code is not long on comments, and digging up all the data sheets for various supported chips is not a casual job.
I'm going to browse the code more this week, the bit not set isn't
documented where I've looked :-(
Anyway, back to working, perhaps there was a note with the patch giving
some hint of what it was doing?
Signature · 5 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Programming without software engineering is like sculpting with a chain saw. The very talented can produce a work of art, the mediocre wind up with a misshapen lump in a pile of rubble, and in neither case does the end result have more than a passing resemblance to the original intent.
Quoted 2 lines · Bill Davidsen
I'm still looking at this, trying to figure out what they were trying to
do here...
Does 2.4.19-pre2 not work for you?
Tim.
*/
Quoted 6 lines · Tim Waugh
Quoted 2 lines · Bill Davidsen
I'm still looking at this, trying to figure out what they were trying to
do here...Does 2.4.19-pre2 not work for you?
1 - didn't try, I checked that the patch had not been reverted, and
assumed that if it was broken and not changed it was broken still. And I only looked in pre2-ac2, if it was fixed and Alan patched it back broken.
2 - understanding vast stretches of uncommented code you may need to
change is worthwhile reading. The corolary is that comments are worthwhile typing.
I'll try to build a plain 19-pre2 kernel after I do a diff with the
2.4.18 to see that something has really changed. Thanks.
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
Quoted 4 lines · Bill Davidsen
1 - didn't try, I checked that the patch had not been reverted, and
assumed that if it was broken and not changed it was broken still. And I only looked in pre2-ac2, if it was fixed and Alan patched it back broken.
Well, try it. The correct patch is in there.
Quoted 3 lines
2 - understanding vast stretches of uncommented code you may need to
change is worthwhile reading. The corolary is that comments are worthwhile typing.
(You must have missed the ChangeLog.)
Tim.
*/
Quoted 8 lines · Tim Waugh
Quoted 4 lines · Bill Davidsen
1 - didn't try, I checked that the patch had not been reverted, and
assumed that if it was broken and not changed it was broken still. And I only looked in pre2-ac2, if it was fixed and Alan patched it back broken.Well, try it. The correct patch is in there.
Interesting, doesn't work for me, and I have a note from Alan Cox which
seems to indicate it doesn't work for him, either.
Quoted 5 lines
Quoted 3 lines
2 - understanding vast stretches of uncommented code you may need to
change is worthwhile reading. The corolary is that comments are worthwhile typing.(You must have missed the ChangeLog.)
I have looked in the changelog in the driver directory, for ac2, and for 19-pre2, and find nothing about the bits used in the control registers. Nor would I expect it to, this is in the chip spec sheets, and if I had written the code would be in very terse form in the definition of the data structure as well.
I'm still looking for the spec sheets, somewhat limited by time. I found only the definition of the 0x20 bit in the writable mask, and the problem seems to stem from the change in init from "0xff" to "~0x10" at least on one machine. Before I go offering that as a solution I want to understand what the bits are doing (or at least intended to do). I try very hard not to offer "this works for me but I don't know why" fixes.
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.