405GP Networking issue

405GP Networking issue

[KISHINAMI Masaya]

Dear all, it's first time to post.

We are debugging a custom board designed based on the 405GP
(200MHz) and have a problem not being sent ECHO REPLY ping
packet from custom board to our PC via repeater hub on the
heavy traffic under 10Mbps and half duplex condition.
We used the latest version of ibm_ocp LAN device driver at
that time from kernel 2.4.21-pre3 and ported it to work on
the kernel 2.4.18 because it costs many time to boot our
custom board on the latest one. The board works fine unless
not be such a case.

Following are the our simplest duplication process and the
results.

1. Connect the repeater hub to backbone LAN.
2. Connect custom board, test PC to ping and other PCs to the
   repeater hub to the full. This case, 10 or more PCs are
   connected to repeater hub and each PC works normally by
   using network.
3. Increase the traffic by using ftp command. The ftp data was
   never addressed to the custom board.
4. Ping from our PC to custom board at one time.
5. The 60% pings were lost such condition.
6. We investigated the ping lost case.
   - LAN protocol analyzer captured the ECHO REQUEST which was
     address to custom board. It shows ECHO REQUEST was issued
     from our PC to LAN cable.
   - Logic analyzer captured the same ping packet which was
     already been captured by LAN analyzer between PHY(Intel
     LXT971A) and EMAC. It shows ECHO REQUEST was reached just
     before the EMAC.
   - The LAN device driver's receive buffer did not receive the
     ECHO REQUEST by using printk command. We suspected that the
     ECHO REQUEST was not issued to the MAL(Memory Access Layer),
     therefore ECHO REQUEST was not translated to the receive
     buffer.

At the same time, many 4 byte short packet(0x000000f0) which was
not addressed to custom board was received to the LAN device driver's
receive buffer with error status. According to 405GP manual, EMAC
discards the packet which is not of its own.

Have anyone experienced a problem like this?
Any help would be appreciated.

Regards, Kishinami.

-----
KISHINAMI Masaya
Fujitsu Limited (Japan)

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

AW: 405GP Networking issue

[Georg Klug]

Hi Kishinami,

> We are debugging a custom board designed based on the 405GP
> (200MHz) and have a problem not being sent ECHO REPLY ping
> packet from custom board to our PC via repeater hub on the
> heavy traffic under 10Mbps and half duplex condition.

> ...

> Following are the our simplest duplication process and the
> results.
>
> 1. Connect the repeater hub to backbone LAN.
> 2. Connect custom board, test PC to ping and other PCs to the
>    repeater hub to the full. This case, 10 or more PCs are
>    connected to repeater hub and each PC works normally by
>    using network.
> 3. Increase the traffic by using ftp command. The ftp data was
>    never addressed to the custom board.
> 4. Ping from our PC to custom board at one time.
> 5. The 60% pings were lost such condition.
> 6. We investigated the ping lost case.
>    - LAN protocol analyzer captured the ECHO REQUEST which was
>      address to custom board. It shows ECHO REQUEST was issued
>      from our PC to LAN cable.
>    - Logic analyzer captured the same ping packet which was
>      already been captured by LAN analyzer between PHY(Intel
>      LXT971A) and EMAC. It shows ECHO REQUEST was reached just
>      before the EMAC.
>    - The LAN device driver's receive buffer did not receive the
>      ECHO REQUEST by using printk command. We suspected that the
>      ECHO REQUEST was not issued to the MAL(Memory Access Layer),
>      therefore ECHO REQUEST was not translated to the receive
>      buffer.
>
> At the same time, many 4 byte short packet(0x000000f0) which was
> not addressed to custom board was received to the LAN device driver's
> receive buffer with error status. According to 405GP manual, EMAC
> discards the packet which is not of its own.

