foundry27 : Post

Forum Topic - mpc85xx driver err: (22 Items)

View: as

Lasse Skov(deleted)

07/14/2009 4:29 AM

post33710

Hey

I using the mpc85xx.so on my development board.
My program send and receive packet on the network port. After some packet is send and received the mpc driver write 
following in slogger.

Jan 01 01:13:24    2    14     0 mpc85xx_receive(): status RXBD_ERR 0x1C94

What does this RXBD_ERR means and what is the 0x1c94 a status error.

/Lasse

Associations:

post38831:
              Re: RE: Native io-pkt Ethernet Driver(mpc85xx) - Same kind of issue - Akash Goswami(deleted)

Hugh Brown

07/14/2009 8:00 AM

post33714

RE: mpc85xx driver err

This means that you received a CRC error on a non-octet aligned buffer.

-----Original Message-----
From: Lasse Skov [mailto:community-noreply@qnx.com] 
Sent: Tuesday, July 14, 2009 4:30 AM
To: drivers-networking
Subject: mpc85xx driver err

Hey

I using the mpc85xx.so on my development board.
My program send and receive packet on the network port. After some
packet is send and received the mpc driver write following in slogger.

Jan 01 01:13:24    2    14     0 mpc85xx_receive(): status RXBD_ERR
0x1C94

What does this RXBD_ERR means and what is the 0x1c94 a status error.

/Lasse

_______________________________________________
Networking Drivers
http://community.qnx.com/sf/go/post33710

Andrew Boyd(deleted)

07/14/2009 9:14 AM

post33731

RE: mpc85xx driver err

> you received a CRC error on a non-octet aligned buffer.

... which should also show up in the nicinfo counts.

Since the movement away from true ethernet 10mbit hubs 
(bit repeaters) about 15 years ago to 100mbit (and then 
gig) switches, these types of physical media error have 
almost entirely disappeared - the links are almost always
simply point-to-point, which is a pretty trivial ethernet.

You might see errors like this when you plug in (or plug out)
a cable.  But you shouldn't see a lot of them.  What is
your nicinfo output?  You need to look at the ratio of
the number of crc errors to the number of packets.  If
it's one in a million, forget about it.  If it's one in
ten, you've got a problem.

--
aboyd

Lasse Skov(deleted)

07/15/2009 3:39 AM

post33788

Re: RE: mpc85xx driver err

Thanks for your answer.

I found it in nicinfo there was many errors, and the problem was some of my ethercat packets has swapped header, on my 
PPC platform.

Andrew Boyd(deleted)

07/15/2009 9:29 AM

post33822

RE: RE: mpc85xx driver err

> problem was some of my ethercat packets 
> has swapped header, on my PPC platform

Is this a driver problem?  If so, please
point me to the offending lines of code.

AFAIK this driver is big endian only, correct?

Are you running ppcle?  I've heard of it,
but never seen it outside of captivity ....

--
aboyd  www.poweredbyqnx.com/images/L39_rollout.jpg

Bjoern Weber

02/08/2010 8:00 AM

post46768

RE: mpc85xx driver err

Andrew,

I just have a customer with the same problem. However it just happens on an eval board which uses MII (4 bit) headers. 
Running another board with RMII headers (2 bit) works fine. Is it possible that our driver doesn't tell the two cases 
apart and starts to mis-align the the date in MII case?

Thanks,

    Bjoern

Andrew Boyd(deleted)

02/08/2010 9:42 AM

post46790

RE: mpc85xx driver err

> mpc85xx_receive(): status RXBD_ERR 0x1C94

Are you seeing exactly the same hex value as
this guy?  You have look up the bits in the 
data sheet to see exactly what error occurred.

