[ECOS] Problem with TCP/IP stack
Gary Thomas
gary@mlbassoc.com
Fri Jan 11 16:29:00 GMT 2008
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
More information about the Ecos-discuss
mailing list