to me it looks like an half duplex issue. You should check whether both:
sender and receiver know that they are connected to a half duplex hub.
Otherwise collisions could occur which are not detected by the receiver
and also not by the transmitting entity. So you should make sure that
FDE is set to 0 in the EMAC Mode register 1 (EMAC0_MR1) according to
the Users manual)

Georg


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: AW: 405GP Networking issue

[KISHINAMI Masaya]

Hi Georg,

Thank you for your suggestion. However, we once checked the EMAC0_MR1,
and it was right configuration. Sorry, not to be informed to you.
But I'll check once again. As a fact, this problem does not happen
everywhere. We need to go another place and it's far from here. Therefore,
next investigation will be held at the middle of next week.
I will keep you informed as more information becomes available.

Regards, Kishinami

--- On Fri, 28 Feb 2003 22:59:11 +0900 Georg Klug<gklug@giga-stream.de> -san wrote:

>> We are debugging a custom board designed based on the 405GP
>> (200MHz) and have a problem not being sent ECHO REPLY ping
>> packet from custom board to our PC via repeater hub on the
>> heavy traffic under 10Mbps and half duplex condition.
>
>> ...
>
>> Following are the our simplest duplication process and the
>> results.
>>
>> 1. Connect the repeater hub to backbone LAN.
>> 2. Connect custom board, test PC to ping and other PCs to the
>>    repeater hub to the full. This case, 10 or more PCs are
>>    connected to repeater hub and each PC works normally by
>>    using network.
>> 3. Increase the traffic by using ftp command. The ftp data was
>>    never addressed to the custom board.
>> 4. Ping from our PC to custom board at one time.
>> 5. The 60% pings were lost such condition.
>> 6. We investigated the ping lost case.
>>    - LAN protocol analyzer captured the ECHO REQUEST which was
>>      address to custom board. It shows ECHO REQUEST was issued
>>      from our PC to LAN cable.
>>    - Logic analyzer captured the same ping packet which was
>>      already been captured by LAN analyzer between PHY(Intel
>>      LXT971A) and EMAC. It shows ECHO REQUEST was reached just
>>      before the EMAC.
>>    - The LAN device driver's receive buffer did not receive the
>>      ECHO REQUEST by using printk command. We suspected that the
>>      ECHO REQUEST was not issued to the MAL(Memory Access Layer),
>>      therefore ECHO REQUEST was not translated to the receive
>>      buffer.
>>
>> At the same time, many 4 byte short packet(0x000000f0) which was
>> not addressed to custom board was received to the LAN device driver's
>> receive buffer with error status. According to 405GP manual, EMAC
>> discards the packet which is not of its own.
>
>to me it looks like an half duplex issue. You should check whether both:
>sender and receiver know that they are connected to a half duplex hub.
>Otherwise collisions could occur which are not detected by the receiver
>and also not by the transmitting entity. So you should make sure that
>FDE is set to 0 in the EMAC Mode register 1 (EMAC0_MR1) according to
>the Users manual)
>

-----
KISHINAMI Masaya
Fujitsu Limited (Japan)

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 405GP Networking issue

[Eugene Surovegin]

At 04:27 AM 2/28/2003, KISHINAMI Masaya wrote:
>We are debugging a custom board designed based on the 405GP
>(200MHz) and have a problem not being sent ECHO REPLY ping
>packet from custom board to our PC via repeater hub on the
>heavy traffic under 10Mbps and half duplex condition.
>We used the latest version of ibm_ocp LAN device driver at
>that time from kernel 2.4.21-pre3 and ported it to work on
>the kernel 2.4.18 because it costs many time to boot our
>custom board on the latest one. The board works fine unless
>not be such a case.


>    - Logic analyzer captured the same ping packet which was
>      already been captured by LAN analyzer between PHY(Intel
>      LXT971A) and EMAC. It shows ECHO REQUEST was reached just
>      before the EMAC.


If other obvious _software_ errors were eliminated (like incorrect
duplex/speed settings etc) you can check _hardware_ related problems:

