On Thu, 2007-07-19 at 18:53 +0300, Caglar Akyuz wrote: > Kieran Mansley wrote: > > On Thu, 2007-07-19 at 18:11 +0300, Caglar Akyuz wrote: > >> Kieran Mansley wrote: > >>> On Thu, 2007-07-19 at 15:35 +0100, Kieran Mansley wrote: > >>>> Can you get a small ethereal capture to illustrate this? The fact that > >>>> the hub makes a difference is interesting. I wonder if it is a problem > >>>> with the boards seeing packets from one of the other boards. Does it > >>>> happen in response to all broadcast ARP packets, or only some? Does it > >>>> happen in response to other broadcast packets? > >>> Is there any traffic (other than broadcast packets and TCP ACKs) going > >>> back from the PC to the devices? If not, it could be just that the > >>> board receiving data is causing them problems (rather than it being > >>> broadcast packets in particular). You could try sending a UDP stream at > >>> the board (which should just drop the packets if there is nothing > >>> listening to receive them) and see what that does. > >>> > >> No there isn't no other traffic other than packets and ACKS. Do you > >> think pinging may cause the same effect because I'm pinging the devices > >> while packets are flying. Some times pinging was ok, sometimes it > >> crushed the boards. > > > > If pinging kills the board I suggest there is something seriously wrong. > > Not sure where though I would guess it might be something to do with > > protection of the core stack. Perhaps you have an rx packet and a tx > > packet being procesed at the same time and this causes corruption. How > > do you synchronise processing of RX and TX in your port? > > I rely on sys_arch_protect and sys_arch_unprotect. They're > disabling/enabling interrupts at the cpu level. I also tried adding some > other protection. For instance, I disabled passing broadcast packets > from my mac driver to lwIP while I'm transmitting any packets.(disabled > before calling tcp_ouput, enabled after tcp_sent callback)
I don't think that is sufficient: you don't just need to protect the tcp_output to tcp_send call, but also any other calls into lwIP. This includes preventing having your sending thread, any of the TCP timers, or any receive packet processing happening concurrently. Even processing a receive packet while you're in a call to tcp_write() for example would be a problem as they're both modifying the same state. > One thing I suspect is that there is something wrong with physical > layer, or at least there are more than one problems and one of them is > related to phy. For that reason, I disabled full duplex mode and I'm > using half-duplex mode at the both sides, I think full-duplex mode > doesn't help me much while using a hub.(I'm not %100 sure...) I think the protection of the stack is more likely than a phy problem. Kieran _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
