public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* [ECOS] crash in tftp_client_test.c
@ 2003-04-26 17:38 HG
  2003-04-28  8:06 ` Andrew Lunn
  0 siblings, 1 reply; 4+ messages in thread
From: HG @ 2003-04-26 17:38 UTC (permalink / raw)
  To: ecos-discuss

Hi All,

I found out what was causing the problem in the previously reported problems
with that test program . It might be useful to others on the list that bring
up new boards.

It appears that the interrupts where not set correctly. The
hal_intc_translation_table in variant.inc did not route all the interrupts
correctly (some but not all) . The HAL_PCI_TRANSLATE_INTERRUPT was not
routing the interrupts to the correct vector for that pci chip. The
experimental observations of the problem where confusing.

viewing the interrupt line coming from the pci 82559 is instructive when
viewed with a logic analyser: it goes low when it needs service , the
service routine does its job , the line goes high again . The low period
where the device is waiting is observed to be typically 40 us but can go as
high as 380 usec.

retesting for file sizes of 255k and 1 Meg usually works except in the
following circumstances : when an other computer on the network (an NT
workstation ) issues udp to the broadcast address of computers on the
network the ecos application crashes (see trace below) . This is viewed by
dumps of the udp activity and also by viewing the logic analyser : when the
app hangs , the service request from the 82559 stays low until the board is
reset.

is there any ecos application ,  package ,  enhancement , workaround to
improve the robustness of the tftp program?

thanks

Henri


windump trace :
all seems to go well until the server computer issues udp packets
at the broadcast address on port 138 . the application stops responding



10:16:09.883420 IP 192.168.0.21.7800 > 192.168.0.4.1227: udp 516
10:16:09.884491 IP 192.168.0.4.1227 > 192.168.0.21.7800: udp 4
10:16:09.886550 IP 192.168.0.21.7800 > 192.168.0.4.1227: udp 516
10:16:09.887645 IP 192.168.0.4.1227 > 192.168.0.21.7800: udp 4
10:16:09.889838 IP 192.168.0.21.7800 > 192.168.0.4.1227: udp 516
10:16:09.890887 IP 192.168.0.4.1227 > 192.168.0.21.7800: udp 4
10:16:14.640327 IP 192.168.0.4.138 > 192.168.0.255.138: udp 201
10:16:16.391931 IP 192.168.0.4.1227 > 192.168.0.21.7800: udp 4
10:16:19.166049 IP 192.168.0.4.137 > 192.168.0.21.137: udp 50
10:16:20.667840 IP 192.168.0.4.137 > 192.168.0.21.137: udp 50
10:16:22.169973 IP 192.168.0.4.137 > 192.168.0.21.137: udp 50
10:16:22.891246 IP 192.168.0.4.1227 > 192.168.0.21.7800: udp 4
10:16:29.400633 IP 192.168.0.4.1227 > 192.168.0.21.7800: udp 4


example output for the tftp_client_test (when it does not crash)
RedBoot> go
[cyg_net_init] Init: mbinit(0x00000000)
[cyg_net_init] Init: cyg_net_init_devs(0x00000000)
Init device 'i82559_eth0'
[cyg_net_init] Init: loopattach(0x00000000)
[cyg_net_init] Init: ifinit(0x00000000)
IFP: 0x803475dc, next: 0x804f1f00
IFP: 0x804f1f00, next: 0x00000000
[cyg_net_init] Init: domaininit(0x00000000)
[cyg_net_init] Init: cyg_net_add_domain(0x80347fcc)
New domain internet at 0x00000000
[cyg_net_init] Init: cyg_net_add_domain(0x80347a04)
[cyg_net_init] Init: cyg_net_add_domain(0x80347a04)
[cyg_net_init] Init: cyg_route_init(0x00000000)
[cyg_net_init] Done
Start TFTP test ,
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.168.0.21
         my IP: 192.168.0.21
     server IP: 192.168.0.4
    gateway IP: 192.168.0.4
  options:
        subnet mask: 255.255.255.0
       IP broadcast: 192.168.0.255
            gateway: 192.168.0.4
Trying tftp_get hello.srec      192.168.0.4...
res = 1043008, err = 0
Trying tftp_put tftp_put      192.168.0.4, length 1043008
put - res: 1043008 , err = 0





-- 
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] 4+ messages in thread

* Re: [ECOS] crash in tftp_client_test.c
  2003-04-26 17:38 [ECOS] crash in tftp_client_test.c HG
@ 2003-04-28  8:06 ` Andrew Lunn
  2003-04-28 12:03   ` HG
  0 siblings, 1 reply; 4+ messages in thread
From: Andrew Lunn @ 2003-04-28  8:06 UTC (permalink / raw)
  To: HG; +Cc: ecos-discuss

On Sat, Apr 26, 2003 at 11:04:15AM -0400, HG wrote:
> Hi All,
> 
> I found out what was causing the problem in the previously reported problems
> with that test program . It might be useful to others on the list that bring
> up new boards.
> 
> It appears that the interrupts where not set correctly. The
> hal_intc_translation_table in variant.inc did not route all the interrupts
> correctly (some but not all) . The HAL_PCI_TRANSLATE_INTERRUPT was not
> routing the interrupts to the correct vector for that pci chip. The
> experimental observations of the problem where confusing.

Can you contribute a patch? 

> retesting for file sizes of 255k and 1 Meg usually works except in the
> following circumstances : when an other computer on the network (an NT
> workstation ) issues udp to the broadcast address of computers on the
> network the ecos application crashes (see trace below) . This is viewed by
> dumps of the udp activity and also by viewing the logic analyser : when the
> app hangs , the service request from the 82559 stays low until the board is
> reset.
> 
> is there any ecos application ,  package ,  enhancement , workaround to
> improve the robustness of the tftp program?

Its not the tftp program thats at fault. Its probably your HAL or the
ethernet device driver. You need to debug this further to see what is
going on. It's is not a problem anyone else has seen before, so there
is no package, enhancement, workaround etc.....

How old is the redboot on your device? A year ago there was a problem
with NTP Broadcast's killing redboot, but i expect you have a more
recent version.

I would try reproducing the problem with a low bandwidth test, eg
pings. Once you can get the system crashing with this, then put some
breakpoints in which are called when broadcast packets are received
and then trace it through to see why it crashes.

    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] 4+ messages in thread

* Re: [ECOS] crash in tftp_client_test.c
  2003-04-28  8:06 ` Andrew Lunn
@ 2003-04-28 12:03   ` HG
  2003-04-28 12:18     ` Andrew Lunn
  0 siblings, 1 reply; 4+ messages in thread
From: HG @ 2003-04-28 12:03 UTC (permalink / raw)
  To: ecos-discuss


> > It appears that the interrupts where not set correctly. The
> > hal_intc_translation_table in variant.inc did not route all the
interrupts
> > correctly (some but not all) . The HAL_PCI_TRANSLATE_INTERRUPT was not
> > routing the interrupts to the correct vector for that pci chip. The
> > experimental observations of the problem where confusing.
>
> Can you contribute a patch?

No problem , I will contribute the board port once it is tested. The 2 items
changed
are specific to that board and which interrupt was wired to the pci chip.
>


> Its not the tftp program thats at fault. Its probably your HAL or the
> ethernet device driver. You need to debug this further to see what is
> going on. It's is not a problem anyone else has seen before, so there
> is no package, enhancement, workaround etc.....

I would have suspected the stack or the application , the driver should
pass all packets received ?????.

>
> How old is the redboot on your device? A year ago there was a problem
> with NTP Broadcast's killing redboot, but i expect you have a more
> recent version.
yes

>
> I would try reproducing the problem with a low bandwidth test, eg
> pings. Once you can get the system crashing with this, then put some
> breakpoints in which are called when broadcast packets are received
> and then trace it through to see why it crashes.
>
I will try your suggestion

thank you

Henri



-- 
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] 4+ messages in thread

* Re: [ECOS] crash in tftp_client_test.c
  2003-04-28 12:03   ` HG
@ 2003-04-28 12:18     ` Andrew Lunn
  0 siblings, 0 replies; 4+ messages in thread
From: Andrew Lunn @ 2003-04-28 12:18 UTC (permalink / raw)
  To: HG; +Cc: ecos-discuss

> > Its not the tftp program thats at fault. Its probably your HAL or the
> > ethernet device driver. You need to debug this further to see what is
> > going on. It's is not a problem anyone else has seen before, so there
> > is no package, enhancement, workaround etc.....
> 
> I would have suspected the stack or the application , the driver should
> pass all packets received ?????.

The stack and application have been well tested with many different
boards. You HAL is new and so is the board specific parts of the
ethernet driver. Hence i think its more likely to be some of the net
parts that are causing the problem.

      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] 4+ messages in thread

end of thread, other threads:[~2003-04-28 12:16 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-04-26 17:38 [ECOS] crash in tftp_client_test.c HG
2003-04-28  8:06 ` Andrew Lunn
2003-04-28 12:03   ` HG
2003-04-28 12:18     ` Andrew Lunn

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).