This is a bit of a weird code - the chip is
reporting that the packet is both too long
and too short (at the same time) and also
that it's non-aligned, but there is no problem
with the crc (or more likely it wasn't calculated).

Are all rxd packets garbled, or just some?

Note that the India team (thanks guys!) found
and fixed a bug in devnp-mpc85xx.so with respect
to error handling.

--
aboyd

Bjoern Weber

02/08/2010 10:28 AM

post46798

Re: RE: mpc85xx driver err

> > mpc85xx_receive(): status RXBD_ERR 0x1C94
> 
> Are you seeing exactly the same hex value as
> this guy?  You have look up the bits in the 
> data sheet to see exactly what error occurred.

They see the same hex value - that's how I found this thread ;)

> This is a bit of a weird code - the chip is
> reporting that the packet is both too long
> and too short (at the same time) and also
> that it's non-aligned, but there is no problem
> with the crc (or more likely it wasn't calculated).
> 
> Are all rxd packets garbled, or just some?

They are running the two interfaces in bridging mode. When data arrives on one port it's accepted but not forwarded to 
the other, instead giving the above message. 

> Note that the India team (thanks guys!) found
> and fixed a bug in devnp-mpc85xx.so with respect
> to error handling.

Maybe that one handles just that kind of quirks. Any chance to get an experimental for the customer to try out?

  bweb

Andrew Boyd(deleted)

02/08/2010 10:35 AM

post46800

RE: RE: mpc85xx driver err

> experimental ... to try out?

This is a head branch ppcbe experimental binary:

www.PoweredByQNX.com/etc/devnp-mpc85xx.so

--
aboyd

Bjoern Weber

02/09/2010 4:49 AM

post46881

Re: RE: RE: mpc85xx driver err

> > experimental ... to try out?
> This is a head branch ppcbe experimental binary:

Thanks for the binary, unfortunately it doesn't soothe the issue:

-- slog sent by customer -->
Jan 01 00:05:36    2    14     0 mpc85xx_init(): rx dma buffer size 2048 bytes
Jan 01 00:05:36    2    14     0 mpc85xx_init(): RCTRL written with 0x203C8, reads as 0x203C8
Jan 01 00:05:36    2    14     0 mpc85xx_init(): RXIC written with 0x818001F4, reads as 0x818001F4
Jan 01 00:05:36    2    14     0 mpc85xx_init(): TCTRL written with 0x6000, reads as 0x6000
Jan 01 00:05:36    2    14     0 mpc85xx_init_phy(): media_rate: 100000, duplex: 1, PHY: 0
Jan 01 00:05:36    2    14     0 mpc85xx_init_phy(): PHY found at address 0
Jan 01 00:05:36    2    14     0 mpc85xx->rx_cap_mask: 0x0

Jan 01 00:05:36    2    14     0 mpc85xx->tx_cap_mask: 0x0

Jan 01 00:05:36    2    14     0 mpc85xx_init(): ending: idx 1

Jan 01 00:05:36    2    14     0 mpc85xx_receive(): status RXBD_ERR 0x1C84
Jan 01 00:05:37    2    14     0 mpc85xx_MDI_MonitorPhy(): NOT calling MDI_MonitorPhy()

Jan 01 00:05:37    2    14     0 mpc85xx_receive(): status RXBD_ERR 0x1C84
Jan 01 00:05:38    2    14     0 mpc85xx_MDI_MonitorPhy(): calling MDI_MonitorPhy()

Jan 01 00:05:38    5    14     0 mpc85xx_mii_callback(): link up lan 1 idx 1 (100 BaseT Full Duplex)
Jan 01 00:05:38    2    14     0 mpc85xx_receive(): status RXBD_ERR 0x1C84
Jan 01 00:05:39    2    14     0 mpc85xx_MDI_MonitorPhy(): calling MDI_MonitorPhy()

Jan 01 00:05:39    2    14     0 mpc85xx_receive(): status RXBD_ERR 0x1C84
Jan 01 00:05:40    2    14     0 mpc85xx_MDI_MonitorPhy(): NOT calling MDI_MonitorPhy()
<----

Looks a bit like noise on the cable, doesn't it?

  bweb

Andrew Boyd(deleted)

02/09/2010 9:26 AM

post46911

RE: RE: RE: mpc85xx driver err

> mpc85xx_receive(): status RXBD_ERR 0x1C84

It probably doesn't mean anything, but 0x1C84
no longer has both the "too large" and "too small"
status bits set - just the "too small" and "misaligned".

There is no nicinfo, so I can't tell if this is
occurring with every rxd packet, or 1% of the packets,
etc.  In the log, they are occurring right after the
link is reported up.  Do you still see them after
that?

Trying a different cable and a different switch (and
at a different speed) probably wouldn't hurt. 

If you want, you can crank up the verbosity (to 10) on 
the driver until you see every read and write to the 
PHY.  If everything else looks ok, that's the place to
look next - is the PHY initialized and configured
correctly?

--
aboyd

Bjoern Weber

02/09/2010 10:27 AM

post46920

Re: mpc85xx driver err

The missing nicinfo was my mistake. I attached it to this post.

  bweb

Attachment:

nicinfo.txt 4.04 KB

Andrew Boyd(deleted)

02/09/2010 10:38 AM

post46926

RE: mpc85xx driver err

That nicinfo output looks pretty good to me:

> Packets Received OK ........................ 319
> Bytes Received OK .......................... 20832
> Broadcast Packets Received OK .............. 26
> Multicast Packets Received OK .............. 115
> Memory Allocation Failures on Receive ...... 0
> (all error counters zero)

Is it possible the rx errors only occur right after
the link goes up?  That's what the sloginfo output
might indicate.

Many times in the past we have seen with different
drivers that right after the link is supposedly up,
packets don't flow correctly for a couple of seconds
afterwards.  Perhaps the other end isn't quite happy
yet?

Is it possible that's what we're seeing here?  From
the nicinfo output, it looks like packets are moving
just fine.

At this point, what happens if you try to use the
network with an ftp or telnet or qnet big file copy 
or ttcp?  Does it work correctly?  Do any more of those
weird rx errors appear in the sloginfo?

--
aboyd

Lasse Skov(deleted)

02/09/2010 1:13 PM

post46955

Re: RE: mpc85xx driver err

Hi Boyd and Weber

Just a comment to our problem.

It is not possible to setup another network traffic over the tsec1 controller.
This controller is direct connected to another mii interface, without phy between the two mii interfaces.

Could this configuration generate a problem for the driver?

Will it generate a problem for the driver that we are using the same phy address for both tsec controllers?


/Lasse

Andrew Boyd(deleted)

RE: RE: mpc85xx driver err

Andrew Boyd(deleted)

02/09/2010 1:37 PM

post46956

RE: RE: mpc85xx driver err

> controller is direct connected to another 
> mii interface, without phy between the two 
> mii interfaces.

Wow.

The driver is going to expect to talk to a PHY
chip.  If there isn't one, you're going to want
to use the emu_phy=X option to fool the driver
into thinking there is a PHY chip there.

Perhaps Hugh could comment ...

> a problem for the driver that we are using 
> the same phy address for both tsec controllers?

Ordinarily, yes, but in your case, you don't
have a PHY.

--
aboyd

Hugh Brown

Re: mpc85xx driver err

Hugh Brown

02/09/2010 1:41 PM

post46959

Re: mpc85xx driver err

Yes, if you don't have a PHY, you can use the emu_phy=X option, where 'X' is
the interface number that doesn't have the PHY.



On 10-02-09 1:44 PM, "Andrew Boyd" <aboyd@qnx.com> wrote:

> 
>> controller is direct connected to another
>> mii interface, without phy between the two
>> mii interfaces.
> 
> Wow.
> 
> The driver is going to expect to talk to a PHY
> chip.  If there isn't one, you're going to want
> to use the emu_phy=X option to fool the driver
> into thinking there is a PHY chip there.
> 
> Perhaps Hugh could comment ...
> 
>> a problem for the driver that we are using
>> the same phy address for both tsec controllers?
> 
> Ordinarily, yes, but in your case, you don't
> have a PHY.
> 
> --
> aboyd
>

Lasse Skov(deleted)

02/09/2010 2:46 PM

post46972

Re: mpc85xx driver err

But again will this generate a problem for the driver.? 
And give mpc85xx_receive(): status RXBD_ERR 0x1C84 error?

tsec0: is connected to phy with add 0
tsec1: is direct connected to hw without a phy.

So if i had tsec0 connected the driver will think both tsec0 and tsec1 is connected because i use the same phy address 
for both? or what?

In the BSP i setup the phy and interrupt information with the following.

add_one_tsec(TSEC0_OFF, TSEC0_IRQ_TX, TSEC0_IRQ_RX, TSEC0_IRQ_ERR, mac, 0);
add_one_tsec(TSEC1_OFF, TSEC1_IRQ_TX, TSEC1_IRQ_RX, TSEC1_IRQ_ERR, mac, 0);

And if i should use the emu_phy i will start the io-pkt with following args.

io-pkt-v4-hc -dmpc85xx syspage,emu_phy=1

and chance the add_one_tsec to
add_one_tsec(TSEC1_OFF, TSEC1_IRQ_TX, TSEC1_IRQ_RX, TSEC1_IRQ_ERR, mac, 1);

Is this correct?

/Lasse

Hugh Brown

02/10/2010 8:15 AM

post47012

Re: mpc85xx driver err

You will have to start the driver as follows:

io-pkt-v4 -dmpc85xx pci=0 -dmpc85xx pci=1,emu_phy=1



On 10-02-09 2:46 PM, "Lasse Skov" <community-noreply@qnx.com> wrote:

> But again will this generate a problem for the driver.?
> And give mpc85xx_receive(): status RXBD_ERR 0x1C84 error?
> 
> tsec0: is connected to phy with add 0
> tsec1: is direct connected to hw without a phy.
> 
> So if i had tsec0 connected the driver will think both tsec0 and tsec1 is
> connected because i use the same phy address for both? or what?
> 
> In the BSP i setup the phy and interrupt information with the following.
> 
> add_one_tsec(TSEC0_OFF, TSEC0_IRQ_TX, TSEC0_IRQ_RX, TSEC0_IRQ_ERR, mac, 0);
> add_one_tsec(TSEC1_OFF, TSEC1_IRQ_TX, TSEC1_IRQ_RX, TSEC1_IRQ_ERR, mac, 0);
> 
> And if i should use the emu_phy i will start the io-pkt with following args.
> 
> io-pkt-v4-hc -dmpc85xx syspage,emu_phy=1
> 
> and chance the add_one_tsec to
> add_one_tsec(TSEC1_OFF, TSEC1_IRQ_TX, TSEC1_IRQ_RX, TSEC1_IRQ_ERR, mac, 1);
> 
> Is this correct?
> 
> /Lasse
> 
> 
> 
> 
> _______________________________________________
> 
> Networking Drivers
> http://community.qnx.com/sf/go/post46972
>

Bjoern Weber

02/11/2010 9:00 AM

post47125

Re: mpc85xx driver err

Hello,

they were able to make it run by disabling the CRC checking on one device. This sounds rather spooky to me: We did a 
small change in the ethernet driver, the line:
#define RXBD_ERR (RXBD_TR | RXBD_OV | RXBD_CR | RXBD_SH | RXBD_NO)

was changed to

#define RXBD_ERR (RXBD_TR | RXBD_OV | RXBD_SH | RXBD_NO)

So basically we just ignore CRC errors. Of course this is not the best solution but it works for now.

My guess is that your driver has a error with the combination of no PHY and EtherCAT, which results in a CRC error even 
though the frames actually have a valid CRC.

This is a workaround, yet it still feels like the problem is deeper within.

  bweb

Andrew Boyd(deleted)

02/11/2010 9:22 AM

post47132

RE: mpc85xx driver err

Wow.  You want to perform some tests to ensure that
you aren't quietly corrupting packets somewhere,
and that the crc error bit is really erroneously
being set.

--
aboyd

Lasse Skov(deleted)

02/17/2010 10:48 AM

post47523

Re: RE: mpc85xx driver err

Hey

As Björn wrote we can get it to work if chance the line.

#define RXBD_ERR (RXBD_TR | RXBD_OV | RXBD_CR | RXBD_SH | RXBD_NO)
was changed to
#define RXBD_ERR (RXBD_TR | RXBD_OV | RXBD_SH | RXBD_NO)

But if I try to start it with the emu phy there is at problem. Because in nicinfo my TSEC1 is Link DOWN

My line for starting the io-pkt is now:
io-pkt-v4-hc -dmpc85xx pci=0,syspage,verbose=0 -dmpc85xx pci=1,emu_phy=1,syspage,verbose=10,duplex=1,speed=100,
promiscuous,probe_phy=0

In the devnp-mpc85xx.so i had also chanced the line for disable autonegotioate.

was
bmsr = BMSR_AN_ABILITY | BMSR_LINK_STATUS | BMSR_EXT_STATUS;
chanced to
bmsr = BMSR_LINK_STATUS | BMSR_EXT_STATUS;


So I cant figure out how to tell the driver to think that there is link, so nicinfo tsec1 is not LINK DOWN.

Ant i know that the physical HW connection is working. Because if i start io-pkt with phy address 0 on both devices.
And starting a bridgemode connection througth my two tsec controllers. Then i can coumminicate from tsec0 to 1 and back 
again.

I had attached the slogger.

/LSkov

Attachment:

slogger 4.44 KB

Hugh Brown

02/17/2010 10:58 AM

post47527

Re: mpc85xx driver err

Unfortunately it is beyond the scope of this forum to try and fix your
problems. You have the source to the driver as well as the chipset
documentation, so it is up to you and try to sort out your
hardware/software. The other solution is to request custom engineering work
for your specific hardware.

Hugh.


On 10-02-17 10:48 AM, "Lasse Skov" <community-noreply@qnx.com> wrote:

> Hey
> 
> As Björn wrote we can get it to work if chance the line.
> 
> #define RXBD_ERR (RXBD_TR | RXBD_OV | RXBD_CR | RXBD_SH | RXBD_NO)
> was changed to
> #define RXBD_ERR (RXBD_TR | RXBD_OV | RXBD_SH | RXBD_NO)
> 
> But if I try to start it with the emu phy there is at problem. Because in
> nicinfo my TSEC1 is Link DOWN
> 
> My line for starting the io-pkt is now:
> io-pkt-v4-hc -dmpc85xx pci=0,syspage,verbose=0 -dmpc85xx
> pci=1,emu_phy=1,syspage,verbose=10,duplex=1,speed=100,promiscuous,probe_phy=0
> 
> In the devnp-mpc85xx.so i had also chanced the line for disable
> autonegotioate.
> 
> was
> bmsr = BMSR_AN_ABILITY | BMSR_LINK_STATUS | BMSR_EXT_STATUS;
> chanced to
> bmsr = BMSR_LINK_STATUS | BMSR_EXT_STATUS;
> 
> 
> So I cant figure out how to tell the driver to think that there is link, so
> nicinfo tsec1 is not LINK DOWN.
> 
> Ant i know that the physical HW connection is working. Because if i start
> io-pkt with phy address 0 on both devices.
> And starting a bridgemode connection througth my two tsec controllers. Then i
> can coumminicate from tsec0 to 1 and back again.
> 
> I had attached the slogger.
> 
> /LSkov
> 
>



_______________________________________________

Networking
> Drivers
http://community.qnx.com/sf/go/post47523

Return

The text you entered is not a valid object ID
More Information
Object IDs begin with an object prefix and end with a number. For example, if you enter
artf2345
the application will jump directly to an artifact with the ID artf2345. Some valid object prefixes are:
artf	for an artifact
doc	for a document
page	for a project page
topc	for a discussion topic
wiki	for a wiki page