Please, check the quality of the clock between PHY and EMAC (MII clock).
We had some problems with this Intel PHY and IBM 440GP when PHY generated
clock was _slightly_ out of spec for IBM CPU.

You can try to increase MII drive strength in LXT971A Digital Config
register (26), write 0x0800 to it.

Make sure that your design uses _crystal_ based oscillator for PHY
clock, not PLL based. This is _general_ observation regarding PHY clock
in any designs (not just 4xx based)

Eugene.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 405GP Networking issue

[KISHINAMI Masaya]

Hi, Eugene.

Thank you for your advice.

--- On Sat, 1 Mar 2003 04:08:33 +0900 Eugene Surovegin<ebs@ebshome.net> -san wrote:

>
>At 04:27 AM 2/28/2003, KISHINAMI Masaya wrote:
>>We are debugging a custom board designed based on the 405GP
>>(200MHz) and have a problem not being sent ECHO REPLY ping
>>packet from custom board to our PC via repeater hub on the
>>heavy traffic under 10Mbps and half duplex condition.
>>We used the latest version of ibm_ocp LAN device driver at
>>that time from kernel 2.4.21-pre3 and ported it to work on
>>the kernel 2.4.18 because it costs many time to boot our
>>custom board on the latest one. The board works fine unless
>>not be such a case.
>
>
>>    - Logic analyzer captured the same ping packet which was
>>      already been captured by LAN analyzer between PHY(Intel
>>      LXT971A) and EMAC. It shows ECHO REQUEST was reached just
>>      before the EMAC.
>
>
>If other obvious _software_ errors were eliminated (like incorrect
>duplex/speed settings etc) you can check _hardware_ related problems:
>
>Please, check the quality of the clock between PHY and EMAC (MII clock).
>We had some problems with this Intel PHY and IBM 440GP when PHY generated
>clock was _slightly_ out of spec for IBM CPU.
>
We have already been checked the quality of the clock and it
was good. However we'll check again. Today, we tried to duplicate
the ping lost case by another custom board designed based on 405GP
and no ping lost occurred on the same line loading condition what
we investigated before. The difference is hardware design (wiring
etc.) and SW(OS, LAN device driver etc.). Each custom board is
designed for another product. Therefor we'll check the difference
at the point of hardware(waveform etc.) and SW(configuration of
EMAC/PHY/MAL and so on).


>You can try to increase MII drive strength in LXT971A Digital Config
>register (26), write 0x0800 to it.
>
>Make sure that your design uses _crystal_ based oscillator for PHY
>clock, not PLL based. This is _general_ observation regarding PHY clock
>in any designs (not just 4xx based)
>

Fortunately, we have designed the same way what you've adviced.
Datasheet said don't use PLL. Before, 100Mbps transfer mode which
clock line is 25MHz was succeded. While the 10Mbps is 2.5MHz.
Therefore we think there is no matter about quality of clock.
Anyway we'll investigate again.

Regards, Kishinami

-----
KISHINAMI Masaya
Fujitsu Limited (Japan)

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

How to load vmlinux in IBM405 Redwood-6 board(Teference board)

[Rakesh Jagota]

Hi all,

I am working with Redwood-6 IBM ppc405 refrence design board. I am not able
test the reference board. I am getting the menu on the Hyperterminal but I am
not able to load the linux source code using serial port and DHCP. Can anyone
suggest me whats wrong and how can i do it. I have configured the DHCP in my
host system, but I am not able to upload the vmlinux i  the target.

I am working in linux and using 7.2 version.

Thanks in advance,

Rakesh


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 405GP Networking issue

[KISHINAMI Masaya]

Hi,

Before, we have experienced a failure that the about 60% ping
commands were lost at the below condition.
- custom board designed based on the 405GP
- kernel 2.4.18
- 2.4.21 pre3 ibm_ocp LAN device driver and ported it to
  work on kernel 2.4.18
