This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problem with TCP/IP stack


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]