This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: PCI Ethernet card (DHCP issue)
- From: Eric Doenges <Eric dot Doenges at DynaPel dot com>
- To: Michael Anburaj <embeddedeng at hotmail dot com>
- Cc: ecos-discuss at sources dot redhat dot com
- Date: Wed, 17 Sep 2003 15:26:07 +0200
- Subject: Re: [ECOS] PCI Ethernet card (DHCP issue)
- References: <Law15-F81z5ndSu9Zsl000183e8@hotmail.com>
Michael Anburaj wrote:
[ ... ]
This got me confused. It looked like the host was not responding for
some reason. But, actually the MIPS board was dropping packets, because
of the PCI INT vector setting. The above ethereal info does not make
sense to me.
I feel it must have been like this,
From MIPS board: DHCP discover
From RH9 host: DHCP Offer <dropped by MIPS board due to INT vector
issue>
From MIPS board: DHCP discover
From RH9 host: DHCP Offer <dropped by MIPS board due to INT vector
issue>
From MIPS board: DHCP discover
From RH9 host: DHCP Offer <dropped by MIPS board due to INT vector
issue>
From MIPS board: DHCP discover
From RH9 host: DHCP Offer <dropped by MIPS board due to INT vector
issue>
Did ethereal mislead me with wrong info.? or did I interpret it wrongly?
What may have happened is that not only did the MIPS board drop received
packets, it also didn't get the transmission complete interrupts -
depending on how the generic ethernet interface is implemented, this may
have triggered a timeout causing the packet to be resent (since the
driver thought something went wrong sending the packet). If this timeout
(assuming it exists) is shorter than the time it takes your DHCP server
to reply to a request, what you saw is understandable (the MIPS board
stopped sending after the fourth paket because the 8139 can only have
four packets pending transmission at any one time).
[ Obligatory disclaimer: the above is almost 100% pure speculation,
since I haven't looked at the sourcecode in question ]
2. The PCI interrupts seems to be mapped in the following manner <My
assumption>:
PCI device number Interrupt controller PIN
0,4,8... INTC
1,5,9... INTD
2,6,10... INTA
3,7,11... INTB
Is this right? Let me know how to know this & is there any material
regarding this?
AFAIK, the PCI specs do not make any assumptions on how PCI interrupts
are mapped to 'real' interrupts; this is left to the vendor's
discretion (and should be documented by the vendor).
3. If I need to send a atlas hal patch, let me know how to generate
change list. Please point me to a document for the same.
I've found that 'cvs diff -u -5 -b' in the topmost directory containing
changes seems to raise no disapproving eyebrows amongst the maintainers.
(And don't forget, no matter how trivial the change, to write a
ChangeLog entry -- not doing this _does_ earn dissapproval =8^)
--
--------------------------------------------------------------------
| Eric Doenges | DynaPel Laboratories GmbH |
| Tel: +49 89 962428 23 | Fraunhoferstrasse 9/2 |
| Fax: +49 89 962428 90 | D - 85737 Ismaning, Germany |
--------------------------------------------------------------------
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss