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
|
|
|
Hugh Brown
07/14/2009 8:00 AM
post33714
|
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
|
> 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)
|
Re: RE: mpc85xx driver err
|
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)
|
RE: RE: mpc85xx driver err
|
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
|
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
|
> 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
|
Re: RE: mpc85xx driver err
|
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)
|
RE: RE: mpc85xx driver err
|
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
|
Re: RE: RE: mpc85xx driver err
|
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)
|
RE: RE: RE: mpc85xx driver err
|
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
|
The missing nicinfo was my mistake. I attached it to this post.
bweb
|
|
|
Andrew Boyd(deleted)
02/09/2010 10:38 AM
post46926
|
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)
|
Re: RE: mpc85xx driver err
|
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
02/09/2010 1:41 PM
post46959
|
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
|
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
|
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
|
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
|
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)
|
Re: RE: mpc85xx driver err
|
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
|
|
|
Hugh Brown
02/17/2010 10:58 AM
post47527
|
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
|
|
|
|