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'
> 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
some at KERN_WARN, just so I could see that status of the irq if they
failed. Maybe a message to show execution on net_debug > 1 would better
fit rather than showing only failed enable/disable.
> (convenient variant being: < and > for send, { and } for receive, E(line)
> for enable, D(line) for disable). Try to beat the fscker into the hangup
> and extract the stuff from the log. It should demonstrate the path where
> the shit hits the fan.
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
the initial state of teh irq dor the pardev being set? parport code at
boot?
If I knew this I'd feel better.
> > } else
> > error = HS_TIMEOUT;
> >
> Erm... Look two lines above that piece. It happens only for
> sending.
ugh, you're right.. :)
> <shrug> I have a nasty gut feeling that you've got a race or two that way.
> I can't back it right now, but... OK, I'll dig out my records and look
> them through. BTW, there is another implementation of PLIP and we can't
> say 'Linux<->Linux link works, screw everything else'. Actually there are
> at least two other impementations: BSD one and original Russell's (for
> DOS).
I'm aware of this, I'm not suggesting a change to the protocol. :) It
wouldn't be a bda thing to have a Native alternative, maybe in a few months
when I get bored.
> > I've been using this 'technique' for a few days now and have had no
> > problems, I would like to have someone else's opinion on this though. What
> > advantage would be gained? What problem should it be causing that I'm not
> > seeing? if you want me to point out how this driver recovers when de-sync "i
> > don't know, grep for 'collision'."
>
> Races.
>
> > As a final note on not managing the irq, my xfer is about equal to
> > 40kbyte/s, the same as under 2.1.1xx
> >
> > I look forward to responses, I'm a kernel hacker wanna-be and any
> > information sent my way is appreciated, even if you do get verbal, at least
> > I'll know. I'm still struggling (between my job and other responsibilities)
> > to understand much of how the kernel works. So most of what I'd thought is
> > wrong is based on assumption. Things you could help me understand so I can
> > shut my trap next time I think something works:
> >
> > The state of the irq when bh_plip() is called? I assumed irq is enabled.
> > What happens if you disable irq from within a bh function? I assumed the
> > state is left unchanged, so if you disable irq it remains disabled until re
> > enabled. And will it be re-enabled before the next call to a bh function? I
> > assumed no since it didn't appear to be working that way.
>
> serialized wrt each other (grep for do_bottom_half and you'll see).
rgrep'd the source tree earlier
> I don't like the idea of leaving the IRQ enabled by several
> reasons. First of all, it has a chance to confuse the hell of top-level
> part. Another thing being:
I am aware what not disabling the irq implies. I'll look at it in a few..
> <rant intensity=mild>
> would be terrible. Except that we can create a table and use it instead of
> bitops. Yes, whole horrible 512 bytes. Sync-on-intr would be much nicer,
Hmm..
> but no such luck. And we can't change the protocol - compatibility hits
> and all such. We could implement the second protocol and that would be the
> Right Thing, but that's another story.
> </rant>
Hmm..
> ;-/ I'ld *really* like to look at the log.
----------------------------------------------------------
---- ely --- <plexus@ionet.net> ------
-
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/