> > OK, several questions: does it happen on both sides? Only on the
> > slow one? What happens if you are pinging the thing? I.e. does another
> > side see your packets? (ifconfig)
>
> Either side, same problem. If I load 2.1.1xx on one machine and ping the
> 2.2 machine the 2.2 machine gets the messages (tcpdump shows this) but all i
> see on the receving end is transmit timeout(1,80) (std timeout msg). Oddly
> enough tcpdump 'eats' icmp ping replies, but I know the message doesn't get
> sent back out because i get no icmp reply, tcpdump just happens to show me
> that 'yes, the message does make it through, and the system tries to reply'
Erm.. Let me reformulate the question.
Suppose you are pinging 2.2 from 2.1. What happens with RX and TX counters
on each side? Ditto for other direction.
> > Another thing: could you include printk's (with KERN_DEBUG
> > priority) into ENABLE/DISABLE (guess why they became macros ;-) and
> > into the beginning/end of plip_send_packet/plip_receive_packet?
>
> printk for thos function to show entrancy, and you want to see printk's at
> each point of return? As for teh enable/disable macros they already have
Hmm... Just include __LINE__ in the output. Then we'll see where the thing
happens.
> Hmm. No lockup, system remains functional, but the interface is no good
> until reboot. I like teh idea, i'll do it in a moment. OTOH, how/where is
Hrm... Does rmmod plip; insmod plip help?
> the initial state of teh irq dor the pardev being set? parport code at
> boot?
Nope. It's done by parport when plip registers/unregisters its IRQ
handler.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/