- repeater hub(10Mbps, half duplex)
- line is much loaded

We investigated the another product designed based on the 405GP
which is not occurred the same failure on the same condition and
we've found the difference and modified the LAN device driver.

[Cause]
- Receive Mode Register(EMAC0_RMR) was not set to receive the
  Runt packet and FCS error packet.
- Even if the above mode is set at the open process(ppc405_enet_open),
  the value was cleared at the multicast configuration process
  (ppc405_enet_set_multicast_list).

[Conclusion]
- In Receive Mode Register(EMAC0_RMR) initialization at the open
  process, allow receiving the runt packet(RRP) and FCS error
  packet(RFP).
  Ex.
	/* enable broadcast and individual address */
	out_be32(&emacp->em0rmr, EMAC_RMR_IAE | EMAC_RMR_BAE);
  ---->
        unsigned long rcv_err_packet=EMAC_RMR_ARRP | EMAC_RMR_ARP;
	/* enable broadcast and individual address */
	out_be32(&emacp->em0rmr,
	 rcv_err_packet | EMAC_RMR_IAE | EMAC_RMR_BAE);

- In ppc405_enet_set_multicast_list(), one of the resolutions is
  to set receiving the error packet in each program line what is
  to be set.
  Ex. (case multicast configuration)
      unsigned long rcv_err_packet=EMAC_RMR_ARRP | EMAC_RMR_ARP;
      out_be32(&emacp->em0rmr,
      rcv_err_packet | EMAC_RMR_IAE | EMAC_RMR_BAE | EMAC_RMR_MAE);

After modification, no frame error was found by ifconfig cmd and no
BAD packet was found in the log file and all ping was succeeded.
We don't understand why such configuration is effective, because
we understand the 405GP's EMAC will discard any bad packets and
managing bad packet by software is not required.
By the way, the reason of another product's LAN device driver is
set to receiving the bad packet is related to the period of development.
At this time(1999), LAN device driver was debugged with engineering
version of 405GP, therefore some error management was covered by
software and this configuration has been kept leaving because no such
failure has occurred as yet.
Sorry not to inform quickly.

Regards. Kishinami

-----
KISHINAMI Masaya
Fujitsu Limited (Japan)

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

405GP Networking issue

[Mark Wisner]

Kishinami,
You are correct, the 405GP's EMAC will discard any bad packets or packets
that do not meet it's address match mechanism. There is one exception. If
the packet received gets a good address match and the packet is large but
has an FCS error, it may pass the bad packet to the MAL. The MAL will
create an EOB interrupt and the RX_EOB routine should then look at the
descriptors status bits to see that it is a bad packet.  This is determined
by the RX threshold value. Once the EMAC starts to send a packet to the MAL
it will continue to send it, even though it fails the FCS check at the end
of the packet. Once it starts a packet it runs to completion. SW then needs
to detect the bad packet by the status bits.

The real question is, why are you receiving what the EMAC thinks are bad
packets?

If you can isolate the board on a hub with only the ping traffic in
question it will make things easier to debug. Most of the time when this
type of thing happens, you have noise between the PHY and the EMAC on the
MII bus. Here is the way I shoot these types of things.
1) Put the EMAC in promiscous mode, enable the reception of every bad
packet it can. You do this by setting the RMR reg. Look at the open routine
for the device. I think the RMR reg is set there.
2) Go to the RX_EOB routine where it checks the status bits in the
descriptor. If it detects a bad packet, print the packet out. Look for any
odd bit patterns. You may have a noisy bit.

Remember, if the MII itnerface is so messed up that the preamble does not
get deteceted correctly the EMAC will not see the packet at all. When I
have it this type of problem, I pull out the Smartbit tester and embed data
patterns in the packet that may fake the EMAC to think it has a preamble.
For example, if I think I am dropping bit 0, I will send in a pattern of
all 5's in the packet for a while and then a F.  By using different data
paterns you can determing the problem bit or bits. I have also seen where
there was to much load on a line so it did not switch as it should.

