Messages in this thread | | | Date | Sun, 31 Jan 1999 03:57:46 -0700 (MST) | From | Ely Wilson <> | Subject | Re: [patch] drivers/net/plip.c |
| |
> 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'
> 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/
| |