* [ECOS] Problem with TCP/IP stack @ 2008-01-10 13:09 Antoine Zen-Ruffinen 2008-01-10 13:18 ` Gary Thomas 0 siblings, 1 reply; 20+ messages in thread From: Antoine Zen-Ruffinen @ 2008-01-10 13:09 UTC (permalink / raw) To: ecos-discuss Hi List folks, I've a problem with the TCP/IP stack: - I use TFTP to load my program in redboot. That work fine. - My application start, call init_all_network_interfaces(), it do the DHCP stuff. That work fine. - Then I open a socket and try to send / receive data. No packet is even send. Does someone has already seen such problem ? Any idea ? Antoine -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ECOS] Problem with TCP/IP stack 2008-01-10 13:09 [ECOS] Problem with TCP/IP stack Antoine Zen-Ruffinen @ 2008-01-10 13:18 ` Gary Thomas [not found] ` <2cbbd8de0801100544j62d5b5ecl75969aaec1da5122@mail.gmail.com> 0 siblings, 1 reply; 20+ messages in thread From: Gary Thomas @ 2008-01-10 13:18 UTC (permalink / raw) To: Antoine Zen-Ruffinen; +Cc: ecos-discuss Antoine Zen-Ruffinen wrote: > Hi List folks, > > I've a problem with the TCP/IP stack: > - I use TFTP to load my program in redboot. That work fine. > - My application start, call init_all_network_interfaces(), it do the > DHCP stuff. That work fine. > - Then I open a socket and try to send / receive data. No packet is even send. > > Does someone has already seen such problem ? > Any idea ? We'll need more data than this in order to help. * What's the target platform? * How did you configure eCos for your failing application? * Have you run any of the standard eCos network test programs? * How do you know nothing was sent? What sort of debugging have you tried so far? -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 20+ messages in thread
[parent not found: <2cbbd8de0801100544j62d5b5ecl75969aaec1da5122@mail.gmail.com>]
* Re: [ECOS] Problem with TCP/IP stack [not found] ` <2cbbd8de0801100544j62d5b5ecl75969aaec1da5122@mail.gmail.com> @ 2008-01-10 13:55 ` Gary Thomas 2008-01-10 14:15 ` Antoine Zen-Ruffinen 0 siblings, 1 reply; 20+ messages in thread From: Gary Thomas @ 2008-01-10 13:55 UTC (permalink / raw) To: Antoine Zen-Ruffinen; +Cc: eCos Discussion Please keep your replies on the eCos list! **EVERYONE** please get this straight. Replies made by me on the eCos discussion list must be followed up on the eCos discussion list unless I invite private replies. This way everyone benefits, not just the interested party. Private email support consultation and support is available, but only with a contract. Antoine Zen-Ruffinen wrote: > The target platform is an embed PC with NS dp83816 NIC. I've port the > eCos driver my self for the PC platform. > > I configure eCos with the configtool, just using the template I made > and the "net" package. > > No, I didn't run a standard eCos network test program. But I build an > redboot with this configuration. If I type ping -n 1000 -r 1 -h > 192.168.165.18 (is my host PC) everything went fine ! This is only partly relevant - RedBoot uses a completely different network stack than normal eCos applications. Also, RedBoot does not use interrupts, which the eCos stacks rely on. > > I know that nothing was send : 1 becose network activity led doesn't > blink, 2 I monitor network with Wireshark (Ethereal). the monitoring > trace show the TFTP exchange and the DHCP init but nothing more. It > look like this : > No. Time Source Destination Protocol Info > 69504 25.515675 192.168.165.18 192.168.165.253 TFTP > Data Packet, Block: 452 > 69505 25.516279 192.168.165.253 192.168.165.18 TFTP > Acknowledgement, Block: 452 > 69506 25.516289 192.168.165.18 192.168.165.253 TFTP > Data Packet, Block: 453 > 69507 25.516662 192.168.165.253 192.168.165.18 TFTP > Error Code, Code: Not defined, Message: redboot > tftp_stream_terminate > 69508 25.826093 0.0.0.0 255.255.255.255 DHCP > DHCP Discover - Transaction ID 0x6c1dfce9 > 69511 26.074789 0.0.0.0 255.255.255.255 DHCP > DHCP Discover - Transaction ID 0x6c1dfce9 > 69512 26.304739 0.0.0.0 255.255.255.255 DHCP > DHCP Discover - Transaction ID 0x6c1dfce9 > 69514 26.451407 0.0.0.0 255.255.255.255 DHCP > DHCP Request - Transaction ID 0x6c1dfde9 > 69516 26.839890 Olicom_c8:1d:6c Broadcast ARP > Who has 192.168.165.254? Gratuitous ARP > Did your eCos application print anything about the DHCP transaction? I'm betting that it did not (which would imply you are having trouble with receive interrupts from your driver) > > 2008/1/10, Gary Thomas <gary@mlbassoc.com>: >> Antoine Zen-Ruffinen wrote: >>> Hi List folks, >>> >>> I've a problem with the TCP/IP stack: >>> - I use TFTP to load my program in redboot. That work fine. >>> - My application start, call init_all_network_interfaces(), it do the >>> DHCP stuff. That work fine. >>> - Then I open a socket and try to send / receive data. No packet is even send. >>> >>> Does someone has already seen such problem ? >>> Any idea ? >> We'll need more data than this in order to help. >> * What's the target platform? >> * How did you configure eCos for your failing application? >> * Have you run any of the standard eCos network test programs? >> * How do you know nothing was sent? What sort of debugging >> have you tried so far? -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ECOS] Problem with TCP/IP stack 2008-01-10 13:55 ` Gary Thomas @ 2008-01-10 14:15 ` Antoine Zen-Ruffinen 2008-01-10 15:32 ` Antoine Zen-Ruffinen 0 siblings, 1 reply; 20+ messages in thread From: Antoine Zen-Ruffinen @ 2008-01-10 14:15 UTC (permalink / raw) To: Gary Thomas; +Cc: eCos Discussion Sorry for the preceding message that was not send to the list, little mistake from me (cliqued "reply" and not "reply to all"). Yes my application print about DHCP transaction and it is ok. I have added some prints in every driver function in order to trace what it is doing. The output is interesting : 1) The NIC is making interrupts all the time 2) The network stack never call the send() function. Here is the output : RedBoot> load -m tftp -h 192.168.165.18 debugProg Entry point: 0x00200000, address range: 0x00200000-0x00238840 RedBoot> go [cyg_net_init] Init: mbinit(0x00000000) [cyg_net_init] Init: cyg_net_init_devs(0x00000000) Init device 'eth0' DP83816 at 0x0000e100, interrupt: 2a DP83816 - get ESA from EEPROM DP83816 - ESA: 00:00:24:c8:1d:6c Init device 'eth1' DP83816 at 0x0000e200, interrupt: 2a DP83816 - get ESA from EEPROM DP83816 - ESA: 00:00:24:c8:1d:6d [cyg_net_init] Init: loopattach(0x00000000) [cyg_net_init] Init: ifinit(0x00000000) [cyg_net_init] Init: domaininit(0x00000000) [cyg_net_init] Init: cyg_net_add_domain(0x00238000) New domain internet at 0x00000000 [cyg_net_init] Init: cyg_net_add_domain(0x002378e0) New domain route at 0x00000000 [cyg_net_init] Init: call_route_init(0x00000000) [cyg_net_init] Done Network testing program V2 Thread started Init network : DP83816 - ISR on eth0 [eth_drv_ioctl] Warning: Driver can't set multi-cast mode [eth_drv_ioctl] Warning: Driver can't set multi-cast mode DP83816 - can_send on eth0 : 16 DP83816 - send on eth0 DP83816 - can_send on eth0 : 15 DP83816 - deliver on eth0 DP83816 - pool on eth0 DP83816 - Tx Event on eth0 DP83816 - Rx event on eth0 DP83816 - recv on eth0 DP83816 - recv on eth0 DP83816 - can_send on eth0 : 16 DP83816 - send on eth0 DDP83816 - ISR on eth0 P83816 - can_send on eth0 : 15 DP83816 - deliver on eth0 DP83816 - pool on eth0 DP83816 - Tx Event on eth0 DP83816 - Rx event on eth0 DP83816 - recv on eth0 BOOTP[eth0] op: REQUEST htype: Ethernet hlen: 6 hops: 0 xid: 0xec511d6c secs: 0 flags: 0x80 hw_addr: 00:00:24:c8:1d:6c client IP: 0.0.0.0 my IP: 192.168.165.254 server IP: 192.168.165.1 gateway IP: 0.0.0.0 file: boots.default options: DHCP message: 3 REQUEST DHCP server id: 192.168.165.1 DHCP time 51: 43200 DHCP time 58: 21600 DHCP time 59: 37800 subnet mask: 255.255.255.0 gateway: 192.168.165.1 domain server: 192.168.165.1 domain name: v165.itslabb.bth.se. DHCP option: 37/55.9: 54 51 58 59 1 3 6 15 28 DHCP option: 39/57.2: 576 DHCP requested ip: 192.168.165.254 BOOTP[eth1] op: REPLY htype: Ethernet hlen: 6 hops: 0 xid: 0x0 secs: 0 flags: 0x0 hw_addr: 00:00:24:c8:1d:6d client IP: 10.0.0.10 my IP: 10.0.0.10 server IP: 0.0.0.0 gateway IP: 0.0.0.0 options: subnet mask: 255.255.255.0 IP broadcast: 10.0.0.255 gateway: 0.0.0.0 DP83816 - ISR on eth0 [eth_drv_ioctl] Warning: Driver can't set multi-cast mode DP83816 - can_send on eth0 : 16 DP83816 - send on eth0 DP83816 - can_send on eth0 : 15 [eth_drv_ioctl] Warning: Driver can't set multi-cast mode DP83816 - can_send on eth0 : 15 DP83816 - send on eth0 DP83816 - can_send on eth0 : 14 [eth_drv_ioctl] Warning: Driver can't set multi-cast mode DP83816 - can_send on eth1 : 16 DP83816 - send on eth1 DP83816 - can_send on eth1 : 15 [eth_drv_ioctl] Warning: Driver can't set multi-cast mode [eth_drv_ioctl] Warning: Driver can't set multi-cast mode DP83816 - can_send on eth1 : 15 DP83816 - send on eth1 DP83816 - can_send on eth1 : 14 [eth_drv_ioctl] Warning: Driver can't set multi-cast mode Network initalized ! Eth0 is up ! Eth1 is up ! socket() = 3 It seem that everthing is OK. start sending packets. A - 0> sendto() = 3 B - 0> Waiting for a packet DP83816 - deliver on eth0 DP83816 - pool on eth0 DP83816 - Tx Event on eth0 DP83816 - ISR on eth0 DP83816 - deliver on eth0 DP83816 - pool on eth0 DP83816 - ISR on eth0 A - 1> sendto() = 3 DP83816 - deliver on eth0 DP83816 - pool on eth0 DP83816 - ISR on eth0 DP83816 - deliver on eth0 DP83816 - pool on eth0 DP83816 - ISR on eth0 DP83816 - deliver on eth0 DP83816 - pool on eth0 DP83816 - ISR on eth0 A - 2> sendto() = 3 DP83816 - deliver on eth0 DP83816 - pool on eth0 DP83816 - ISR on eth0 DP83816 - deliver on eth0 DP83816 - pool on eth0 DP83816 - ISR on eth0 2008/1/10, Gary Thomas <gary@mlbassoc.com>: > Please keep your replies on the eCos list! > > **EVERYONE** please get this straight. Replies made by me on the > eCos discussion list must be followed up on the eCos discussion list > unless I invite private replies. This way everyone benefits, not > just the interested party. Private email support consultation and > support is available, but only with a contract. > > Antoine Zen-Ruffinen wrote: > > The target platform is an embed PC with NS dp83816 NIC. I've port the > > eCos driver my self for the PC platform. > > > > I configure eCos with the configtool, just using the template I made > > and the "net" package. > > > > No, I didn't run a standard eCos network test program. But I build an > > redboot with this configuration. If I type ping -n 1000 -r 1 -h > > 192.168.165.18 (is my host PC) everything went fine ! > > This is only partly relevant - RedBoot uses a completely different > network stack than normal eCos applications. Also, RedBoot does > not use interrupts, which the eCos stacks rely on. > > > > > I know that nothing was send : 1 becose network activity led doesn't > > blink, 2 I monitor network with Wireshark (Ethereal). the monitoring > > trace show the TFTP exchange and the DHCP init but nothing more. It > > look like this : > > No. Time Source Destination Protocol Info > > 69504 25.515675 192.168.165.18 192.168.165.253 TFTP > > Data Packet, Block: 452 > > 69505 25.516279 192.168.165.253 192.168.165.18 TFTP > > Acknowledgement, Block: 452 > > 69506 25.516289 192.168.165.18 192.168.165.253 TFTP > > Data Packet, Block: 453 > > 69507 25.516662 192.168.165.253 192.168.165.18 TFTP > > Error Code, Code: Not defined, Message: redboot > > tftp_stream_terminate > > 69508 25.826093 0.0.0.0 255.255.255.255 DHCP > > DHCP Discover - Transaction ID 0x6c1dfce9 > > 69511 26.074789 0.0.0.0 255.255.255.255 DHCP > > DHCP Discover - Transaction ID 0x6c1dfce9 > > 69512 26.304739 0.0.0.0 255.255.255.255 DHCP > > DHCP Discover - Transaction ID 0x6c1dfce9 > > 69514 26.451407 0.0.0.0 255.255.255.255 DHCP > > DHCP Request - Transaction ID 0x6c1dfde9 > > 69516 26.839890 Olicom_c8:1d:6c Broadcast ARP > > Who has 192.168.165.254? Gratuitous ARP > > > > Did your eCos application print anything about the DHCP transaction? > I'm betting that it did not (which would imply you are having trouble > with receive interrupts from your driver) > > > > > 2008/1/10, Gary Thomas <gary@mlbassoc.com>: > >> Antoine Zen-Ruffinen wrote: > >>> Hi List folks, > >>> > >>> I've a problem with the TCP/IP stack: > >>> - I use TFTP to load my program in redboot. That work fine. > >>> - My application start, call init_all_network_interfaces(), it do the > >>> DHCP stuff. That work fine. > >>> - Then I open a socket and try to send / receive data. No packet is even send. > >>> > >>> Does someone has already seen such problem ? > >>> Any idea ? > >> We'll need more data than this in order to help. > >> * What's the target platform? > >> * How did you configure eCos for your failing application? > >> * Have you run any of the standard eCos network test programs? > >> * How do you know nothing was sent? What sort of debugging > >> have you tried so far? > > > -- > ------------------------------------------------------------ > Gary Thomas | Consulting for the > MLB Associates | Embedded world > ------------------------------------------------------------ > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ECOS] Problem with TCP/IP stack 2008-01-10 14:15 ` Antoine Zen-Ruffinen @ 2008-01-10 15:32 ` Antoine Zen-Ruffinen 2008-01-11 8:48 ` Antoine Zen-Ruffinen 0 siblings, 1 reply; 20+ messages in thread From: Antoine Zen-Ruffinen @ 2008-01-10 15:32 UTC (permalink / raw) To: Gary Thomas; +Cc: eCos Discussion The previous post "[ECOS] Cannot sendto multicast using FreeBSD stack" put me on the way!! No IP packet are send, but ARP is done. But it seem that the stack doesn't get the ARP reply witch is on the wire. When calling send(), for the fist calls, send() return > 0, but with errno=2 (No such entry) then send() return -1 wiht erron=364 (Host is down). Can this be because I have 2 NIC that share the same interrupt ? 2008/1/10, Antoine Zen-Ruffinen <antoine.zen@gmail.com>: > Sorry for the preceding message that was not send to the list, little > mistake from me (cliqued "reply" and not "reply to all"). > > Yes my application print about DHCP transaction and it is ok. I have > added some prints in every driver function in order to trace what it > is doing. The output is interesting : > 1) The NIC is making interrupts all the time > 2) The network stack never call the send() function. > > Here is the output : > RedBoot> load -m tftp -h 192.168.165.18 debugProg > Entry point: 0x00200000, address range: 0x00200000-0x00238840 > RedBoot> go > [cyg_net_init] Init: mbinit(0x00000000) > [cyg_net_init] Init: cyg_net_init_devs(0x00000000) > Init device 'eth0' > DP83816 at 0x0000e100, interrupt: 2a > DP83816 - get ESA from EEPROM > DP83816 - ESA: 00:00:24:c8:1d:6c > Init device 'eth1' > DP83816 at 0x0000e200, interrupt: 2a > DP83816 - get ESA from EEPROM > DP83816 - ESA: 00:00:24:c8:1d:6d > [cyg_net_init] Init: loopattach(0x00000000) > [cyg_net_init] Init: ifinit(0x00000000) > [cyg_net_init] Init: domaininit(0x00000000) > [cyg_net_init] Init: cyg_net_add_domain(0x00238000) > New domain internet at 0x00000000 > [cyg_net_init] Init: cyg_net_add_domain(0x002378e0) > New domain route at 0x00000000 > [cyg_net_init] Init: call_route_init(0x00000000) > [cyg_net_init] Done > Network testing program V2 > Thread started > Init network : DP83816 - ISR on eth0 > [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > DP83816 - can_send on eth0 : 16 > DP83816 - send on eth0 > DP83816 - can_send on eth0 : 15 > DP83816 - deliver on eth0 > DP83816 - pool on eth0 > DP83816 - Tx Event on eth0 > DP83816 - Rx event on eth0 > DP83816 - recv on eth0 > DP83816 - recv on eth0 > DP83816 - can_send on eth0 : 16 > DP83816 - send on eth0 > DDP83816 - ISR on eth0 > P83816 - can_send on eth0 : 15 > DP83816 - deliver on eth0 > DP83816 - pool on eth0 > DP83816 - Tx Event on eth0 > DP83816 - Rx event on eth0 > DP83816 - recv on eth0 > BOOTP[eth0] op: REQUEST > htype: Ethernet > hlen: 6 > hops: 0 > xid: 0xec511d6c > secs: 0 > flags: 0x80 > hw_addr: 00:00:24:c8:1d:6c > client IP: 0.0.0.0 > my IP: 192.168.165.254 > server IP: 192.168.165.1 > gateway IP: 0.0.0.0 > file: boots.default > options: > DHCP message: 3 REQUEST > DHCP server id: 192.168.165.1 > DHCP time 51: 43200 > DHCP time 58: 21600 > DHCP time 59: 37800 > subnet mask: 255.255.255.0 > gateway: 192.168.165.1 > domain server: 192.168.165.1 > domain name: v165.itslabb.bth.se. > DHCP option: 37/55.9: 54 51 58 59 1 3 6 15 28 > DHCP option: 39/57.2: 576 > DHCP requested ip: 192.168.165.254 > BOOTP[eth1] op: REPLY > htype: Ethernet > hlen: 6 > hops: 0 > xid: 0x0 > secs: 0 > flags: 0x0 > hw_addr: 00:00:24:c8:1d:6d > client IP: 10.0.0.10 > my IP: 10.0.0.10 > server IP: 0.0.0.0 > gateway IP: 0.0.0.0 > options: > subnet mask: 255.255.255.0 > IP broadcast: 10.0.0.255 > gateway: 0.0.0.0 > DP83816 - ISR on eth0 > [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > DP83816 - can_send on eth0 : 16 > DP83816 - send on eth0 > DP83816 - can_send on eth0 : 15 > [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > DP83816 - can_send on eth0 : 15 > DP83816 - send on eth0 > DP83816 - can_send on eth0 : 14 > [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > DP83816 - can_send on eth1 : 16 > DP83816 - send on eth1 > DP83816 - can_send on eth1 : 15 > [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > DP83816 - can_send on eth1 : 15 > DP83816 - send on eth1 > DP83816 - can_send on eth1 : 14 > [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > Network initalized ! > Eth0 is up ! > Eth1 is up ! > socket() = 3 > It seem that everthing is OK. start sending packets. > A - 0> sendto() = 3 > B - 0> Waiting for a packet > DP83816 - deliver on eth0 > DP83816 - pool on eth0 > DP83816 - Tx Event on eth0 > DP83816 - ISR on eth0 > DP83816 - deliver on eth0 > DP83816 - pool on eth0 > DP83816 - ISR on eth0 > A - 1> sendto() = 3 > DP83816 - deliver on eth0 > DP83816 - pool on eth0 > DP83816 - ISR on eth0 > DP83816 - deliver on eth0 > DP83816 - pool on eth0 > DP83816 - ISR on eth0 > DP83816 - deliver on eth0 > DP83816 - pool on eth0 > DP83816 - ISR on eth0 > A - 2> sendto() = 3 > DP83816 - deliver on eth0 > DP83816 - pool on eth0 > DP83816 - ISR on eth0 > DP83816 - deliver on eth0 > DP83816 - pool on eth0 > DP83816 - ISR on eth0 > > > > > 2008/1/10, Gary Thomas <gary@mlbassoc.com>: > > Please keep your replies on the eCos list! > > > > **EVERYONE** please get this straight. Replies made by me on the > > eCos discussion list must be followed up on the eCos discussion list > > unless I invite private replies. This way everyone benefits, not > > just the interested party. Private email support consultation and > > support is available, but only with a contract. > > > > Antoine Zen-Ruffinen wrote: > > > The target platform is an embed PC with NS dp83816 NIC. I've port the > > > eCos driver my self for the PC platform. > > > > > > I configure eCos with the configtool, just using the template I made > > > and the "net" package. > > > > > > No, I didn't run a standard eCos network test program. But I build an > > > redboot with this configuration. If I type ping -n 1000 -r 1 -h > > > 192.168.165.18 (is my host PC) everything went fine ! > > > > This is only partly relevant - RedBoot uses a completely different > > network stack than normal eCos applications. Also, RedBoot does > > not use interrupts, which the eCos stacks rely on. > > > > > > > > I know that nothing was send : 1 becose network activity led doesn't > > > blink, 2 I monitor network with Wireshark (Ethereal). the monitoring > > > trace show the TFTP exchange and the DHCP init but nothing more. It > > > look like this : > > > No. Time Source Destination Protocol Info > > > 69504 25.515675 192.168.165.18 192.168.165.253 TFTP > > > Data Packet, Block: 452 > > > 69505 25.516279 192.168.165.253 192.168.165.18 TFTP > > > Acknowledgement, Block: 452 > > > 69506 25.516289 192.168.165.18 192.168.165.253 TFTP > > > Data Packet, Block: 453 > > > 69507 25.516662 192.168.165.253 192.168.165.18 TFTP > > > Error Code, Code: Not defined, Message: redboot > > > tftp_stream_terminate > > > 69508 25.826093 0.0.0.0 255.255.255.255 DHCP > > > DHCP Discover - Transaction ID 0x6c1dfce9 > > > 69511 26.074789 0.0.0.0 255.255.255.255 DHCP > > > DHCP Discover - Transaction ID 0x6c1dfce9 > > > 69512 26.304739 0.0.0.0 255.255.255.255 DHCP > > > DHCP Discover - Transaction ID 0x6c1dfce9 > > > 69514 26.451407 0.0.0.0 255.255.255.255 DHCP > > > DHCP Request - Transaction ID 0x6c1dfde9 > > > 69516 26.839890 Olicom_c8:1d:6c Broadcast ARP > > > Who has 192.168.165.254? Gratuitous ARP > > > > > > > Did your eCos application print anything about the DHCP transaction? > > I'm betting that it did not (which would imply you are having trouble > > with receive interrupts from your driver) > > > > > > > > 2008/1/10, Gary Thomas <gary@mlbassoc.com>: > > >> Antoine Zen-Ruffinen wrote: > > >>> Hi List folks, > > >>> > > >>> I've a problem with the TCP/IP stack: > > >>> - I use TFTP to load my program in redboot. That work fine. > > >>> - My application start, call init_all_network_interfaces(), it do the > > >>> DHCP stuff. That work fine. > > >>> - Then I open a socket and try to send / receive data. No packet is even send. > > >>> > > >>> Does someone has already seen such problem ? > > >>> Any idea ? > > >> We'll need more data than this in order to help. > > >> * What's the target platform? > > >> * How did you configure eCos for your failing application? > > >> * Have you run any of the standard eCos network test programs? > > >> * How do you know nothing was sent? What sort of debugging > > >> have you tried so far? > > > > > > -- > > ------------------------------------------------------------ > > Gary Thomas | Consulting for the > > MLB Associates | Embedded world > > ------------------------------------------------------------ > > > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ECOS] Problem with TCP/IP stack 2008-01-10 15:32 ` Antoine Zen-Ruffinen @ 2008-01-11 8:48 ` Antoine Zen-Ruffinen 2008-01-11 12:38 ` Antoine Zen-Ruffinen 0 siblings, 1 reply; 20+ messages in thread From: Antoine Zen-Ruffinen @ 2008-01-11 8:48 UTC (permalink / raw) To: Gary Thomas; +Cc: eCos Discussion Some new discover : If a use only one of the two NIC I have on my system, everything work fine. When using two NIC, interrupts all the time, even if no network activity, even if doing nothing and ARP response are not catch by network stack. So the problem is a conflict between both interfaces. Here is my driver declaration (for the i386 platform), maybe something wrong there : #include <cyg/hal/hal_cache.h> #include <cyg/io/pci.h> static cyg_bool find_dp83816_match_func(cyg_uint16 v, cyg_uint16 d, cyg_uint32 c, void *p) { return ((v == 0x100B) && (d == 0x0020)); } cyg_pci_device_id devid = CYG_PCI_NULL_DEVID; static void _i386_pc_eth_init(dp83816_priv_data_t *dp) { cyg_pci_device dev_info; if (cyg_pci_find_matching( &find_dp83816_match_func, NULL, &devid )) { cyg_pci_get_device_info(devid, &dev_info); cyg_pci_translate_interrupt(&dev_info, &dp->interrupt); dp->base = (cyg_uint8 *)(dev_info.base_map[0] & ~1); diag_printf("DP83816 at %p, interrupt: %x\n", dp->base, dp->interrupt); } } #undef CYGHWR_NS_DP83816_PLF_INIT #define CYGHWR_NS_DP83816_PLF_INIT(dp) _i386_pc_eth_init(dp) // Align buffers on a cache boundary #define RxBUFSIZE (CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM * _DP83816_BUFSIZE) #define TxBUFSIZE (CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM * _DP83816_BUFSIZE) static unsigned char dp83816_eth0_rxbufs[RxBUFSIZE] __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); static unsigned char dp83816_eth0_txbufs[TxBUFSIZE] __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); static dp83816_bd_t dp83816_eth0_rxbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM] __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); static dp83816_bd_t dp83816_eth0_txbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM] __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); static unsigned char dp83816_eth1_rxbufs[RxBUFSIZE] __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); static unsigned char dp83816_eth1_txbufs[TxBUFSIZE] __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); static dp83816_bd_t dp83816_eth1_rxbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM] __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); static dp83816_bd_t dp83816_eth1_txbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM] __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); // eth0 delacration char _i386_pc_eth0_ESA[6]; static dp83816_priv_data_t dp83816_eth0_priv_data = { "eth0_esa", _i386_pc_eth0_ESA, CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM, // Number of Rx buffers dp83816_eth0_rxbufs, // Rx buffer space dp83816_eth0_rxbd, // Rx buffer headers CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM, // Number of Tx buffers dp83816_eth0_txbufs, // Tx buffer space dp83816_eth0_txbd, // Tx buffer headers }; ETH_DRV_SC(dp83816_sc0, &dp83816_eth0_priv_data, // Driver specific data "eth0", dp83816_start, dp83816_stop, dp83816_control, dp83816_can_send, dp83816_send, dp83816_recv, dp83816_deliver, // "pseudoDSR" called from fast net thread dp83816_poll, // poll function, encapsulates ISR and DSR dp83816_int_vector); NETDEVTAB_ENTRY(dp83816_netdev0, "eth0", dp83816_init, &dp83816_sc0); // eth1 delacration char _i386_pc_eth1_ESA[6]; static dp83816_priv_data_t dp83816_eth1_priv_data = { "eth1_esa", _i386_pc_eth1_ESA, CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM, // Number of Rx buffers dp83816_eth1_rxbufs, // Rx buffer space dp83816_eth1_rxbd, // Rx buffer headers CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM, // Number of Tx buffers dp83816_eth1_txbufs, // Tx buffer space dp83816_eth1_txbd, // Tx buffer headers }; ETH_DRV_SC(dp83816_sc1, &dp83816_eth1_priv_data, // Driver specific data "eth1", dp83816_start, dp83816_stop, dp83816_control, dp83816_can_send, dp83816_send, dp83816_recv, dp83816_deliver, // "pseudoDSR" called from fast net thread dp83816_poll, // poll function, encapsulates ISR and DSR dp83816_int_vector); NETDEVTAB_ENTRY(dp83816_netdev1, "eth1", dp83816_init, &dp83816_sc1); 2008/1/10, Antoine Zen-Ruffinen <antoine.zen@gmail.com>: > The previous post "[ECOS] Cannot sendto multicast using FreeBSD stack" > put me on the way!! > > No IP packet are send, but ARP is done. But it seem that the stack > doesn't get the ARP reply witch is on the wire. When calling send(), > for the fist calls, send() return > 0, but with errno=2 (No such > entry) then send() return -1 wiht erron=364 (Host is down). Can this > be because I have 2 NIC that share the same interrupt ? > > 2008/1/10, Antoine Zen-Ruffinen <antoine.zen@gmail.com>: > > Sorry for the preceding message that was not send to the list, little > > mistake from me (cliqued "reply" and not "reply to all"). > > > > Yes my application print about DHCP transaction and it is ok. I have > > added some prints in every driver function in order to trace what it > > is doing. The output is interesting : > > 1) The NIC is making interrupts all the time > > 2) The network stack never call the send() function. > > > > Here is the output : > > RedBoot> load -m tftp -h 192.168.165.18 debugProg > > Entry point: 0x00200000, address range: 0x00200000-0x00238840 > > RedBoot> go > > [cyg_net_init] Init: mbinit(0x00000000) > > [cyg_net_init] Init: cyg_net_init_devs(0x00000000) > > Init device 'eth0' > > DP83816 at 0x0000e100, interrupt: 2a > > DP83816 - get ESA from EEPROM > > DP83816 - ESA: 00:00:24:c8:1d:6c > > Init device 'eth1' > > DP83816 at 0x0000e200, interrupt: 2a > > DP83816 - get ESA from EEPROM > > DP83816 - ESA: 00:00:24:c8:1d:6d > > [cyg_net_init] Init: loopattach(0x00000000) > > [cyg_net_init] Init: ifinit(0x00000000) > > [cyg_net_init] Init: domaininit(0x00000000) > > [cyg_net_init] Init: cyg_net_add_domain(0x00238000) > > New domain internet at 0x00000000 > > [cyg_net_init] Init: cyg_net_add_domain(0x002378e0) > > New domain route at 0x00000000 > > [cyg_net_init] Init: call_route_init(0x00000000) > > [cyg_net_init] Done > > Network testing program V2 > > Thread started > > Init network : DP83816 - ISR on eth0 > > [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > > [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > > DP83816 - can_send on eth0 : 16 > > DP83816 - send on eth0 > > DP83816 - can_send on eth0 : 15 > > DP83816 - deliver on eth0 > > DP83816 - pool on eth0 > > DP83816 - Tx Event on eth0 > > DP83816 - Rx event on eth0 > > DP83816 - recv on eth0 > > DP83816 - recv on eth0 > > DP83816 - can_send on eth0 : 16 > > DP83816 - send on eth0 > > DDP83816 - ISR on eth0 > > P83816 - can_send on eth0 : 15 > > DP83816 - deliver on eth0 > > DP83816 - pool on eth0 > > DP83816 - Tx Event on eth0 > > DP83816 - Rx event on eth0 > > DP83816 - recv on eth0 > > BOOTP[eth0] op: REQUEST > > htype: Ethernet > > hlen: 6 > > hops: 0 > > xid: 0xec511d6c > > secs: 0 > > flags: 0x80 > > hw_addr: 00:00:24:c8:1d:6c > > client IP: 0.0.0.0 > > my IP: 192.168.165.254 > > server IP: 192.168.165.1 > > gateway IP: 0.0.0.0 > > file: boots.default > > options: > > DHCP message: 3 REQUEST > > DHCP server id: 192.168.165.1 > > DHCP time 51: 43200 > > DHCP time 58: 21600 > > DHCP time 59: 37800 > > subnet mask: 255.255.255.0 > > gateway: 192.168.165.1 > > domain server: 192.168.165.1 > > domain name: v165.itslabb.bth.se. > > DHCP option: 37/55.9: 54 51 58 59 1 3 6 15 28 > > DHCP option: 39/57.2: 576 > > DHCP requested ip: 192.168.165.254 > > BOOTP[eth1] op: REPLY > > htype: Ethernet > > hlen: 6 > > hops: 0 > > xid: 0x0 > > secs: 0 > > flags: 0x0 > > hw_addr: 00:00:24:c8:1d:6d > > client IP: 10.0.0.10 > > my IP: 10.0.0.10 > > server IP: 0.0.0.0 > > gateway IP: 0.0.0.0 > > options: > > subnet mask: 255.255.255.0 > > IP broadcast: 10.0.0.255 > > gateway: 0.0.0.0 > > DP83816 - ISR on eth0 > > [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > > DP83816 - can_send on eth0 : 16 > > DP83816 - send on eth0 > > DP83816 - can_send on eth0 : 15 > > [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > > DP83816 - can_send on eth0 : 15 > > DP83816 - send on eth0 > > DP83816 - can_send on eth0 : 14 > > [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > > DP83816 - can_send on eth1 : 16 > > DP83816 - send on eth1 > > DP83816 - can_send on eth1 : 15 > > [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > > [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > > DP83816 - can_send on eth1 : 15 > > DP83816 - send on eth1 > > DP83816 - can_send on eth1 : 14 > > [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > > Network initalized ! > > Eth0 is up ! > > Eth1 is up ! > > socket() = 3 > > It seem that everthing is OK. start sending packets. > > A - 0> sendto() = 3 > > B - 0> Waiting for a packet > > DP83816 - deliver on eth0 > > DP83816 - pool on eth0 > > DP83816 - Tx Event on eth0 > > DP83816 - ISR on eth0 > > DP83816 - deliver on eth0 > > DP83816 - pool on eth0 > > DP83816 - ISR on eth0 > > A - 1> sendto() = 3 > > DP83816 - deliver on eth0 > > DP83816 - pool on eth0 > > DP83816 - ISR on eth0 > > DP83816 - deliver on eth0 > > DP83816 - pool on eth0 > > DP83816 - ISR on eth0 > > DP83816 - deliver on eth0 > > DP83816 - pool on eth0 > > DP83816 - ISR on eth0 > > A - 2> sendto() = 3 > > DP83816 - deliver on eth0 > > DP83816 - pool on eth0 > > DP83816 - ISR on eth0 > > DP83816 - deliver on eth0 > > DP83816 - pool on eth0 > > DP83816 - ISR on eth0 > > > > > > > > > > 2008/1/10, Gary Thomas <gary@mlbassoc.com>: > > > Please keep your replies on the eCos list! > > > > > > **EVERYONE** please get this straight. Replies made by me on the > > > eCos discussion list must be followed up on the eCos discussion list > > > unless I invite private replies. This way everyone benefits, not > > > just the interested party. Private email support consultation and > > > support is available, but only with a contract. > > > > > > Antoine Zen-Ruffinen wrote: > > > > The target platform is an embed PC with NS dp83816 NIC. I've port the > > > > eCos driver my self for the PC platform. > > > > > > > > I configure eCos with the configtool, just using the template I made > > > > and the "net" package. > > > > > > > > No, I didn't run a standard eCos network test program. But I build an > > > > redboot with this configuration. If I type ping -n 1000 -r 1 -h > > > > 192.168.165.18 (is my host PC) everything went fine ! > > > > > > This is only partly relevant - RedBoot uses a completely different > > > network stack than normal eCos applications. Also, RedBoot does > > > not use interrupts, which the eCos stacks rely on. > > > > > > > > > > > I know that nothing was send : 1 becose network activity led doesn't > > > > blink, 2 I monitor network with Wireshark (Ethereal). the monitoring > > > > trace show the TFTP exchange and the DHCP init but nothing more. It > > > > look like this : > > > > No. Time Source Destination Protocol Info > > > > 69504 25.515675 192.168.165.18 192.168.165.253 TFTP > > > > Data Packet, Block: 452 > > > > 69505 25.516279 192.168.165.253 192.168.165.18 TFTP > > > > Acknowledgement, Block: 452 > > > > 69506 25.516289 192.168.165.18 192.168.165.253 TFTP > > > > Data Packet, Block: 453 > > > > 69507 25.516662 192.168.165.253 192.168.165.18 TFTP > > > > Error Code, Code: Not defined, Message: redboot > > > > tftp_stream_terminate > > > > 69508 25.826093 0.0.0.0 255.255.255.255 DHCP > > > > DHCP Discover - Transaction ID 0x6c1dfce9 > > > > 69511 26.074789 0.0.0.0 255.255.255.255 DHCP > > > > DHCP Discover - Transaction ID 0x6c1dfce9 > > > > 69512 26.304739 0.0.0.0 255.255.255.255 DHCP > > > > DHCP Discover - Transaction ID 0x6c1dfce9 > > > > 69514 26.451407 0.0.0.0 255.255.255.255 DHCP > > > > DHCP Request - Transaction ID 0x6c1dfde9 > > > > 69516 26.839890 Olicom_c8:1d:6c Broadcast ARP > > > > Who has 192.168.165.254? Gratuitous ARP > > > > > > > > > > Did your eCos application print anything about the DHCP transaction? > > > I'm betting that it did not (which would imply you are having trouble > > > with receive interrupts from your driver) > > > > > > > > > > > 2008/1/10, Gary Thomas <gary@mlbassoc.com>: > > > >> Antoine Zen-Ruffinen wrote: > > > >>> Hi List folks, > > > >>> > > > >>> I've a problem with the TCP/IP stack: > > > >>> - I use TFTP to load my program in redboot. That work fine. > > > >>> - My application start, call init_all_network_interfaces(), it do the > > > >>> DHCP stuff. That work fine. > > > >>> - Then I open a socket and try to send / receive data. No packet is even send. > > > >>> > > > >>> Does someone has already seen such problem ? > > > >>> Any idea ? > > > >> We'll need more data than this in order to help. > > > >> * What's the target platform? > > > >> * How did you configure eCos for your failing application? > > > >> * Have you run any of the standard eCos network test programs? > > > >> * How do you know nothing was sent? What sort of debugging > > > >> have you tried so far? > > > > > > > > > -- > > > ------------------------------------------------------------ > > > Gary Thomas | Consulting for the > > > MLB Associates | Embedded world > > > ------------------------------------------------------------ > > > > > > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ECOS] Problem with TCP/IP stack 2008-01-11 8:48 ` Antoine Zen-Ruffinen @ 2008-01-11 12:38 ` Antoine Zen-Ruffinen 2008-01-11 12:47 ` Gary Thomas 0 siblings, 1 reply; 20+ messages in thread From: Antoine Zen-Ruffinen @ 2008-01-11 12:38 UTC (permalink / raw) To: Gary Thomas; +Cc: eCos Discussion Ok, I found the problem but I dont' know how to solve it: My two NIC are sharing the same interrupt. So when the second NIC do an interrupt, it is handel like it is the first NIC that interrupt. Does someone know how to solve such an issue ? 2008/1/11, Antoine Zen-Ruffinen <antoine.zen@gmail.com>: > Some new discover : If a use only one of the two NIC I have on my > system, everything work fine. When using two NIC, interrupts all the > time, even if no network activity, even if doing nothing and ARP > response are not catch by network stack. So the problem is a conflict > between both interfaces. Here is my driver declaration (for the i386 > platform), maybe something wrong there : > > #include <cyg/hal/hal_cache.h> > #include <cyg/io/pci.h> > > > static cyg_bool > find_dp83816_match_func(cyg_uint16 v, cyg_uint16 d, cyg_uint32 c, void *p) > { > return ((v == 0x100B) && (d == 0x0020)); > } > > cyg_pci_device_id devid = CYG_PCI_NULL_DEVID; > static void > _i386_pc_eth_init(dp83816_priv_data_t *dp) > { > > cyg_pci_device dev_info; > > > if (cyg_pci_find_matching( &find_dp83816_match_func, NULL, &devid )) { > cyg_pci_get_device_info(devid, &dev_info); > cyg_pci_translate_interrupt(&dev_info, &dp->interrupt); > dp->base = (cyg_uint8 *)(dev_info.base_map[0] & ~1); > diag_printf("DP83816 at %p, interrupt: %x\n", dp->base, dp->interrupt); > } > } > > #undef CYGHWR_NS_DP83816_PLF_INIT > #define CYGHWR_NS_DP83816_PLF_INIT(dp) _i386_pc_eth_init(dp) > > // Align buffers on a cache boundary > #define RxBUFSIZE (CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM * _DP83816_BUFSIZE) > #define TxBUFSIZE (CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM * _DP83816_BUFSIZE) > static unsigned char dp83816_eth0_rxbufs[RxBUFSIZE] > __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > static unsigned char dp83816_eth0_txbufs[TxBUFSIZE] > __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > static dp83816_bd_t > dp83816_eth0_rxbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM] > __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > static dp83816_bd_t > dp83816_eth0_txbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM] > __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > > static unsigned char dp83816_eth1_rxbufs[RxBUFSIZE] > __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > static unsigned char dp83816_eth1_txbufs[TxBUFSIZE] > __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > static dp83816_bd_t > dp83816_eth1_rxbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM] > __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > static dp83816_bd_t > dp83816_eth1_txbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM] > __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > > > // eth0 delacration > char _i386_pc_eth0_ESA[6]; > static dp83816_priv_data_t dp83816_eth0_priv_data = { > "eth0_esa", > _i386_pc_eth0_ESA, > CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM, // Number of Rx buffers > dp83816_eth0_rxbufs, // Rx buffer space > dp83816_eth0_rxbd, // Rx buffer headers > CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM, // Number of Tx buffers > dp83816_eth0_txbufs, // Tx buffer space > dp83816_eth0_txbd, // Tx buffer headers > }; > > ETH_DRV_SC(dp83816_sc0, > &dp83816_eth0_priv_data, // Driver specific data > "eth0", > dp83816_start, > dp83816_stop, > dp83816_control, > dp83816_can_send, > dp83816_send, > dp83816_recv, > dp83816_deliver, // "pseudoDSR" called from fast net thread > dp83816_poll, // poll function, encapsulates ISR and DSR > dp83816_int_vector); > > NETDEVTAB_ENTRY(dp83816_netdev0, > "eth0", > dp83816_init, > &dp83816_sc0); > > // eth1 delacration > char _i386_pc_eth1_ESA[6]; > static dp83816_priv_data_t dp83816_eth1_priv_data = { > "eth1_esa", > _i386_pc_eth1_ESA, > CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM, // Number of Rx buffers > dp83816_eth1_rxbufs, // Rx buffer space > dp83816_eth1_rxbd, // Rx buffer headers > CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM, // Number of Tx buffers > dp83816_eth1_txbufs, // Tx buffer space > dp83816_eth1_txbd, // Tx buffer headers > }; > > ETH_DRV_SC(dp83816_sc1, > &dp83816_eth1_priv_data, // Driver specific data > "eth1", > dp83816_start, > dp83816_stop, > dp83816_control, > dp83816_can_send, > dp83816_send, > dp83816_recv, > dp83816_deliver, // "pseudoDSR" called from fast net thread > dp83816_poll, // poll function, encapsulates ISR and DSR > dp83816_int_vector); > > NETDEVTAB_ENTRY(dp83816_netdev1, > "eth1", > dp83816_init, > &dp83816_sc1); > > > > 2008/1/10, Antoine Zen-Ruffinen <antoine.zen@gmail.com>: > > The previous post "[ECOS] Cannot sendto multicast using FreeBSD stack" > > put me on the way!! > > > > No IP packet are send, but ARP is done. But it seem that the stack > > doesn't get the ARP reply witch is on the wire. When calling send(), > > for the fist calls, send() return > 0, but with errno=2 (No such > > entry) then send() return -1 wiht erron=364 (Host is down). Can this > > be because I have 2 NIC that share the same interrupt ? > > > > 2008/1/10, Antoine Zen-Ruffinen <antoine.zen@gmail.com>: > > > Sorry for the preceding message that was not send to the list, little > > > mistake from me (cliqued "reply" and not "reply to all"). > > > > > > Yes my application print about DHCP transaction and it is ok. I have > > > added some prints in every driver function in order to trace what it > > > is doing. The output is interesting : > > > 1) The NIC is making interrupts all the time > > > 2) The network stack never call the send() function. > > > > > > Here is the output : > > > RedBoot> load -m tftp -h 192.168.165.18 debugProg > > > Entry point: 0x00200000, address range: 0x00200000-0x00238840 > > > RedBoot> go > > > [cyg_net_init] Init: mbinit(0x00000000) > > > [cyg_net_init] Init: cyg_net_init_devs(0x00000000) > > > Init device 'eth0' > > > DP83816 at 0x0000e100, interrupt: 2a > > > DP83816 - get ESA from EEPROM > > > DP83816 - ESA: 00:00:24:c8:1d:6c > > > Init device 'eth1' > > > DP83816 at 0x0000e200, interrupt: 2a > > > DP83816 - get ESA from EEPROM > > > DP83816 - ESA: 00:00:24:c8:1d:6d > > > [cyg_net_init] Init: loopattach(0x00000000) > > > [cyg_net_init] Init: ifinit(0x00000000) > > > [cyg_net_init] Init: domaininit(0x00000000) > > > [cyg_net_init] Init: cyg_net_add_domain(0x00238000) > > > New domain internet at 0x00000000 > > > [cyg_net_init] Init: cyg_net_add_domain(0x002378e0) > > > New domain route at 0x00000000 > > > [cyg_net_init] Init: call_route_init(0x00000000) > > > [cyg_net_init] Done > > > Network testing program V2 > > > Thread started > > > Init network : DP83816 - ISR on eth0 > > > [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > > > [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > > > DP83816 - can_send on eth0 : 16 > > > DP83816 - send on eth0 > > > DP83816 - can_send on eth0 : 15 > > > DP83816 - deliver on eth0 > > > DP83816 - pool on eth0 > > > DP83816 - Tx Event on eth0 > > > DP83816 - Rx event on eth0 > > > DP83816 - recv on eth0 > > > DP83816 - recv on eth0 > > > DP83816 - can_send on eth0 : 16 > > > DP83816 - send on eth0 > > > DDP83816 - ISR on eth0 > > > P83816 - can_send on eth0 : 15 > > > DP83816 - deliver on eth0 > > > DP83816 - pool on eth0 > > > DP83816 - Tx Event on eth0 > > > DP83816 - Rx event on eth0 > > > DP83816 - recv on eth0 > > > BOOTP[eth0] op: REQUEST > > > htype: Ethernet > > > hlen: 6 > > > hops: 0 > > > xid: 0xec511d6c > > > secs: 0 > > > flags: 0x80 > > > hw_addr: 00:00:24:c8:1d:6c > > > client IP: 0.0.0.0 > > > my IP: 192.168.165.254 > > > server IP: 192.168.165.1 > > > gateway IP: 0.0.0.0 > > > file: boots.default > > > options: > > > DHCP message: 3 REQUEST > > > DHCP server id: 192.168.165.1 > > > DHCP time 51: 43200 > > > DHCP time 58: 21600 > > > DHCP time 59: 37800 > > > subnet mask: 255.255.255.0 > > > gateway: 192.168.165.1 > > > domain server: 192.168.165.1 > > > domain name: v165.itslabb.bth.se. > > > DHCP option: 37/55.9: 54 51 58 59 1 3 6 15 28 > > > DHCP option: 39/57.2: 576 > > > DHCP requested ip: 192.168.165.254 > > > BOOTP[eth1] op: REPLY > > > htype: Ethernet > > > hlen: 6 > > > hops: 0 > > > xid: 0x0 > > > secs: 0 > > > flags: 0x0 > > > hw_addr: 00:00:24:c8:1d:6d > > > client IP: 10.0.0.10 > > > my IP: 10.0.0.10 > > > server IP: 0.0.0.0 > > > gateway IP: 0.0.0.0 > > > options: > > > subnet mask: 255.255.255.0 > > > IP broadcast: 10.0.0.255 > > > gateway: 0.0.0.0 > > > DP83816 - ISR on eth0 > > > [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > > > DP83816 - can_send on eth0 : 16 > > > DP83816 - send on eth0 > > > DP83816 - can_send on eth0 : 15 > > > [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > > > DP83816 - can_send on eth0 : 15 > > > DP83816 - send on eth0 > > > DP83816 - can_send on eth0 : 14 > > > [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > > > DP83816 - can_send on eth1 : 16 > > > DP83816 - send on eth1 > > > DP83816 - can_send on eth1 : 15 > > > [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > > > [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > > > DP83816 - can_send on eth1 : 15 > > > DP83816 - send on eth1 > > > DP83816 - can_send on eth1 : 14 > > > [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > > > Network initalized ! > > > Eth0 is up ! > > > Eth1 is up ! > > > socket() = 3 > > > It seem that everthing is OK. start sending packets. > > > A - 0> sendto() = 3 > > > B - 0> Waiting for a packet > > > DP83816 - deliver on eth0 > > > DP83816 - pool on eth0 > > > DP83816 - Tx Event on eth0 > > > DP83816 - ISR on eth0 > > > DP83816 - deliver on eth0 > > > DP83816 - pool on eth0 > > > DP83816 - ISR on eth0 > > > A - 1> sendto() = 3 > > > DP83816 - deliver on eth0 > > > DP83816 - pool on eth0 > > > DP83816 - ISR on eth0 > > > DP83816 - deliver on eth0 > > > DP83816 - pool on eth0 > > > DP83816 - ISR on eth0 > > > DP83816 - deliver on eth0 > > > DP83816 - pool on eth0 > > > DP83816 - ISR on eth0 > > > A - 2> sendto() = 3 > > > DP83816 - deliver on eth0 > > > DP83816 - pool on eth0 > > > DP83816 - ISR on eth0 > > > DP83816 - deliver on eth0 > > > DP83816 - pool on eth0 > > > DP83816 - ISR on eth0 > > > > > > > > > > > > > > > 2008/1/10, Gary Thomas <gary@mlbassoc.com>: > > > > Please keep your replies on the eCos list! > > > > > > > > **EVERYONE** please get this straight. Replies made by me on the > > > > eCos discussion list must be followed up on the eCos discussion list > > > > unless I invite private replies. This way everyone benefits, not > > > > just the interested party. Private email support consultation and > > > > support is available, but only with a contract. > > > > > > > > Antoine Zen-Ruffinen wrote: > > > > > The target platform is an embed PC with NS dp83816 NIC. I've port the > > > > > eCos driver my self for the PC platform. > > > > > > > > > > I configure eCos with the configtool, just using the template I made > > > > > and the "net" package. > > > > > > > > > > No, I didn't run a standard eCos network test program. But I build an > > > > > redboot with this configuration. If I type ping -n 1000 -r 1 -h > > > > > 192.168.165.18 (is my host PC) everything went fine ! > > > > > > > > This is only partly relevant - RedBoot uses a completely different > > > > network stack than normal eCos applications. Also, RedBoot does > > > > not use interrupts, which the eCos stacks rely on. > > > > > > > > > > > > > > I know that nothing was send : 1 becose network activity led doesn't > > > > > blink, 2 I monitor network with Wireshark (Ethereal). the monitoring > > > > > trace show the TFTP exchange and the DHCP init but nothing more. It > > > > > look like this : > > > > > No. Time Source Destination Protocol Info > > > > > 69504 25.515675 192.168.165.18 192.168.165.253 TFTP > > > > > Data Packet, Block: 452 > > > > > 69505 25.516279 192.168.165.253 192.168.165.18 TFTP > > > > > Acknowledgement, Block: 452 > > > > > 69506 25.516289 192.168.165.18 192.168.165.253 TFTP > > > > > Data Packet, Block: 453 > > > > > 69507 25.516662 192.168.165.253 192.168.165.18 TFTP > > > > > Error Code, Code: Not defined, Message: redboot > > > > > tftp_stream_terminate > > > > > 69508 25.826093 0.0.0.0 255.255.255.255 DHCP > > > > > DHCP Discover - Transaction ID 0x6c1dfce9 > > > > > 69511 26.074789 0.0.0.0 255.255.255.255 DHCP > > > > > DHCP Discover - Transaction ID 0x6c1dfce9 > > > > > 69512 26.304739 0.0.0.0 255.255.255.255 DHCP > > > > > DHCP Discover - Transaction ID 0x6c1dfce9 > > > > > 69514 26.451407 0.0.0.0 255.255.255.255 DHCP > > > > > DHCP Request - Transaction ID 0x6c1dfde9 > > > > > 69516 26.839890 Olicom_c8:1d:6c Broadcast ARP > > > > > Who has 192.168.165.254? Gratuitous ARP > > > > > > > > > > > > > Did your eCos application print anything about the DHCP transaction? > > > > I'm betting that it did not (which would imply you are having trouble > > > > with receive interrupts from your driver) > > > > > > > > > > > > > > 2008/1/10, Gary Thomas <gary@mlbassoc.com>: > > > > >> Antoine Zen-Ruffinen wrote: > > > > >>> Hi List folks, > > > > >>> > > > > >>> I've a problem with the TCP/IP stack: > > > > >>> - I use TFTP to load my program in redboot. That work fine. > > > > >>> - My application start, call init_all_network_interfaces(), it do the > > > > >>> DHCP stuff. That work fine. > > > > >>> - Then I open a socket and try to send / receive data. No packet is even send. > > > > >>> > > > > >>> Does someone has already seen such problem ? > > > > >>> Any idea ? > > > > >> We'll need more data than this in order to help. > > > > >> * What's the target platform? > > > > >> * How did you configure eCos for your failing application? > > > > >> * Have you run any of the standard eCos network test programs? > > > > >> * How do you know nothing was sent? What sort of debugging > > > > >> have you tried so far? > > > > > > > > > > > > -- > > > > ------------------------------------------------------------ > > > > Gary Thomas | Consulting for the > > > > MLB Associates | Embedded world > > > > ------------------------------------------------------------ > > > > > > > > > > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ECOS] Problem with TCP/IP stack 2008-01-11 12:38 ` Antoine Zen-Ruffinen @ 2008-01-11 12:47 ` Gary Thomas 2008-01-11 12:52 ` Andrew Lunn 2008-01-11 15:43 ` Antoine Zen-Ruffinen 0 siblings, 2 replies; 20+ messages in thread From: Gary Thomas @ 2008-01-11 12:47 UTC (permalink / raw) To: Antoine Zen-Ruffinen; +Cc: eCos Discussion Antoine Zen-Ruffinen wrote: > Ok, I found the problem but I dont' know how to solve it: My two NIC > are sharing the same interrupt. So when the second NIC do an > interrupt, it is handel like it is the first NIC that interrupt. > > Does someone know how to solve such an issue ? > The key is to make your interrupt handler (ISR) tell the upper layers which board did it. This is reflected in the (struct eth_drv_sc *) parameter that you pass upstream. Somehow, your driver will have to keep track of these (there is one such structure per physical device entity), then determine which board is responsible and use that information to decide which device (i.e. structure) to use. If you're using the same interrupt for both devices, surely you have Interrupt Chaining turned on in eCos? This allows for multiple ISR/DSR pairs to be registered for the same interrupt. eCos will call these ISR functions until one of them returns that it had handled the interrupt. This could be used to easily handle your situation. > 2008/1/11, Antoine Zen-Ruffinen <antoine.zen@gmail.com>: >> Some new discover : If a use only one of the two NIC I have on my >> system, everything work fine. When using two NIC, interrupts all the >> time, even if no network activity, even if doing nothing and ARP >> response are not catch by network stack. So the problem is a conflict >> between both interfaces. Here is my driver declaration (for the i386 >> platform), maybe something wrong there : >> >> #include <cyg/hal/hal_cache.h> >> #include <cyg/io/pci.h> >> >> >> static cyg_bool >> find_dp83816_match_func(cyg_uint16 v, cyg_uint16 d, cyg_uint32 c, void *p) >> { >> return ((v == 0x100B) && (d == 0x0020)); >> } >> >> cyg_pci_device_id devid = CYG_PCI_NULL_DEVID; >> static void >> _i386_pc_eth_init(dp83816_priv_data_t *dp) >> { >> >> cyg_pci_device dev_info; >> >> >> if (cyg_pci_find_matching( &find_dp83816_match_func, NULL, &devid )) { >> cyg_pci_get_device_info(devid, &dev_info); >> cyg_pci_translate_interrupt(&dev_info, &dp->interrupt); >> dp->base = (cyg_uint8 *)(dev_info.base_map[0] & ~1); >> diag_printf("DP83816 at %p, interrupt: %x\n", dp->base, dp->interrupt); >> } >> } >> >> #undef CYGHWR_NS_DP83816_PLF_INIT >> #define CYGHWR_NS_DP83816_PLF_INIT(dp) _i386_pc_eth_init(dp) >> >> // Align buffers on a cache boundary >> #define RxBUFSIZE (CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM * _DP83816_BUFSIZE) >> #define TxBUFSIZE (CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM * _DP83816_BUFSIZE) >> static unsigned char dp83816_eth0_rxbufs[RxBUFSIZE] >> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); >> static unsigned char dp83816_eth0_txbufs[TxBUFSIZE] >> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); >> static dp83816_bd_t >> dp83816_eth0_rxbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM] >> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); >> static dp83816_bd_t >> dp83816_eth0_txbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM] >> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); >> >> static unsigned char dp83816_eth1_rxbufs[RxBUFSIZE] >> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); >> static unsigned char dp83816_eth1_txbufs[TxBUFSIZE] >> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); >> static dp83816_bd_t >> dp83816_eth1_rxbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM] >> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); >> static dp83816_bd_t >> dp83816_eth1_txbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM] >> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); >> >> >> // eth0 delacration >> char _i386_pc_eth0_ESA[6]; >> static dp83816_priv_data_t dp83816_eth0_priv_data = { >> "eth0_esa", >> _i386_pc_eth0_ESA, >> CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM, // Number of Rx buffers >> dp83816_eth0_rxbufs, // Rx buffer space >> dp83816_eth0_rxbd, // Rx buffer headers >> CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM, // Number of Tx buffers >> dp83816_eth0_txbufs, // Tx buffer space >> dp83816_eth0_txbd, // Tx buffer headers >> }; >> >> ETH_DRV_SC(dp83816_sc0, >> &dp83816_eth0_priv_data, // Driver specific data >> "eth0", >> dp83816_start, >> dp83816_stop, >> dp83816_control, >> dp83816_can_send, >> dp83816_send, >> dp83816_recv, >> dp83816_deliver, // "pseudoDSR" called from fast net thread >> dp83816_poll, // poll function, encapsulates ISR and DSR >> dp83816_int_vector); >> >> NETDEVTAB_ENTRY(dp83816_netdev0, >> "eth0", >> dp83816_init, >> &dp83816_sc0); >> >> // eth1 delacration >> char _i386_pc_eth1_ESA[6]; >> static dp83816_priv_data_t dp83816_eth1_priv_data = { >> "eth1_esa", >> _i386_pc_eth1_ESA, >> CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM, // Number of Rx buffers >> dp83816_eth1_rxbufs, // Rx buffer space >> dp83816_eth1_rxbd, // Rx buffer headers >> CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM, // Number of Tx buffers >> dp83816_eth1_txbufs, // Tx buffer space >> dp83816_eth1_txbd, // Tx buffer headers >> }; >> >> ETH_DRV_SC(dp83816_sc1, >> &dp83816_eth1_priv_data, // Driver specific data >> "eth1", >> dp83816_start, >> dp83816_stop, >> dp83816_control, >> dp83816_can_send, >> dp83816_send, >> dp83816_recv, >> dp83816_deliver, // "pseudoDSR" called from fast net thread >> dp83816_poll, // poll function, encapsulates ISR and DSR >> dp83816_int_vector); >> >> NETDEVTAB_ENTRY(dp83816_netdev1, >> "eth1", >> dp83816_init, >> &dp83816_sc1); >> >> >> >> 2008/1/10, Antoine Zen-Ruffinen <antoine.zen@gmail.com>: >>> The previous post "[ECOS] Cannot sendto multicast using FreeBSD stack" >>> put me on the way!! >>> >>> No IP packet are send, but ARP is done. But it seem that the stack >>> doesn't get the ARP reply witch is on the wire. When calling send(), >>> for the fist calls, send() return > 0, but with errno=2 (No such >>> entry) then send() return -1 wiht erron=364 (Host is down). Can this >>> be because I have 2 NIC that share the same interrupt ? >>> >>> 2008/1/10, Antoine Zen-Ruffinen <antoine.zen@gmail.com>: >>>> Sorry for the preceding message that was not send to the list, little >>>> mistake from me (cliqued "reply" and not "reply to all"). >>>> >>>> Yes my application print about DHCP transaction and it is ok. I have >>>> added some prints in every driver function in order to trace what it >>>> is doing. The output is interesting : >>>> 1) The NIC is making interrupts all the time >>>> 2) The network stack never call the send() function. >>>> >>>> Here is the output : >>>> RedBoot> load -m tftp -h 192.168.165.18 debugProg >>>> Entry point: 0x00200000, address range: 0x00200000-0x00238840 >>>> RedBoot> go >>>> [cyg_net_init] Init: mbinit(0x00000000) >>>> [cyg_net_init] Init: cyg_net_init_devs(0x00000000) >>>> Init device 'eth0' >>>> DP83816 at 0x0000e100, interrupt: 2a >>>> DP83816 - get ESA from EEPROM >>>> DP83816 - ESA: 00:00:24:c8:1d:6c >>>> Init device 'eth1' >>>> DP83816 at 0x0000e200, interrupt: 2a >>>> DP83816 - get ESA from EEPROM >>>> DP83816 - ESA: 00:00:24:c8:1d:6d >>>> [cyg_net_init] Init: loopattach(0x00000000) >>>> [cyg_net_init] Init: ifinit(0x00000000) >>>> [cyg_net_init] Init: domaininit(0x00000000) >>>> [cyg_net_init] Init: cyg_net_add_domain(0x00238000) >>>> New domain internet at 0x00000000 >>>> [cyg_net_init] Init: cyg_net_add_domain(0x002378e0) >>>> New domain route at 0x00000000 >>>> [cyg_net_init] Init: call_route_init(0x00000000) >>>> [cyg_net_init] Done >>>> Network testing program V2 >>>> Thread started >>>> Init network : DP83816 - ISR on eth0 >>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode >>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode >>>> DP83816 - can_send on eth0 : 16 >>>> DP83816 - send on eth0 >>>> DP83816 - can_send on eth0 : 15 >>>> DP83816 - deliver on eth0 >>>> DP83816 - pool on eth0 >>>> DP83816 - Tx Event on eth0 >>>> DP83816 - Rx event on eth0 >>>> DP83816 - recv on eth0 >>>> DP83816 - recv on eth0 >>>> DP83816 - can_send on eth0 : 16 >>>> DP83816 - send on eth0 >>>> DDP83816 - ISR on eth0 >>>> P83816 - can_send on eth0 : 15 >>>> DP83816 - deliver on eth0 >>>> DP83816 - pool on eth0 >>>> DP83816 - Tx Event on eth0 >>>> DP83816 - Rx event on eth0 >>>> DP83816 - recv on eth0 >>>> BOOTP[eth0] op: REQUEST >>>> htype: Ethernet >>>> hlen: 6 >>>> hops: 0 >>>> xid: 0xec511d6c >>>> secs: 0 >>>> flags: 0x80 >>>> hw_addr: 00:00:24:c8:1d:6c >>>> client IP: 0.0.0.0 >>>> my IP: 192.168.165.254 >>>> server IP: 192.168.165.1 >>>> gateway IP: 0.0.0.0 >>>> file: boots.default >>>> options: >>>> DHCP message: 3 REQUEST >>>> DHCP server id: 192.168.165.1 >>>> DHCP time 51: 43200 >>>> DHCP time 58: 21600 >>>> DHCP time 59: 37800 >>>> subnet mask: 255.255.255.0 >>>> gateway: 192.168.165.1 >>>> domain server: 192.168.165.1 >>>> domain name: v165.itslabb.bth.se. >>>> DHCP option: 37/55.9: 54 51 58 59 1 3 6 15 28 >>>> DHCP option: 39/57.2: 576 >>>> DHCP requested ip: 192.168.165.254 >>>> BOOTP[eth1] op: REPLY >>>> htype: Ethernet >>>> hlen: 6 >>>> hops: 0 >>>> xid: 0x0 >>>> secs: 0 >>>> flags: 0x0 >>>> hw_addr: 00:00:24:c8:1d:6d >>>> client IP: 10.0.0.10 >>>> my IP: 10.0.0.10 >>>> server IP: 0.0.0.0 >>>> gateway IP: 0.0.0.0 >>>> options: >>>> subnet mask: 255.255.255.0 >>>> IP broadcast: 10.0.0.255 >>>> gateway: 0.0.0.0 >>>> DP83816 - ISR on eth0 >>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode >>>> DP83816 - can_send on eth0 : 16 >>>> DP83816 - send on eth0 >>>> DP83816 - can_send on eth0 : 15 >>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode >>>> DP83816 - can_send on eth0 : 15 >>>> DP83816 - send on eth0 >>>> DP83816 - can_send on eth0 : 14 >>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode >>>> DP83816 - can_send on eth1 : 16 >>>> DP83816 - send on eth1 >>>> DP83816 - can_send on eth1 : 15 >>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode >>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode >>>> DP83816 - can_send on eth1 : 15 >>>> DP83816 - send on eth1 >>>> DP83816 - can_send on eth1 : 14 >>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode >>>> Network initalized ! >>>> Eth0 is up ! >>>> Eth1 is up ! >>>> socket() = 3 >>>> It seem that everthing is OK. start sending packets. >>>> A - 0> sendto() = 3 >>>> B - 0> Waiting for a packet >>>> DP83816 - deliver on eth0 >>>> DP83816 - pool on eth0 >>>> DP83816 - Tx Event on eth0 >>>> DP83816 - ISR on eth0 >>>> DP83816 - deliver on eth0 >>>> DP83816 - pool on eth0 >>>> DP83816 - ISR on eth0 >>>> A - 1> sendto() = 3 >>>> DP83816 - deliver on eth0 >>>> DP83816 - pool on eth0 >>>> DP83816 - ISR on eth0 >>>> DP83816 - deliver on eth0 >>>> DP83816 - pool on eth0 >>>> DP83816 - ISR on eth0 >>>> DP83816 - deliver on eth0 >>>> DP83816 - pool on eth0 >>>> DP83816 - ISR on eth0 >>>> A - 2> sendto() = 3 >>>> DP83816 - deliver on eth0 >>>> DP83816 - pool on eth0 >>>> DP83816 - ISR on eth0 >>>> DP83816 - deliver on eth0 >>>> DP83816 - pool on eth0 >>>> DP83816 - ISR on eth0 >>>> >>>> >>>> >>>> >>>> 2008/1/10, Gary Thomas <gary@mlbassoc.com>: >>>>> Please keep your replies on the eCos list! >>>>> >>>>> **EVERYONE** please get this straight. Replies made by me on the >>>>> eCos discussion list must be followed up on the eCos discussion list >>>>> unless I invite private replies. This way everyone benefits, not >>>>> just the interested party. Private email support consultation and >>>>> support is available, but only with a contract. >>>>> >>>>> Antoine Zen-Ruffinen wrote: >>>>>> The target platform is an embed PC with NS dp83816 NIC. I've port the >>>>>> eCos driver my self for the PC platform. >>>>>> >>>>>> I configure eCos with the configtool, just using the template I made >>>>>> and the "net" package. >>>>>> >>>>>> No, I didn't run a standard eCos network test program. But I build an >>>>>> redboot with this configuration. If I type ping -n 1000 -r 1 -h >>>>>> 192.168.165.18 (is my host PC) everything went fine ! >>>>> This is only partly relevant - RedBoot uses a completely different >>>>> network stack than normal eCos applications. Also, RedBoot does >>>>> not use interrupts, which the eCos stacks rely on. >>>>> >>>>>> I know that nothing was send : 1 becose network activity led doesn't >>>>>> blink, 2 I monitor network with Wireshark (Ethereal). the monitoring >>>>>> trace show the TFTP exchange and the DHCP init but nothing more. It >>>>>> look like this : >>>>>> No. Time Source Destination Protocol Info >>>>>> 69504 25.515675 192.168.165.18 192.168.165.253 TFTP >>>>>> Data Packet, Block: 452 >>>>>> 69505 25.516279 192.168.165.253 192.168.165.18 TFTP >>>>>> Acknowledgement, Block: 452 >>>>>> 69506 25.516289 192.168.165.18 192.168.165.253 TFTP >>>>>> Data Packet, Block: 453 >>>>>> 69507 25.516662 192.168.165.253 192.168.165.18 TFTP >>>>>> Error Code, Code: Not defined, Message: redboot >>>>>> tftp_stream_terminate >>>>>> 69508 25.826093 0.0.0.0 255.255.255.255 DHCP >>>>>> DHCP Discover - Transaction ID 0x6c1dfce9 >>>>>> 69511 26.074789 0.0.0.0 255.255.255.255 DHCP >>>>>> DHCP Discover - Transaction ID 0x6c1dfce9 >>>>>> 69512 26.304739 0.0.0.0 255.255.255.255 DHCP >>>>>> DHCP Discover - Transaction ID 0x6c1dfce9 >>>>>> 69514 26.451407 0.0.0.0 255.255.255.255 DHCP >>>>>> DHCP Request - Transaction ID 0x6c1dfde9 >>>>>> 69516 26.839890 Olicom_c8:1d:6c Broadcast ARP >>>>>> Who has 192.168.165.254? Gratuitous ARP >>>>>> >>>>> Did your eCos application print anything about the DHCP transaction? >>>>> I'm betting that it did not (which would imply you are having trouble >>>>> with receive interrupts from your driver) >>>>> >>>>>> 2008/1/10, Gary Thomas <gary@mlbassoc.com>: >>>>>>> Antoine Zen-Ruffinen wrote: >>>>>>>> Hi List folks, >>>>>>>> >>>>>>>> I've a problem with the TCP/IP stack: >>>>>>>> - I use TFTP to load my program in redboot. That work fine. >>>>>>>> - My application start, call init_all_network_interfaces(), it do the >>>>>>>> DHCP stuff. That work fine. >>>>>>>> - Then I open a socket and try to send / receive data. No packet is even send. >>>>>>>> >>>>>>>> Does someone has already seen such problem ? >>>>>>>> Any idea ? >>>>>>> We'll need more data than this in order to help. >>>>>>> * What's the target platform? >>>>>>> * How did you configure eCos for your failing application? >>>>>>> * Have you run any of the standard eCos network test programs? >>>>>>> * How do you know nothing was sent? What sort of debugging >>>>>>> have you tried so far? >>>>> -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ECOS] Problem with TCP/IP stack 2008-01-11 12:47 ` Gary Thomas @ 2008-01-11 12:52 ` Andrew Lunn 2008-01-11 15:43 ` Antoine Zen-Ruffinen 1 sibling, 0 replies; 20+ messages in thread From: Andrew Lunn @ 2008-01-11 12:52 UTC (permalink / raw) To: Gary Thomas; +Cc: Antoine Zen-Ruffinen, eCos Discussion On Fri, Jan 11, 2008 at 05:46:46AM -0700, Gary Thomas wrote: > Antoine Zen-Ruffinen wrote: >> Ok, I found the problem but I dont' know how to solve it: My two NIC >> are sharing the same interrupt. So when the second NIC do an >> interrupt, it is handel like it is the first NIC that interrupt. >> >> Does someone know how to solve such an issue ? >> > > The key is to make your interrupt handler (ISR) tell the upper > layers which board did it. The intel i82559 driver can do this. Take a look at its interrupt handler code. Andrew -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ECOS] Problem with TCP/IP stack 2008-01-11 12:47 ` Gary Thomas 2008-01-11 12:52 ` Andrew Lunn @ 2008-01-11 15:43 ` Antoine Zen-Ruffinen 2008-01-11 15:59 ` Gary Thomas 1 sibling, 1 reply; 20+ messages in thread From: Antoine Zen-Ruffinen @ 2008-01-11 15:43 UTC (permalink / raw) To: Gary Thomas; +Cc: eCos Discussion Ok, I am trying to do that. But if the ISR of my fist interface return 0, the ISR of the second interface is not called. Does it nead to have 2 different ISR routine or the same with different parameter is enough ? 2008/1/11, Gary Thomas <gary@mlbassoc.com>: > Antoine Zen-Ruffinen wrote: > > Ok, I found the problem but I dont' know how to solve it: My two NIC > > are sharing the same interrupt. So when the second NIC do an > > interrupt, it is handel like it is the first NIC that interrupt. > > > > Does someone know how to solve such an issue ? > > > > The key is to make your interrupt handler (ISR) tell the upper > layers which board did it. This is reflected in the (struct eth_drv_sc *) > parameter that you pass upstream. Somehow, your driver will have > to keep track of these (there is one such structure per physical > device entity), then determine which board is responsible and > use that information to decide which device (i.e. structure) to use. > > If you're using the same interrupt for both devices, surely you > have Interrupt Chaining turned on in eCos? This allows for multiple > ISR/DSR pairs to be registered for the same interrupt. eCos will > call these ISR functions until one of them returns that it had > handled the interrupt. This could be used to easily handle your > situation. > > > 2008/1/11, Antoine Zen-Ruffinen <antoine.zen@gmail.com>: > >> Some new discover : If a use only one of the two NIC I have on my > >> system, everything work fine. When using two NIC, interrupts all the > >> time, even if no network activity, even if doing nothing and ARP > >> response are not catch by network stack. So the problem is a conflict > >> between both interfaces. Here is my driver declaration (for the i386 > >> platform), maybe something wrong there : > >> > >> #include <cyg/hal/hal_cache.h> > >> #include <cyg/io/pci.h> > >> > >> > >> static cyg_bool > >> find_dp83816_match_func(cyg_uint16 v, cyg_uint16 d, cyg_uint32 c, void *p) > >> { > >> return ((v == 0x100B) && (d == 0x0020)); > >> } > >> > >> cyg_pci_device_id devid = CYG_PCI_NULL_DEVID; > >> static void > >> _i386_pc_eth_init(dp83816_priv_data_t *dp) > >> { > >> > >> cyg_pci_device dev_info; > >> > >> > >> if (cyg_pci_find_matching( &find_dp83816_match_func, NULL, &devid )) { > >> cyg_pci_get_device_info(devid, &dev_info); > >> cyg_pci_translate_interrupt(&dev_info, &dp->interrupt); > >> dp->base = (cyg_uint8 *)(dev_info.base_map[0] & ~1); > >> diag_printf("DP83816 at %p, interrupt: %x\n", dp->base, dp->interrupt); > >> } > >> } > >> > >> #undef CYGHWR_NS_DP83816_PLF_INIT > >> #define CYGHWR_NS_DP83816_PLF_INIT(dp) _i386_pc_eth_init(dp) > >> > >> // Align buffers on a cache boundary > >> #define RxBUFSIZE (CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM * _DP83816_BUFSIZE) > >> #define TxBUFSIZE (CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM * _DP83816_BUFSIZE) > >> static unsigned char dp83816_eth0_rxbufs[RxBUFSIZE] > >> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > >> static unsigned char dp83816_eth0_txbufs[TxBUFSIZE] > >> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > >> static dp83816_bd_t > >> dp83816_eth0_rxbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM] > >> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > >> static dp83816_bd_t > >> dp83816_eth0_txbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM] > >> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > >> > >> static unsigned char dp83816_eth1_rxbufs[RxBUFSIZE] > >> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > >> static unsigned char dp83816_eth1_txbufs[TxBUFSIZE] > >> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > >> static dp83816_bd_t > >> dp83816_eth1_rxbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM] > >> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > >> static dp83816_bd_t > >> dp83816_eth1_txbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM] > >> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > >> > >> > >> // eth0 delacration > >> char _i386_pc_eth0_ESA[6]; > >> static dp83816_priv_data_t dp83816_eth0_priv_data = { > >> "eth0_esa", > >> _i386_pc_eth0_ESA, > >> CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM, // Number of Rx buffers > >> dp83816_eth0_rxbufs, // Rx buffer space > >> dp83816_eth0_rxbd, // Rx buffer headers > >> CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM, // Number of Tx buffers > >> dp83816_eth0_txbufs, // Tx buffer space > >> dp83816_eth0_txbd, // Tx buffer headers > >> }; > >> > >> ETH_DRV_SC(dp83816_sc0, > >> &dp83816_eth0_priv_data, // Driver specific data > >> "eth0", > >> dp83816_start, > >> dp83816_stop, > >> dp83816_control, > >> dp83816_can_send, > >> dp83816_send, > >> dp83816_recv, > >> dp83816_deliver, // "pseudoDSR" called from fast net thread > >> dp83816_poll, // poll function, encapsulates ISR and DSR > >> dp83816_int_vector); > >> > >> NETDEVTAB_ENTRY(dp83816_netdev0, > >> "eth0", > >> dp83816_init, > >> &dp83816_sc0); > >> > >> // eth1 delacration > >> char _i386_pc_eth1_ESA[6]; > >> static dp83816_priv_data_t dp83816_eth1_priv_data = { > >> "eth1_esa", > >> _i386_pc_eth1_ESA, > >> CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM, // Number of Rx buffers > >> dp83816_eth1_rxbufs, // Rx buffer space > >> dp83816_eth1_rxbd, // Rx buffer headers > >> CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM, // Number of Tx buffers > >> dp83816_eth1_txbufs, // Tx buffer space > >> dp83816_eth1_txbd, // Tx buffer headers > >> }; > >> > >> ETH_DRV_SC(dp83816_sc1, > >> &dp83816_eth1_priv_data, // Driver specific data > >> "eth1", > >> dp83816_start, > >> dp83816_stop, > >> dp83816_control, > >> dp83816_can_send, > >> dp83816_send, > >> dp83816_recv, > >> dp83816_deliver, // "pseudoDSR" called from fast net thread > >> dp83816_poll, // poll function, encapsulates ISR and DSR > >> dp83816_int_vector); > >> > >> NETDEVTAB_ENTRY(dp83816_netdev1, > >> "eth1", > >> dp83816_init, > >> &dp83816_sc1); > >> > >> > >> > >> 2008/1/10, Antoine Zen-Ruffinen <antoine.zen@gmail.com>: > >>> The previous post "[ECOS] Cannot sendto multicast using FreeBSD stack" > >>> put me on the way!! > >>> > >>> No IP packet are send, but ARP is done. But it seem that the stack > >>> doesn't get the ARP reply witch is on the wire. When calling send(), > >>> for the fist calls, send() return > 0, but with errno=2 (No such > >>> entry) then send() return -1 wiht erron=364 (Host is down). Can this > >>> be because I have 2 NIC that share the same interrupt ? > >>> > >>> 2008/1/10, Antoine Zen-Ruffinen <antoine.zen@gmail.com>: > >>>> Sorry for the preceding message that was not send to the list, little > >>>> mistake from me (cliqued "reply" and not "reply to all"). > >>>> > >>>> Yes my application print about DHCP transaction and it is ok. I have > >>>> added some prints in every driver function in order to trace what it > >>>> is doing. The output is interesting : > >>>> 1) The NIC is making interrupts all the time > >>>> 2) The network stack never call the send() function. > >>>> > >>>> Here is the output : > >>>> RedBoot> load -m tftp -h 192.168.165.18 debugProg > >>>> Entry point: 0x00200000, address range: 0x00200000-0x00238840 > >>>> RedBoot> go > >>>> [cyg_net_init] Init: mbinit(0x00000000) > >>>> [cyg_net_init] Init: cyg_net_init_devs(0x00000000) > >>>> Init device 'eth0' > >>>> DP83816 at 0x0000e100, interrupt: 2a > >>>> DP83816 - get ESA from EEPROM > >>>> DP83816 - ESA: 00:00:24:c8:1d:6c > >>>> Init device 'eth1' > >>>> DP83816 at 0x0000e200, interrupt: 2a > >>>> DP83816 - get ESA from EEPROM > >>>> DP83816 - ESA: 00:00:24:c8:1d:6d > >>>> [cyg_net_init] Init: loopattach(0x00000000) > >>>> [cyg_net_init] Init: ifinit(0x00000000) > >>>> [cyg_net_init] Init: domaininit(0x00000000) > >>>> [cyg_net_init] Init: cyg_net_add_domain(0x00238000) > >>>> New domain internet at 0x00000000 > >>>> [cyg_net_init] Init: cyg_net_add_domain(0x002378e0) > >>>> New domain route at 0x00000000 > >>>> [cyg_net_init] Init: call_route_init(0x00000000) > >>>> [cyg_net_init] Done > >>>> Network testing program V2 > >>>> Thread started > >>>> Init network : DP83816 - ISR on eth0 > >>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > >>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > >>>> DP83816 - can_send on eth0 : 16 > >>>> DP83816 - send on eth0 > >>>> DP83816 - can_send on eth0 : 15 > >>>> DP83816 - deliver on eth0 > >>>> DP83816 - pool on eth0 > >>>> DP83816 - Tx Event on eth0 > >>>> DP83816 - Rx event on eth0 > >>>> DP83816 - recv on eth0 > >>>> DP83816 - recv on eth0 > >>>> DP83816 - can_send on eth0 : 16 > >>>> DP83816 - send on eth0 > >>>> DDP83816 - ISR on eth0 > >>>> P83816 - can_send on eth0 : 15 > >>>> DP83816 - deliver on eth0 > >>>> DP83816 - pool on eth0 > >>>> DP83816 - Tx Event on eth0 > >>>> DP83816 - Rx event on eth0 > >>>> DP83816 - recv on eth0 > >>>> BOOTP[eth0] op: REQUEST > >>>> htype: Ethernet > >>>> hlen: 6 > >>>> hops: 0 > >>>> xid: 0xec511d6c > >>>> secs: 0 > >>>> flags: 0x80 > >>>> hw_addr: 00:00:24:c8:1d:6c > >>>> client IP: 0.0.0.0 > >>>> my IP: 192.168.165.254 > >>>> server IP: 192.168.165.1 > >>>> gateway IP: 0.0.0.0 > >>>> file: boots.default > >>>> options: > >>>> DHCP message: 3 REQUEST > >>>> DHCP server id: 192.168.165.1 > >>>> DHCP time 51: 43200 > >>>> DHCP time 58: 21600 > >>>> DHCP time 59: 37800 > >>>> subnet mask: 255.255.255.0 > >>>> gateway: 192.168.165.1 > >>>> domain server: 192.168.165.1 > >>>> domain name: v165.itslabb.bth.se. > >>>> DHCP option: 37/55.9: 54 51 58 59 1 3 6 15 28 > >>>> DHCP option: 39/57.2: 576 > >>>> DHCP requested ip: 192.168.165.254 > >>>> BOOTP[eth1] op: REPLY > >>>> htype: Ethernet > >>>> hlen: 6 > >>>> hops: 0 > >>>> xid: 0x0 > >>>> secs: 0 > >>>> flags: 0x0 > >>>> hw_addr: 00:00:24:c8:1d:6d > >>>> client IP: 10.0.0.10 > >>>> my IP: 10.0.0.10 > >>>> server IP: 0.0.0.0 > >>>> gateway IP: 0.0.0.0 > >>>> options: > >>>> subnet mask: 255.255.255.0 > >>>> IP broadcast: 10.0.0.255 > >>>> gateway: 0.0.0.0 > >>>> DP83816 - ISR on eth0 > >>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > >>>> DP83816 - can_send on eth0 : 16 > >>>> DP83816 - send on eth0 > >>>> DP83816 - can_send on eth0 : 15 > >>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > >>>> DP83816 - can_send on eth0 : 15 > >>>> DP83816 - send on eth0 > >>>> DP83816 - can_send on eth0 : 14 > >>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > >>>> DP83816 - can_send on eth1 : 16 > >>>> DP83816 - send on eth1 > >>>> DP83816 - can_send on eth1 : 15 > >>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > >>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > >>>> DP83816 - can_send on eth1 : 15 > >>>> DP83816 - send on eth1 > >>>> DP83816 - can_send on eth1 : 14 > >>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > >>>> Network initalized ! > >>>> Eth0 is up ! > >>>> Eth1 is up ! > >>>> socket() = 3 > >>>> It seem that everthing is OK. start sending packets. > >>>> A - 0> sendto() = 3 > >>>> B - 0> Waiting for a packet > >>>> DP83816 - deliver on eth0 > >>>> DP83816 - pool on eth0 > >>>> DP83816 - Tx Event on eth0 > >>>> DP83816 - ISR on eth0 > >>>> DP83816 - deliver on eth0 > >>>> DP83816 - pool on eth0 > >>>> DP83816 - ISR on eth0 > >>>> A - 1> sendto() = 3 > >>>> DP83816 - deliver on eth0 > >>>> DP83816 - pool on eth0 > >>>> DP83816 - ISR on eth0 > >>>> DP83816 - deliver on eth0 > >>>> DP83816 - pool on eth0 > >>>> DP83816 - ISR on eth0 > >>>> DP83816 - deliver on eth0 > >>>> DP83816 - pool on eth0 > >>>> DP83816 - ISR on eth0 > >>>> A - 2> sendto() = 3 > >>>> DP83816 - deliver on eth0 > >>>> DP83816 - pool on eth0 > >>>> DP83816 - ISR on eth0 > >>>> DP83816 - deliver on eth0 > >>>> DP83816 - pool on eth0 > >>>> DP83816 - ISR on eth0 > >>>> > >>>> > >>>> > >>>> > >>>> 2008/1/10, Gary Thomas <gary@mlbassoc.com>: > >>>>> Please keep your replies on the eCos list! > >>>>> > >>>>> **EVERYONE** please get this straight. Replies made by me on the > >>>>> eCos discussion list must be followed up on the eCos discussion list > >>>>> unless I invite private replies. This way everyone benefits, not > >>>>> just the interested party. Private email support consultation and > >>>>> support is available, but only with a contract. > >>>>> > >>>>> Antoine Zen-Ruffinen wrote: > >>>>>> The target platform is an embed PC with NS dp83816 NIC. I've port the > >>>>>> eCos driver my self for the PC platform. > >>>>>> > >>>>>> I configure eCos with the configtool, just using the template I made > >>>>>> and the "net" package. > >>>>>> > >>>>>> No, I didn't run a standard eCos network test program. But I build an > >>>>>> redboot with this configuration. If I type ping -n 1000 -r 1 -h > >>>>>> 192.168.165.18 (is my host PC) everything went fine ! > >>>>> This is only partly relevant - RedBoot uses a completely different > >>>>> network stack than normal eCos applications. Also, RedBoot does > >>>>> not use interrupts, which the eCos stacks rely on. > >>>>> > >>>>>> I know that nothing was send : 1 becose network activity led doesn't > >>>>>> blink, 2 I monitor network with Wireshark (Ethereal). the monitoring > >>>>>> trace show the TFTP exchange and the DHCP init but nothing more. It > >>>>>> look like this : > >>>>>> No. Time Source Destination Protocol Info > >>>>>> 69504 25.515675 192.168.165.18 192.168.165.253 TFTP > >>>>>> Data Packet, Block: 452 > >>>>>> 69505 25.516279 192.168.165.253 192.168.165.18 TFTP > >>>>>> Acknowledgement, Block: 452 > >>>>>> 69506 25.516289 192.168.165.18 192.168.165.253 TFTP > >>>>>> Data Packet, Block: 453 > >>>>>> 69507 25.516662 192.168.165.253 192.168.165.18 TFTP > >>>>>> Error Code, Code: Not defined, Message: redboot > >>>>>> tftp_stream_terminate > >>>>>> 69508 25.826093 0.0.0.0 255.255.255.255 DHCP > >>>>>> DHCP Discover - Transaction ID 0x6c1dfce9 > >>>>>> 69511 26.074789 0.0.0.0 255.255.255.255 DHCP > >>>>>> DHCP Discover - Transaction ID 0x6c1dfce9 > >>>>>> 69512 26.304739 0.0.0.0 255.255.255.255 DHCP > >>>>>> DHCP Discover - Transaction ID 0x6c1dfce9 > >>>>>> 69514 26.451407 0.0.0.0 255.255.255.255 DHCP > >>>>>> DHCP Request - Transaction ID 0x6c1dfde9 > >>>>>> 69516 26.839890 Olicom_c8:1d:6c Broadcast ARP > >>>>>> Who has 192.168.165.254? Gratuitous ARP > >>>>>> > >>>>> Did your eCos application print anything about the DHCP transaction? > >>>>> I'm betting that it did not (which would imply you are having trouble > >>>>> with receive interrupts from your driver) > >>>>> > >>>>>> 2008/1/10, Gary Thomas <gary@mlbassoc.com>: > >>>>>>> Antoine Zen-Ruffinen wrote: > >>>>>>>> Hi List folks, > >>>>>>>> > >>>>>>>> I've a problem with the TCP/IP stack: > >>>>>>>> - I use TFTP to load my program in redboot. That work fine. > >>>>>>>> - My application start, call init_all_network_interfaces(), it do the > >>>>>>>> DHCP stuff. That work fine. > >>>>>>>> - Then I open a socket and try to send / receive data. No packet is even send. > >>>>>>>> > >>>>>>>> Does someone has already seen such problem ? > >>>>>>>> Any idea ? > >>>>>>> We'll need more data than this in order to help. > >>>>>>> * What's the target platform? > >>>>>>> * How did you configure eCos for your failing application? > >>>>>>> * Have you run any of the standard eCos network test programs? > >>>>>>> * How do you know nothing was sent? What sort of debugging > >>>>>>> have you tried so far? > >>>>> > > -- > ------------------------------------------------------------ > Gary Thomas | Consulting for the > MLB Associates | Embedded world > ------------------------------------------------------------ > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ECOS] Problem with TCP/IP stack 2008-01-11 15:43 ` Antoine Zen-Ruffinen @ 2008-01-11 15:59 ` Gary Thomas 2008-01-11 16:08 ` Antoine Zen-Ruffinen 0 siblings, 1 reply; 20+ messages in thread From: Gary Thomas @ 2008-01-11 15:59 UTC (permalink / raw) To: Antoine Zen-Ruffinen; +Cc: eCos Discussion Antoine Zen-Ruffinen wrote: > Ok, I am trying to do that. But if the ISR of my fist interface return > 0, the ISR of the second interface is not called. Does it nead to have > 2 different ISR routine or the same with different parameter is enough > ? You can use the same ISR with different parameters. Do you have interrupt chaining enabled? Does your HAL properly support chained interrupts? (what's your target?) > 2008/1/11, Gary Thomas <gary@mlbassoc.com>: >> Antoine Zen-Ruffinen wrote: >>> Ok, I found the problem but I dont' know how to solve it: My two NIC >>> are sharing the same interrupt. So when the second NIC do an >>> interrupt, it is handel like it is the first NIC that interrupt. >>> >>> Does someone know how to solve such an issue ? >>> >> The key is to make your interrupt handler (ISR) tell the upper >> layers which board did it. This is reflected in the (struct eth_drv_sc *) >> parameter that you pass upstream. Somehow, your driver will have >> to keep track of these (there is one such structure per physical >> device entity), then determine which board is responsible and >> use that information to decide which device (i.e. structure) to use. >> >> If you're using the same interrupt for both devices, surely you >> have Interrupt Chaining turned on in eCos? This allows for multiple >> ISR/DSR pairs to be registered for the same interrupt. eCos will >> call these ISR functions until one of them returns that it had >> handled the interrupt. This could be used to easily handle your >> situation. >> >>> 2008/1/11, Antoine Zen-Ruffinen <antoine.zen@gmail.com>: >>>> Some new discover : If a use only one of the two NIC I have on my >>>> system, everything work fine. When using two NIC, interrupts all the >>>> time, even if no network activity, even if doing nothing and ARP >>>> response are not catch by network stack. So the problem is a conflict >>>> between both interfaces. Here is my driver declaration (for the i386 >>>> platform), maybe something wrong there : >>>> >>>> #include <cyg/hal/hal_cache.h> >>>> #include <cyg/io/pci.h> >>>> >>>> >>>> static cyg_bool >>>> find_dp83816_match_func(cyg_uint16 v, cyg_uint16 d, cyg_uint32 c, void *p) >>>> { >>>> return ((v == 0x100B) && (d == 0x0020)); >>>> } >>>> >>>> cyg_pci_device_id devid = CYG_PCI_NULL_DEVID; >>>> static void >>>> _i386_pc_eth_init(dp83816_priv_data_t *dp) >>>> { >>>> >>>> cyg_pci_device dev_info; >>>> >>>> >>>> if (cyg_pci_find_matching( &find_dp83816_match_func, NULL, &devid )) { >>>> cyg_pci_get_device_info(devid, &dev_info); >>>> cyg_pci_translate_interrupt(&dev_info, &dp->interrupt); >>>> dp->base = (cyg_uint8 *)(dev_info.base_map[0] & ~1); >>>> diag_printf("DP83816 at %p, interrupt: %x\n", dp->base, dp->interrupt); >>>> } >>>> } >>>> >>>> #undef CYGHWR_NS_DP83816_PLF_INIT >>>> #define CYGHWR_NS_DP83816_PLF_INIT(dp) _i386_pc_eth_init(dp) >>>> >>>> // Align buffers on a cache boundary >>>> #define RxBUFSIZE (CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM * _DP83816_BUFSIZE) >>>> #define TxBUFSIZE (CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM * _DP83816_BUFSIZE) >>>> static unsigned char dp83816_eth0_rxbufs[RxBUFSIZE] >>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); >>>> static unsigned char dp83816_eth0_txbufs[TxBUFSIZE] >>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); >>>> static dp83816_bd_t >>>> dp83816_eth0_rxbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM] >>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); >>>> static dp83816_bd_t >>>> dp83816_eth0_txbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM] >>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); >>>> >>>> static unsigned char dp83816_eth1_rxbufs[RxBUFSIZE] >>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); >>>> static unsigned char dp83816_eth1_txbufs[TxBUFSIZE] >>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); >>>> static dp83816_bd_t >>>> dp83816_eth1_rxbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM] >>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); >>>> static dp83816_bd_t >>>> dp83816_eth1_txbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM] >>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); >>>> >>>> >>>> // eth0 delacration >>>> char _i386_pc_eth0_ESA[6]; >>>> static dp83816_priv_data_t dp83816_eth0_priv_data = { >>>> "eth0_esa", >>>> _i386_pc_eth0_ESA, >>>> CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM, // Number of Rx buffers >>>> dp83816_eth0_rxbufs, // Rx buffer space >>>> dp83816_eth0_rxbd, // Rx buffer headers >>>> CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM, // Number of Tx buffers >>>> dp83816_eth0_txbufs, // Tx buffer space >>>> dp83816_eth0_txbd, // Tx buffer headers >>>> }; >>>> >>>> ETH_DRV_SC(dp83816_sc0, >>>> &dp83816_eth0_priv_data, // Driver specific data >>>> "eth0", >>>> dp83816_start, >>>> dp83816_stop, >>>> dp83816_control, >>>> dp83816_can_send, >>>> dp83816_send, >>>> dp83816_recv, >>>> dp83816_deliver, // "pseudoDSR" called from fast net thread >>>> dp83816_poll, // poll function, encapsulates ISR and DSR >>>> dp83816_int_vector); >>>> >>>> NETDEVTAB_ENTRY(dp83816_netdev0, >>>> "eth0", >>>> dp83816_init, >>>> &dp83816_sc0); >>>> >>>> // eth1 delacration >>>> char _i386_pc_eth1_ESA[6]; >>>> static dp83816_priv_data_t dp83816_eth1_priv_data = { >>>> "eth1_esa", >>>> _i386_pc_eth1_ESA, >>>> CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM, // Number of Rx buffers >>>> dp83816_eth1_rxbufs, // Rx buffer space >>>> dp83816_eth1_rxbd, // Rx buffer headers >>>> CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM, // Number of Tx buffers >>>> dp83816_eth1_txbufs, // Tx buffer space >>>> dp83816_eth1_txbd, // Tx buffer headers >>>> }; >>>> >>>> ETH_DRV_SC(dp83816_sc1, >>>> &dp83816_eth1_priv_data, // Driver specific data >>>> "eth1", >>>> dp83816_start, >>>> dp83816_stop, >>>> dp83816_control, >>>> dp83816_can_send, >>>> dp83816_send, >>>> dp83816_recv, >>>> dp83816_deliver, // "pseudoDSR" called from fast net thread >>>> dp83816_poll, // poll function, encapsulates ISR and DSR >>>> dp83816_int_vector); >>>> >>>> NETDEVTAB_ENTRY(dp83816_netdev1, >>>> "eth1", >>>> dp83816_init, >>>> &dp83816_sc1); >>>> >>>> >>>> >>>> 2008/1/10, Antoine Zen-Ruffinen <antoine.zen@gmail.com>: >>>>> The previous post "[ECOS] Cannot sendto multicast using FreeBSD stack" >>>>> put me on the way!! >>>>> >>>>> No IP packet are send, but ARP is done. But it seem that the stack >>>>> doesn't get the ARP reply witch is on the wire. When calling send(), >>>>> for the fist calls, send() return > 0, but with errno=2 (No such >>>>> entry) then send() return -1 wiht erron=364 (Host is down). Can this >>>>> be because I have 2 NIC that share the same interrupt ? >>>>> >>>>> 2008/1/10, Antoine Zen-Ruffinen <antoine.zen@gmail.com>: >>>>>> Sorry for the preceding message that was not send to the list, little >>>>>> mistake from me (cliqued "reply" and not "reply to all"). >>>>>> >>>>>> Yes my application print about DHCP transaction and it is ok. I have >>>>>> added some prints in every driver function in order to trace what it >>>>>> is doing. The output is interesting : >>>>>> 1) The NIC is making interrupts all the time >>>>>> 2) The network stack never call the send() function. >>>>>> >>>>>> Here is the output : >>>>>> RedBoot> load -m tftp -h 192.168.165.18 debugProg >>>>>> Entry point: 0x00200000, address range: 0x00200000-0x00238840 >>>>>> RedBoot> go >>>>>> [cyg_net_init] Init: mbinit(0x00000000) >>>>>> [cyg_net_init] Init: cyg_net_init_devs(0x00000000) >>>>>> Init device 'eth0' >>>>>> DP83816 at 0x0000e100, interrupt: 2a >>>>>> DP83816 - get ESA from EEPROM >>>>>> DP83816 - ESA: 00:00:24:c8:1d:6c >>>>>> Init device 'eth1' >>>>>> DP83816 at 0x0000e200, interrupt: 2a >>>>>> DP83816 - get ESA from EEPROM >>>>>> DP83816 - ESA: 00:00:24:c8:1d:6d >>>>>> [cyg_net_init] Init: loopattach(0x00000000) >>>>>> [cyg_net_init] Init: ifinit(0x00000000) >>>>>> [cyg_net_init] Init: domaininit(0x00000000) >>>>>> [cyg_net_init] Init: cyg_net_add_domain(0x00238000) >>>>>> New domain internet at 0x00000000 >>>>>> [cyg_net_init] Init: cyg_net_add_domain(0x002378e0) >>>>>> New domain route at 0x00000000 >>>>>> [cyg_net_init] Init: call_route_init(0x00000000) >>>>>> [cyg_net_init] Done >>>>>> Network testing program V2 >>>>>> Thread started >>>>>> Init network : DP83816 - ISR on eth0 >>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode >>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode >>>>>> DP83816 - can_send on eth0 : 16 >>>>>> DP83816 - send on eth0 >>>>>> DP83816 - can_send on eth0 : 15 >>>>>> DP83816 - deliver on eth0 >>>>>> DP83816 - pool on eth0 >>>>>> DP83816 - Tx Event on eth0 >>>>>> DP83816 - Rx event on eth0 >>>>>> DP83816 - recv on eth0 >>>>>> DP83816 - recv on eth0 >>>>>> DP83816 - can_send on eth0 : 16 >>>>>> DP83816 - send on eth0 >>>>>> DDP83816 - ISR on eth0 >>>>>> P83816 - can_send on eth0 : 15 >>>>>> DP83816 - deliver on eth0 >>>>>> DP83816 - pool on eth0 >>>>>> DP83816 - Tx Event on eth0 >>>>>> DP83816 - Rx event on eth0 >>>>>> DP83816 - recv on eth0 >>>>>> BOOTP[eth0] op: REQUEST >>>>>> htype: Ethernet >>>>>> hlen: 6 >>>>>> hops: 0 >>>>>> xid: 0xec511d6c >>>>>> secs: 0 >>>>>> flags: 0x80 >>>>>> hw_addr: 00:00:24:c8:1d:6c >>>>>> client IP: 0.0.0.0 >>>>>> my IP: 192.168.165.254 >>>>>> server IP: 192.168.165.1 >>>>>> gateway IP: 0.0.0.0 >>>>>> file: boots.default >>>>>> options: >>>>>> DHCP message: 3 REQUEST >>>>>> DHCP server id: 192.168.165.1 >>>>>> DHCP time 51: 43200 >>>>>> DHCP time 58: 21600 >>>>>> DHCP time 59: 37800 >>>>>> subnet mask: 255.255.255.0 >>>>>> gateway: 192.168.165.1 >>>>>> domain server: 192.168.165.1 >>>>>> domain name: v165.itslabb.bth.se. >>>>>> DHCP option: 37/55.9: 54 51 58 59 1 3 6 15 28 >>>>>> DHCP option: 39/57.2: 576 >>>>>> DHCP requested ip: 192.168.165.254 >>>>>> BOOTP[eth1] op: REPLY >>>>>> htype: Ethernet >>>>>> hlen: 6 >>>>>> hops: 0 >>>>>> xid: 0x0 >>>>>> secs: 0 >>>>>> flags: 0x0 >>>>>> hw_addr: 00:00:24:c8:1d:6d >>>>>> client IP: 10.0.0.10 >>>>>> my IP: 10.0.0.10 >>>>>> server IP: 0.0.0.0 >>>>>> gateway IP: 0.0.0.0 >>>>>> options: >>>>>> subnet mask: 255.255.255.0 >>>>>> IP broadcast: 10.0.0.255 >>>>>> gateway: 0.0.0.0 >>>>>> DP83816 - ISR on eth0 >>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode >>>>>> DP83816 - can_send on eth0 : 16 >>>>>> DP83816 - send on eth0 >>>>>> DP83816 - can_send on eth0 : 15 >>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode >>>>>> DP83816 - can_send on eth0 : 15 >>>>>> DP83816 - send on eth0 >>>>>> DP83816 - can_send on eth0 : 14 >>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode >>>>>> DP83816 - can_send on eth1 : 16 >>>>>> DP83816 - send on eth1 >>>>>> DP83816 - can_send on eth1 : 15 >>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode >>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode >>>>>> DP83816 - can_send on eth1 : 15 >>>>>> DP83816 - send on eth1 >>>>>> DP83816 - can_send on eth1 : 14 >>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode >>>>>> Network initalized ! >>>>>> Eth0 is up ! >>>>>> Eth1 is up ! >>>>>> socket() = 3 >>>>>> It seem that everthing is OK. start sending packets. >>>>>> A - 0> sendto() = 3 >>>>>> B - 0> Waiting for a packet >>>>>> DP83816 - deliver on eth0 >>>>>> DP83816 - pool on eth0 >>>>>> DP83816 - Tx Event on eth0 >>>>>> DP83816 - ISR on eth0 >>>>>> DP83816 - deliver on eth0 >>>>>> DP83816 - pool on eth0 >>>>>> DP83816 - ISR on eth0 >>>>>> A - 1> sendto() = 3 >>>>>> DP83816 - deliver on eth0 >>>>>> DP83816 - pool on eth0 >>>>>> DP83816 - ISR on eth0 >>>>>> DP83816 - deliver on eth0 >>>>>> DP83816 - pool on eth0 >>>>>> DP83816 - ISR on eth0 >>>>>> DP83816 - deliver on eth0 >>>>>> DP83816 - pool on eth0 >>>>>> DP83816 - ISR on eth0 >>>>>> A - 2> sendto() = 3 >>>>>> DP83816 - deliver on eth0 >>>>>> DP83816 - pool on eth0 >>>>>> DP83816 - ISR on eth0 >>>>>> DP83816 - deliver on eth0 >>>>>> DP83816 - pool on eth0 >>>>>> DP83816 - ISR on eth0 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 2008/1/10, Gary Thomas <gary@mlbassoc.com>: >>>>>>> Please keep your replies on the eCos list! >>>>>>> >>>>>>> **EVERYONE** please get this straight. Replies made by me on the >>>>>>> eCos discussion list must be followed up on the eCos discussion list >>>>>>> unless I invite private replies. This way everyone benefits, not >>>>>>> just the interested party. Private email support consultation and >>>>>>> support is available, but only with a contract. >>>>>>> >>>>>>> Antoine Zen-Ruffinen wrote: >>>>>>>> The target platform is an embed PC with NS dp83816 NIC. I've port the >>>>>>>> eCos driver my self for the PC platform. >>>>>>>> >>>>>>>> I configure eCos with the configtool, just using the template I made >>>>>>>> and the "net" package. >>>>>>>> >>>>>>>> No, I didn't run a standard eCos network test program. But I build an >>>>>>>> redboot with this configuration. If I type ping -n 1000 -r 1 -h >>>>>>>> 192.168.165.18 (is my host PC) everything went fine ! >>>>>>> This is only partly relevant - RedBoot uses a completely different >>>>>>> network stack than normal eCos applications. Also, RedBoot does >>>>>>> not use interrupts, which the eCos stacks rely on. >>>>>>> >>>>>>>> I know that nothing was send : 1 becose network activity led doesn't >>>>>>>> blink, 2 I monitor network with Wireshark (Ethereal). the monitoring >>>>>>>> trace show the TFTP exchange and the DHCP init but nothing more. It >>>>>>>> look like this : >>>>>>>> No. Time Source Destination Protocol Info >>>>>>>> 69504 25.515675 192.168.165.18 192.168.165.253 TFTP >>>>>>>> Data Packet, Block: 452 >>>>>>>> 69505 25.516279 192.168.165.253 192.168.165.18 TFTP >>>>>>>> Acknowledgement, Block: 452 >>>>>>>> 69506 25.516289 192.168.165.18 192.168.165.253 TFTP >>>>>>>> Data Packet, Block: 453 >>>>>>>> 69507 25.516662 192.168.165.253 192.168.165.18 TFTP >>>>>>>> Error Code, Code: Not defined, Message: redboot >>>>>>>> tftp_stream_terminate >>>>>>>> 69508 25.826093 0.0.0.0 255.255.255.255 DHCP >>>>>>>> DHCP Discover - Transaction ID 0x6c1dfce9 >>>>>>>> 69511 26.074789 0.0.0.0 255.255.255.255 DHCP >>>>>>>> DHCP Discover - Transaction ID 0x6c1dfce9 >>>>>>>> 69512 26.304739 0.0.0.0 255.255.255.255 DHCP >>>>>>>> DHCP Discover - Transaction ID 0x6c1dfce9 >>>>>>>> 69514 26.451407 0.0.0.0 255.255.255.255 DHCP >>>>>>>> DHCP Request - Transaction ID 0x6c1dfde9 >>>>>>>> 69516 26.839890 Olicom_c8:1d:6c Broadcast ARP >>>>>>>> Who has 192.168.165.254? Gratuitous ARP >>>>>>>> >>>>>>> Did your eCos application print anything about the DHCP transaction? >>>>>>> I'm betting that it did not (which would imply you are having trouble >>>>>>> with receive interrupts from your driver) >>>>>>> >>>>>>>> 2008/1/10, Gary Thomas <gary@mlbassoc.com>: >>>>>>>>> Antoine Zen-Ruffinen wrote: >>>>>>>>>> Hi List folks, >>>>>>>>>> >>>>>>>>>> I've a problem with the TCP/IP stack: >>>>>>>>>> - I use TFTP to load my program in redboot. That work fine. >>>>>>>>>> - My application start, call init_all_network_interfaces(), it do the >>>>>>>>>> DHCP stuff. That work fine. >>>>>>>>>> - Then I open a socket and try to send / receive data. No packet is even send. >>>>>>>>>> >>>>>>>>>> Does someone has already seen such problem ? >>>>>>>>>> Any idea ? >>>>>>>>> We'll need more data than this in order to help. >>>>>>>>> * What's the target platform? >>>>>>>>> * How did you configure eCos for your failing application? >>>>>>>>> * Have you run any of the standard eCos network test programs? >>>>>>>>> * How do you know nothing was sent? What sort of debugging >>>>>>>>> have you tried so far? -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ECOS] Problem with TCP/IP stack 2008-01-11 15:59 ` Gary Thomas @ 2008-01-11 16:08 ` Antoine Zen-Ruffinen 2008-01-11 16:29 ` Gary Thomas 0 siblings, 1 reply; 20+ messages in thread From: Antoine Zen-Ruffinen @ 2008-01-11 16:08 UTC (permalink / raw) To: Gary Thomas; +Cc: eCos Discussion Yes i have CYGIMP_HAL_INTERRUPTS_CHAIN = true in configtool. Does I need something else ? My target is i386-PC. 2008/1/11, Gary Thomas <gary@mlbassoc.com>: > Antoine Zen-Ruffinen wrote: > > Ok, I am trying to do that. But if the ISR of my fist interface return > > 0, the ISR of the second interface is not called. Does it nead to have > > 2 different ISR routine or the same with different parameter is enough > > ? > > You can use the same ISR with different parameters. > > Do you have interrupt chaining enabled? > Does your HAL properly support chained interrupts? (what's your target?) > > > 2008/1/11, Gary Thomas <gary@mlbassoc.com>: > >> Antoine Zen-Ruffinen wrote: > >>> Ok, I found the problem but I dont' know how to solve it: My two NIC > >>> are sharing the same interrupt. So when the second NIC do an > >>> interrupt, it is handel like it is the first NIC that interrupt. > >>> > >>> Does someone know how to solve such an issue ? > >>> > >> The key is to make your interrupt handler (ISR) tell the upper > >> layers which board did it. This is reflected in the (struct eth_drv_sc *) > >> parameter that you pass upstream. Somehow, your driver will have > >> to keep track of these (there is one such structure per physical > >> device entity), then determine which board is responsible and > >> use that information to decide which device (i.e. structure) to use. > >> > >> If you're using the same interrupt for both devices, surely you > >> have Interrupt Chaining turned on in eCos? This allows for multiple > >> ISR/DSR pairs to be registered for the same interrupt. eCos will > >> call these ISR functions until one of them returns that it had > >> handled the interrupt. This could be used to easily handle your > >> situation. > >> > >>> 2008/1/11, Antoine Zen-Ruffinen <antoine.zen@gmail.com>: > >>>> Some new discover : If a use only one of the two NIC I have on my > >>>> system, everything work fine. When using two NIC, interrupts all the > >>>> time, even if no network activity, even if doing nothing and ARP > >>>> response are not catch by network stack. So the problem is a conflict > >>>> between both interfaces. Here is my driver declaration (for the i386 > >>>> platform), maybe something wrong there : > >>>> > >>>> #include <cyg/hal/hal_cache.h> > >>>> #include <cyg/io/pci.h> > >>>> > >>>> > >>>> static cyg_bool > >>>> find_dp83816_match_func(cyg_uint16 v, cyg_uint16 d, cyg_uint32 c, void *p) > >>>> { > >>>> return ((v == 0x100B) && (d == 0x0020)); > >>>> } > >>>> > >>>> cyg_pci_device_id devid = CYG_PCI_NULL_DEVID; > >>>> static void > >>>> _i386_pc_eth_init(dp83816_priv_data_t *dp) > >>>> { > >>>> > >>>> cyg_pci_device dev_info; > >>>> > >>>> > >>>> if (cyg_pci_find_matching( &find_dp83816_match_func, NULL, &devid )) { > >>>> cyg_pci_get_device_info(devid, &dev_info); > >>>> cyg_pci_translate_interrupt(&dev_info, &dp->interrupt); > >>>> dp->base = (cyg_uint8 *)(dev_info.base_map[0] & ~1); > >>>> diag_printf("DP83816 at %p, interrupt: %x\n", dp->base, dp->interrupt); > >>>> } > >>>> } > >>>> > >>>> #undef CYGHWR_NS_DP83816_PLF_INIT > >>>> #define CYGHWR_NS_DP83816_PLF_INIT(dp) _i386_pc_eth_init(dp) > >>>> > >>>> // Align buffers on a cache boundary > >>>> #define RxBUFSIZE (CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM * _DP83816_BUFSIZE) > >>>> #define TxBUFSIZE (CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM * _DP83816_BUFSIZE) > >>>> static unsigned char dp83816_eth0_rxbufs[RxBUFSIZE] > >>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > >>>> static unsigned char dp83816_eth0_txbufs[TxBUFSIZE] > >>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > >>>> static dp83816_bd_t > >>>> dp83816_eth0_rxbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM] > >>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > >>>> static dp83816_bd_t > >>>> dp83816_eth0_txbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM] > >>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > >>>> > >>>> static unsigned char dp83816_eth1_rxbufs[RxBUFSIZE] > >>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > >>>> static unsigned char dp83816_eth1_txbufs[TxBUFSIZE] > >>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > >>>> static dp83816_bd_t > >>>> dp83816_eth1_rxbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM] > >>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > >>>> static dp83816_bd_t > >>>> dp83816_eth1_txbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM] > >>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > >>>> > >>>> > >>>> // eth0 delacration > >>>> char _i386_pc_eth0_ESA[6]; > >>>> static dp83816_priv_data_t dp83816_eth0_priv_data = { > >>>> "eth0_esa", > >>>> _i386_pc_eth0_ESA, > >>>> CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM, // Number of Rx buffers > >>>> dp83816_eth0_rxbufs, // Rx buffer space > >>>> dp83816_eth0_rxbd, // Rx buffer headers > >>>> CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM, // Number of Tx buffers > >>>> dp83816_eth0_txbufs, // Tx buffer space > >>>> dp83816_eth0_txbd, // Tx buffer headers > >>>> }; > >>>> > >>>> ETH_DRV_SC(dp83816_sc0, > >>>> &dp83816_eth0_priv_data, // Driver specific data > >>>> "eth0", > >>>> dp83816_start, > >>>> dp83816_stop, > >>>> dp83816_control, > >>>> dp83816_can_send, > >>>> dp83816_send, > >>>> dp83816_recv, > >>>> dp83816_deliver, // "pseudoDSR" called from fast net thread > >>>> dp83816_poll, // poll function, encapsulates ISR and DSR > >>>> dp83816_int_vector); > >>>> > >>>> NETDEVTAB_ENTRY(dp83816_netdev0, > >>>> "eth0", > >>>> dp83816_init, > >>>> &dp83816_sc0); > >>>> > >>>> // eth1 delacration > >>>> char _i386_pc_eth1_ESA[6]; > >>>> static dp83816_priv_data_t dp83816_eth1_priv_data = { > >>>> "eth1_esa", > >>>> _i386_pc_eth1_ESA, > >>>> CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM, // Number of Rx buffers > >>>> dp83816_eth1_rxbufs, // Rx buffer space > >>>> dp83816_eth1_rxbd, // Rx buffer headers > >>>> CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM, // Number of Tx buffers > >>>> dp83816_eth1_txbufs, // Tx buffer space > >>>> dp83816_eth1_txbd, // Tx buffer headers > >>>> }; > >>>> > >>>> ETH_DRV_SC(dp83816_sc1, > >>>> &dp83816_eth1_priv_data, // Driver specific data > >>>> "eth1", > >>>> dp83816_start, > >>>> dp83816_stop, > >>>> dp83816_control, > >>>> dp83816_can_send, > >>>> dp83816_send, > >>>> dp83816_recv, > >>>> dp83816_deliver, // "pseudoDSR" called from fast net thread > >>>> dp83816_poll, // poll function, encapsulates ISR and DSR > >>>> dp83816_int_vector); > >>>> > >>>> NETDEVTAB_ENTRY(dp83816_netdev1, > >>>> "eth1", > >>>> dp83816_init, > >>>> &dp83816_sc1); > >>>> > >>>> > >>>> > >>>> 2008/1/10, Antoine Zen-Ruffinen <antoine.zen@gmail.com>: > >>>>> The previous post "[ECOS] Cannot sendto multicast using FreeBSD stack" > >>>>> put me on the way!! > >>>>> > >>>>> No IP packet are send, but ARP is done. But it seem that the stack > >>>>> doesn't get the ARP reply witch is on the wire. When calling send(), > >>>>> for the fist calls, send() return > 0, but with errno=2 (No such > >>>>> entry) then send() return -1 wiht erron=364 (Host is down). Can this > >>>>> be because I have 2 NIC that share the same interrupt ? > >>>>> > >>>>> 2008/1/10, Antoine Zen-Ruffinen <antoine.zen@gmail.com>: > >>>>>> Sorry for the preceding message that was not send to the list, little > >>>>>> mistake from me (cliqued "reply" and not "reply to all"). > >>>>>> > >>>>>> Yes my application print about DHCP transaction and it is ok. I have > >>>>>> added some prints in every driver function in order to trace what it > >>>>>> is doing. The output is interesting : > >>>>>> 1) The NIC is making interrupts all the time > >>>>>> 2) The network stack never call the send() function. > >>>>>> > >>>>>> Here is the output : > >>>>>> RedBoot> load -m tftp -h 192.168.165.18 debugProg > >>>>>> Entry point: 0x00200000, address range: 0x00200000-0x00238840 > >>>>>> RedBoot> go > >>>>>> [cyg_net_init] Init: mbinit(0x00000000) > >>>>>> [cyg_net_init] Init: cyg_net_init_devs(0x00000000) > >>>>>> Init device 'eth0' > >>>>>> DP83816 at 0x0000e100, interrupt: 2a > >>>>>> DP83816 - get ESA from EEPROM > >>>>>> DP83816 - ESA: 00:00:24:c8:1d:6c > >>>>>> Init device 'eth1' > >>>>>> DP83816 at 0x0000e200, interrupt: 2a > >>>>>> DP83816 - get ESA from EEPROM > >>>>>> DP83816 - ESA: 00:00:24:c8:1d:6d > >>>>>> [cyg_net_init] Init: loopattach(0x00000000) > >>>>>> [cyg_net_init] Init: ifinit(0x00000000) > >>>>>> [cyg_net_init] Init: domaininit(0x00000000) > >>>>>> [cyg_net_init] Init: cyg_net_add_domain(0x00238000) > >>>>>> New domain internet at 0x00000000 > >>>>>> [cyg_net_init] Init: cyg_net_add_domain(0x002378e0) > >>>>>> New domain route at 0x00000000 > >>>>>> [cyg_net_init] Init: call_route_init(0x00000000) > >>>>>> [cyg_net_init] Done > >>>>>> Network testing program V2 > >>>>>> Thread started > >>>>>> Init network : DP83816 - ISR on eth0 > >>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > >>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > >>>>>> DP83816 - can_send on eth0 : 16 > >>>>>> DP83816 - send on eth0 > >>>>>> DP83816 - can_send on eth0 : 15 > >>>>>> DP83816 - deliver on eth0 > >>>>>> DP83816 - pool on eth0 > >>>>>> DP83816 - Tx Event on eth0 > >>>>>> DP83816 - Rx event on eth0 > >>>>>> DP83816 - recv on eth0 > >>>>>> DP83816 - recv on eth0 > >>>>>> DP83816 - can_send on eth0 : 16 > >>>>>> DP83816 - send on eth0 > >>>>>> DDP83816 - ISR on eth0 > >>>>>> P83816 - can_send on eth0 : 15 > >>>>>> DP83816 - deliver on eth0 > >>>>>> DP83816 - pool on eth0 > >>>>>> DP83816 - Tx Event on eth0 > >>>>>> DP83816 - Rx event on eth0 > >>>>>> DP83816 - recv on eth0 > >>>>>> BOOTP[eth0] op: REQUEST > >>>>>> htype: Ethernet > >>>>>> hlen: 6 > >>>>>> hops: 0 > >>>>>> xid: 0xec511d6c > >>>>>> secs: 0 > >>>>>> flags: 0x80 > >>>>>> hw_addr: 00:00:24:c8:1d:6c > >>>>>> client IP: 0.0.0.0 > >>>>>> my IP: 192.168.165.254 > >>>>>> server IP: 192.168.165.1 > >>>>>> gateway IP: 0.0.0.0 > >>>>>> file: boots.default > >>>>>> options: > >>>>>> DHCP message: 3 REQUEST > >>>>>> DHCP server id: 192.168.165.1 > >>>>>> DHCP time 51: 43200 > >>>>>> DHCP time 58: 21600 > >>>>>> DHCP time 59: 37800 > >>>>>> subnet mask: 255.255.255.0 > >>>>>> gateway: 192.168.165.1 > >>>>>> domain server: 192.168.165.1 > >>>>>> domain name: v165.itslabb.bth.se. > >>>>>> DHCP option: 37/55.9: 54 51 58 59 1 3 6 15 28 > >>>>>> DHCP option: 39/57.2: 576 > >>>>>> DHCP requested ip: 192.168.165.254 > >>>>>> BOOTP[eth1] op: REPLY > >>>>>> htype: Ethernet > >>>>>> hlen: 6 > >>>>>> hops: 0 > >>>>>> xid: 0x0 > >>>>>> secs: 0 > >>>>>> flags: 0x0 > >>>>>> hw_addr: 00:00:24:c8:1d:6d > >>>>>> client IP: 10.0.0.10 > >>>>>> my IP: 10.0.0.10 > >>>>>> server IP: 0.0.0.0 > >>>>>> gateway IP: 0.0.0.0 > >>>>>> options: > >>>>>> subnet mask: 255.255.255.0 > >>>>>> IP broadcast: 10.0.0.255 > >>>>>> gateway: 0.0.0.0 > >>>>>> DP83816 - ISR on eth0 > >>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > >>>>>> DP83816 - can_send on eth0 : 16 > >>>>>> DP83816 - send on eth0 > >>>>>> DP83816 - can_send on eth0 : 15 > >>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > >>>>>> DP83816 - can_send on eth0 : 15 > >>>>>> DP83816 - send on eth0 > >>>>>> DP83816 - can_send on eth0 : 14 > >>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > >>>>>> DP83816 - can_send on eth1 : 16 > >>>>>> DP83816 - send on eth1 > >>>>>> DP83816 - can_send on eth1 : 15 > >>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > >>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > >>>>>> DP83816 - can_send on eth1 : 15 > >>>>>> DP83816 - send on eth1 > >>>>>> DP83816 - can_send on eth1 : 14 > >>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > >>>>>> Network initalized ! > >>>>>> Eth0 is up ! > >>>>>> Eth1 is up ! > >>>>>> socket() = 3 > >>>>>> It seem that everthing is OK. start sending packets. > >>>>>> A - 0> sendto() = 3 > >>>>>> B - 0> Waiting for a packet > >>>>>> DP83816 - deliver on eth0 > >>>>>> DP83816 - pool on eth0 > >>>>>> DP83816 - Tx Event on eth0 > >>>>>> DP83816 - ISR on eth0 > >>>>>> DP83816 - deliver on eth0 > >>>>>> DP83816 - pool on eth0 > >>>>>> DP83816 - ISR on eth0 > >>>>>> A - 1> sendto() = 3 > >>>>>> DP83816 - deliver on eth0 > >>>>>> DP83816 - pool on eth0 > >>>>>> DP83816 - ISR on eth0 > >>>>>> DP83816 - deliver on eth0 > >>>>>> DP83816 - pool on eth0 > >>>>>> DP83816 - ISR on eth0 > >>>>>> DP83816 - deliver on eth0 > >>>>>> DP83816 - pool on eth0 > >>>>>> DP83816 - ISR on eth0 > >>>>>> A - 2> sendto() = 3 > >>>>>> DP83816 - deliver on eth0 > >>>>>> DP83816 - pool on eth0 > >>>>>> DP83816 - ISR on eth0 > >>>>>> DP83816 - deliver on eth0 > >>>>>> DP83816 - pool on eth0 > >>>>>> DP83816 - ISR on eth0 > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> 2008/1/10, Gary Thomas <gary@mlbassoc.com>: > >>>>>>> Please keep your replies on the eCos list! > >>>>>>> > >>>>>>> **EVERYONE** please get this straight. Replies made by me on the > >>>>>>> eCos discussion list must be followed up on the eCos discussion list > >>>>>>> unless I invite private replies. This way everyone benefits, not > >>>>>>> just the interested party. Private email support consultation and > >>>>>>> support is available, but only with a contract. > >>>>>>> > >>>>>>> Antoine Zen-Ruffinen wrote: > >>>>>>>> The target platform is an embed PC with NS dp83816 NIC. I've port the > >>>>>>>> eCos driver my self for the PC platform. > >>>>>>>> > >>>>>>>> I configure eCos with the configtool, just using the template I made > >>>>>>>> and the "net" package. > >>>>>>>> > >>>>>>>> No, I didn't run a standard eCos network test program. But I build an > >>>>>>>> redboot with this configuration. If I type ping -n 1000 -r 1 -h > >>>>>>>> 192.168.165.18 (is my host PC) everything went fine ! > >>>>>>> This is only partly relevant - RedBoot uses a completely different > >>>>>>> network stack than normal eCos applications. Also, RedBoot does > >>>>>>> not use interrupts, which the eCos stacks rely on. > >>>>>>> > >>>>>>>> I know that nothing was send : 1 becose network activity led doesn't > >>>>>>>> blink, 2 I monitor network with Wireshark (Ethereal). the monitoring > >>>>>>>> trace show the TFTP exchange and the DHCP init but nothing more. It > >>>>>>>> look like this : > >>>>>>>> No. Time Source Destination Protocol Info > >>>>>>>> 69504 25.515675 192.168.165.18 192.168.165.253 TFTP > >>>>>>>> Data Packet, Block: 452 > >>>>>>>> 69505 25.516279 192.168.165.253 192.168.165.18 TFTP > >>>>>>>> Acknowledgement, Block: 452 > >>>>>>>> 69506 25.516289 192.168.165.18 192.168.165.253 TFTP > >>>>>>>> Data Packet, Block: 453 > >>>>>>>> 69507 25.516662 192.168.165.253 192.168.165.18 TFTP > >>>>>>>> Error Code, Code: Not defined, Message: redboot > >>>>>>>> tftp_stream_terminate > >>>>>>>> 69508 25.826093 0.0.0.0 255.255.255.255 DHCP > >>>>>>>> DHCP Discover - Transaction ID 0x6c1dfce9 > >>>>>>>> 69511 26.074789 0.0.0.0 255.255.255.255 DHCP > >>>>>>>> DHCP Discover - Transaction ID 0x6c1dfce9 > >>>>>>>> 69512 26.304739 0.0.0.0 255.255.255.255 DHCP > >>>>>>>> DHCP Discover - Transaction ID 0x6c1dfce9 > >>>>>>>> 69514 26.451407 0.0.0.0 255.255.255.255 DHCP > >>>>>>>> DHCP Request - Transaction ID 0x6c1dfde9 > >>>>>>>> 69516 26.839890 Olicom_c8:1d:6c Broadcast ARP > >>>>>>>> Who has 192.168.165.254? Gratuitous ARP > >>>>>>>> > >>>>>>> Did your eCos application print anything about the DHCP transaction? > >>>>>>> I'm betting that it did not (which would imply you are having trouble > >>>>>>> with receive interrupts from your driver) > >>>>>>> > >>>>>>>> 2008/1/10, Gary Thomas <gary@mlbassoc.com>: > >>>>>>>>> Antoine Zen-Ruffinen wrote: > >>>>>>>>>> Hi List folks, > >>>>>>>>>> > >>>>>>>>>> I've a problem with the TCP/IP stack: > >>>>>>>>>> - I use TFTP to load my program in redboot. That work fine. > >>>>>>>>>> - My application start, call init_all_network_interfaces(), it do the > >>>>>>>>>> DHCP stuff. That work fine. > >>>>>>>>>> - Then I open a socket and try to send / receive data. No packet is even send. > >>>>>>>>>> > >>>>>>>>>> Does someone has already seen such problem ? > >>>>>>>>>> Any idea ? > >>>>>>>>> We'll need more data than this in order to help. > >>>>>>>>> * What's the target platform? > >>>>>>>>> * How did you configure eCos for your failing application? > >>>>>>>>> * Have you run any of the standard eCos network test programs? > >>>>>>>>> * How do you know nothing was sent? What sort of debugging > >>>>>>>>> have you tried so far? > > -- > ------------------------------------------------------------ > Gary Thomas | Consulting for the > MLB Associates | Embedded world > ------------------------------------------------------------ > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ECOS] Problem with TCP/IP stack 2008-01-11 16:08 ` Antoine Zen-Ruffinen @ 2008-01-11 16:29 ` Gary Thomas 2008-01-11 16:38 ` Antoine Zen-Ruffinen 0 siblings, 1 reply; 20+ messages in thread From: Gary Thomas @ 2008-01-11 16:29 UTC (permalink / raw) To: Antoine Zen-Ruffinen; +Cc: eCos Discussion Antoine Zen-Ruffinen wrote: > Yes i have CYGIMP_HAL_INTERRUPTS_CHAIN = true in configtool. Does I > need something else ? My target is i386-PC. That just says that your HAL knows *how* to managed chained interrupts. You also need CYGIMP_KERNEL_INTERRUPTS_CHAIN, so the kernel will support chained interrupts for ISRs. > 2008/1/11, Gary Thomas <gary@mlbassoc.com>: >> Antoine Zen-Ruffinen wrote: >>> Ok, I am trying to do that. But if the ISR of my fist interface return >>> 0, the ISR of the second interface is not called. Does it nead to have >>> 2 different ISR routine or the same with different parameter is enough >>> ? >> You can use the same ISR with different parameters. >> >> Do you have interrupt chaining enabled? >> Does your HAL properly support chained interrupts? (what's your target?) >> >>> 2008/1/11, Gary Thomas <gary@mlbassoc.com>: >>>> Antoine Zen-Ruffinen wrote: >>>>> Ok, I found the problem but I dont' know how to solve it: My two NIC >>>>> are sharing the same interrupt. So when the second NIC do an >>>>> interrupt, it is handel like it is the first NIC that interrupt. >>>>> >>>>> Does someone know how to solve such an issue ? >>>>> >>>> The key is to make your interrupt handler (ISR) tell the upper >>>> layers which board did it. This is reflected in the (struct eth_drv_sc *) >>>> parameter that you pass upstream. Somehow, your driver will have >>>> to keep track of these (there is one such structure per physical >>>> device entity), then determine which board is responsible and >>>> use that information to decide which device (i.e. structure) to use. >>>> >>>> If you're using the same interrupt for both devices, surely you >>>> have Interrupt Chaining turned on in eCos? This allows for multiple >>>> ISR/DSR pairs to be registered for the same interrupt. eCos will >>>> call these ISR functions until one of them returns that it had >>>> handled the interrupt. This could be used to easily handle your >>>> situation. >>>> >>>>> 2008/1/11, Antoine Zen-Ruffinen <antoine.zen@gmail.com>: >>>>>> Some new discover : If a use only one of the two NIC I have on my >>>>>> system, everything work fine. When using two NIC, interrupts all the >>>>>> time, even if no network activity, even if doing nothing and ARP >>>>>> response are not catch by network stack. So the problem is a conflict >>>>>> between both interfaces. Here is my driver declaration (for the i386 >>>>>> platform), maybe something wrong there : >>>>>> >>>>>> #include <cyg/hal/hal_cache.h> >>>>>> #include <cyg/io/pci.h> >>>>>> >>>>>> >>>>>> static cyg_bool >>>>>> find_dp83816_match_func(cyg_uint16 v, cyg_uint16 d, cyg_uint32 c, void *p) >>>>>> { >>>>>> return ((v == 0x100B) && (d == 0x0020)); >>>>>> } >>>>>> >>>>>> cyg_pci_device_id devid = CYG_PCI_NULL_DEVID; >>>>>> static void >>>>>> _i386_pc_eth_init(dp83816_priv_data_t *dp) >>>>>> { >>>>>> >>>>>> cyg_pci_device dev_info; >>>>>> >>>>>> >>>>>> if (cyg_pci_find_matching( &find_dp83816_match_func, NULL, &devid )) { >>>>>> cyg_pci_get_device_info(devid, &dev_info); >>>>>> cyg_pci_translate_interrupt(&dev_info, &dp->interrupt); >>>>>> dp->base = (cyg_uint8 *)(dev_info.base_map[0] & ~1); >>>>>> diag_printf("DP83816 at %p, interrupt: %x\n", dp->base, dp->interrupt); >>>>>> } >>>>>> } >>>>>> >>>>>> #undef CYGHWR_NS_DP83816_PLF_INIT >>>>>> #define CYGHWR_NS_DP83816_PLF_INIT(dp) _i386_pc_eth_init(dp) >>>>>> >>>>>> // Align buffers on a cache boundary >>>>>> #define RxBUFSIZE (CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM * _DP83816_BUFSIZE) >>>>>> #define TxBUFSIZE (CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM * _DP83816_BUFSIZE) >>>>>> static unsigned char dp83816_eth0_rxbufs[RxBUFSIZE] >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); >>>>>> static unsigned char dp83816_eth0_txbufs[TxBUFSIZE] >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); >>>>>> static dp83816_bd_t >>>>>> dp83816_eth0_rxbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM] >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); >>>>>> static dp83816_bd_t >>>>>> dp83816_eth0_txbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM] >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); >>>>>> >>>>>> static unsigned char dp83816_eth1_rxbufs[RxBUFSIZE] >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); >>>>>> static unsigned char dp83816_eth1_txbufs[TxBUFSIZE] >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); >>>>>> static dp83816_bd_t >>>>>> dp83816_eth1_rxbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM] >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); >>>>>> static dp83816_bd_t >>>>>> dp83816_eth1_txbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM] >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); >>>>>> >>>>>> >>>>>> // eth0 delacration >>>>>> char _i386_pc_eth0_ESA[6]; >>>>>> static dp83816_priv_data_t dp83816_eth0_priv_data = { >>>>>> "eth0_esa", >>>>>> _i386_pc_eth0_ESA, >>>>>> CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM, // Number of Rx buffers >>>>>> dp83816_eth0_rxbufs, // Rx buffer space >>>>>> dp83816_eth0_rxbd, // Rx buffer headers >>>>>> CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM, // Number of Tx buffers >>>>>> dp83816_eth0_txbufs, // Tx buffer space >>>>>> dp83816_eth0_txbd, // Tx buffer headers >>>>>> }; >>>>>> >>>>>> ETH_DRV_SC(dp83816_sc0, >>>>>> &dp83816_eth0_priv_data, // Driver specific data >>>>>> "eth0", >>>>>> dp83816_start, >>>>>> dp83816_stop, >>>>>> dp83816_control, >>>>>> dp83816_can_send, >>>>>> dp83816_send, >>>>>> dp83816_recv, >>>>>> dp83816_deliver, // "pseudoDSR" called from fast net thread >>>>>> dp83816_poll, // poll function, encapsulates ISR and DSR >>>>>> dp83816_int_vector); >>>>>> >>>>>> NETDEVTAB_ENTRY(dp83816_netdev0, >>>>>> "eth0", >>>>>> dp83816_init, >>>>>> &dp83816_sc0); >>>>>> >>>>>> // eth1 delacration >>>>>> char _i386_pc_eth1_ESA[6]; >>>>>> static dp83816_priv_data_t dp83816_eth1_priv_data = { >>>>>> "eth1_esa", >>>>>> _i386_pc_eth1_ESA, >>>>>> CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM, // Number of Rx buffers >>>>>> dp83816_eth1_rxbufs, // Rx buffer space >>>>>> dp83816_eth1_rxbd, // Rx buffer headers >>>>>> CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM, // Number of Tx buffers >>>>>> dp83816_eth1_txbufs, // Tx buffer space >>>>>> dp83816_eth1_txbd, // Tx buffer headers >>>>>> }; >>>>>> >>>>>> ETH_DRV_SC(dp83816_sc1, >>>>>> &dp83816_eth1_priv_data, // Driver specific data >>>>>> "eth1", >>>>>> dp83816_start, >>>>>> dp83816_stop, >>>>>> dp83816_control, >>>>>> dp83816_can_send, >>>>>> dp83816_send, >>>>>> dp83816_recv, >>>>>> dp83816_deliver, // "pseudoDSR" called from fast net thread >>>>>> dp83816_poll, // poll function, encapsulates ISR and DSR >>>>>> dp83816_int_vector); >>>>>> >>>>>> NETDEVTAB_ENTRY(dp83816_netdev1, >>>>>> "eth1", >>>>>> dp83816_init, >>>>>> &dp83816_sc1); >>>>>> >>>>>> >>>>>> >>>>>> 2008/1/10, Antoine Zen-Ruffinen <antoine.zen@gmail.com>: >>>>>>> The previous post "[ECOS] Cannot sendto multicast using FreeBSD stack" >>>>>>> put me on the way!! >>>>>>> >>>>>>> No IP packet are send, but ARP is done. But it seem that the stack >>>>>>> doesn't get the ARP reply witch is on the wire. When calling send(), >>>>>>> for the fist calls, send() return > 0, but with errno=2 (No such >>>>>>> entry) then send() return -1 wiht erron=364 (Host is down). Can this >>>>>>> be because I have 2 NIC that share the same interrupt ? >>>>>>> >>>>>>> 2008/1/10, Antoine Zen-Ruffinen <antoine.zen@gmail.com>: >>>>>>>> Sorry for the preceding message that was not send to the list, little >>>>>>>> mistake from me (cliqued "reply" and not "reply to all"). >>>>>>>> >>>>>>>> Yes my application print about DHCP transaction and it is ok. I have >>>>>>>> added some prints in every driver function in order to trace what it >>>>>>>> is doing. The output is interesting : >>>>>>>> 1) The NIC is making interrupts all the time >>>>>>>> 2) The network stack never call the send() function. >>>>>>>> >>>>>>>> Here is the output : >>>>>>>> RedBoot> load -m tftp -h 192.168.165.18 debugProg >>>>>>>> Entry point: 0x00200000, address range: 0x00200000-0x00238840 >>>>>>>> RedBoot> go >>>>>>>> [cyg_net_init] Init: mbinit(0x00000000) >>>>>>>> [cyg_net_init] Init: cyg_net_init_devs(0x00000000) >>>>>>>> Init device 'eth0' >>>>>>>> DP83816 at 0x0000e100, interrupt: 2a >>>>>>>> DP83816 - get ESA from EEPROM >>>>>>>> DP83816 - ESA: 00:00:24:c8:1d:6c >>>>>>>> Init device 'eth1' >>>>>>>> DP83816 at 0x0000e200, interrupt: 2a >>>>>>>> DP83816 - get ESA from EEPROM >>>>>>>> DP83816 - ESA: 00:00:24:c8:1d:6d >>>>>>>> [cyg_net_init] Init: loopattach(0x00000000) >>>>>>>> [cyg_net_init] Init: ifinit(0x00000000) >>>>>>>> [cyg_net_init] Init: domaininit(0x00000000) >>>>>>>> [cyg_net_init] Init: cyg_net_add_domain(0x00238000) >>>>>>>> New domain internet at 0x00000000 >>>>>>>> [cyg_net_init] Init: cyg_net_add_domain(0x002378e0) >>>>>>>> New domain route at 0x00000000 >>>>>>>> [cyg_net_init] Init: call_route_init(0x00000000) >>>>>>>> [cyg_net_init] Done >>>>>>>> Network testing program V2 >>>>>>>> Thread started >>>>>>>> Init network : DP83816 - ISR on eth0 >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode >>>>>>>> DP83816 - can_send on eth0 : 16 >>>>>>>> DP83816 - send on eth0 >>>>>>>> DP83816 - can_send on eth0 : 15 >>>>>>>> DP83816 - deliver on eth0 >>>>>>>> DP83816 - pool on eth0 >>>>>>>> DP83816 - Tx Event on eth0 >>>>>>>> DP83816 - Rx event on eth0 >>>>>>>> DP83816 - recv on eth0 >>>>>>>> DP83816 - recv on eth0 >>>>>>>> DP83816 - can_send on eth0 : 16 >>>>>>>> DP83816 - send on eth0 >>>>>>>> DDP83816 - ISR on eth0 >>>>>>>> P83816 - can_send on eth0 : 15 >>>>>>>> DP83816 - deliver on eth0 >>>>>>>> DP83816 - pool on eth0 >>>>>>>> DP83816 - Tx Event on eth0 >>>>>>>> DP83816 - Rx event on eth0 >>>>>>>> DP83816 - recv on eth0 >>>>>>>> BOOTP[eth0] op: REQUEST >>>>>>>> htype: Ethernet >>>>>>>> hlen: 6 >>>>>>>> hops: 0 >>>>>>>> xid: 0xec511d6c >>>>>>>> secs: 0 >>>>>>>> flags: 0x80 >>>>>>>> hw_addr: 00:00:24:c8:1d:6c >>>>>>>> client IP: 0.0.0.0 >>>>>>>> my IP: 192.168.165.254 >>>>>>>> server IP: 192.168.165.1 >>>>>>>> gateway IP: 0.0.0.0 >>>>>>>> file: boots.default >>>>>>>> options: >>>>>>>> DHCP message: 3 REQUEST >>>>>>>> DHCP server id: 192.168.165.1 >>>>>>>> DHCP time 51: 43200 >>>>>>>> DHCP time 58: 21600 >>>>>>>> DHCP time 59: 37800 >>>>>>>> subnet mask: 255.255.255.0 >>>>>>>> gateway: 192.168.165.1 >>>>>>>> domain server: 192.168.165.1 >>>>>>>> domain name: v165.itslabb.bth.se. >>>>>>>> DHCP option: 37/55.9: 54 51 58 59 1 3 6 15 28 >>>>>>>> DHCP option: 39/57.2: 576 >>>>>>>> DHCP requested ip: 192.168.165.254 >>>>>>>> BOOTP[eth1] op: REPLY >>>>>>>> htype: Ethernet >>>>>>>> hlen: 6 >>>>>>>> hops: 0 >>>>>>>> xid: 0x0 >>>>>>>> secs: 0 >>>>>>>> flags: 0x0 >>>>>>>> hw_addr: 00:00:24:c8:1d:6d >>>>>>>> client IP: 10.0.0.10 >>>>>>>> my IP: 10.0.0.10 >>>>>>>> server IP: 0.0.0.0 >>>>>>>> gateway IP: 0.0.0.0 >>>>>>>> options: >>>>>>>> subnet mask: 255.255.255.0 >>>>>>>> IP broadcast: 10.0.0.255 >>>>>>>> gateway: 0.0.0.0 >>>>>>>> DP83816 - ISR on eth0 >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode >>>>>>>> DP83816 - can_send on eth0 : 16 >>>>>>>> DP83816 - send on eth0 >>>>>>>> DP83816 - can_send on eth0 : 15 >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode >>>>>>>> DP83816 - can_send on eth0 : 15 >>>>>>>> DP83816 - send on eth0 >>>>>>>> DP83816 - can_send on eth0 : 14 >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode >>>>>>>> DP83816 - can_send on eth1 : 16 >>>>>>>> DP83816 - send on eth1 >>>>>>>> DP83816 - can_send on eth1 : 15 >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode >>>>>>>> DP83816 - can_send on eth1 : 15 >>>>>>>> DP83816 - send on eth1 >>>>>>>> DP83816 - can_send on eth1 : 14 >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode >>>>>>>> Network initalized ! >>>>>>>> Eth0 is up ! >>>>>>>> Eth1 is up ! >>>>>>>> socket() = 3 >>>>>>>> It seem that everthing is OK. start sending packets. >>>>>>>> A - 0> sendto() = 3 >>>>>>>> B - 0> Waiting for a packet >>>>>>>> DP83816 - deliver on eth0 >>>>>>>> DP83816 - pool on eth0 >>>>>>>> DP83816 - Tx Event on eth0 >>>>>>>> DP83816 - ISR on eth0 >>>>>>>> DP83816 - deliver on eth0 >>>>>>>> DP83816 - pool on eth0 >>>>>>>> DP83816 - ISR on eth0 >>>>>>>> A - 1> sendto() = 3 >>>>>>>> DP83816 - deliver on eth0 >>>>>>>> DP83816 - pool on eth0 >>>>>>>> DP83816 - ISR on eth0 >>>>>>>> DP83816 - deliver on eth0 >>>>>>>> DP83816 - pool on eth0 >>>>>>>> DP83816 - ISR on eth0 >>>>>>>> DP83816 - deliver on eth0 >>>>>>>> DP83816 - pool on eth0 >>>>>>>> DP83816 - ISR on eth0 >>>>>>>> A - 2> sendto() = 3 >>>>>>>> DP83816 - deliver on eth0 >>>>>>>> DP83816 - pool on eth0 >>>>>>>> DP83816 - ISR on eth0 >>>>>>>> DP83816 - deliver on eth0 >>>>>>>> DP83816 - pool on eth0 >>>>>>>> DP83816 - ISR on eth0 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2008/1/10, Gary Thomas <gary@mlbassoc.com>: >>>>>>>>> Please keep your replies on the eCos list! >>>>>>>>> >>>>>>>>> **EVERYONE** please get this straight. Replies made by me on the >>>>>>>>> eCos discussion list must be followed up on the eCos discussion list >>>>>>>>> unless I invite private replies. This way everyone benefits, not >>>>>>>>> just the interested party. Private email support consultation and >>>>>>>>> support is available, but only with a contract. >>>>>>>>> >>>>>>>>> Antoine Zen-Ruffinen wrote: >>>>>>>>>> The target platform is an embed PC with NS dp83816 NIC. I've port the >>>>>>>>>> eCos driver my self for the PC platform. >>>>>>>>>> >>>>>>>>>> I configure eCos with the configtool, just using the template I made >>>>>>>>>> and the "net" package. >>>>>>>>>> >>>>>>>>>> No, I didn't run a standard eCos network test program. But I build an >>>>>>>>>> redboot with this configuration. If I type ping -n 1000 -r 1 -h >>>>>>>>>> 192.168.165.18 (is my host PC) everything went fine ! >>>>>>>>> This is only partly relevant - RedBoot uses a completely different >>>>>>>>> network stack than normal eCos applications. Also, RedBoot does >>>>>>>>> not use interrupts, which the eCos stacks rely on. >>>>>>>>> >>>>>>>>>> I know that nothing was send : 1 becose network activity led doesn't >>>>>>>>>> blink, 2 I monitor network with Wireshark (Ethereal). the monitoring >>>>>>>>>> trace show the TFTP exchange and the DHCP init but nothing more. It >>>>>>>>>> look like this : >>>>>>>>>> No. Time Source Destination Protocol Info >>>>>>>>>> 69504 25.515675 192.168.165.18 192.168.165.253 TFTP >>>>>>>>>> Data Packet, Block: 452 >>>>>>>>>> 69505 25.516279 192.168.165.253 192.168.165.18 TFTP >>>>>>>>>> Acknowledgement, Block: 452 >>>>>>>>>> 69506 25.516289 192.168.165.18 192.168.165.253 TFTP >>>>>>>>>> Data Packet, Block: 453 >>>>>>>>>> 69507 25.516662 192.168.165.253 192.168.165.18 TFTP >>>>>>>>>> Error Code, Code: Not defined, Message: redboot >>>>>>>>>> tftp_stream_terminate >>>>>>>>>> 69508 25.826093 0.0.0.0 255.255.255.255 DHCP >>>>>>>>>> DHCP Discover - Transaction ID 0x6c1dfce9 >>>>>>>>>> 69511 26.074789 0.0.0.0 255.255.255.255 DHCP >>>>>>>>>> DHCP Discover - Transaction ID 0x6c1dfce9 >>>>>>>>>> 69512 26.304739 0.0.0.0 255.255.255.255 DHCP >>>>>>>>>> DHCP Discover - Transaction ID 0x6c1dfce9 >>>>>>>>>> 69514 26.451407 0.0.0.0 255.255.255.255 DHCP >>>>>>>>>> DHCP Request - Transaction ID 0x6c1dfde9 >>>>>>>>>> 69516 26.839890 Olicom_c8:1d:6c Broadcast ARP >>>>>>>>>> Who has 192.168.165.254? Gratuitous ARP >>>>>>>>>> >>>>>>>>> Did your eCos application print anything about the DHCP transaction? >>>>>>>>> I'm betting that it did not (which would imply you are having trouble >>>>>>>>> with receive interrupts from your driver) >>>>>>>>> >>>>>>>>>> 2008/1/10, Gary Thomas <gary@mlbassoc.com>: >>>>>>>>>>> Antoine Zen-Ruffinen wrote: >>>>>>>>>>>> Hi List folks, >>>>>>>>>>>> >>>>>>>>>>>> I've a problem with the TCP/IP stack: >>>>>>>>>>>> - I use TFTP to load my program in redboot. That work fine. >>>>>>>>>>>> - My application start, call init_all_network_interfaces(), it do the >>>>>>>>>>>> DHCP stuff. That work fine. >>>>>>>>>>>> - Then I open a socket and try to send / receive data. No packet is even send. >>>>>>>>>>>> >>>>>>>>>>>> Does someone has already seen such problem ? >>>>>>>>>>>> Any idea ? >>>>>>>>>>> We'll need more data than this in order to help. >>>>>>>>>>> * What's the target platform? >>>>>>>>>>> * How did you configure eCos for your failing application? >>>>>>>>>>> * Have you run any of the standard eCos network test programs? >>>>>>>>>>> * How do you know nothing was sent? What sort of debugging >>>>>>>>>>> have you tried so far? >> -- >> ------------------------------------------------------------ >> Gary Thomas | Consulting for the >> MLB Associates | Embedded world >> ------------------------------------------------------------ >> > -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ECOS] Problem with TCP/IP stack 2008-01-11 16:29 ` Gary Thomas @ 2008-01-11 16:38 ` Antoine Zen-Ruffinen 2008-01-11 16:39 ` Antoine Zen-Ruffinen 0 siblings, 1 reply; 20+ messages in thread From: Antoine Zen-Ruffinen @ 2008-01-11 16:38 UTC (permalink / raw) To: Gary Thomas; +Cc: eCos Discussion IT WORK NOW!!!!! 2008/1/11, Gary Thomas <gary@mlbassoc.com>: > Antoine Zen-Ruffinen wrote: > > Yes i have CYGIMP_HAL_INTERRUPTS_CHAIN = true in configtool. Does I > > need something else ? My target is i386-PC. > > That just says that your HAL knows *how* to managed chained interrupts. > > You also need CYGIMP_KERNEL_INTERRUPTS_CHAIN, so the kernel will > support chained interrupts for ISRs. > > > 2008/1/11, Gary Thomas <gary@mlbassoc.com>: > >> Antoine Zen-Ruffinen wrote: > >>> Ok, I am trying to do that. But if the ISR of my fist interface return > >>> 0, the ISR of the second interface is not called. Does it nead to have > >>> 2 different ISR routine or the same with different parameter is enough > >>> ? > >> You can use the same ISR with different parameters. > >> > >> Do you have interrupt chaining enabled? > >> Does your HAL properly support chained interrupts? (what's your target?) > >> > >>> 2008/1/11, Gary Thomas <gary@mlbassoc.com>: > >>>> Antoine Zen-Ruffinen wrote: > >>>>> Ok, I found the problem but I dont' know how to solve it: My two NIC > >>>>> are sharing the same interrupt. So when the second NIC do an > >>>>> interrupt, it is handel like it is the first NIC that interrupt. > >>>>> > >>>>> Does someone know how to solve such an issue ? > >>>>> > >>>> The key is to make your interrupt handler (ISR) tell the upper > >>>> layers which board did it. This is reflected in the (struct eth_drv_sc *) > >>>> parameter that you pass upstream. Somehow, your driver will have > >>>> to keep track of these (there is one such structure per physical > >>>> device entity), then determine which board is responsible and > >>>> use that information to decide which device (i.e. structure) to use. > >>>> > >>>> If you're using the same interrupt for both devices, surely you > >>>> have Interrupt Chaining turned on in eCos? This allows for multiple > >>>> ISR/DSR pairs to be registered for the same interrupt. eCos will > >>>> call these ISR functions until one of them returns that it had > >>>> handled the interrupt. This could be used to easily handle your > >>>> situation. > >>>> > >>>>> 2008/1/11, Antoine Zen-Ruffinen <antoine.zen@gmail.com>: > >>>>>> Some new discover : If a use only one of the two NIC I have on my > >>>>>> system, everything work fine. When using two NIC, interrupts all the > >>>>>> time, even if no network activity, even if doing nothing and ARP > >>>>>> response are not catch by network stack. So the problem is a conflict > >>>>>> between both interfaces. Here is my driver declaration (for the i386 > >>>>>> platform), maybe something wrong there : > >>>>>> > >>>>>> #include <cyg/hal/hal_cache.h> > >>>>>> #include <cyg/io/pci.h> > >>>>>> > >>>>>> > >>>>>> static cyg_bool > >>>>>> find_dp83816_match_func(cyg_uint16 v, cyg_uint16 d, cyg_uint32 c, void *p) > >>>>>> { > >>>>>> return ((v == 0x100B) && (d == 0x0020)); > >>>>>> } > >>>>>> > >>>>>> cyg_pci_device_id devid = CYG_PCI_NULL_DEVID; > >>>>>> static void > >>>>>> _i386_pc_eth_init(dp83816_priv_data_t *dp) > >>>>>> { > >>>>>> > >>>>>> cyg_pci_device dev_info; > >>>>>> > >>>>>> > >>>>>> if (cyg_pci_find_matching( &find_dp83816_match_func, NULL, &devid )) { > >>>>>> cyg_pci_get_device_info(devid, &dev_info); > >>>>>> cyg_pci_translate_interrupt(&dev_info, &dp->interrupt); > >>>>>> dp->base = (cyg_uint8 *)(dev_info.base_map[0] & ~1); > >>>>>> diag_printf("DP83816 at %p, interrupt: %x\n", dp->base, dp->interrupt); > >>>>>> } > >>>>>> } > >>>>>> > >>>>>> #undef CYGHWR_NS_DP83816_PLF_INIT > >>>>>> #define CYGHWR_NS_DP83816_PLF_INIT(dp) _i386_pc_eth_init(dp) > >>>>>> > >>>>>> // Align buffers on a cache boundary > >>>>>> #define RxBUFSIZE (CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM * _DP83816_BUFSIZE) > >>>>>> #define TxBUFSIZE (CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM * _DP83816_BUFSIZE) > >>>>>> static unsigned char dp83816_eth0_rxbufs[RxBUFSIZE] > >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > >>>>>> static unsigned char dp83816_eth0_txbufs[TxBUFSIZE] > >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > >>>>>> static dp83816_bd_t > >>>>>> dp83816_eth0_rxbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM] > >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > >>>>>> static dp83816_bd_t > >>>>>> dp83816_eth0_txbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM] > >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > >>>>>> > >>>>>> static unsigned char dp83816_eth1_rxbufs[RxBUFSIZE] > >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > >>>>>> static unsigned char dp83816_eth1_txbufs[TxBUFSIZE] > >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > >>>>>> static dp83816_bd_t > >>>>>> dp83816_eth1_rxbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM] > >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > >>>>>> static dp83816_bd_t > >>>>>> dp83816_eth1_txbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM] > >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > >>>>>> > >>>>>> > >>>>>> // eth0 delacration > >>>>>> char _i386_pc_eth0_ESA[6]; > >>>>>> static dp83816_priv_data_t dp83816_eth0_priv_data = { > >>>>>> "eth0_esa", > >>>>>> _i386_pc_eth0_ESA, > >>>>>> CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM, // Number of Rx buffers > >>>>>> dp83816_eth0_rxbufs, // Rx buffer space > >>>>>> dp83816_eth0_rxbd, // Rx buffer headers > >>>>>> CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM, // Number of Tx buffers > >>>>>> dp83816_eth0_txbufs, // Tx buffer space > >>>>>> dp83816_eth0_txbd, // Tx buffer headers > >>>>>> }; > >>>>>> > >>>>>> ETH_DRV_SC(dp83816_sc0, > >>>>>> &dp83816_eth0_priv_data, // Driver specific data > >>>>>> "eth0", > >>>>>> dp83816_start, > >>>>>> dp83816_stop, > >>>>>> dp83816_control, > >>>>>> dp83816_can_send, > >>>>>> dp83816_send, > >>>>>> dp83816_recv, > >>>>>> dp83816_deliver, // "pseudoDSR" called from fast net thread > >>>>>> dp83816_poll, // poll function, encapsulates ISR and DSR > >>>>>> dp83816_int_vector); > >>>>>> > >>>>>> NETDEVTAB_ENTRY(dp83816_netdev0, > >>>>>> "eth0", > >>>>>> dp83816_init, > >>>>>> &dp83816_sc0); > >>>>>> > >>>>>> // eth1 delacration > >>>>>> char _i386_pc_eth1_ESA[6]; > >>>>>> static dp83816_priv_data_t dp83816_eth1_priv_data = { > >>>>>> "eth1_esa", > >>>>>> _i386_pc_eth1_ESA, > >>>>>> CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM, // Number of Rx buffers > >>>>>> dp83816_eth1_rxbufs, // Rx buffer space > >>>>>> dp83816_eth1_rxbd, // Rx buffer headers > >>>>>> CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM, // Number of Tx buffers > >>>>>> dp83816_eth1_txbufs, // Tx buffer space > >>>>>> dp83816_eth1_txbd, // Tx buffer headers > >>>>>> }; > >>>>>> > >>>>>> ETH_DRV_SC(dp83816_sc1, > >>>>>> &dp83816_eth1_priv_data, // Driver specific data > >>>>>> "eth1", > >>>>>> dp83816_start, > >>>>>> dp83816_stop, > >>>>>> dp83816_control, > >>>>>> dp83816_can_send, > >>>>>> dp83816_send, > >>>>>> dp83816_recv, > >>>>>> dp83816_deliver, // "pseudoDSR" called from fast net thread > >>>>>> dp83816_poll, // poll function, encapsulates ISR and DSR > >>>>>> dp83816_int_vector); > >>>>>> > >>>>>> NETDEVTAB_ENTRY(dp83816_netdev1, > >>>>>> "eth1", > >>>>>> dp83816_init, > >>>>>> &dp83816_sc1); > >>>>>> > >>>>>> > >>>>>> > >>>>>> 2008/1/10, Antoine Zen-Ruffinen <antoine.zen@gmail.com>: > >>>>>>> The previous post "[ECOS] Cannot sendto multicast using FreeBSD stack" > >>>>>>> put me on the way!! > >>>>>>> > >>>>>>> No IP packet are send, but ARP is done. But it seem that the stack > >>>>>>> doesn't get the ARP reply witch is on the wire. When calling send(), > >>>>>>> for the fist calls, send() return > 0, but with errno=2 (No such > >>>>>>> entry) then send() return -1 wiht erron=364 (Host is down). Can this > >>>>>>> be because I have 2 NIC that share the same interrupt ? > >>>>>>> > >>>>>>> 2008/1/10, Antoine Zen-Ruffinen <antoine.zen@gmail.com>: > >>>>>>>> Sorry for the preceding message that was not send to the list, little > >>>>>>>> mistake from me (cliqued "reply" and not "reply to all"). > >>>>>>>> > >>>>>>>> Yes my application print about DHCP transaction and it is ok. I have > >>>>>>>> added some prints in every driver function in order to trace what it > >>>>>>>> is doing. The output is interesting : > >>>>>>>> 1) The NIC is making interrupts all the time > >>>>>>>> 2) The network stack never call the send() function. > >>>>>>>> > >>>>>>>> Here is the output : > >>>>>>>> RedBoot> load -m tftp -h 192.168.165.18 debugProg > >>>>>>>> Entry point: 0x00200000, address range: 0x00200000-0x00238840 > >>>>>>>> RedBoot> go > >>>>>>>> [cyg_net_init] Init: mbinit(0x00000000) > >>>>>>>> [cyg_net_init] Init: cyg_net_init_devs(0x00000000) > >>>>>>>> Init device 'eth0' > >>>>>>>> DP83816 at 0x0000e100, interrupt: 2a > >>>>>>>> DP83816 - get ESA from EEPROM > >>>>>>>> DP83816 - ESA: 00:00:24:c8:1d:6c > >>>>>>>> Init device 'eth1' > >>>>>>>> DP83816 at 0x0000e200, interrupt: 2a > >>>>>>>> DP83816 - get ESA from EEPROM > >>>>>>>> DP83816 - ESA: 00:00:24:c8:1d:6d > >>>>>>>> [cyg_net_init] Init: loopattach(0x00000000) > >>>>>>>> [cyg_net_init] Init: ifinit(0x00000000) > >>>>>>>> [cyg_net_init] Init: domaininit(0x00000000) > >>>>>>>> [cyg_net_init] Init: cyg_net_add_domain(0x00238000) > >>>>>>>> New domain internet at 0x00000000 > >>>>>>>> [cyg_net_init] Init: cyg_net_add_domain(0x002378e0) > >>>>>>>> New domain route at 0x00000000 > >>>>>>>> [cyg_net_init] Init: call_route_init(0x00000000) > >>>>>>>> [cyg_net_init] Done > >>>>>>>> Network testing program V2 > >>>>>>>> Thread started > >>>>>>>> Init network : DP83816 - ISR on eth0 > >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > >>>>>>>> DP83816 - can_send on eth0 : 16 > >>>>>>>> DP83816 - send on eth0 > >>>>>>>> DP83816 - can_send on eth0 : 15 > >>>>>>>> DP83816 - deliver on eth0 > >>>>>>>> DP83816 - pool on eth0 > >>>>>>>> DP83816 - Tx Event on eth0 > >>>>>>>> DP83816 - Rx event on eth0 > >>>>>>>> DP83816 - recv on eth0 > >>>>>>>> DP83816 - recv on eth0 > >>>>>>>> DP83816 - can_send on eth0 : 16 > >>>>>>>> DP83816 - send on eth0 > >>>>>>>> DDP83816 - ISR on eth0 > >>>>>>>> P83816 - can_send on eth0 : 15 > >>>>>>>> DP83816 - deliver on eth0 > >>>>>>>> DP83816 - pool on eth0 > >>>>>>>> DP83816 - Tx Event on eth0 > >>>>>>>> DP83816 - Rx event on eth0 > >>>>>>>> DP83816 - recv on eth0 > >>>>>>>> BOOTP[eth0] op: REQUEST > >>>>>>>> htype: Ethernet > >>>>>>>> hlen: 6 > >>>>>>>> hops: 0 > >>>>>>>> xid: 0xec511d6c > >>>>>>>> secs: 0 > >>>>>>>> flags: 0x80 > >>>>>>>> hw_addr: 00:00:24:c8:1d:6c > >>>>>>>> client IP: 0.0.0.0 > >>>>>>>> my IP: 192.168.165.254 > >>>>>>>> server IP: 192.168.165.1 > >>>>>>>> gateway IP: 0.0.0.0 > >>>>>>>> file: boots.default > >>>>>>>> options: > >>>>>>>> DHCP message: 3 REQUEST > >>>>>>>> DHCP server id: 192.168.165.1 > >>>>>>>> DHCP time 51: 43200 > >>>>>>>> DHCP time 58: 21600 > >>>>>>>> DHCP time 59: 37800 > >>>>>>>> subnet mask: 255.255.255.0 > >>>>>>>> gateway: 192.168.165.1 > >>>>>>>> domain server: 192.168.165.1 > >>>>>>>> domain name: v165.itslabb.bth.se. > >>>>>>>> DHCP option: 37/55.9: 54 51 58 59 1 3 6 15 28 > >>>>>>>> DHCP option: 39/57.2: 576 > >>>>>>>> DHCP requested ip: 192.168.165.254 > >>>>>>>> BOOTP[eth1] op: REPLY > >>>>>>>> htype: Ethernet > >>>>>>>> hlen: 6 > >>>>>>>> hops: 0 > >>>>>>>> xid: 0x0 > >>>>>>>> secs: 0 > >>>>>>>> flags: 0x0 > >>>>>>>> hw_addr: 00:00:24:c8:1d:6d > >>>>>>>> client IP: 10.0.0.10 > >>>>>>>> my IP: 10.0.0.10 > >>>>>>>> server IP: 0.0.0.0 > >>>>>>>> gateway IP: 0.0.0.0 > >>>>>>>> options: > >>>>>>>> subnet mask: 255.255.255.0 > >>>>>>>> IP broadcast: 10.0.0.255 > >>>>>>>> gateway: 0.0.0.0 > >>>>>>>> DP83816 - ISR on eth0 > >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > >>>>>>>> DP83816 - can_send on eth0 : 16 > >>>>>>>> DP83816 - send on eth0 > >>>>>>>> DP83816 - can_send on eth0 : 15 > >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > >>>>>>>> DP83816 - can_send on eth0 : 15 > >>>>>>>> DP83816 - send on eth0 > >>>>>>>> DP83816 - can_send on eth0 : 14 > >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > >>>>>>>> DP83816 - can_send on eth1 : 16 > >>>>>>>> DP83816 - send on eth1 > >>>>>>>> DP83816 - can_send on eth1 : 15 > >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > >>>>>>>> DP83816 - can_send on eth1 : 15 > >>>>>>>> DP83816 - send on eth1 > >>>>>>>> DP83816 - can_send on eth1 : 14 > >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > >>>>>>>> Network initalized ! > >>>>>>>> Eth0 is up ! > >>>>>>>> Eth1 is up ! > >>>>>>>> socket() = 3 > >>>>>>>> It seem that everthing is OK. start sending packets. > >>>>>>>> A - 0> sendto() = 3 > >>>>>>>> B - 0> Waiting for a packet > >>>>>>>> DP83816 - deliver on eth0 > >>>>>>>> DP83816 - pool on eth0 > >>>>>>>> DP83816 - Tx Event on eth0 > >>>>>>>> DP83816 - ISR on eth0 > >>>>>>>> DP83816 - deliver on eth0 > >>>>>>>> DP83816 - pool on eth0 > >>>>>>>> DP83816 - ISR on eth0 > >>>>>>>> A - 1> sendto() = 3 > >>>>>>>> DP83816 - deliver on eth0 > >>>>>>>> DP83816 - pool on eth0 > >>>>>>>> DP83816 - ISR on eth0 > >>>>>>>> DP83816 - deliver on eth0 > >>>>>>>> DP83816 - pool on eth0 > >>>>>>>> DP83816 - ISR on eth0 > >>>>>>>> DP83816 - deliver on eth0 > >>>>>>>> DP83816 - pool on eth0 > >>>>>>>> DP83816 - ISR on eth0 > >>>>>>>> A - 2> sendto() = 3 > >>>>>>>> DP83816 - deliver on eth0 > >>>>>>>> DP83816 - pool on eth0 > >>>>>>>> DP83816 - ISR on eth0 > >>>>>>>> DP83816 - deliver on eth0 > >>>>>>>> DP83816 - pool on eth0 > >>>>>>>> DP83816 - ISR on eth0 > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> 2008/1/10, Gary Thomas <gary@mlbassoc.com>: > >>>>>>>>> Please keep your replies on the eCos list! > >>>>>>>>> > >>>>>>>>> **EVERYONE** please get this straight. Replies made by me on the > >>>>>>>>> eCos discussion list must be followed up on the eCos discussion list > >>>>>>>>> unless I invite private replies. This way everyone benefits, not > >>>>>>>>> just the interested party. Private email support consultation and > >>>>>>>>> support is available, but only with a contract. > >>>>>>>>> > >>>>>>>>> Antoine Zen-Ruffinen wrote: > >>>>>>>>>> The target platform is an embed PC with NS dp83816 NIC. I've port the > >>>>>>>>>> eCos driver my self for the PC platform. > >>>>>>>>>> > >>>>>>>>>> I configure eCos with the configtool, just using the template I made > >>>>>>>>>> and the "net" package. > >>>>>>>>>> > >>>>>>>>>> No, I didn't run a standard eCos network test program. But I build an > >>>>>>>>>> redboot with this configuration. If I type ping -n 1000 -r 1 -h > >>>>>>>>>> 192.168.165.18 (is my host PC) everything went fine ! > >>>>>>>>> This is only partly relevant - RedBoot uses a completely different > >>>>>>>>> network stack than normal eCos applications. Also, RedBoot does > >>>>>>>>> not use interrupts, which the eCos stacks rely on. > >>>>>>>>> > >>>>>>>>>> I know that nothing was send : 1 becose network activity led doesn't > >>>>>>>>>> blink, 2 I monitor network with Wireshark (Ethereal). the monitoring > >>>>>>>>>> trace show the TFTP exchange and the DHCP init but nothing more. It > >>>>>>>>>> look like this : > >>>>>>>>>> No. Time Source Destination Protocol Info > >>>>>>>>>> 69504 25.515675 192.168.165.18 192.168.165.253 TFTP > >>>>>>>>>> Data Packet, Block: 452 > >>>>>>>>>> 69505 25.516279 192.168.165.253 192.168.165.18 TFTP > >>>>>>>>>> Acknowledgement, Block: 452 > >>>>>>>>>> 69506 25.516289 192.168.165.18 192.168.165.253 TFTP > >>>>>>>>>> Data Packet, Block: 453 > >>>>>>>>>> 69507 25.516662 192.168.165.253 192.168.165.18 TFTP > >>>>>>>>>> Error Code, Code: Not defined, Message: redboot > >>>>>>>>>> tftp_stream_terminate > >>>>>>>>>> 69508 25.826093 0.0.0.0 255.255.255.255 DHCP > >>>>>>>>>> DHCP Discover - Transaction ID 0x6c1dfce9 > >>>>>>>>>> 69511 26.074789 0.0.0.0 255.255.255.255 DHCP > >>>>>>>>>> DHCP Discover - Transaction ID 0x6c1dfce9 > >>>>>>>>>> 69512 26.304739 0.0.0.0 255.255.255.255 DHCP > >>>>>>>>>> DHCP Discover - Transaction ID 0x6c1dfce9 > >>>>>>>>>> 69514 26.451407 0.0.0.0 255.255.255.255 DHCP > >>>>>>>>>> DHCP Request - Transaction ID 0x6c1dfde9 > >>>>>>>>>> 69516 26.839890 Olicom_c8:1d:6c Broadcast ARP > >>>>>>>>>> Who has 192.168.165.254? Gratuitous ARP > >>>>>>>>>> > >>>>>>>>> Did your eCos application print anything about the DHCP transaction? > >>>>>>>>> I'm betting that it did not (which would imply you are having trouble > >>>>>>>>> with receive interrupts from your driver) > >>>>>>>>> > >>>>>>>>>> 2008/1/10, Gary Thomas <gary@mlbassoc.com>: > >>>>>>>>>>> Antoine Zen-Ruffinen wrote: > >>>>>>>>>>>> Hi List folks, > >>>>>>>>>>>> > >>>>>>>>>>>> I've a problem with the TCP/IP stack: > >>>>>>>>>>>> - I use TFTP to load my program in redboot. That work fine. > >>>>>>>>>>>> - My application start, call init_all_network_interfaces(), it do the > >>>>>>>>>>>> DHCP stuff. That work fine. > >>>>>>>>>>>> - Then I open a socket and try to send / receive data. No packet is even send. > >>>>>>>>>>>> > >>>>>>>>>>>> Does someone has already seen such problem ? > >>>>>>>>>>>> Any idea ? > >>>>>>>>>>> We'll need more data than this in order to help. > >>>>>>>>>>> * What's the target platform? > >>>>>>>>>>> * How did you configure eCos for your failing application? > >>>>>>>>>>> * Have you run any of the standard eCos network test programs? > >>>>>>>>>>> * How do you know nothing was sent? What sort of debugging > >>>>>>>>>>> have you tried so far? > >> -- > >> ------------------------------------------------------------ > >> Gary Thomas | Consulting for the > >> MLB Associates | Embedded world > >> ------------------------------------------------------------ > >> > > > > > -- > ------------------------------------------------------------ > Gary Thomas | Consulting for the > MLB Associates | Embedded world > ------------------------------------------------------------ > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ECOS] Problem with TCP/IP stack 2008-01-11 16:38 ` Antoine Zen-Ruffinen @ 2008-01-11 16:39 ` Antoine Zen-Ruffinen 2008-01-11 16:46 ` Gary Thomas 0 siblings, 1 reply; 20+ messages in thread From: Antoine Zen-Ruffinen @ 2008-01-11 16:39 UTC (permalink / raw) To: Gary Thomas; +Cc: eCos Discussion Thank you Gary, Thank you Andrew. You saved my week-end!!!! Thank's a lot !! Antoine 2008/1/11, Antoine Zen-Ruffinen <antoine.zen@gmail.com>: > IT WORK NOW!!!!! > > 2008/1/11, Gary Thomas <gary@mlbassoc.com>: > > Antoine Zen-Ruffinen wrote: > > > Yes i have CYGIMP_HAL_INTERRUPTS_CHAIN = true in configtool. Does I > > > need something else ? My target is i386-PC. > > > > That just says that your HAL knows *how* to managed chained interrupts. > > > > You also need CYGIMP_KERNEL_INTERRUPTS_CHAIN, so the kernel will > > support chained interrupts for ISRs. > > > > > 2008/1/11, Gary Thomas <gary@mlbassoc.com>: > > >> Antoine Zen-Ruffinen wrote: > > >>> Ok, I am trying to do that. But if the ISR of my fist interface return > > >>> 0, the ISR of the second interface is not called. Does it nead to have > > >>> 2 different ISR routine or the same with different parameter is enough > > >>> ? > > >> You can use the same ISR with different parameters. > > >> > > >> Do you have interrupt chaining enabled? > > >> Does your HAL properly support chained interrupts? (what's your target?) > > >> > > >>> 2008/1/11, Gary Thomas <gary@mlbassoc.com>: > > >>>> Antoine Zen-Ruffinen wrote: > > >>>>> Ok, I found the problem but I dont' know how to solve it: My two NIC > > >>>>> are sharing the same interrupt. So when the second NIC do an > > >>>>> interrupt, it is handel like it is the first NIC that interrupt. > > >>>>> > > >>>>> Does someone know how to solve such an issue ? > > >>>>> > > >>>> The key is to make your interrupt handler (ISR) tell the upper > > >>>> layers which board did it. This is reflected in the (struct eth_drv_sc *) > > >>>> parameter that you pass upstream. Somehow, your driver will have > > >>>> to keep track of these (there is one such structure per physical > > >>>> device entity), then determine which board is responsible and > > >>>> use that information to decide which device (i.e. structure) to use. > > >>>> > > >>>> If you're using the same interrupt for both devices, surely you > > >>>> have Interrupt Chaining turned on in eCos? This allows for multiple > > >>>> ISR/DSR pairs to be registered for the same interrupt. eCos will > > >>>> call these ISR functions until one of them returns that it had > > >>>> handled the interrupt. This could be used to easily handle your > > >>>> situation. > > >>>> > > >>>>> 2008/1/11, Antoine Zen-Ruffinen <antoine.zen@gmail.com>: > > >>>>>> Some new discover : If a use only one of the two NIC I have on my > > >>>>>> system, everything work fine. When using two NIC, interrupts all the > > >>>>>> time, even if no network activity, even if doing nothing and ARP > > >>>>>> response are not catch by network stack. So the problem is a conflict > > >>>>>> between both interfaces. Here is my driver declaration (for the i386 > > >>>>>> platform), maybe something wrong there : > > >>>>>> > > >>>>>> #include <cyg/hal/hal_cache.h> > > >>>>>> #include <cyg/io/pci.h> > > >>>>>> > > >>>>>> > > >>>>>> static cyg_bool > > >>>>>> find_dp83816_match_func(cyg_uint16 v, cyg_uint16 d, cyg_uint32 c, void *p) > > >>>>>> { > > >>>>>> return ((v == 0x100B) && (d == 0x0020)); > > >>>>>> } > > >>>>>> > > >>>>>> cyg_pci_device_id devid = CYG_PCI_NULL_DEVID; > > >>>>>> static void > > >>>>>> _i386_pc_eth_init(dp83816_priv_data_t *dp) > > >>>>>> { > > >>>>>> > > >>>>>> cyg_pci_device dev_info; > > >>>>>> > > >>>>>> > > >>>>>> if (cyg_pci_find_matching( &find_dp83816_match_func, NULL, &devid )) { > > >>>>>> cyg_pci_get_device_info(devid, &dev_info); > > >>>>>> cyg_pci_translate_interrupt(&dev_info, &dp->interrupt); > > >>>>>> dp->base = (cyg_uint8 *)(dev_info.base_map[0] & ~1); > > >>>>>> diag_printf("DP83816 at %p, interrupt: %x\n", dp->base, dp->interrupt); > > >>>>>> } > > >>>>>> } > > >>>>>> > > >>>>>> #undef CYGHWR_NS_DP83816_PLF_INIT > > >>>>>> #define CYGHWR_NS_DP83816_PLF_INIT(dp) _i386_pc_eth_init(dp) > > >>>>>> > > >>>>>> // Align buffers on a cache boundary > > >>>>>> #define RxBUFSIZE (CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM * _DP83816_BUFSIZE) > > >>>>>> #define TxBUFSIZE (CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM * _DP83816_BUFSIZE) > > >>>>>> static unsigned char dp83816_eth0_rxbufs[RxBUFSIZE] > > >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > > >>>>>> static unsigned char dp83816_eth0_txbufs[TxBUFSIZE] > > >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > > >>>>>> static dp83816_bd_t > > >>>>>> dp83816_eth0_rxbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM] > > >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > > >>>>>> static dp83816_bd_t > > >>>>>> dp83816_eth0_txbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM] > > >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > > >>>>>> > > >>>>>> static unsigned char dp83816_eth1_rxbufs[RxBUFSIZE] > > >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > > >>>>>> static unsigned char dp83816_eth1_txbufs[TxBUFSIZE] > > >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > > >>>>>> static dp83816_bd_t > > >>>>>> dp83816_eth1_rxbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM] > > >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > > >>>>>> static dp83816_bd_t > > >>>>>> dp83816_eth1_txbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM] > > >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); > > >>>>>> > > >>>>>> > > >>>>>> // eth0 delacration > > >>>>>> char _i386_pc_eth0_ESA[6]; > > >>>>>> static dp83816_priv_data_t dp83816_eth0_priv_data = { > > >>>>>> "eth0_esa", > > >>>>>> _i386_pc_eth0_ESA, > > >>>>>> CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM, // Number of Rx buffers > > >>>>>> dp83816_eth0_rxbufs, // Rx buffer space > > >>>>>> dp83816_eth0_rxbd, // Rx buffer headers > > >>>>>> CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM, // Number of Tx buffers > > >>>>>> dp83816_eth0_txbufs, // Tx buffer space > > >>>>>> dp83816_eth0_txbd, // Tx buffer headers > > >>>>>> }; > > >>>>>> > > >>>>>> ETH_DRV_SC(dp83816_sc0, > > >>>>>> &dp83816_eth0_priv_data, // Driver specific data > > >>>>>> "eth0", > > >>>>>> dp83816_start, > > >>>>>> dp83816_stop, > > >>>>>> dp83816_control, > > >>>>>> dp83816_can_send, > > >>>>>> dp83816_send, > > >>>>>> dp83816_recv, > > >>>>>> dp83816_deliver, // "pseudoDSR" called from fast net thread > > >>>>>> dp83816_poll, // poll function, encapsulates ISR and DSR > > >>>>>> dp83816_int_vector); > > >>>>>> > > >>>>>> NETDEVTAB_ENTRY(dp83816_netdev0, > > >>>>>> "eth0", > > >>>>>> dp83816_init, > > >>>>>> &dp83816_sc0); > > >>>>>> > > >>>>>> // eth1 delacration > > >>>>>> char _i386_pc_eth1_ESA[6]; > > >>>>>> static dp83816_priv_data_t dp83816_eth1_priv_data = { > > >>>>>> "eth1_esa", > > >>>>>> _i386_pc_eth1_ESA, > > >>>>>> CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM, // Number of Rx buffers > > >>>>>> dp83816_eth1_rxbufs, // Rx buffer space > > >>>>>> dp83816_eth1_rxbd, // Rx buffer headers > > >>>>>> CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM, // Number of Tx buffers > > >>>>>> dp83816_eth1_txbufs, // Tx buffer space > > >>>>>> dp83816_eth1_txbd, // Tx buffer headers > > >>>>>> }; > > >>>>>> > > >>>>>> ETH_DRV_SC(dp83816_sc1, > > >>>>>> &dp83816_eth1_priv_data, // Driver specific data > > >>>>>> "eth1", > > >>>>>> dp83816_start, > > >>>>>> dp83816_stop, > > >>>>>> dp83816_control, > > >>>>>> dp83816_can_send, > > >>>>>> dp83816_send, > > >>>>>> dp83816_recv, > > >>>>>> dp83816_deliver, // "pseudoDSR" called from fast net thread > > >>>>>> dp83816_poll, // poll function, encapsulates ISR and DSR > > >>>>>> dp83816_int_vector); > > >>>>>> > > >>>>>> NETDEVTAB_ENTRY(dp83816_netdev1, > > >>>>>> "eth1", > > >>>>>> dp83816_init, > > >>>>>> &dp83816_sc1); > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> 2008/1/10, Antoine Zen-Ruffinen <antoine.zen@gmail.com>: > > >>>>>>> The previous post "[ECOS] Cannot sendto multicast using FreeBSD stack" > > >>>>>>> put me on the way!! > > >>>>>>> > > >>>>>>> No IP packet are send, but ARP is done. But it seem that the stack > > >>>>>>> doesn't get the ARP reply witch is on the wire. When calling send(), > > >>>>>>> for the fist calls, send() return > 0, but with errno=2 (No such > > >>>>>>> entry) then send() return -1 wiht erron=364 (Host is down). Can this > > >>>>>>> be because I have 2 NIC that share the same interrupt ? > > >>>>>>> > > >>>>>>> 2008/1/10, Antoine Zen-Ruffinen <antoine.zen@gmail.com>: > > >>>>>>>> Sorry for the preceding message that was not send to the list, little > > >>>>>>>> mistake from me (cliqued "reply" and not "reply to all"). > > >>>>>>>> > > >>>>>>>> Yes my application print about DHCP transaction and it is ok. I have > > >>>>>>>> added some prints in every driver function in order to trace what it > > >>>>>>>> is doing. The output is interesting : > > >>>>>>>> 1) The NIC is making interrupts all the time > > >>>>>>>> 2) The network stack never call the send() function. > > >>>>>>>> > > >>>>>>>> Here is the output : > > >>>>>>>> RedBoot> load -m tftp -h 192.168.165.18 debugProg > > >>>>>>>> Entry point: 0x00200000, address range: 0x00200000-0x00238840 > > >>>>>>>> RedBoot> go > > >>>>>>>> [cyg_net_init] Init: mbinit(0x00000000) > > >>>>>>>> [cyg_net_init] Init: cyg_net_init_devs(0x00000000) > > >>>>>>>> Init device 'eth0' > > >>>>>>>> DP83816 at 0x0000e100, interrupt: 2a > > >>>>>>>> DP83816 - get ESA from EEPROM > > >>>>>>>> DP83816 - ESA: 00:00:24:c8:1d:6c > > >>>>>>>> Init device 'eth1' > > >>>>>>>> DP83816 at 0x0000e200, interrupt: 2a > > >>>>>>>> DP83816 - get ESA from EEPROM > > >>>>>>>> DP83816 - ESA: 00:00:24:c8:1d:6d > > >>>>>>>> [cyg_net_init] Init: loopattach(0x00000000) > > >>>>>>>> [cyg_net_init] Init: ifinit(0x00000000) > > >>>>>>>> [cyg_net_init] Init: domaininit(0x00000000) > > >>>>>>>> [cyg_net_init] Init: cyg_net_add_domain(0x00238000) > > >>>>>>>> New domain internet at 0x00000000 > > >>>>>>>> [cyg_net_init] Init: cyg_net_add_domain(0x002378e0) > > >>>>>>>> New domain route at 0x00000000 > > >>>>>>>> [cyg_net_init] Init: call_route_init(0x00000000) > > >>>>>>>> [cyg_net_init] Done > > >>>>>>>> Network testing program V2 > > >>>>>>>> Thread started > > >>>>>>>> Init network : DP83816 - ISR on eth0 > > >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > > >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > > >>>>>>>> DP83816 - can_send on eth0 : 16 > > >>>>>>>> DP83816 - send on eth0 > > >>>>>>>> DP83816 - can_send on eth0 : 15 > > >>>>>>>> DP83816 - deliver on eth0 > > >>>>>>>> DP83816 - pool on eth0 > > >>>>>>>> DP83816 - Tx Event on eth0 > > >>>>>>>> DP83816 - Rx event on eth0 > > >>>>>>>> DP83816 - recv on eth0 > > >>>>>>>> DP83816 - recv on eth0 > > >>>>>>>> DP83816 - can_send on eth0 : 16 > > >>>>>>>> DP83816 - send on eth0 > > >>>>>>>> DDP83816 - ISR on eth0 > > >>>>>>>> P83816 - can_send on eth0 : 15 > > >>>>>>>> DP83816 - deliver on eth0 > > >>>>>>>> DP83816 - pool on eth0 > > >>>>>>>> DP83816 - Tx Event on eth0 > > >>>>>>>> DP83816 - Rx event on eth0 > > >>>>>>>> DP83816 - recv on eth0 > > >>>>>>>> BOOTP[eth0] op: REQUEST > > >>>>>>>> htype: Ethernet > > >>>>>>>> hlen: 6 > > >>>>>>>> hops: 0 > > >>>>>>>> xid: 0xec511d6c > > >>>>>>>> secs: 0 > > >>>>>>>> flags: 0x80 > > >>>>>>>> hw_addr: 00:00:24:c8:1d:6c > > >>>>>>>> client IP: 0.0.0.0 > > >>>>>>>> my IP: 192.168.165.254 > > >>>>>>>> server IP: 192.168.165.1 > > >>>>>>>> gateway IP: 0.0.0.0 > > >>>>>>>> file: boots.default > > >>>>>>>> options: > > >>>>>>>> DHCP message: 3 REQUEST > > >>>>>>>> DHCP server id: 192.168.165.1 > > >>>>>>>> DHCP time 51: 43200 > > >>>>>>>> DHCP time 58: 21600 > > >>>>>>>> DHCP time 59: 37800 > > >>>>>>>> subnet mask: 255.255.255.0 > > >>>>>>>> gateway: 192.168.165.1 > > >>>>>>>> domain server: 192.168.165.1 > > >>>>>>>> domain name: v165.itslabb.bth.se. > > >>>>>>>> DHCP option: 37/55.9: 54 51 58 59 1 3 6 15 28 > > >>>>>>>> DHCP option: 39/57.2: 576 > > >>>>>>>> DHCP requested ip: 192.168.165.254 > > >>>>>>>> BOOTP[eth1] op: REPLY > > >>>>>>>> htype: Ethernet > > >>>>>>>> hlen: 6 > > >>>>>>>> hops: 0 > > >>>>>>>> xid: 0x0 > > >>>>>>>> secs: 0 > > >>>>>>>> flags: 0x0 > > >>>>>>>> hw_addr: 00:00:24:c8:1d:6d > > >>>>>>>> client IP: 10.0.0.10 > > >>>>>>>> my IP: 10.0.0.10 > > >>>>>>>> server IP: 0.0.0.0 > > >>>>>>>> gateway IP: 0.0.0.0 > > >>>>>>>> options: > > >>>>>>>> subnet mask: 255.255.255.0 > > >>>>>>>> IP broadcast: 10.0.0.255 > > >>>>>>>> gateway: 0.0.0.0 > > >>>>>>>> DP83816 - ISR on eth0 > > >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > > >>>>>>>> DP83816 - can_send on eth0 : 16 > > >>>>>>>> DP83816 - send on eth0 > > >>>>>>>> DP83816 - can_send on eth0 : 15 > > >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > > >>>>>>>> DP83816 - can_send on eth0 : 15 > > >>>>>>>> DP83816 - send on eth0 > > >>>>>>>> DP83816 - can_send on eth0 : 14 > > >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > > >>>>>>>> DP83816 - can_send on eth1 : 16 > > >>>>>>>> DP83816 - send on eth1 > > >>>>>>>> DP83816 - can_send on eth1 : 15 > > >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > > >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > > >>>>>>>> DP83816 - can_send on eth1 : 15 > > >>>>>>>> DP83816 - send on eth1 > > >>>>>>>> DP83816 - can_send on eth1 : 14 > > >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode > > >>>>>>>> Network initalized ! > > >>>>>>>> Eth0 is up ! > > >>>>>>>> Eth1 is up ! > > >>>>>>>> socket() = 3 > > >>>>>>>> It seem that everthing is OK. start sending packets. > > >>>>>>>> A - 0> sendto() = 3 > > >>>>>>>> B - 0> Waiting for a packet > > >>>>>>>> DP83816 - deliver on eth0 > > >>>>>>>> DP83816 - pool on eth0 > > >>>>>>>> DP83816 - Tx Event on eth0 > > >>>>>>>> DP83816 - ISR on eth0 > > >>>>>>>> DP83816 - deliver on eth0 > > >>>>>>>> DP83816 - pool on eth0 > > >>>>>>>> DP83816 - ISR on eth0 > > >>>>>>>> A - 1> sendto() = 3 > > >>>>>>>> DP83816 - deliver on eth0 > > >>>>>>>> DP83816 - pool on eth0 > > >>>>>>>> DP83816 - ISR on eth0 > > >>>>>>>> DP83816 - deliver on eth0 > > >>>>>>>> DP83816 - pool on eth0 > > >>>>>>>> DP83816 - ISR on eth0 > > >>>>>>>> DP83816 - deliver on eth0 > > >>>>>>>> DP83816 - pool on eth0 > > >>>>>>>> DP83816 - ISR on eth0 > > >>>>>>>> A - 2> sendto() = 3 > > >>>>>>>> DP83816 - deliver on eth0 > > >>>>>>>> DP83816 - pool on eth0 > > >>>>>>>> DP83816 - ISR on eth0 > > >>>>>>>> DP83816 - deliver on eth0 > > >>>>>>>> DP83816 - pool on eth0 > > >>>>>>>> DP83816 - ISR on eth0 > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> 2008/1/10, Gary Thomas <gary@mlbassoc.com>: > > >>>>>>>>> Please keep your replies on the eCos list! > > >>>>>>>>> > > >>>>>>>>> **EVERYONE** please get this straight. Replies made by me on the > > >>>>>>>>> eCos discussion list must be followed up on the eCos discussion list > > >>>>>>>>> unless I invite private replies. This way everyone benefits, not > > >>>>>>>>> just the interested party. Private email support consultation and > > >>>>>>>>> support is available, but only with a contract. > > >>>>>>>>> > > >>>>>>>>> Antoine Zen-Ruffinen wrote: > > >>>>>>>>>> The target platform is an embed PC with NS dp83816 NIC. I've port the > > >>>>>>>>>> eCos driver my self for the PC platform. > > >>>>>>>>>> > > >>>>>>>>>> I configure eCos with the configtool, just using the template I made > > >>>>>>>>>> and the "net" package. > > >>>>>>>>>> > > >>>>>>>>>> No, I didn't run a standard eCos network test program. But I build an > > >>>>>>>>>> redboot with this configuration. If I type ping -n 1000 -r 1 -h > > >>>>>>>>>> 192.168.165.18 (is my host PC) everything went fine ! > > >>>>>>>>> This is only partly relevant - RedBoot uses a completely different > > >>>>>>>>> network stack than normal eCos applications. Also, RedBoot does > > >>>>>>>>> not use interrupts, which the eCos stacks rely on. > > >>>>>>>>> > > >>>>>>>>>> I know that nothing was send : 1 becose network activity led doesn't > > >>>>>>>>>> blink, 2 I monitor network with Wireshark (Ethereal). the monitoring > > >>>>>>>>>> trace show the TFTP exchange and the DHCP init but nothing more. It > > >>>>>>>>>> look like this : > > >>>>>>>>>> No. Time Source Destination Protocol Info > > >>>>>>>>>> 69504 25.515675 192.168.165.18 192.168.165.253 TFTP > > >>>>>>>>>> Data Packet, Block: 452 > > >>>>>>>>>> 69505 25.516279 192.168.165.253 192.168.165.18 TFTP > > >>>>>>>>>> Acknowledgement, Block: 452 > > >>>>>>>>>> 69506 25.516289 192.168.165.18 192.168.165.253 TFTP > > >>>>>>>>>> Data Packet, Block: 453 > > >>>>>>>>>> 69507 25.516662 192.168.165.253 192.168.165.18 TFTP > > >>>>>>>>>> Error Code, Code: Not defined, Message: redboot > > >>>>>>>>>> tftp_stream_terminate > > >>>>>>>>>> 69508 25.826093 0.0.0.0 255.255.255.255 DHCP > > >>>>>>>>>> DHCP Discover - Transaction ID 0x6c1dfce9 > > >>>>>>>>>> 69511 26.074789 0.0.0.0 255.255.255.255 DHCP > > >>>>>>>>>> DHCP Discover - Transaction ID 0x6c1dfce9 > > >>>>>>>>>> 69512 26.304739 0.0.0.0 255.255.255.255 DHCP > > >>>>>>>>>> DHCP Discover - Transaction ID 0x6c1dfce9 > > >>>>>>>>>> 69514 26.451407 0.0.0.0 255.255.255.255 DHCP > > >>>>>>>>>> DHCP Request - Transaction ID 0x6c1dfde9 > > >>>>>>>>>> 69516 26.839890 Olicom_c8:1d:6c Broadcast ARP > > >>>>>>>>>> Who has 192.168.165.254? Gratuitous ARP > > >>>>>>>>>> > > >>>>>>>>> Did your eCos application print anything about the DHCP transaction? > > >>>>>>>>> I'm betting that it did not (which would imply you are having trouble > > >>>>>>>>> with receive interrupts from your driver) > > >>>>>>>>> > > >>>>>>>>>> 2008/1/10, Gary Thomas <gary@mlbassoc.com>: > > >>>>>>>>>>> Antoine Zen-Ruffinen wrote: > > >>>>>>>>>>>> Hi List folks, > > >>>>>>>>>>>> > > >>>>>>>>>>>> I've a problem with the TCP/IP stack: > > >>>>>>>>>>>> - I use TFTP to load my program in redboot. That work fine. > > >>>>>>>>>>>> - My application start, call init_all_network_interfaces(), it do the > > >>>>>>>>>>>> DHCP stuff. That work fine. > > >>>>>>>>>>>> - Then I open a socket and try to send / receive data. No packet is even send. > > >>>>>>>>>>>> > > >>>>>>>>>>>> Does someone has already seen such problem ? > > >>>>>>>>>>>> Any idea ? > > >>>>>>>>>>> We'll need more data than this in order to help. > > >>>>>>>>>>> * What's the target platform? > > >>>>>>>>>>> * How did you configure eCos for your failing application? > > >>>>>>>>>>> * Have you run any of the standard eCos network test programs? > > >>>>>>>>>>> * How do you know nothing was sent? What sort of debugging > > >>>>>>>>>>> have you tried so far? > > >> -- > > >> ------------------------------------------------------------ > > >> Gary Thomas | Consulting for the > > >> MLB Associates | Embedded world > > >> ------------------------------------------------------------ > > >> > > > > > > > > > -- > > ------------------------------------------------------------ > > Gary Thomas | Consulting for the > > MLB Associates | Embedded world > > ------------------------------------------------------------ > > > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ECOS] Problem with TCP/IP stack 2008-01-11 16:39 ` Antoine Zen-Ruffinen @ 2008-01-11 16:46 ` Gary Thomas 0 siblings, 0 replies; 20+ messages in thread From: Gary Thomas @ 2008-01-11 16:46 UTC (permalink / raw) To: Antoine Zen-Ruffinen; +Cc: eCos Discussion Antoine Zen-Ruffinen wrote: > Thank you Gary, Thank you Andrew. You saved my week-end!!!! Thank's a lot !! Applause not necessary :-) A 2005 Bordeaux premier-cru will do nicely! > 2008/1/11, Antoine Zen-Ruffinen <antoine.zen@gmail.com>: >> IT WORK NOW!!!!! >> >> 2008/1/11, Gary Thomas <gary@mlbassoc.com>: >>> Antoine Zen-Ruffinen wrote: >>>> Yes i have CYGIMP_HAL_INTERRUPTS_CHAIN = true in configtool. Does I >>>> need something else ? My target is i386-PC. >>> That just says that your HAL knows *how* to managed chained interrupts. >>> >>> You also need CYGIMP_KERNEL_INTERRUPTS_CHAIN, so the kernel will >>> support chained interrupts for ISRs. >>> >>>> 2008/1/11, Gary Thomas <gary@mlbassoc.com>: >>>>> Antoine Zen-Ruffinen wrote: >>>>>> Ok, I am trying to do that. But if the ISR of my fist interface return >>>>>> 0, the ISR of the second interface is not called. Does it nead to have >>>>>> 2 different ISR routine or the same with different parameter is enough >>>>>> ? >>>>> You can use the same ISR with different parameters. >>>>> >>>>> Do you have interrupt chaining enabled? >>>>> Does your HAL properly support chained interrupts? (what's your target?) >>>>> >>>>>> 2008/1/11, Gary Thomas <gary@mlbassoc.com>: >>>>>>> Antoine Zen-Ruffinen wrote: >>>>>>>> Ok, I found the problem but I dont' know how to solve it: My two NIC >>>>>>>> are sharing the same interrupt. So when the second NIC do an >>>>>>>> interrupt, it is handel like it is the first NIC that interrupt. >>>>>>>> >>>>>>>> Does someone know how to solve such an issue ? >>>>>>>> >>>>>>> The key is to make your interrupt handler (ISR) tell the upper >>>>>>> layers which board did it. This is reflected in the (struct eth_drv_sc *) >>>>>>> parameter that you pass upstream. Somehow, your driver will have >>>>>>> to keep track of these (there is one such structure per physical >>>>>>> device entity), then determine which board is responsible and >>>>>>> use that information to decide which device (i.e. structure) to use. >>>>>>> >>>>>>> If you're using the same interrupt for both devices, surely you >>>>>>> have Interrupt Chaining turned on in eCos? This allows for multiple >>>>>>> ISR/DSR pairs to be registered for the same interrupt. eCos will >>>>>>> call these ISR functions until one of them returns that it had >>>>>>> handled the interrupt. This could be used to easily handle your >>>>>>> situation. >>>>>>> >>>>>>>> 2008/1/11, Antoine Zen-Ruffinen <antoine.zen@gmail.com>: >>>>>>>>> Some new discover : If a use only one of the two NIC I have on my >>>>>>>>> system, everything work fine. When using two NIC, interrupts all the >>>>>>>>> time, even if no network activity, even if doing nothing and ARP >>>>>>>>> response are not catch by network stack. So the problem is a conflict >>>>>>>>> between both interfaces. Here is my driver declaration (for the i386 >>>>>>>>> platform), maybe something wrong there : >>>>>>>>> >>>>>>>>> #include <cyg/hal/hal_cache.h> >>>>>>>>> #include <cyg/io/pci.h> >>>>>>>>> >>>>>>>>> >>>>>>>>> static cyg_bool >>>>>>>>> find_dp83816_match_func(cyg_uint16 v, cyg_uint16 d, cyg_uint32 c, void *p) >>>>>>>>> { >>>>>>>>> return ((v == 0x100B) && (d == 0x0020)); >>>>>>>>> } >>>>>>>>> >>>>>>>>> cyg_pci_device_id devid = CYG_PCI_NULL_DEVID; >>>>>>>>> static void >>>>>>>>> _i386_pc_eth_init(dp83816_priv_data_t *dp) >>>>>>>>> { >>>>>>>>> >>>>>>>>> cyg_pci_device dev_info; >>>>>>>>> >>>>>>>>> >>>>>>>>> if (cyg_pci_find_matching( &find_dp83816_match_func, NULL, &devid )) { >>>>>>>>> cyg_pci_get_device_info(devid, &dev_info); >>>>>>>>> cyg_pci_translate_interrupt(&dev_info, &dp->interrupt); >>>>>>>>> dp->base = (cyg_uint8 *)(dev_info.base_map[0] & ~1); >>>>>>>>> diag_printf("DP83816 at %p, interrupt: %x\n", dp->base, dp->interrupt); >>>>>>>>> } >>>>>>>>> } >>>>>>>>> >>>>>>>>> #undef CYGHWR_NS_DP83816_PLF_INIT >>>>>>>>> #define CYGHWR_NS_DP83816_PLF_INIT(dp) _i386_pc_eth_init(dp) >>>>>>>>> >>>>>>>>> // Align buffers on a cache boundary >>>>>>>>> #define RxBUFSIZE (CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM * _DP83816_BUFSIZE) >>>>>>>>> #define TxBUFSIZE (CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM * _DP83816_BUFSIZE) >>>>>>>>> static unsigned char dp83816_eth0_rxbufs[RxBUFSIZE] >>>>>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); >>>>>>>>> static unsigned char dp83816_eth0_txbufs[TxBUFSIZE] >>>>>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); >>>>>>>>> static dp83816_bd_t >>>>>>>>> dp83816_eth0_rxbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM] >>>>>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); >>>>>>>>> static dp83816_bd_t >>>>>>>>> dp83816_eth0_txbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM] >>>>>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); >>>>>>>>> >>>>>>>>> static unsigned char dp83816_eth1_rxbufs[RxBUFSIZE] >>>>>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); >>>>>>>>> static unsigned char dp83816_eth1_txbufs[TxBUFSIZE] >>>>>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); >>>>>>>>> static dp83816_bd_t >>>>>>>>> dp83816_eth1_rxbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM] >>>>>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); >>>>>>>>> static dp83816_bd_t >>>>>>>>> dp83816_eth1_txbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM] >>>>>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); >>>>>>>>> >>>>>>>>> >>>>>>>>> // eth0 delacration >>>>>>>>> char _i386_pc_eth0_ESA[6]; >>>>>>>>> static dp83816_priv_data_t dp83816_eth0_priv_data = { >>>>>>>>> "eth0_esa", >>>>>>>>> _i386_pc_eth0_ESA, >>>>>>>>> CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM, // Number of Rx buffers >>>>>>>>> dp83816_eth0_rxbufs, // Rx buffer space >>>>>>>>> dp83816_eth0_rxbd, // Rx buffer headers >>>>>>>>> CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM, // Number of Tx buffers >>>>>>>>> dp83816_eth0_txbufs, // Tx buffer space >>>>>>>>> dp83816_eth0_txbd, // Tx buffer headers >>>>>>>>> }; >>>>>>>>> >>>>>>>>> ETH_DRV_SC(dp83816_sc0, >>>>>>>>> &dp83816_eth0_priv_data, // Driver specific data >>>>>>>>> "eth0", >>>>>>>>> dp83816_start, >>>>>>>>> dp83816_stop, >>>>>>>>> dp83816_control, >>>>>>>>> dp83816_can_send, >>>>>>>>> dp83816_send, >>>>>>>>> dp83816_recv, >>>>>>>>> dp83816_deliver, // "pseudoDSR" called from fast net thread >>>>>>>>> dp83816_poll, // poll function, encapsulates ISR and DSR >>>>>>>>> dp83816_int_vector); >>>>>>>>> >>>>>>>>> NETDEVTAB_ENTRY(dp83816_netdev0, >>>>>>>>> "eth0", >>>>>>>>> dp83816_init, >>>>>>>>> &dp83816_sc0); >>>>>>>>> >>>>>>>>> // eth1 delacration >>>>>>>>> char _i386_pc_eth1_ESA[6]; >>>>>>>>> static dp83816_priv_data_t dp83816_eth1_priv_data = { >>>>>>>>> "eth1_esa", >>>>>>>>> _i386_pc_eth1_ESA, >>>>>>>>> CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM, // Number of Rx buffers >>>>>>>>> dp83816_eth1_rxbufs, // Rx buffer space >>>>>>>>> dp83816_eth1_rxbd, // Rx buffer headers >>>>>>>>> CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM, // Number of Tx buffers >>>>>>>>> dp83816_eth1_txbufs, // Tx buffer space >>>>>>>>> dp83816_eth1_txbd, // Tx buffer headers >>>>>>>>> }; >>>>>>>>> >>>>>>>>> ETH_DRV_SC(dp83816_sc1, >>>>>>>>> &dp83816_eth1_priv_data, // Driver specific data >>>>>>>>> "eth1", >>>>>>>>> dp83816_start, >>>>>>>>> dp83816_stop, >>>>>>>>> dp83816_control, >>>>>>>>> dp83816_can_send, >>>>>>>>> dp83816_send, >>>>>>>>> dp83816_recv, >>>>>>>>> dp83816_deliver, // "pseudoDSR" called from fast net thread >>>>>>>>> dp83816_poll, // poll function, encapsulates ISR and DSR >>>>>>>>> dp83816_int_vector); >>>>>>>>> >>>>>>>>> NETDEVTAB_ENTRY(dp83816_netdev1, >>>>>>>>> "eth1", >>>>>>>>> dp83816_init, >>>>>>>>> &dp83816_sc1); >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2008/1/10, Antoine Zen-Ruffinen <antoine.zen@gmail.com>: >>>>>>>>>> The previous post "[ECOS] Cannot sendto multicast using FreeBSD stack" >>>>>>>>>> put me on the way!! >>>>>>>>>> >>>>>>>>>> No IP packet are send, but ARP is done. But it seem that the stack >>>>>>>>>> doesn't get the ARP reply witch is on the wire. When calling send(), >>>>>>>>>> for the fist calls, send() return > 0, but with errno=2 (No such >>>>>>>>>> entry) then send() return -1 wiht erron=364 (Host is down). Can this >>>>>>>>>> be because I have 2 NIC that share the same interrupt ? >>>>>>>>>> >>>>>>>>>> 2008/1/10, Antoine Zen-Ruffinen <antoine.zen@gmail.com>: >>>>>>>>>>> Sorry for the preceding message that was not send to the list, little >>>>>>>>>>> mistake from me (cliqued "reply" and not "reply to all"). >>>>>>>>>>> >>>>>>>>>>> Yes my application print about DHCP transaction and it is ok. I have >>>>>>>>>>> added some prints in every driver function in order to trace what it >>>>>>>>>>> is doing. The output is interesting : >>>>>>>>>>> 1) The NIC is making interrupts all the time >>>>>>>>>>> 2) The network stack never call the send() function. >>>>>>>>>>> >>>>>>>>>>> Here is the output : >>>>>>>>>>> RedBoot> load -m tftp -h 192.168.165.18 debugProg >>>>>>>>>>> Entry point: 0x00200000, address range: 0x00200000-0x00238840 >>>>>>>>>>> RedBoot> go >>>>>>>>>>> [cyg_net_init] Init: mbinit(0x00000000) >>>>>>>>>>> [cyg_net_init] Init: cyg_net_init_devs(0x00000000) >>>>>>>>>>> Init device 'eth0' >>>>>>>>>>> DP83816 at 0x0000e100, interrupt: 2a >>>>>>>>>>> DP83816 - get ESA from EEPROM >>>>>>>>>>> DP83816 - ESA: 00:00:24:c8:1d:6c >>>>>>>>>>> Init device 'eth1' >>>>>>>>>>> DP83816 at 0x0000e200, interrupt: 2a >>>>>>>>>>> DP83816 - get ESA from EEPROM >>>>>>>>>>> DP83816 - ESA: 00:00:24:c8:1d:6d >>>>>>>>>>> [cyg_net_init] Init: loopattach(0x00000000) >>>>>>>>>>> [cyg_net_init] Init: ifinit(0x00000000) >>>>>>>>>>> [cyg_net_init] Init: domaininit(0x00000000) >>>>>>>>>>> [cyg_net_init] Init: cyg_net_add_domain(0x00238000) >>>>>>>>>>> New domain internet at 0x00000000 >>>>>>>>>>> [cyg_net_init] Init: cyg_net_add_domain(0x002378e0) >>>>>>>>>>> New domain route at 0x00000000 >>>>>>>>>>> [cyg_net_init] Init: call_route_init(0x00000000) >>>>>>>>>>> [cyg_net_init] Done >>>>>>>>>>> Network testing program V2 >>>>>>>>>>> Thread started >>>>>>>>>>> Init network : DP83816 - ISR on eth0 >>>>>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode >>>>>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode >>>>>>>>>>> DP83816 - can_send on eth0 : 16 >>>>>>>>>>> DP83816 - send on eth0 >>>>>>>>>>> DP83816 - can_send on eth0 : 15 >>>>>>>>>>> DP83816 - deliver on eth0 >>>>>>>>>>> DP83816 - pool on eth0 >>>>>>>>>>> DP83816 - Tx Event on eth0 >>>>>>>>>>> DP83816 - Rx event on eth0 >>>>>>>>>>> DP83816 - recv on eth0 >>>>>>>>>>> DP83816 - recv on eth0 >>>>>>>>>>> DP83816 - can_send on eth0 : 16 >>>>>>>>>>> DP83816 - send on eth0 >>>>>>>>>>> DDP83816 - ISR on eth0 >>>>>>>>>>> P83816 - can_send on eth0 : 15 >>>>>>>>>>> DP83816 - deliver on eth0 >>>>>>>>>>> DP83816 - pool on eth0 >>>>>>>>>>> DP83816 - Tx Event on eth0 >>>>>>>>>>> DP83816 - Rx event on eth0 >>>>>>>>>>> DP83816 - recv on eth0 >>>>>>>>>>> BOOTP[eth0] op: REQUEST >>>>>>>>>>> htype: Ethernet >>>>>>>>>>> hlen: 6 >>>>>>>>>>> hops: 0 >>>>>>>>>>> xid: 0xec511d6c >>>>>>>>>>> secs: 0 >>>>>>>>>>> flags: 0x80 >>>>>>>>>>> hw_addr: 00:00:24:c8:1d:6c >>>>>>>>>>> client IP: 0.0.0.0 >>>>>>>>>>> my IP: 192.168.165.254 >>>>>>>>>>> server IP: 192.168.165.1 >>>>>>>>>>> gateway IP: 0.0.0.0 >>>>>>>>>>> file: boots.default >>>>>>>>>>> options: >>>>>>>>>>> DHCP message: 3 REQUEST >>>>>>>>>>> DHCP server id: 192.168.165.1 >>>>>>>>>>> DHCP time 51: 43200 >>>>>>>>>>> DHCP time 58: 21600 >>>>>>>>>>> DHCP time 59: 37800 >>>>>>>>>>> subnet mask: 255.255.255.0 >>>>>>>>>>> gateway: 192.168.165.1 >>>>>>>>>>> domain server: 192.168.165.1 >>>>>>>>>>> domain name: v165.itslabb.bth.se. >>>>>>>>>>> DHCP option: 37/55.9: 54 51 58 59 1 3 6 15 28 >>>>>>>>>>> DHCP option: 39/57.2: 576 >>>>>>>>>>> DHCP requested ip: 192.168.165.254 >>>>>>>>>>> BOOTP[eth1] op: REPLY >>>>>>>>>>> htype: Ethernet >>>>>>>>>>> hlen: 6 >>>>>>>>>>> hops: 0 >>>>>>>>>>> xid: 0x0 >>>>>>>>>>> secs: 0 >>>>>>>>>>> flags: 0x0 >>>>>>>>>>> hw_addr: 00:00:24:c8:1d:6d >>>>>>>>>>> client IP: 10.0.0.10 >>>>>>>>>>> my IP: 10.0.0.10 >>>>>>>>>>> server IP: 0.0.0.0 >>>>>>>>>>> gateway IP: 0.0.0.0 >>>>>>>>>>> options: >>>>>>>>>>> subnet mask: 255.255.255.0 >>>>>>>>>>> IP broadcast: 10.0.0.255 >>>>>>>>>>> gateway: 0.0.0.0 >>>>>>>>>>> DP83816 - ISR on eth0 >>>>>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode >>>>>>>>>>> DP83816 - can_send on eth0 : 16 >>>>>>>>>>> DP83816 - send on eth0 >>>>>>>>>>> DP83816 - can_send on eth0 : 15 >>>>>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode >>>>>>>>>>> DP83816 - can_send on eth0 : 15 >>>>>>>>>>> DP83816 - send on eth0 >>>>>>>>>>> DP83816 - can_send on eth0 : 14 >>>>>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode >>>>>>>>>>> DP83816 - can_send on eth1 : 16 >>>>>>>>>>> DP83816 - send on eth1 >>>>>>>>>>> DP83816 - can_send on eth1 : 15 >>>>>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode >>>>>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode >>>>>>>>>>> DP83816 - can_send on eth1 : 15 >>>>>>>>>>> DP83816 - send on eth1 >>>>>>>>>>> DP83816 - can_send on eth1 : 14 >>>>>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode >>>>>>>>>>> Network initalized ! >>>>>>>>>>> Eth0 is up ! >>>>>>>>>>> Eth1 is up ! >>>>>>>>>>> socket() = 3 >>>>>>>>>>> It seem that everthing is OK. start sending packets. >>>>>>>>>>> A - 0> sendto() = 3 >>>>>>>>>>> B - 0> Waiting for a packet >>>>>>>>>>> DP83816 - deliver on eth0 >>>>>>>>>>> DP83816 - pool on eth0 >>>>>>>>>>> DP83816 - Tx Event on eth0 >>>>>>>>>>> DP83816 - ISR on eth0 >>>>>>>>>>> DP83816 - deliver on eth0 >>>>>>>>>>> DP83816 - pool on eth0 >>>>>>>>>>> DP83816 - ISR on eth0 >>>>>>>>>>> A - 1> sendto() = 3 >>>>>>>>>>> DP83816 - deliver on eth0 >>>>>>>>>>> DP83816 - pool on eth0 >>>>>>>>>>> DP83816 - ISR on eth0 >>>>>>>>>>> DP83816 - deliver on eth0 >>>>>>>>>>> DP83816 - pool on eth0 >>>>>>>>>>> DP83816 - ISR on eth0 >>>>>>>>>>> DP83816 - deliver on eth0 >>>>>>>>>>> DP83816 - pool on eth0 >>>>>>>>>>> DP83816 - ISR on eth0 >>>>>>>>>>> A - 2> sendto() = 3 >>>>>>>>>>> DP83816 - deliver on eth0 >>>>>>>>>>> DP83816 - pool on eth0 >>>>>>>>>>> DP83816 - ISR on eth0 >>>>>>>>>>> DP83816 - deliver on eth0 >>>>>>>>>>> DP83816 - pool on eth0 >>>>>>>>>>> DP83816 - ISR on eth0 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2008/1/10, Gary Thomas <gary@mlbassoc.com>: >>>>>>>>>>>> Please keep your replies on the eCos list! >>>>>>>>>>>> >>>>>>>>>>>> **EVERYONE** please get this straight. Replies made by me on the >>>>>>>>>>>> eCos discussion list must be followed up on the eCos discussion list >>>>>>>>>>>> unless I invite private replies. This way everyone benefits, not >>>>>>>>>>>> just the interested party. Private email support consultation and >>>>>>>>>>>> support is available, but only with a contract. >>>>>>>>>>>> >>>>>>>>>>>> Antoine Zen-Ruffinen wrote: >>>>>>>>>>>>> The target platform is an embed PC with NS dp83816 NIC. I've port the >>>>>>>>>>>>> eCos driver my self for the PC platform. >>>>>>>>>>>>> >>>>>>>>>>>>> I configure eCos with the configtool, just using the template I made >>>>>>>>>>>>> and the "net" package. >>>>>>>>>>>>> >>>>>>>>>>>>> No, I didn't run a standard eCos network test program. But I build an >>>>>>>>>>>>> redboot with this configuration. If I type ping -n 1000 -r 1 -h >>>>>>>>>>>>> 192.168.165.18 (is my host PC) everything went fine ! >>>>>>>>>>>> This is only partly relevant - RedBoot uses a completely different >>>>>>>>>>>> network stack than normal eCos applications. Also, RedBoot does >>>>>>>>>>>> not use interrupts, which the eCos stacks rely on. >>>>>>>>>>>> >>>>>>>>>>>>> I know that nothing was send : 1 becose network activity led doesn't >>>>>>>>>>>>> blink, 2 I monitor network with Wireshark (Ethereal). the monitoring >>>>>>>>>>>>> trace show the TFTP exchange and the DHCP init but nothing more. It >>>>>>>>>>>>> look like this : >>>>>>>>>>>>> No. Time Source Destination Protocol Info >>>>>>>>>>>>> 69504 25.515675 192.168.165.18 192.168.165.253 TFTP >>>>>>>>>>>>> Data Packet, Block: 452 >>>>>>>>>>>>> 69505 25.516279 192.168.165.253 192.168.165.18 TFTP >>>>>>>>>>>>> Acknowledgement, Block: 452 >>>>>>>>>>>>> 69506 25.516289 192.168.165.18 192.168.165.253 TFTP >>>>>>>>>>>>> Data Packet, Block: 453 >>>>>>>>>>>>> 69507 25.516662 192.168.165.253 192.168.165.18 TFTP >>>>>>>>>>>>> Error Code, Code: Not defined, Message: redboot >>>>>>>>>>>>> tftp_stream_terminate >>>>>>>>>>>>> 69508 25.826093 0.0.0.0 255.255.255.255 DHCP >>>>>>>>>>>>> DHCP Discover - Transaction ID 0x6c1dfce9 >>>>>>>>>>>>> 69511 26.074789 0.0.0.0 255.255.255.255 DHCP >>>>>>>>>>>>> DHCP Discover - Transaction ID 0x6c1dfce9 >>>>>>>>>>>>> 69512 26.304739 0.0.0.0 255.255.255.255 DHCP >>>>>>>>>>>>> DHCP Discover - Transaction ID 0x6c1dfce9 >>>>>>>>>>>>> 69514 26.451407 0.0.0.0 255.255.255.255 DHCP >>>>>>>>>>>>> DHCP Request - Transaction ID 0x6c1dfde9 >>>>>>>>>>>>> 69516 26.839890 Olicom_c8:1d:6c Broadcast ARP >>>>>>>>>>>>> Who has 192.168.165.254? Gratuitous ARP >>>>>>>>>>>>> >>>>>>>>>>>> Did your eCos application print anything about the DHCP transaction? >>>>>>>>>>>> I'm betting that it did not (which would imply you are having trouble >>>>>>>>>>>> with receive interrupts from your driver) >>>>>>>>>>>> >>>>>>>>>>>>> 2008/1/10, Gary Thomas <gary@mlbassoc.com>: >>>>>>>>>>>>>> Antoine Zen-Ruffinen wrote: >>>>>>>>>>>>>>> Hi List folks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I've a problem with the TCP/IP stack: >>>>>>>>>>>>>>> - I use TFTP to load my program in redboot. That work fine. >>>>>>>>>>>>>>> - My application start, call init_all_network_interfaces(), it do the >>>>>>>>>>>>>>> DHCP stuff. That work fine. >>>>>>>>>>>>>>> - Then I open a socket and try to send / receive data. No packet is even send. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Does someone has already seen such problem ? >>>>>>>>>>>>>>> Any idea ? >>>>>>>>>>>>>> We'll need more data than this in order to help. >>>>>>>>>>>>>> * What's the target platform? >>>>>>>>>>>>>> * How did you configure eCos for your failing application? >>>>>>>>>>>>>> * Have you run any of the standard eCos network test programs? >>>>>>>>>>>>>> * How do you know nothing was sent? What sort of debugging >>>>>>>>>>>>>> have you tried so far? -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 20+ messages in thread
* [ECOS] Problem with TCP/IP Stack @ 2002-07-18 22:44 Your Name 0 siblings, 0 replies; 20+ messages in thread From: Your Name @ 2002-07-18 22:44 UTC (permalink / raw) To: ecos-discuss Hi All I am facing a peculiar problem with eCos FreeBSD TCP/IP Stack. TCP layer is not responding from Windows Systems. In my application HTTP & Telnet Services are running. When i give either HTTP or Telnet requests from Windows systems, it's not responding, But when i give requests from Linux system, i am getting response after 1 minute. Could any one solve my problem. I missing somewhere, i could not get where i am missing. Regards Shobhan -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss ^ permalink raw reply [flat|nested] 20+ messages in thread
* [ECOS] problem with TCP/IP stack @ 2001-01-26 10:47 Gary Guangyu Pei 2001-01-26 13:46 ` Gary Thomas 0 siblings, 1 reply; 20+ messages in thread From: Gary Guangyu Pei @ 2001-01-26 10:47 UTC (permalink / raw) To: ecos-discuss Hi, I encountered the following problem with TCP/IP stack: It cannot run both UDP server and client together. If I run server only, it can receive UDP packets from the other nodes. However, if I run both client and server, the client can keep on sending out packets, the server will stop receiving packets after it receives the first packet (or sometime the first 2 packets) from a client. I use the gdb to trace the program. I find the received packages travelling along the protocol stack all way up to udp_usrreq.c. After calling the sorwakeup() at line 565, the server thread never gets to run. Does anyone know what might go wrong? Do you have similar experience? The network priority is 7. I tried both 6,7,8 priority for the udp server. Thank you very much, any suggestion is highly appreciated. Gary ^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: [ECOS] problem with TCP/IP stack 2001-01-26 10:47 [ECOS] problem with TCP/IP stack Gary Guangyu Pei @ 2001-01-26 13:46 ` Gary Thomas 2001-01-26 16:39 ` Gary Guangyu Pei 0 siblings, 1 reply; 20+ messages in thread From: Gary Thomas @ 2001-01-26 13:46 UTC (permalink / raw) To: Gary Guangyu Pei; +Cc: ecos-discuss Are you trying to run one of our test/demo programs? If not, I'm not sure I understand your "UDP server" terminology. On 26-Jan-2001 Gary Guangyu Pei wrote: > Hi, > I encountered the following problem with TCP/IP stack: > It cannot run both UDP server and client together. If I run server only, > it can receive UDP packets from the other nodes. However, if I run both > client and server, the client can keep on sending out packets, the server > will stop receiving packets after it receives the first packet (or > sometime the first 2 packets) from a client. I use the gdb to trace the > program. I find the received packages travelling along the protocol stack > all way up to udp_usrreq.c. After calling the sorwakeup() at line 565, the > server thread never gets to run. > > Does anyone know what might go wrong? Do you have similar experience? > > The network priority is 7. I tried both 6,7,8 priority for the udp server. > > Thank you very much, any suggestion is highly appreciated. > > Gary > ^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: [ECOS] problem with TCP/IP stack 2001-01-26 13:46 ` Gary Thomas @ 2001-01-26 16:39 ` Gary Guangyu Pei 0 siblings, 0 replies; 20+ messages in thread From: Gary Guangyu Pei @ 2001-01-26 16:39 UTC (permalink / raw) To: Gary Thomas; +Cc: ecos-discuss Yes, you are right. I modified one of the test program: udp_lo_test.c program. Instead of using a loopback address, I use the real IP address. Thank you, Gary On Fri, 26 Jan 2001, Gary Thomas wrote: |Are you trying to run one of our test/demo programs? If not, I'm not |sure I understand your "UDP server" terminology. | |On 26-Jan-2001 Gary Guangyu Pei wrote: |> Hi, |> I encountered the following problem with TCP/IP stack: |> It cannot run both UDP server and client together. If I run server only, |> it can receive UDP packets from the other nodes. However, if I run both |> client and server, the client can keep on sending out packets, the server |> will stop receiving packets after it receives the first packet (or |> sometime the first 2 packets) from a client. I use the gdb to trace the |> program. I find the received packages travelling along the protocol stack |> all way up to udp_usrreq.c. After calling the sorwakeup() at line 565, the |> server thread never gets to run. |> |> Does anyone know what might go wrong? Do you have similar experience? |> |> The network priority is 7. I tried both 6,7,8 priority for the udp server. |> |> Thank you very much, any suggestion is highly appreciated. |> |> Gary |> | ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2008-01-11 16:46 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-01-10 13:09 [ECOS] Problem with TCP/IP stack Antoine Zen-Ruffinen
2008-01-10 13:18 ` Gary Thomas
[not found] ` <2cbbd8de0801100544j62d5b5ecl75969aaec1da5122@mail.gmail.com>
2008-01-10 13:55 ` Gary Thomas
2008-01-10 14:15 ` Antoine Zen-Ruffinen
2008-01-10 15:32 ` Antoine Zen-Ruffinen
2008-01-11 8:48 ` Antoine Zen-Ruffinen
2008-01-11 12:38 ` Antoine Zen-Ruffinen
2008-01-11 12:47 ` Gary Thomas
2008-01-11 12:52 ` Andrew Lunn
2008-01-11 15:43 ` Antoine Zen-Ruffinen
2008-01-11 15:59 ` Gary Thomas
2008-01-11 16:08 ` Antoine Zen-Ruffinen
2008-01-11 16:29 ` Gary Thomas
2008-01-11 16:38 ` Antoine Zen-Ruffinen
2008-01-11 16:39 ` Antoine Zen-Ruffinen
2008-01-11 16:46 ` Gary Thomas
-- strict thread matches above, loose matches on Subject: below --
2002-07-18 22:44 [ECOS] Problem with TCP/IP Stack Your Name
2001-01-26 10:47 [ECOS] problem with TCP/IP stack Gary Guangyu Pei
2001-01-26 13:46 ` Gary Thomas
2001-01-26 16:39 ` Gary Guangyu Pei
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).