You should send your problem to PPCSUPP@us.ibm.com, IBM support. Send them
a shapshot of what you captured on the MII interface. Also, a scope capture
showing the RX_DV( I think that is the name of the MII signal that marks
the beginning of a RX packet)  line and a data line so they can see how
they switch together. If the ctl line is late or the data line is early,
you can get some weird results.

Mark K. Wisner
Advisory Software Engineer
IBM Microelectronics
3039 Cornwallis Rd
RTP, NC 27709
Tel. 919-254-7191
Fax 919-543-7575
---------------------- Forwarded by Mark Wisner/Raleigh/IBM on 02/28/2003
10:36 AM ---------------------------

Mark Wisner
02/28/2003 09:10 AM

To:    kishinami@cs.fujitsu.com.jp
cc:
From:  Mark Wisner/Raleigh/IBM@IBMUS
Subject:    405GP Networking issue


Kishinami,
You are correct, the 405GP's EMAC will discard any bad packets or packets
that do not meet it's address match mechanism. There is one exception. If
the packet received gets a good address match and the packet is large but
has an FCS error, it may pass the bad packet to the MAL. The MAL will
create an EOB interrupt and the RX_EOB routine should then look at the
descriptors status bits to see that it is a bad packet.  This is determined
by the RX threshold value. Once the EMAC starts to send a packet to the MAL
it will continue to send it, even though it fails the FCS check at the end
of the packet. Once it starts a packet it runs to completion. SW then needs
to detect the bad packet by the status bits.

The real question is, why are you receiving what the EMAC thinks are bad
packets?

If you can isolate the board on a hub with only the ping traffic in
question it will make things easier to debug. Most of the time when this
type of thing happens, you have noise between the PHY and the EMAC on the
MII bus. Here is the way I shoot these types of things.
1) Put the EMAC in promiscous mode, enable the reception of every bad
packet it can. You do this by setting the RMR reg. Look at the open routine
for the device. I think the RMR reg is set there.
2) Go to the RX_EOB routine where it checks the status bits in the
descriptor. If it detects a bad packet, print the packet out. Look for any
odd bit patterns. You may have a noisy bit.

Remember, if the MII itnerface is so messed up that the preamble does not
get deteceted correctly the EMAC will not see the packet at all. When I
have it this type of problem, I pull out the Smartbit tester and embed data
patterns in the packet that may fake the EMAC to think it has a preamble.
For example, if I think I am dropping bit 0, I will send in a pattern of
all 5's in the packet for a while and then a F.  By using different data
paterns you can determing the problem bit or bits. I have also seen where
there was to much load on a line so it did not switch as it should.

You should send your problem to PPCSUPP@us.ibm.com, IBM support. Send them
a shapshot of what you captured on the MII interface. Also, a scope capture
showing the RX_DV( I think that is the name of the MII signal that marks
the beginning of a RX packet)  line and a data line so they can see how
they switch together. If the ctl line is late or the data line is early,
you can get some weird results.

Mark K. Wisner
Advisory Software Engineer
IBM Microelectronics
3039 Cornwallis Rd
RTP, NC 27709
Tel. 919-254-7191
Fax 919-543-7575
---------------------- Forwarded by Mark Wisner/Raleigh/IBM on 02/28/2003
08:34 AM ---------------------------

Ralph Blach
02/28/2003 08:22 AM

To:    Mark Wisner/Raleigh/IBM@IBMUS
cc:
From:  Ralph Blach/Raleigh/IBM@IBMUS
Subject:    405GP Networking issue



---------------------- Forwarded by Ralph Blach/Raleigh/IBM on 02/28/2003
08:22 AM ---------------------------

KISHINAMI Masaya <kishinami@cs.fujitsu.co.jp>@lists.linuxppc.org on
02/28/2003 07:27:56 AM

Sent by:    owner-linuxppc-embedded@lists.linuxppc.org


To:    linuxppc-embedded@lists.linuxppc.org
cc:
Subject:    405GP Networking issue




Dear all, it's first time to post.

We are debugging a custom board designed based on the 405GP
(200MHz) and have a problem not being sent ECHO REPLY ping
packet from custom board to our PC via repeater hub on the
heavy traffic under 10Mbps and half duplex condition.
We used the latest version of ibm_ocp LAN device driver at
that time from kernel 2.4.21-pre3 and ported it to work on
the kernel 2.4.18 because it costs many time to boot our
custom board on the latest one. The board works fine unless
not be such a case.

Following are the our simplest duplication process and the
results.

1. Connect the repeater hub to backbone LAN.
2. Connect custom board, test PC to ping and other PCs to the
   repeater hub to the full. This case, 10 or more PCs are
   connected to repeater hub and each PC works normally by
   using network.
3. Increase the traffic by using ftp command. The ftp data was
   never addressed to the custom board.
4. Ping from our PC to custom board at one time.
5. The 60% pings were lost such condition.
6. We investigated the ping lost case.
   - LAN protocol analyzer captured the ECHO REQUEST which was
     address to custom board. It shows ECHO REQUEST was issued
     from our PC to LAN cable.
   - Logic analyzer captured the same ping packet which was
     already been captured by LAN analyzer between PHY(Intel
     LXT971A) and EMAC. It shows ECHO REQUEST was reached just
     before the EMAC.
   - The LAN device driver's receive buffer did not receive the
     ECHO REQUEST by using printk command. We suspected that the
     ECHO REQUEST was not issued to the MAL(Memory Access Layer),
     therefore ECHO REQUEST was not translated to the receive
     buffer.

At the same time, many 4 byte short packet(0x000000f0) which was
not addressed to custom board was received to the LAN device driver's
receive buffer with error status. According to 405GP manual, EMAC
discards the packet which is not of its own.

Have anyone experienced a problem like this?
Any help would be appreciated.

Regards, Kishinami.

-----
KISHINAMI Masaya
Fujitsu Limited (Japan)


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 405GP Networking issue

[KISHINAMI Masaya]

Hi, Mark

--- On Sat, 1 Mar 2003 00:41:29 +0900 Mark Wisner<markwiz@us.ibm.com> -san wrote:

>
>Kishinami,
>You are correct, the 405GP's EMAC will discard any bad packets or packets
>that do not meet it's address match mechanism. There is one exception. If
>the packet received gets a good address match and the packet is large but
>has an FCS error, it may pass the bad packet to the MAL. The MAL will
>create an EOB interrupt and the RX_EOB routine should then look at the
>descriptors status bits to see that it is a bad packet.  This is determined
>by the RX threshold value. Once the EMAC starts to send a packet to the MAL
>it will continue to send it, even though it fails the FCS check at the end
>of the packet. Once it starts a packet it runs to completion. SW then needs
>to detect the bad packet by the status bits.
>

I understand the detection mechanism of bad packet. However I think
almost bad packet does not include a FCS error because only ten or
more ping packets or some broadcast address meet custom board's address.
The number of bad packets detected by SW is more than what we sent by
using ping command or broadcast by investigating LAN protocol analyzer.
By the way, is RX threshold a programmed value or related to hard? I wonder
the EMAC0_TRTR meets or not.

>The real question is, why are you receiving what the EMAC thinks are bad
>packets?
>

I don't know. For now, this case can be duplicated only one place. The
condition is as follows.
- Repeater hub which is connected to backbone LAN and many PCs work.
- Line condition is much loaded.

Therefore we think something is wrong with in such a special case.

>If you can isolate the board on a hub with only the ping traffic in
>question it will make things easier to debug. Most of the time when this
>type of thing happens, you have noise between the PHY and the EMAC on the
>MII bus. Here is the way I shoot these types of things.
>1) Put the EMAC in promiscous mode, enable the reception of every bad
>packet it can. You do this by setting the RMR reg. Look at the open routine
>for the device. I think the RMR reg is set there.
>2) Go to the RX_EOB routine where it checks the status bits in the
>descriptor. If it detects a bad packet, print the packet out. Look for any
>odd bit patterns. You may have a noisy bit.
>

The 4 bytes short packet what we once captured is 0x000000f0 pattern.
However, promiscous mode was disabled. Is this data effective? If so,
do you think noisy bit is included?

>Remember, if the MII itnerface is so messed up that the preamble does not
>get deteceted correctly the EMAC will not see the packet at all. When I
>have it this type of problem, I pull out the Smartbit tester and embed data
>patterns in the packet that may fake the EMAC to think it has a preamble.
>For example, if I think I am dropping bit 0, I will send in a pattern of
>all 5's in the packet for a while and then a F.  By using different data
>paterns you can determing the problem bit or bits. I have also seen where
>there was to much load on a line so it did not switch as it should.
>

The ping flood test by using ping -f command under 100Mbps and
full duplex by connecting custom board and PC directory was almost
good. How do you think about this test result?

>You should send your problem to PPCSUPP@us.ibm.com, IBM support. Send them
>a shapshot of what you captured on the MII interface. Also, a scope capture
>showing the RX_DV( I think that is the name of the MII signal that marks
>the beginning of a RX packet)  line and a data line so they can see how
>they switch together. If the ctl line is late or the data line is early,
>you can get some weird results.
>
>Mark K. Wisner
>Advisory Software Engineer
>IBM Microelectronics
>3039 Cornwallis Rd
>RTP, NC 27709
>Tel. 919-254-7191
>Fax 919-543-7575

Regards, Kishinami


>---------------------- Forwarded by Mark Wisner/Raleigh/IBM on 02/28/2003
>10:36 AM ---------------------------
>
>Mark Wisner
>02/28/2003 09:10 AM
>
>To:    kishinami@cs.fujitsu.com.jp
>cc:
>From:  Mark Wisner/Raleigh/IBM@IBMUS
>Subject:    405GP Networking issue
>
>
>Kishinami,
>You are correct, the 405GP's EMAC will discard any bad packets or packets
>that do not meet it's address match mechanism. There is one exception. If
>the packet received gets a good address match and the packet is large but
>has an FCS error, it may pass the bad packet to the MAL. The MAL will
>create an EOB interrupt and the RX_EOB routine should then look at the
>descriptors status bits to see that it is a bad packet.  This is determined
>by the RX threshold value. Once the EMAC starts to send a packet to the MAL
>it will continue to send it, even though it fails the FCS check at the end
>of the packet. Once it starts a packet it runs to completion. SW then needs
>to detect the bad packet by the status bits.
>
>The real question is, why are you receiving what the EMAC thinks are bad
>packets?
>
>If you can isolate the board on a hub with only the ping traffic in
>question it will make things easier to debug. Most of the time when this
>type of thing happens, you have noise between the PHY and the EMAC on the
>MII bus. Here is the way I shoot these types of things.
>1) Put the EMAC in promiscous mode, enable the reception of every bad
>packet it can. You do this by setting the RMR reg. Look at the open routine
>for the device. I think the RMR reg is set there.
>2) Go to the RX_EOB routine where it checks the status bits in the
>descriptor. If it detects a bad packet, print the packet out. Look for any
>odd bit patterns. You may have a noisy bit.
>
>Remember, if the MII itnerface is so messed up that the preamble does not
>get deteceted correctly the EMAC will not see the packet at all. When I
>have it this type of problem, I pull out the Smartbit tester and embed data
>patterns in the packet that may fake the EMAC to think it has a preamble.
>For example, if I think I am dropping bit 0, I will send in a pattern of
>all 5's in the packet for a while and then a F.  By using different data
>paterns you can determing the problem bit or bits. I have also seen where
>there was to much load on a line so it did not switch as it should.
>
>You should send your problem to PPCSUPP@us.ibm.com, IBM support. Send them
>a shapshot of what you captured on the MII interface. Also, a scope capture
>showing the RX_DV( I think that is the name of the MII signal that marks
>the beginning of a RX packet)  line and a data line so they can see how
>they switch together. If the ctl line is late or the data line is early,
>you can get some weird results.
>
>Mark K. Wisner
>Advisory Software Engineer
>IBM Microelectronics
>3039 Cornwallis Rd
>RTP, NC 27709
>Tel. 919-254-7191
>Fax 919-543-7575
>---------------------- Forwarded by Mark Wisner/Raleigh/IBM on 02/28/2003
>08:34 AM ---------------------------
>
>Ralph Blach
>02/28/2003 08:22 AM
>
>To:    Mark Wisner/Raleigh/IBM@IBMUS
>cc:
>From:  Ralph Blach/Raleigh/IBM@IBMUS
>Subject:    405GP Networking issue
>
>
>
>---------------------- Forwarded by Ralph Blach/Raleigh/IBM on 02/28/2003
>08:22 AM ---------------------------
>
>KISHINAMI Masaya <kishinami@cs.fujitsu.co.jp>@lists.linuxppc.org on
>02/28/2003 07:27:56 AM
>
>Sent by:    owner-linuxppc-embedded@lists.linuxppc.org
>
>
>To:    linuxppc-embedded@lists.linuxppc.org
>cc:
>Subject:    405GP Networking issue
>
>
>
>
>Dear all, it's first time to post.
>
>We are debugging a custom board designed based on the 405GP
>(200MHz) and have a problem not being sent ECHO REPLY ping
>packet from custom board to our PC via repeater hub on the
>heavy traffic under 10Mbps and half duplex condition.
>We used the latest version of ibm_ocp LAN device driver at
>that time from kernel 2.4.21-pre3 and ported it to work on
>the kernel 2.4.18 because it costs many time to boot our
>custom board on the latest one. The board works fine unless
>not be such a case.
>
>Following are the our simplest duplication process and the
>results.
>
>1. Connect the repeater hub to backbone LAN.
>2. Connect custom board, test PC to ping and other PCs to the
>   repeater hub to the full. This case, 10 or more PCs are
>   connected to repeater hub and each PC works normally by
>   using network.
>3. Increase the traffic by using ftp command. The ftp data was
>   never addressed to the custom board.
>4. Ping from our PC to custom board at one time.
>5. The 60% pings were lost such condition.
>6. We investigated the ping lost case.
>   - LAN protocol analyzer captured the ECHO REQUEST which was
>     address to custom board. It shows ECHO REQUEST was issued
>     from our PC to LAN cable.
>   - Logic analyzer captured the same ping packet which was
>     already been captured by LAN analyzer between PHY(Intel
>     LXT971A) and EMAC. It shows ECHO REQUEST was reached just
>     before the EMAC.
>   - The LAN device driver's receive buffer did not receive the
>     ECHO REQUEST by using printk command. We suspected that the
>     ECHO REQUEST was not issued to the MAL(Memory Access Layer),
>     therefore ECHO REQUEST was not translated to the receive
>     buffer.
>
>At the same time, many 4 byte short packet(0x000000f0) which was
>not addressed to custom board was received to the LAN device driver's
>receive buffer with error status. According to 405GP manual, EMAC
>discards the packet which is not of its own.
>
>Have anyone experienced a problem like this?
>Any help would be appreciated.
>
>Regards, Kishinami.
>
>-----
>KISHINAMI Masaya
>Fujitsu Limited (Japan)
>
>
>
>

-----
KISHINAMI Masaya
Fujitsu Limited (Japan)

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/