Been busy testing the patches (in mass) that we've previously discussed.
So far the worst bug has been a particular printer, cable, port combo
that has random data loss from a weak line driver somewhere. After two
and half days of code debugging I realized I had the same problem with
the existing kernel code. After more useless testing I discovered if I
moved the printer to my 2nd port the bad printer works fine. And guess
what the bad port works with my 2nd laserjet just fine too.
The "patch" is getting pretty large. The coding is complete I think but
debugging isn't. Would you like to review the "patch" before I finished
my testing? And what if anything to you want with it? There are code
paths I don't have the hardware to test (nothing in true ECP for ex.).
And finally, I think the fifo stuck code in function
"parport_pc_compat_write_block_pio" should drop any attempt at recovery.
My reasoning is as follows: In compatible mode your not performing a
true block operation like in ECP your just sending a window on a stream.
When the "fifo sticks" in this mode there doesn't appear to be a
reliable (across all chipsets) way of stopping the transfer and putting
the chip in ECR_TST. However, since we've working in compatible mode the
fifo should be already full at time-out occurrence. Now if on time-out
we immediately switch to ECR_PS2 mode (while we have the fifo full
condition) we already know the recovery point and this would minimize
the window for data corruption to microseconds at best. The longer we
wait between time-out detection and moving back to ECR_PS2 mode
increases the chance that the fault will be corrected fifo transmission
will automatically restart. But we've lost the code state to resume
transmission. We also delay (we're doing typically a second 64 second
time-out in "parport_pc_compat_write_block_pio" this delays notification
back to "lp" and the log (and whatever) of the fault conditions.
Look forward to hearing from you.
-- 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 2b29 : Thu Dec 20 2001 - 10:28:35 EST