* [ECOS] EB40LS ping_test problem
@ 2003-09-17 9:18 RandyLin
2003-09-17 9:43 ` Andrew Lunn
0 siblings, 1 reply; 7+ messages in thread
From: RandyLin @ 2003-09-17 9:18 UTC (permalink / raw)
To: ecos-discuss
In my last post "EB40LS ethernet card problem"
I found the problem:) thanks Andrew...
I didn't enable the EBI_CSR3,
so any access to this memory block(0x4000000) cause hang(using redboot
command "dump").
In the ping_test, the initialize is not complete, and I got the
ff:ff:ff:ff:ff:ff mac address.
after initialize the EBI_CSR3, things going better...
I load ping_test to EB40LS again.
I got the following messages:
=====================================
(gdb) load
Loading section .rom_vectors, size 0x40 lma 0x20a0000
Loading section .text, size 0x3b0b8 lma 0x20a0040
Loading section .rodata, size 0x2848 lma 0x20db0f8
Loading section .data, size 0x1188 lma 0x20dd940
Start address 0x20a0040, load size 256712
Transfer rate: 27022 bits/sec, 302 bytes/write.
(gdb) cont
Continuing.
[cyg_net_init] Init: mbinit(0x00000000)
[cyg_net_init] Init: cyg_net_init_devs(0x00000000)
Init device 'cs8900a_eth0'
CS8900A[0x04000000] - type: 0x630e, rev: 0x0900
CS8900 - status: 0x08d6 (no EEPROM present)
ESA 08:88:12:34:56:78
[cyg_net_init] Init: loopattach(0x00000000)
[cyg_net_init] Init: ifinit(0x00000000)
IFP: 0x020ddab4, next: 0x0212b900
IFP: 0x0212b900, next: 0x00000000
[cyg_net_init] Init: domaininit(0x00000000)
[cyg_net_init] Init: cyg_net_add_domain(0x020de538)
New domain internet at 0x00000000
[cyg_net_init] Init: cyg_net_add_domain(0x020ddf8c)
New domain route at 0x00000000
[cyg_net_init] Init: cyg_route_init(0x00000000)
[cyg_net_init] Done
Start PING test
[eth_drv_ioctl]:SIOCGIFHWADDR
BOOTP[eth0] op: REPLY
htype: Ethernet
hlen: 6
hops: 0
xid: 0x0
secs: 0
flags: 0x0
hw_addr: 08:88:12:34:56:78
client IP: 192.9.207.130
my IP: 192.9.207.130
server IP: 192.9.207.120
gateway IP: 192.9.207.254
options:
subnet mask: 255.255.255.0
IP broadcast: 192.9.207.255
gateway: 192.9.207.254
PING server 192.9.207.120
recvfrom: Operation timed out
recvfrom: Operation timed out
recvfrom: Operation timed out
recvfrom: Operation timed out
recvfrom: Operation timed out
recvfrom: Operation timed out
sendto: Host is down
sendto: Host is down
sendto: Host is down
sendto: Host is down
sendto: Host is down
sendto: Host is down
sendto: Host is down
sendto: Host is down
sendto: Host is down
sendto: Host is down
Sent 16 packets, received 0 OK, 0 bad
==================================================
I use ethernal to capture the packets.
EB40LS first send ARP packet, and Linux reply.
But EB40LS seems don't receive the reply packets, it resend the ARP
packets.
Where may be the problem??
Thanks!
--
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] 7+ messages in thread
* Re: [ECOS] EB40LS ping_test problem
2003-09-17 9:18 [ECOS] EB40LS ping_test problem RandyLin
@ 2003-09-17 9:43 ` Andrew Lunn
0 siblings, 0 replies; 7+ messages in thread
From: Andrew Lunn @ 2003-09-17 9:43 UTC (permalink / raw)
To: RandyLin; +Cc: ecos-discuss
> I use ethernal to capture the packets.
> EB40LS first send ARP packet, and Linux reply.
> But EB40LS seems don't receive the reply packets, it resend the ARP
> packets.
> Where may be the problem??
Probably the receive part of the driver. Check to see if you are
getting interrupts when it receives a packet. Then check what actually
happens during the receive.
Andrew
--
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] 7+ messages in thread
* Re: [ECOS] EB40LS ping_test problem
@ 2003-09-24 10:03 RandyLin
0 siblings, 0 replies; 7+ messages in thread
From: RandyLin @ 2003-09-24 10:03 UTC (permalink / raw)
To: ecos-discuss
Yes, u are right!
The clocktruth is ok, but tm_basic is not.
I enable ASSERT, and got the message:
================================================================
Init device 'cs8900a_eth0'
ASSERT FAIL: <1>at91_misc.c[243]hal_interrupt_set_level() Invalid level
================================================================
I found the code in if_cs8900a.c:
cyg_drv_interrupt_create(cpd->interrupt,
0, // Priority - what goes here? <== ???
(cyg_addrword_t)cpd, // Data item passed to
interrupt handler
(cyg_ISR_t *)cs8900a_isr,
(cyg_DSR_t *)cs8900a_dsr,
&cpd->interrupt_handle,
&cpd->interrupt_object);
cyg_drv_interrupt_attach(cpd->interrupt_handle);
Is this a bug? hal_interrupt_set_level accept level between 1~7
after change the priority, run tm_basic:
=================================================================
Confidence
Ave Min Max Var Ave Min Function
====== ====== ====== ====== ========== ========
445.88 397.46 708.01 28.58 65% 35% Create thread
65.37 64.45 65.43 0.11 93% 6% Yield thread [all suspended]
53.77 53.71 54.69 0.11 93% 93% Suspend [suspended] thread
54.93 54.69 55.66 0.37 75% 75% Resume thread
61.77 61.52 62.50 0.37 75% 75% Set priority
1.95 1.95 1.95 0.00 100% 100% Get priority
110.35 110.35 110.35 0.00 100% 100% Kill [suspended] thread
65.37 64.45 65.43 0.11 93% 6% Yield [no other] thread
73.23 72.27 73.24 0.03 98% 1% Resume [suspended low prio]
thread
54.87 54.69 55.66 0.30 81% 81% Resume [runnable low prio]
thread
71.75 69.34 72.27 0.52 48% 1% Suspend [runnable] thread
65.37 64.45 65.43 0.11 93% 6% Yield [only low prio] thread
53.77 53.71 54.69 0.11 93% 93% Suspend [runnable->not
runnable]
110.35 110.35 110.35 0.00 100% 100% Kill [runnable] thread
69.34 69.34 69.34 0.00 100% 100% Destroy [dead] thread
166.99 161.13 429.69 8.21 98% 98% Destroy [runnable] thread
281.83 276.37 545.90 9.73 96% 96% Resume [high priority] thread
hangs here....?
I think it block at cyg_semaphore_wait(&synchro) in run_thread_switch_test
();
I am still tracing.
> It's seems that arpintr is not scheduled.
> I think this is the problem, but I don't know why?
> BTW, I change the priority to 3 in pint_test.c cyg_thread_creat()
> because program hangs if priority >=7.
It should like something more fundamental is wrong. Maybe you clock is
not working. Try running the test program clocktruth and tm_basic. See
if they work correctly.
Andrew
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
--
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] 7+ messages in thread
* Re: [ECOS] EB40LS ping_test problem
2003-09-22 7:12 RandyLin
@ 2003-09-22 9:27 ` Andrew Lunn
0 siblings, 0 replies; 7+ messages in thread
From: Andrew Lunn @ 2003-09-22 9:27 UTC (permalink / raw)
To: RandyLin; +Cc: ecos-discuss
> It's seems that arpintr is not scheduled.
> I think this is the problem, but I don't know why?
> BTW, I change the priority to 3 in pint_test.c cyg_thread_creat()
> because program hangs if priority >=7.
It should like something more fundamental is wrong. Maybe you clock is
not working. Try running the test program clocktruth and tm_basic. See
if they work correctly.
Andrew
--
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] 7+ messages in thread
* Re: [ECOS] EB40LS ping_test problem
@ 2003-09-22 7:12 RandyLin
2003-09-22 9:27 ` Andrew Lunn
0 siblings, 1 reply; 7+ messages in thread
From: RandyLin @ 2003-09-22 7:12 UTC (permalink / raw)
To: ecos-discuss
Yes! I got interrupt.
I trace the code, in
~/packages/net/bsd_tcpip/v2_0/src/sys/net/if_ethersubr.c
ether_demux():
===============================
case ETHERTYPE_ARP:
if (ifp->if_flags & IFF_NOARP) {
/* Discard packet if ARP is disabled on interface */
m_freem(m);
return;
}
schednetisr(NETISR_ARP);
inq = &arpintrq;
break;
================================
after the schednetisr(NETISR_ARP);
arpintr should be scheduled to run, and I set breakpoint there.
It's seems that arpintr is not scheduled.
I think this is the problem, but I don't know why?
BTW, I change the priority to 3 in pint_test.c cyg_thread_creat()
because program hangs if priority >=7.
Andrew Lunn
<andrew@lunn.ch> 收件人： RandyLin@mxic.com.tw
寄件人： 副本抄送： ecos-discuss@sources.redhat.com
ecos-discuss-owner@sources 主旨： Re: [ECOS] EB40LS ping_test problem
.redhat.com
2003/09/21 04:52 AM
> > I use ethernal to capture the packets.
> > EB40LS first send ARP packet, and Linux reply.
> > But EB40LS seems don't receive the reply packets, it resend the ARP
> > packets.
> > Where may be the problem??
>
> Probably the receive part of the driver. Check to see if you are
> getting interrupts when it receives a packet. Then check what actually
> happens during the receive.
>
> Andrew
>
> I enable the The CYGDBG_IO_ETH_DRIVERS_DEBUG,and set
> CYGDBG_IO_ETH_DRIVERS_DEBUG_VERBOSITY=2,
> I got the following message:
> Q1: In the first two packets, why it sends arp to 192.9.207.130?
> The target is 192.9.207.130!
Its testing to see if there is another device using the IP address it
want to use. If there is another device, it will reply to the arp.
> Q2: Sending bytes is 42, who will do the padding to 60?
> Because Linux got 60 bytes of arp.
The hardware. Ethernet packets must be at least 64 bytes in size,
including the CRC. Modern hardware will automatically pad the packet
as its sent, unless padding has been disabled.
> Q3: EB40LS got arp reply, but it don't send the icmp(ping),
> it's just sending the arp out.
Back to my original question. Are you getting interrupts? Have you
checked what happens to the ARP reply? Is it dropped? Is an entry
added to the table? You need to do some real, hands on debugging
yourself.
Andrew
> =======================================================
> hw_addr: 08:88:12:34:56:78
> client IP: 192.9.207.130
> my IP: 192.9.207.130
> server IP: 192.9.207.120
> gateway IP: 192.9.207.254
> options:
> subnet mask: 255.255.255.0
> IP broadcast: 192.9.207.255
> gateway: 192.9.207.254
> Sending 42 bytes
> xmit 42 bytes at 20f8c56 sg[1]
> 020F8C56: FF FF FF FF FF FF 08 88 12 34 56 78 08 06 00 01
> |.........4Vx....|
> 020F8C66: 08 00 06 04 00 01 08 88 12 34 56 78 C0 09 CF 82
> |.........4Vx....|
> 020F8C76: 00 00 00 00 00 00 C0 09 CF 82 |..........
> |
> Sending 42 bytes
> xmit 42 bytes at 20f8bd6 sg[1]
> 020F8BD6: FF FF FF FF FF FF 08 88 12 34 56 78 08 06 00 01
> |.........4Vx....|
> 020F8BE6: 08 00 06 04 00 01 08 88 12 34 56 78 C0 09 CF 82
> |.........4Vx....|
> 020F8BF6: 00 00 00 00 00 00 C0 09 CF 82 |..........
> |
> PING server 192.9.207.120
> Sending 42 bytes
> xmit 42 bytes at 20f8a56 sg[1]
> 020F8A56: FF FF FF FF FF FF 08 88 12 34 56 78 08 06 00 01
> |.........4Vx....|
> 020F8A66: 08 00 06 04 00 01 08 88 12 34 56 78 C0 09 CF 82
> |.........4Vx....|
> 020F8A76: 00 00 00 00 00 00 C0 09 CF 78 |.........x
> |
> RxEvent - stat: 504, len: 60
> rx 14 bytes at 2128f74 sg[0]
> 02128F74: 08 88 12 34 56 78 00 50 BF 43 DD AC 08 06
|...4Vx.P.C....
> |
> rx 46 bytes at 20f89ac sg[1]
> 020F89AC: 00 01 08 00 06 04 00 02 00 50 BF 43 DD AC C0 09
> |.........P.C....|
> 020F89BC: CF 78 08 88 12 34 56 78 C0 09 CF 82 11 0A 11 75
> |.x...4Vx.......u|
> 020F89CC: C0 09 CF 78 00 8A 00 C3 00 00 20 46 43 45 |...x......
FCE
> |
> Tx event: 8
> recvfrom: Operation timed out
> --
> Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> and search the list archive: http://sources.redhat.com/ml/ecos-discuss
>
>
>
>
--
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] 7+ messages in thread
* Re: [ECOS] EB40LS ping_test problem
2003-09-19 1:57 RandyLin
@ 2003-09-20 20:52 ` Andrew Lunn
0 siblings, 0 replies; 7+ messages in thread
From: Andrew Lunn @ 2003-09-20 20:52 UTC (permalink / raw)
To: RandyLin; +Cc: ecos-discuss
> > I use ethernal to capture the packets.
> > EB40LS first send ARP packet, and Linux reply.
> > But EB40LS seems don't receive the reply packets, it resend the ARP
> > packets.
> > Where may be the problem??
>
> Probably the receive part of the driver. Check to see if you are
> getting interrupts when it receives a packet. Then check what actually
> happens during the receive.
>
> Andrew
>
> I enable the The CYGDBG_IO_ETH_DRIVERS_DEBUG,and set
> CYGDBG_IO_ETH_DRIVERS_DEBUG_VERBOSITY=2,
> I got the following message:
> Q1: In the first two packets, why it sends arp to 192.9.207.130?
> The target is 192.9.207.130!
Its testing to see if there is another device using the IP address it
want to use. If there is another device, it will reply to the arp.
> Q2: Sending bytes is 42, who will do the padding to 60?
> Because Linux got 60 bytes of arp.
The hardware. Ethernet packets must be at least 64 bytes in size,
including the CRC. Modern hardware will automatically pad the packet
as its sent, unless padding has been disabled.
> Q3: EB40LS got arp reply, but it don't send the icmp(ping),
> it's just sending the arp out.
Back to my original question. Are you getting interrupts? Have you
checked what happens to the ARP reply? Is it dropped? Is an entry
added to the table? You need to do some real, hands on debugging
yourself.
Andrew
> =======================================================
> hw_addr: 08:88:12:34:56:78
> client IP: 192.9.207.130
> my IP: 192.9.207.130
> server IP: 192.9.207.120
> gateway IP: 192.9.207.254
> options:
> subnet mask: 255.255.255.0
> IP broadcast: 192.9.207.255
> gateway: 192.9.207.254
> Sending 42 bytes
> xmit 42 bytes at 20f8c56 sg[1]
> 020F8C56: FF FF FF FF FF FF 08 88 12 34 56 78 08 06 00 01
> |.........4Vx....|
> 020F8C66: 08 00 06 04 00 01 08 88 12 34 56 78 C0 09 CF 82
> |.........4Vx....|
> 020F8C76: 00 00 00 00 00 00 C0 09 CF 82 |..........
> |
> Sending 42 bytes
> xmit 42 bytes at 20f8bd6 sg[1]
> 020F8BD6: FF FF FF FF FF FF 08 88 12 34 56 78 08 06 00 01
> |.........4Vx....|
> 020F8BE6: 08 00 06 04 00 01 08 88 12 34 56 78 C0 09 CF 82
> |.........4Vx....|
> 020F8BF6: 00 00 00 00 00 00 C0 09 CF 82 |..........
> |
> PING server 192.9.207.120
> Sending 42 bytes
> xmit 42 bytes at 20f8a56 sg[1]
> 020F8A56: FF FF FF FF FF FF 08 88 12 34 56 78 08 06 00 01
> |.........4Vx....|
> 020F8A66: 08 00 06 04 00 01 08 88 12 34 56 78 C0 09 CF 82
> |.........4Vx....|
> 020F8A76: 00 00 00 00 00 00 C0 09 CF 78 |.........x
> |
> RxEvent - stat: 504, len: 60
> rx 14 bytes at 2128f74 sg[0]
> 02128F74: 08 88 12 34 56 78 00 50 BF 43 DD AC 08 06 |...4Vx.P.C....
> |
> rx 46 bytes at 20f89ac sg[1]
> 020F89AC: 00 01 08 00 06 04 00 02 00 50 BF 43 DD AC C0 09
> |.........P.C....|
> 020F89BC: CF 78 08 88 12 34 56 78 C0 09 CF 82 11 0A 11 75
> |.x...4Vx.......u|
> 020F89CC: C0 09 CF 78 00 8A 00 C3 00 00 20 46 43 45 |...x...... FCE
> |
> Tx event: 8
> recvfrom: Operation timed out
> --
> Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> and search the list archive: http://sources.redhat.com/ml/ecos-discuss
>
>
>
>
--
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] 7+ messages in thread
* Re: [ECOS] EB40LS ping_test problem
@ 2003-09-19 1:57 RandyLin
2003-09-20 20:52 ` Andrew Lunn
0 siblings, 1 reply; 7+ messages in thread
From: RandyLin @ 2003-09-19 1:57 UTC (permalink / raw)
To: ecos-discuss
Andrew Lunn
<andrew@lunn.ch> 收件人： RandyLin@mxic.com.tw
寄件人： 副本抄送： ecos-discuss@sources.redhat.com
ecos-discuss-owner@sources 主旨： Re: [ECOS] EB40LS ping_test problem
.redhat.com
2003/09/17 05:43 PM
> I use ethernal to capture the packets.
> EB40LS first send ARP packet, and Linux reply.
> But EB40LS seems don't receive the reply packets, it resend the ARP
> packets.
> Where may be the problem??
Probably the receive part of the driver. Check to see if you are
getting interrupts when it receives a packet. Then check what actually
happens during the receive.
Andrew
I enable the The CYGDBG_IO_ETH_DRIVERS_DEBUG,and set
CYGDBG_IO_ETH_DRIVERS_DEBUG_VERBOSITY=2,
I got the following message:
Q1: In the first two packets, why it sends arp to 192.9.207.130?
The target is 192.9.207.130!
Q2: Sending bytes is 42, who will do the padding to 60?
Because Linux got 60 bytes of arp.
Q3: EB40LS got arp reply, but it don't send the icmp(ping),
it's just sending the arp out.
=======================================================
hw_addr: 08:88:12:34:56:78
client IP: 192.9.207.130
my IP: 192.9.207.130
server IP: 192.9.207.120
gateway IP: 192.9.207.254
options:
subnet mask: 255.255.255.0
IP broadcast: 192.9.207.255
gateway: 192.9.207.254
Sending 42 bytes
xmit 42 bytes at 20f8c56 sg[1]
020F8C56: FF FF FF FF FF FF 08 88 12 34 56 78 08 06 00 01
|.........4Vx....|
020F8C66: 08 00 06 04 00 01 08 88 12 34 56 78 C0 09 CF 82
|.........4Vx....|
020F8C76: 00 00 00 00 00 00 C0 09 CF 82 |..........
|
Sending 42 bytes
xmit 42 bytes at 20f8bd6 sg[1]
020F8BD6: FF FF FF FF FF FF 08 88 12 34 56 78 08 06 00 01
|.........4Vx....|
020F8BE6: 08 00 06 04 00 01 08 88 12 34 56 78 C0 09 CF 82
|.........4Vx....|
020F8BF6: 00 00 00 00 00 00 C0 09 CF 82 |..........
|
PING server 192.9.207.120
Sending 42 bytes
xmit 42 bytes at 20f8a56 sg[1]
020F8A56: FF FF FF FF FF FF 08 88 12 34 56 78 08 06 00 01
|.........4Vx....|
020F8A66: 08 00 06 04 00 01 08 88 12 34 56 78 C0 09 CF 82
|.........4Vx....|
020F8A76: 00 00 00 00 00 00 C0 09 CF 78 |.........x
|
RxEvent - stat: 504, len: 60
rx 14 bytes at 2128f74 sg[0]
02128F74: 08 88 12 34 56 78 00 50 BF 43 DD AC 08 06 |...4Vx.P.C....
|
rx 46 bytes at 20f89ac sg[1]
020F89AC: 00 01 08 00 06 04 00 02 00 50 BF 43 DD AC C0 09
|.........P.C....|
020F89BC: CF 78 08 88 12 34 56 78 C0 09 CF 82 11 0A 11 75
|.x...4Vx.......u|
020F89CC: C0 09 CF 78 00 8A 00 C3 00 00 20 46 43 45 |...x...... FCE
|
Tx event: 8
recvfrom: Operation timed out
--
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] 7+ messages in thread
end of thread, other threads:[~2003-09-24 10:03 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-09-17 9:18 [ECOS] EB40LS ping_test problem RandyLin
2003-09-17 9:43 ` Andrew Lunn
2003-09-19 1:57 RandyLin
2003-09-20 20:52 ` Andrew Lunn
2003-09-22 7:12 RandyLin
2003-09-22 9:27 ` Andrew Lunn
2003-09-24 10:03 RandyLin
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).