Re: [ECOS] PCI Ethernet card (DHCP issue)

Re: [ECOS] PCI Ethernet card (DHCP issue)

[Michael Anburaj]

Hi,

Thanks to Andrew & Eric.

The problem was with the atlas pci definitions.

HAL_PCI_TRANSLATE_INTERRUPT() macro of plf_io.h was not complete. I fixed it 
& the eth interface works fine now. I will send the patch for it soon.


Questions:
1. The ethereal debug info showed the following:
	From MIPS board: DHCP discover
	From MIPS board: DHCP discover
	From MIPS board: DHCP discover
	From MIPS board: DHCP discover
	From RH9 host: DHCP Offer
	From RH9 host: DHCP Offer
	From RH9 host: DHCP Offer
	From RH9 host: DHCP Offer


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?

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?

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.

Thanks a lot & cheers,
-Mike.

_________________________________________________________________
Fast, faster, fastest: Upgrade to Cable or DSL today!   
https://broadband.msn.com


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] PCI Ethernet card (DHCP issue)

[Andrew Lunn]

On Wed, Sep 17, 2003 at 05:52:08AM +0000, Michael Anburaj wrote:
> Hi,
> 
> Thanks to Andrew & Eric.
> 
> The problem was with the atlas pci definitions.
> 
> HAL_PCI_TRANSLATE_INTERRUPT() macro of plf_io.h was not complete. I fixed 
> it & the eth interface works fine now. I will send the patch for it soon.
> 
> 
> Questions:
> 1. The ethereal debug info showed the following:
> 	From MIPS board: DHCP discover
> 	From MIPS board: DHCP discover
> 	From MIPS board: DHCP discover
> 	From MIPS board: DHCP discover
> 	From RH9 host: DHCP Offer
> 	From RH9 host: DHCP Offer
> 	From RH9 host: DHCP Offer
> 	From RH9 host: DHCP Offer
> 
> 
> 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.

It does seem wrong. Are you running Ethereal on the RH9 server or some
other machine? I've know M$ boxes get packets out of order when used
with tcpdump. 

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

Actually, it might not be that simple. Quite often when the ethernet
driver is requested to send something it also checks the receive queue
and processes anything thats waiting. So you can still sometimes
receive when interrupts are broken. If that is happening, the dhcp
client probably drops the received packets because they are too late.

> 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?

I beleave there is a defacto standard, but i've known hardware get it
wrong. You need to look at the documentation for your specific board.

       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

Re: [ECOS] PCI Ethernet card (DHCP issue)

[Eric Doenges]

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

RE: [ECOS] PCI Ethernet card (DHCP issue)

[Andy Dyer]

> From:	ecos-discuss-owner@sources.redhat.com on behalf of Eric Doenges
> Sent:	Wed 9/17/2003 8:26 AM
> To:	Michael Anburaj
> Cc:	ecos-discuss@sources.redhat.com
> Subject:	Re: [ECOS] PCI Ethernet card (DHCP issue)
> Michael Anburaj wrote:
> 
> 
> > 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).

How the PCI interrupts are mapped depends on how the physical slots
are hooked up - both how the IDSEL pins are connected and how the
INT[A-D] signals go.

Since almost all cards only support the INTA signal, IIRC it is
recommended (not required) in the PCI spec that the interrupts be
done like this:

slot #    slot signal    motherboard 
                         signal

1         INTA           INTA
1         INTB           INTB
1         INTC           INTC
1         INTD           INTD

2         INTA           INTB
2         INTB           INTC
2         INTC           INTD
2         INTD           INTA

3         INTA           INTC
3         INTB           INTD
3         INTC           INTA
3         INTD           INTB

4         INTA           INTD
4         INTB           INTA
4         INTC           INTB
4         INTD           INTC

and this repeats for more slots or other on-board
devices using that same PCI bus segment.  This makes
for the minimum amount of interrupt sharing by
spreading the add-in card INTA signals across all
the PCI INT signals.



--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] PCI Ethernet card (DHCP issue)

[Eric Doenges]

Andrew Lunn wrote:
> On Sun, Sep 14, 2003 at 12:53:41AM +0000, Michael Anburaj wrote:
> 
>>Hi,
>>
>>The DHCP protocol was successful with Redboot, but fails with ecos. After 
>>analyzing the packet captures using ethereal, I found some differences in 
>>the "DHCP Discover" packet --> under Bootstrap protocol --> BootP Flags = 
>>0x8000 (in case of ecos) & 0x0000 (in case of redboot).
> 
> 
> Redboot uses BOOTP and normally eCos uses DHCP. This could be the flag
> that differentiates between the two.

I'd just like to add here that ethereal claims this is the 'broadcast'
flag - since I'm no expert on BOOTP/DHCP, I don't know what this means
exactly.

> 
> 
>>In the case of redboot, the DHCP server (RH9 running my dhcpd.conf) 
>>responds with the DHCP offer soon after seeing the DHCP discover packet. 
>>But in case of ecos it responds 4 times after 4 DHCP discover packets.
>>
>>Please suggest me a way to debug this issue.
> 
> 
> Put some breakpoints in do_dhcp. One on each recvfrom will probably
> do. Run the code and see why its dropping the replys.
-- 
--------------------------------------------------------------------
|     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

Re: [ECOS] PCI Ethernet card (DHCP issue)

[Andrew Lunn]

On Sun, Sep 14, 2003 at 12:53:41AM +0000, Michael Anburaj wrote:
> Hi,
> 
> The DHCP protocol was successful with Redboot, but fails with ecos. After 
> analyzing the packet captures using ethereal, I found some differences in 
> the "DHCP Discover" packet --> under Bootstrap protocol --> BootP Flags = 
> 0x8000 (in case of ecos) & 0x0000 (in case of redboot).

Redboot uses BOOTP and normally eCos uses DHCP. This could be the flag
that differentiates between the two.

> In the case of redboot, the DHCP server (RH9 running my dhcpd.conf) 
> responds with the DHCP offer soon after seeing the DHCP discover packet. 
> But in case of ecos it responds 4 times after 4 DHCP discover packets.
>
> Please suggest me a way to debug this issue.

Put some breakpoints in do_dhcp. One on each recvfrom will probably
do. Run the code and see why its dropping the replys.

    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

Re: [ECOS] PCI Ethernet card (DHCP issue)

[Michael Anburaj]

Hi,

The DHCP protocol was successful with Redboot, but fails with ecos. After 
analyzing the packet captures using ethereal, I found some differences in 
the "DHCP Discover" packet --> under Bootstrap protocol --> BootP Flags = 
0x8000 (in case of ecos) & 0x0000 (in case of redboot).

In the case of redboot, the DHCP server (RH9 running my dhcpd.conf) responds 
with the DHCP offer soon after seeing the DHCP discover packet. But in case 
of ecos it responds 4 times after 4 DHCP discover packets.

Please suggest me a way to debug this issue.

I have also included the URL for the ethereal captures.

http://www.geocities.com/michaelanburaj/downloads/eth.zip

Thanks a lot,
-Mike.

_________________________________________________________________
Compare Cable, DSL or Satellite plans: As low as $29.95.  
https://broadband.msn.com


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss