From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14848 invoked by alias); 11 Jan 2008 15:59:18 -0000 Received: (qmail 14833 invoked by uid 22791); 11 Jan 2008 15:59:15 -0000 X-Spam-Check-By: sourceware.org Received: from 204-133-123-27.dia.static.slbbi.com (HELO mail.chez-thomas.org) (204.133.123.27) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 11 Jan 2008 15:58:55 +0000 Received: by mail.chez-thomas.org (Postfix, from userid 999) id 298801950125; Fri, 11 Jan 2008 08:58:54 -0700 (MST) Received: from hermes.chez-thomas.org (hermes_local [192.168.1.101]) by mail.chez-thomas.org (Postfix) with ESMTP id 32B2A19500E6; Fri, 11 Jan 2008 08:58:42 -0700 (MST) Message-ID: <47879231.7020205@mlbassoc.com> Date: Fri, 11 Jan 2008 15:59:00 -0000 From: Gary Thomas User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Antoine Zen-Ruffinen CC: eCos Discussion References: <2cbbd8de0801100509x43959b34ka8e8e6f35dd081e5@mail.gmail.com> <47861B06.30303@mlbassoc.com> <2cbbd8de0801100544j62d5b5ecl75969aaec1da5122@mail.gmail.com> <478623CE.9030406@mlbassoc.com> <2cbbd8de0801100615t7ddec856h752b60c4c747e401@mail.gmail.com> <2cbbd8de0801100732s602930faj583502f8caf2633d@mail.gmail.com> <2cbbd8de0801110047i49478a2fy705443f4505fcd14@mail.gmail.com> <2cbbd8de0801110438ld37c75bpea97698811a5bc5d@mail.gmail.com> <47876536.8070800@mlbassoc.com> <2cbbd8de0801110743q567448d7l872973b5921a2a4@mail.gmail.com> In-Reply-To: <2cbbd8de0801110743q567448d7l872973b5921a2a4@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] Problem with TCP/IP stack X-SW-Source: 2008-01/txt/msg00065.txt.bz2 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 : >> 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 : >>>> 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 >>>> #include >>>> >>>> >>>> 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 : >>>>> 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 : >>>>>> 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 : >>>>>>> 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 : >>>>>>>>> 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