* Re: DPAA Ethernet traffice troubles with Linux kernel
@ 2018-01-16 17:57 ` Joakim Tjernlund
0 siblings, 0 replies; 63+ messages in thread
From: Joakim Tjernlund @ 2018-01-16 17:57 UTC (permalink / raw)
To: andrew; +Cc: linuxppc-dev, netdev, madalin.bucur, madskateman
T24gVGh1LCAxOTcwLTAxLTAxIGF0IDAwOjAwICswMDAwLCBBbmRyZXcgTHVubiB3cm90ZToNCj4g
Q0FVVElPTjogVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0aGUgb3JnYW5p
emF0aW9uLiBEbyBub3QgY2xpY2sgbGlua3Mgb3Igb3BlbiBhdHRhY2htZW50cyB1bmxlc3MgeW91
IHJlY29nbml6ZSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50IGlzIHNhZmUuDQo+IA0K
PiANCj4gPiBIaSwganVzdCBzYXcgdGhpcyBhbmQgdGhvdWdodCBvZiBhIHNtYWxsIHBhdGNoIEkg
anVzdCB3cm90ZSBmb3IgbWRpbyBidXMsIG8gaWRlYQ0KPiA+IGlmIGl0IGlzIHJlbGV2YW50IGJ1
dCBoZXJlIGdvZXM6DQo+ID4gDQo+ID4gRnJvbSBmZTBiOThkNTRhNzk3Nzk0ODI3MDA2NzYzMzFi
NGQxMGEwZjNjYWRhIE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQ0KPiA+IEZyb206IEpvYWtpbSBU
amVybmx1bmQgPGpvYWtpbS50amVybmx1bmRAaW5maW5lcmEuY29tPg0KPiA+IERhdGU6IFN1biwg
MTQgSmFuIDIwMTggMjE6Mjc6MjAgKzAxMDANCj4gPiBTdWJqZWN0OiBbUEFUQ0hdIG9mX21kaW9i
dXNfcmVnaXN0ZXI6IENvbnRpbnVlIGFmdGVyIGVycm9yDQo+ID4gDQo+ID4gb2ZfbWRpb2J1c19y
ZWdpc3RlciB1bnJlZ2lzdGVyIGl0c2VsZiBpZiBvbmUgcGh5IGZhaWxzIHRvIHJlZ2lzdGVyDQo+
ID4gd2hpY2ggaXMgYmFkIGZvciBzeXN0ZW0gaGF2aW5nIGFsbCBpdHMgUEhZcyBvbiB0aGUgc2Ft
ZSBNRElPIGJ1cy4NCj4gPiBKdXN0IGxvZyB0aGUgZXJyb3IgYW5kIGNvbnRpbnVlIHdpdGggdGhl
IHJlbWFpbmluZyBQSFlzIGluc3RlYWQuDQo+ID4gDQo+ID4gU2lnbmVkLW9mZi1ieTogSm9ha2lt
IFRqZXJubHVuZCA8am9ha2ltLnRqZXJubHVuZEBpbmZpbmVyYS5jb20+DQo+IA0KPiBIaSBKb2Fr
aW0NCj4gDQo+IFlvdSBhcHBlYXIgdG8gYmUgdXNpbmcgYW4gb2xkIGtlcm5lbC4gVGFrZSBhIGxv
b2sgYXQ6DQoNCk5vdCByZWFsbHksIEkgYW0gdXNpbmcgNC4xNC54IGFuZCBJIGRvbid0IHRoaW5r
IHRoYXQgaXMgb2xkLiBTZWVtcyBsaWtlIHRoaXMNCnBhdGNoIGhhc24ndCBiZWVuIHNlbnQgdG8g
NC4xNC54Lg0KDQpJIHdvbmRlciBpZiBJIG1pZ2h0IGJlIG1pc3Npbmcgc29tZXRoaW5nIGVsc2Us
IHdlIGp1c3QgbW92ZWQgdG8gNC4xNCBhbmQgbm90aWMgdGhhdCBhbGwNCm91ciBmaXhlZCBQSFlz
IGFyZSBub24gZnVuY3Rpb25pbmc6DQpmc2xfbWFjIGZmZTRlMjAwMC5ldGhlcm5ldDogRk1hbiBN
RU1BQw0KZnNsX21hYyBmZmU0ZTIwMDAuZXRoZXJuZXQ6IEZNYW4gTUFDIGFkZHJlc3M6IDAwOjA2
OjljOjBiOjA2OjIwDQpmc2xfbWFjIGRwYWEtZXRoZXJuZXQuMDogX19kZXZtX3JlcXVlc3RfbWVt
X3JlZ2lvbihtYWMpIGZhaWxlZA0KZnNsX21hYzogcHJvYmUgb2YgZHBhYS1ldGhlcm5ldC4wIGZh
aWxlZCB3aXRoIGVycm9yIC0xNg0KZnNsX21hYyBmZmU0ZTQwMDAuZXRoZXJuZXQ6IEZNYW4gTUVN
QUMNCmZzbF9tYWMgZmZlNGU0MDAwLmV0aGVybmV0OiBGTWFuIE1BQyBhZGRyZXNzOiAwMDowNjo5
YzowYjowNjoyMQ0KZnNsX21hYyBkcGFhLWV0aGVybmV0LjE6IF9fZGV2bV9yZXF1ZXN0X21lbV9y
ZWdpb24obWFjKSBmYWlsZWQNCmZzbF9tYWM6IHByb2JlIG9mIGRwYWEtZXRoZXJuZXQuMSBmYWls
ZWQgd2l0aCBlcnJvciAtMTYNCmZzbF9tYWMgZmZlNGU2MDAwLmV0aGVybmV0OiBGTWFuIE1FTUFD
DQpmc2xfbWFjIGZmZTRlNjAwMC5ldGhlcm5ldDogRk1hbiBNQUMgYWRkcmVzczogMDA6MDY6OWM6
MGI6MDY6MjINCmZzbF9tYWMgZHBhYS1ldGhlcm5ldC4yOiBfX2Rldm1fcmVxdWVzdF9tZW1fcmVn
aW9uKG1hYykgZmFpbGVkDQpmc2xfbWFjOiBwcm9iZSBvZiBkcGFhLWV0aGVybmV0LjIgZmFpbGVk
IHdpdGggZXJyb3IgLTE2DQpmc2xfbWFjIGZmZTRlODAwMC5ldGhlcm5ldDogRk1hbiBNRU1BQw0K
ZnNsX21hYyBmZmU0ZTgwMDAuZXRoZXJuZXQ6IEZNYW4gTUFDIGFkZHJlc3M6IDAwOjA2OjljOjBi
OjA2OjIzDQpmc2xfbWFjIGRwYWEtZXRoZXJuZXQuMzogX19kZXZtX3JlcXVlc3RfbWVtX3JlZ2lv
bihtYWMpIGZhaWxlZA0KZnNsX21hYzogcHJvYmUgb2YgZHBhYS1ldGhlcm5ldC4zIGZhaWxlZCB3
aXRoIGVycm9yIC0xNg0KDQpGZWVscyBsaWtlIEZNQU4gc3RpbGwgdGhpbmsgdGhlcmUgYXJlIHJl
YWwgUEhZcyB0aGVyZSA/DQo+IA0KPiBjb21taXQgOTVmNTY2ZGUwMjY5YTBjNTlmZDZhNzM3YTE0
NzczMTMwMjEzNjQyOQ0KPiBBdXRob3I6IE1hZGFsaW4gQnVjdXIgPG1hZGFsaW4uYnVjdXJAbnhw
LmNvbT4NCj4gRGF0ZTogICBUdWUgSmFuIDkgMTQ6NDM6MzQgMjAxOCArMDIwMA0KPiANCj4gICAg
IG9mX21kaW86IGF2b2lkIE1ESU8gYnVzIHJlbW92YWwgd2hlbiBhIFBIWSBpcyBtaXNzaW5nDQo+
IA0KPiAgICAgSWYgb25lIG9mIHRoZSBjaGlsZCBkZXZpY2VzIGlzIG1pc3NpbmcgdGhlIG9mX21k
aW9idXNfcmVnaXN0ZXJfcGh5KCkNCj4gICAgIGNhbGwgd2lsbCByZXR1cm4gLUVOT0RFVi4gV2hl
biBhIG1pc3NpbmcgZGV2aWNlIGlzIGVuY291bnRlcmVkIHRoZQ0KPiAgICAgcmVnaXN0cmF0aW9u
IG9mIHRoZSByZW1haW5pbmcgUEhZcyBpcyBzdG9wcGVkIGFuZCB0aGUgTURJTyBidXMgd2lsbA0K
PiAgICAgZmFpbCB0byByZWdpc3Rlci4gUHJvcGFnYXRlIGFsbCBlcnJvcnMgZXhjZXB0IEVOT0RF
ViB0byBhdm9pZCBpdC4NCj4gDQo+ICAgICBTaWduZWQtb2ZmLWJ5OiBNYWRhbGluIEJ1Y3VyIDxt
YWRhbGluLmJ1Y3VyQG54cC5jb20+DQo+ICAgICBSZXZpZXdlZC1ieTogQW5kcmV3IEx1bm4gPGFu
ZHJld0BsdW5uLmNoPg0KPiAgICAgU2lnbmVkLW9mZi1ieTogRGF2aWQgUy4gTWlsbGVyIDxkYXZl
bUBkYXZlbWxvZnQubmV0Pg0KPiANCj4gDQo+ICAgICBBbmRyZXcNCg==
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: DPAA Ethernet traffice troubles with Linux kernel
2018-01-16 17:57 ` Joakim Tjernlund
@ 2018-01-16 18:16 ` mad skateman
-1 siblings, 0 replies; 63+ messages in thread
From: mad skateman @ 2018-01-16 18:16 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: andrew, madalin.bucur, linuxppc-dev, netdev
[-- Attachment #1: Type: text/plain, Size: 3997 bytes --]
Hi,
I have been looking deeper into my wireshark packet captures and found
something that could be helpfull.
I can see that the Ethernet NICS at least do something. ARP BROADCAST
traffic is seen.
But i also found some packets...which have LG BITs set to 1 .. when i think
0 should be the correct value..
This has something to do with the MAC adresses being non Authorative.. and
since whe can use Uboot and choose any Mac addr we want, this could make
sense.. More info about this
https://osqa-ask.wireshark.org/questions/59761/oui-lookup-tool-does-not-recognize-local-addresses
Logs like these appear: not the original.
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Address: Broadcast (ff:ff:ff:ff:ff:ff)
.... ..1. .... .... .... .... = LG bit: Locally administered address (this
is NOT the factory default)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
Will try to get the picture more clear... but think about this..
On Tue, Jan 16, 2018 at 6:57 PM, Joakim Tjernlund <
Joakim.Tjernlund@infinera.com> wrote:
> On Thu, 1970-01-01 at 00:00 +0000, Andrew Lunn wrote:
> > CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
> >
> >
> > > Hi, just saw this and thought of a small patch I just wrote for mdio
> bus, o idea
> > > if it is relevant but here goes:
> > >
> > > From fe0b98d54a79779482700676331b4d10a0f3cada Mon Sep 17 00:00:00 2001
> > > From: Joakim Tjernlund <joakim.tjernlund@infinera.com>
> > > Date: Sun, 14 Jan 2018 21:27:20 +0100
> > > Subject: [PATCH] of_mdiobus_register: Continue after error
> > >
> > > of_mdiobus_register unregister itself if one phy fails to register
> > > which is bad for system having all its PHYs on the same MDIO bus.
> > > Just log the error and continue with the remaining PHYs instead.
> > >
> > > Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com>
> >
> > Hi Joakim
> >
> > You appear to be using an old kernel. Take a look at:
>
> Not really, I am using 4.14.x and I don't think that is old. Seems like
> this
> patch hasn't been sent to 4.14.x.
>
> I wonder if I might be missing something else, we just moved to 4.14 and
> notic that all
> our fixed PHYs are non functioning:
> fsl_mac ffe4e2000.ethernet: FMan MEMAC
> fsl_mac ffe4e2000.ethernet: FMan MAC address: 00:06:9c:0b:06:20
> fsl_mac dpaa-ethernet.0: __devm_request_mem_region(mac) failed
> fsl_mac: probe of dpaa-ethernet.0 failed with error -16
> fsl_mac ffe4e4000.ethernet: FMan MEMAC
> fsl_mac ffe4e4000.ethernet: FMan MAC address: 00:06:9c:0b:06:21
> fsl_mac dpaa-ethernet.1: __devm_request_mem_region(mac) failed
> fsl_mac: probe of dpaa-ethernet.1 failed with error -16
> fsl_mac ffe4e6000.ethernet: FMan MEMAC
> fsl_mac ffe4e6000.ethernet: FMan MAC address: 00:06:9c:0b:06:22
> fsl_mac dpaa-ethernet.2: __devm_request_mem_region(mac) failed
> fsl_mac: probe of dpaa-ethernet.2 failed with error -16
> fsl_mac ffe4e8000.ethernet: FMan MEMAC
> fsl_mac ffe4e8000.ethernet: FMan MAC address: 00:06:9c:0b:06:23
> fsl_mac dpaa-ethernet.3: __devm_request_mem_region(mac) failed
> fsl_mac: probe of dpaa-ethernet.3 failed with error -16
>
> Feels like FMAN still think there are real PHYs there ?
> >
> > commit 95f566de0269a0c59fd6a737a147731302136429
> > Author: Madalin Bucur <madalin.bucur@nxp.com>
> > Date: Tue Jan 9 14:43:34 2018 +0200
> >
> > of_mdio: avoid MDIO bus removal when a PHY is missing
> >
> > If one of the child devices is missing the of_mdiobus_register_phy()
> > call will return -ENODEV. When a missing device is encountered the
> > registration of the remaining PHYs is stopped and the MDIO bus will
> > fail to register. Propagate all errors except ENODEV to avoid it.
> >
> > Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
> > Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> > Signed-off-by: David S. Miller <davem@davemloft.net>
> >
> >
> > Andrew
>
[-- Attachment #2: Type: text/html, Size: 6177 bytes --]
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: DPAA Ethernet traffice troubles with Linux kernel
@ 2018-01-16 18:16 ` mad skateman
0 siblings, 0 replies; 63+ messages in thread
From: mad skateman @ 2018-01-16 18:16 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: andrew, linuxppc-dev, netdev, madalin.bucur
[-- Attachment #1: Type: text/plain, Size: 3997 bytes --]
Hi,
I have been looking deeper into my wireshark packet captures and found
something that could be helpfull.
I can see that the Ethernet NICS at least do something. ARP BROADCAST
traffic is seen.
But i also found some packets...which have LG BITs set to 1 .. when i think
0 should be the correct value..
This has something to do with the MAC adresses being non Authorative.. and
since whe can use Uboot and choose any Mac addr we want, this could make
sense.. More info about this
https://osqa-ask.wireshark.org/questions/59761/oui-lookup-tool-does-not-recognize-local-addresses
Logs like these appear: not the original.
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Address: Broadcast (ff:ff:ff:ff:ff:ff)
.... ..1. .... .... .... .... = LG bit: Locally administered address (this
is NOT the factory default)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
Will try to get the picture more clear... but think about this..
On Tue, Jan 16, 2018 at 6:57 PM, Joakim Tjernlund <
Joakim.Tjernlund@infinera.com> wrote:
> On Thu, 1970-01-01 at 00:00 +0000, Andrew Lunn wrote:
> > CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
> >
> >
> > > Hi, just saw this and thought of a small patch I just wrote for mdio
> bus, o idea
> > > if it is relevant but here goes:
> > >
> > > From fe0b98d54a79779482700676331b4d10a0f3cada Mon Sep 17 00:00:00 2001
> > > From: Joakim Tjernlund <joakim.tjernlund@infinera.com>
> > > Date: Sun, 14 Jan 2018 21:27:20 +0100
> > > Subject: [PATCH] of_mdiobus_register: Continue after error
> > >
> > > of_mdiobus_register unregister itself if one phy fails to register
> > > which is bad for system having all its PHYs on the same MDIO bus.
> > > Just log the error and continue with the remaining PHYs instead.
> > >
> > > Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com>
> >
> > Hi Joakim
> >
> > You appear to be using an old kernel. Take a look at:
>
> Not really, I am using 4.14.x and I don't think that is old. Seems like
> this
> patch hasn't been sent to 4.14.x.
>
> I wonder if I might be missing something else, we just moved to 4.14 and
> notic that all
> our fixed PHYs are non functioning:
> fsl_mac ffe4e2000.ethernet: FMan MEMAC
> fsl_mac ffe4e2000.ethernet: FMan MAC address: 00:06:9c:0b:06:20
> fsl_mac dpaa-ethernet.0: __devm_request_mem_region(mac) failed
> fsl_mac: probe of dpaa-ethernet.0 failed with error -16
> fsl_mac ffe4e4000.ethernet: FMan MEMAC
> fsl_mac ffe4e4000.ethernet: FMan MAC address: 00:06:9c:0b:06:21
> fsl_mac dpaa-ethernet.1: __devm_request_mem_region(mac) failed
> fsl_mac: probe of dpaa-ethernet.1 failed with error -16
> fsl_mac ffe4e6000.ethernet: FMan MEMAC
> fsl_mac ffe4e6000.ethernet: FMan MAC address: 00:06:9c:0b:06:22
> fsl_mac dpaa-ethernet.2: __devm_request_mem_region(mac) failed
> fsl_mac: probe of dpaa-ethernet.2 failed with error -16
> fsl_mac ffe4e8000.ethernet: FMan MEMAC
> fsl_mac ffe4e8000.ethernet: FMan MAC address: 00:06:9c:0b:06:23
> fsl_mac dpaa-ethernet.3: __devm_request_mem_region(mac) failed
> fsl_mac: probe of dpaa-ethernet.3 failed with error -16
>
> Feels like FMAN still think there are real PHYs there ?
> >
> > commit 95f566de0269a0c59fd6a737a147731302136429
> > Author: Madalin Bucur <madalin.bucur@nxp.com>
> > Date: Tue Jan 9 14:43:34 2018 +0200
> >
> > of_mdio: avoid MDIO bus removal when a PHY is missing
> >
> > If one of the child devices is missing the of_mdiobus_register_phy()
> > call will return -ENODEV. When a missing device is encountered the
> > registration of the remaining PHYs is stopped and the MDIO bus will
> > fail to register. Propagate all errors except ENODEV to avoid it.
> >
> > Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
> > Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> > Signed-off-by: David S. Miller <davem@davemloft.net>
> >
> >
> > Andrew
>
[-- Attachment #2: Type: text/html, Size: 6177 bytes --]
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: DPAA Ethernet traffice troubles with Linux kernel
2018-01-16 17:57 ` Joakim Tjernlund
@ 2018-01-16 18:38 ` mad skateman
-1 siblings, 0 replies; 63+ messages in thread
From: mad skateman @ 2018-01-16 18:38 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: andrew, madalin.bucur, linuxppc-dev, netdev
[-- Attachment #1: Type: text/plain, Size: 4477 bytes --]
Hi,
I have been looking deeper into my wireshark packet captures and found
something that could be helpfull.
I can see using wireshark that the Ethernet NIC at least does something.
ARP BROADCAST traffic is seen.
But i also found some packets...which have LG BITs set to 1 .. when i think
0 should be the correct value..
This has something to do with the MAC adresses being locally administered
.. and since whe can use Uboot and choose any Mac addr we want, this could
make sense..
These types of Logs also apear in my Wireshark Capture files... ( these are
not my org. logs)
Ethernet II, Src: Microchi_8f:c6:a8 (d8:80:39:8f:c6:a8), Dst: Broadcast
(ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Address: Broadcast (ff:ff:ff:ff:ff:ff)
.... ..1. .... .... .... .... = LG bit: Locally administered address (this
is NOT the factory default)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
Source: Microchi_8f:c6:a8 (d8:80:39:8f:c6:a8)
Address: Microchi_8f:c6:a8 (d8:80:39:8f:c6:a8)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory
default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IP (0x0800)
Internet Protocol Version 4, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255
(255.255.255.255)
In the link below some similair Logs and problems regarding DHCP for
example.
Dave
https://www.microchip.com/forums/m/tm.aspx?m=956881&fp=1&p=2
On Tue, Jan 16, 2018 at 6:57 PM, Joakim Tjernlund <
Joakim.Tjernlund@infinera.com> wrote:
> On Thu, 1970-01-01 at 00:00 +0000, Andrew Lunn wrote:
> > CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
> >
> >
> > > Hi, just saw this and thought of a small patch I just wrote for mdio
> bus, o idea
> > > if it is relevant but here goes:
> > >
> > > From fe0b98d54a79779482700676331b4d10a0f3cada Mon Sep 17 00:00:00 2001
> > > From: Joakim Tjernlund <joakim.tjernlund@infinera.com>
> > > Date: Sun, 14 Jan 2018 21:27:20 +0100
> > > Subject: [PATCH] of_mdiobus_register: Continue after error
> > >
> > > of_mdiobus_register unregister itself if one phy fails to register
> > > which is bad for system having all its PHYs on the same MDIO bus.
> > > Just log the error and continue with the remaining PHYs instead.
> > >
> > > Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com>
> >
> > Hi Joakim
> >
> > You appear to be using an old kernel. Take a look at:
>
> Not really, I am using 4.14.x and I don't think that is old. Seems like
> this
> patch hasn't been sent to 4.14.x.
>
> I wonder if I might be missing something else, we just moved to 4.14 and
> notic that all
> our fixed PHYs are non functioning:
> fsl_mac ffe4e2000.ethernet: FMan MEMAC
> fsl_mac ffe4e2000.ethernet: FMan MAC address: 00:06:9c:0b:06:20
> fsl_mac dpaa-ethernet.0: __devm_request_mem_region(mac) failed
> fsl_mac: probe of dpaa-ethernet.0 failed with error -16
> fsl_mac ffe4e4000.ethernet: FMan MEMAC
> fsl_mac ffe4e4000.ethernet: FMan MAC address: 00:06:9c:0b:06:21
> fsl_mac dpaa-ethernet.1: __devm_request_mem_region(mac) failed
> fsl_mac: probe of dpaa-ethernet.1 failed with error -16
> fsl_mac ffe4e6000.ethernet: FMan MEMAC
> fsl_mac ffe4e6000.ethernet: FMan MAC address: 00:06:9c:0b:06:22
> fsl_mac dpaa-ethernet.2: __devm_request_mem_region(mac) failed
> fsl_mac: probe of dpaa-ethernet.2 failed with error -16
> fsl_mac ffe4e8000.ethernet: FMan MEMAC
> fsl_mac ffe4e8000.ethernet: FMan MAC address: 00:06:9c:0b:06:23
> fsl_mac dpaa-ethernet.3: __devm_request_mem_region(mac) failed
> fsl_mac: probe of dpaa-ethernet.3 failed with error -16
>
> Feels like FMAN still think there are real PHYs there ?
> >
> > commit 95f566de0269a0c59fd6a737a147731302136429
> > Author: Madalin Bucur <madalin.bucur@nxp.com>
> > Date: Tue Jan 9 14:43:34 2018 +0200
> >
> > of_mdio: avoid MDIO bus removal when a PHY is missing
> >
> > If one of the child devices is missing the of_mdiobus_register_phy()
> > call will return -ENODEV. When a missing device is encountered the
> > registration of the remaining PHYs is stopped and the MDIO bus will
> > fail to register. Propagate all errors except ENODEV to avoid it.
> >
> > Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
> > Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> > Signed-off-by: David S. Miller <davem@davemloft.net>
> >
> >
> > Andrew
>
[-- Attachment #2: Type: text/html, Size: 6495 bytes --]
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: DPAA Ethernet traffice troubles with Linux kernel
@ 2018-01-16 18:38 ` mad skateman
0 siblings, 0 replies; 63+ messages in thread
From: mad skateman @ 2018-01-16 18:38 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: andrew, linuxppc-dev, netdev, madalin.bucur
[-- Attachment #1: Type: text/plain, Size: 4477 bytes --]
Hi,
I have been looking deeper into my wireshark packet captures and found
something that could be helpfull.
I can see using wireshark that the Ethernet NIC at least does something.
ARP BROADCAST traffic is seen.
But i also found some packets...which have LG BITs set to 1 .. when i think
0 should be the correct value..
This has something to do with the MAC adresses being locally administered
.. and since whe can use Uboot and choose any Mac addr we want, this could
make sense..
These types of Logs also apear in my Wireshark Capture files... ( these are
not my org. logs)
Ethernet II, Src: Microchi_8f:c6:a8 (d8:80:39:8f:c6:a8), Dst: Broadcast
(ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Address: Broadcast (ff:ff:ff:ff:ff:ff)
.... ..1. .... .... .... .... = LG bit: Locally administered address (this
is NOT the factory default)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
Source: Microchi_8f:c6:a8 (d8:80:39:8f:c6:a8)
Address: Microchi_8f:c6:a8 (d8:80:39:8f:c6:a8)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory
default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IP (0x0800)
Internet Protocol Version 4, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255
(255.255.255.255)
In the link below some similair Logs and problems regarding DHCP for
example.
Dave
https://www.microchip.com/forums/m/tm.aspx?m=956881&fp=1&p=2
On Tue, Jan 16, 2018 at 6:57 PM, Joakim Tjernlund <
Joakim.Tjernlund@infinera.com> wrote:
> On Thu, 1970-01-01 at 00:00 +0000, Andrew Lunn wrote:
> > CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
> >
> >
> > > Hi, just saw this and thought of a small patch I just wrote for mdio
> bus, o idea
> > > if it is relevant but here goes:
> > >
> > > From fe0b98d54a79779482700676331b4d10a0f3cada Mon Sep 17 00:00:00 2001
> > > From: Joakim Tjernlund <joakim.tjernlund@infinera.com>
> > > Date: Sun, 14 Jan 2018 21:27:20 +0100
> > > Subject: [PATCH] of_mdiobus_register: Continue after error
> > >
> > > of_mdiobus_register unregister itself if one phy fails to register
> > > which is bad for system having all its PHYs on the same MDIO bus.
> > > Just log the error and continue with the remaining PHYs instead.
> > >
> > > Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com>
> >
> > Hi Joakim
> >
> > You appear to be using an old kernel. Take a look at:
>
> Not really, I am using 4.14.x and I don't think that is old. Seems like
> this
> patch hasn't been sent to 4.14.x.
>
> I wonder if I might be missing something else, we just moved to 4.14 and
> notic that all
> our fixed PHYs are non functioning:
> fsl_mac ffe4e2000.ethernet: FMan MEMAC
> fsl_mac ffe4e2000.ethernet: FMan MAC address: 00:06:9c:0b:06:20
> fsl_mac dpaa-ethernet.0: __devm_request_mem_region(mac) failed
> fsl_mac: probe of dpaa-ethernet.0 failed with error -16
> fsl_mac ffe4e4000.ethernet: FMan MEMAC
> fsl_mac ffe4e4000.ethernet: FMan MAC address: 00:06:9c:0b:06:21
> fsl_mac dpaa-ethernet.1: __devm_request_mem_region(mac) failed
> fsl_mac: probe of dpaa-ethernet.1 failed with error -16
> fsl_mac ffe4e6000.ethernet: FMan MEMAC
> fsl_mac ffe4e6000.ethernet: FMan MAC address: 00:06:9c:0b:06:22
> fsl_mac dpaa-ethernet.2: __devm_request_mem_region(mac) failed
> fsl_mac: probe of dpaa-ethernet.2 failed with error -16
> fsl_mac ffe4e8000.ethernet: FMan MEMAC
> fsl_mac ffe4e8000.ethernet: FMan MAC address: 00:06:9c:0b:06:23
> fsl_mac dpaa-ethernet.3: __devm_request_mem_region(mac) failed
> fsl_mac: probe of dpaa-ethernet.3 failed with error -16
>
> Feels like FMAN still think there are real PHYs there ?
> >
> > commit 95f566de0269a0c59fd6a737a147731302136429
> > Author: Madalin Bucur <madalin.bucur@nxp.com>
> > Date: Tue Jan 9 14:43:34 2018 +0200
> >
> > of_mdio: avoid MDIO bus removal when a PHY is missing
> >
> > If one of the child devices is missing the of_mdiobus_register_phy()
> > call will return -ENODEV. When a missing device is encountered the
> > registration of the remaining PHYs is stopped and the MDIO bus will
> > fail to register. Propagate all errors except ENODEV to avoid it.
> >
> > Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
> > Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> > Signed-off-by: David S. Miller <davem@davemloft.net>
> >
> >
> > Andrew
>
[-- Attachment #2: Type: text/html, Size: 6495 bytes --]
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: DPAA Ethernet traffice troubles with Linux kernel
2018-01-16 17:57 ` Joakim Tjernlund
@ 2018-01-16 18:39 ` mad skateman
-1 siblings, 0 replies; 63+ messages in thread
From: mad skateman @ 2018-01-16 18:39 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: andrew, madalin.bucur, linuxppc-dev, netdev
[-- Attachment #1: Type: text/plain, Size: 4415 bytes --]
Hi,
I have been looking deeper into my wireshark packet captures and found
something that could be helpfull.
I can see using wireshark that the Ethernet NIC at least does something.
ARP BROADCAST traffic is seen.
But i also found some packets...which have LG BITs set to 1 .. when i think
0 should be the correct value..
This has something to do with the MAC adresses being locally administered
.. and since whe can use Uboot and choose any Mac addr we want, this could
make sense..
These types of Logs also apear in my Wireshark Capture files... ( these are
not my org. logs)
Ethernet II, Src: Microchi_8f:c6:a8 (d8:80:39:8f:c6:a8), Dst: Broadcast
(ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Address: Broadcast (ff:ff:ff:ff:ff:ff)
.... ..1. .... .... .... .... = LG bit: Locally administered address (this
is NOT the factory default)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
Source: Microchi_8f:c6:a8 (d8:80:39:8f:c6:a8)
Address: Microchi_8f:c6:a8 (d8:80:39:8f:c6:a8)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory
default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IP (0x0800)
Internet Protocol Version 4, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255
(255.255.255.255)
In the link below some similair Logs and problems regarding DHCP for
example.
Dave
On Tue, Jan 16, 2018 at 6:57 PM, Joakim Tjernlund <
Joakim.Tjernlund@infinera.com> wrote:
> On Thu, 1970-01-01 at 00:00 +0000, Andrew Lunn wrote:
> > CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
> >
> >
> > > Hi, just saw this and thought of a small patch I just wrote for mdio
> bus, o idea
> > > if it is relevant but here goes:
> > >
> > > From fe0b98d54a79779482700676331b4d10a0f3cada Mon Sep 17 00:00:00 2001
> > > From: Joakim Tjernlund <joakim.tjernlund@infinera.com>
> > > Date: Sun, 14 Jan 2018 21:27:20 +0100
> > > Subject: [PATCH] of_mdiobus_register: Continue after error
> > >
> > > of_mdiobus_register unregister itself if one phy fails to register
> > > which is bad for system having all its PHYs on the same MDIO bus.
> > > Just log the error and continue with the remaining PHYs instead.
> > >
> > > Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com>
> >
> > Hi Joakim
> >
> > You appear to be using an old kernel. Take a look at:
>
> Not really, I am using 4.14.x and I don't think that is old. Seems like
> this
> patch hasn't been sent to 4.14.x.
>
> I wonder if I might be missing something else, we just moved to 4.14 and
> notic that all
> our fixed PHYs are non functioning:
> fsl_mac ffe4e2000.ethernet: FMan MEMAC
> fsl_mac ffe4e2000.ethernet: FMan MAC address: 00:06:9c:0b:06:20
> fsl_mac dpaa-ethernet.0: __devm_request_mem_region(mac) failed
> fsl_mac: probe of dpaa-ethernet.0 failed with error -16
> fsl_mac ffe4e4000.ethernet: FMan MEMAC
> fsl_mac ffe4e4000.ethernet: FMan MAC address: 00:06:9c:0b:06:21
> fsl_mac dpaa-ethernet.1: __devm_request_mem_region(mac) failed
> fsl_mac: probe of dpaa-ethernet.1 failed with error -16
> fsl_mac ffe4e6000.ethernet: FMan MEMAC
> fsl_mac ffe4e6000.ethernet: FMan MAC address: 00:06:9c:0b:06:22
> fsl_mac dpaa-ethernet.2: __devm_request_mem_region(mac) failed
> fsl_mac: probe of dpaa-ethernet.2 failed with error -16
> fsl_mac ffe4e8000.ethernet: FMan MEMAC
> fsl_mac ffe4e8000.ethernet: FMan MAC address: 00:06:9c:0b:06:23
> fsl_mac dpaa-ethernet.3: __devm_request_mem_region(mac) failed
> fsl_mac: probe of dpaa-ethernet.3 failed with error -16
>
> Feels like FMAN still think there are real PHYs there ?
> >
> > commit 95f566de0269a0c59fd6a737a147731302136429
> > Author: Madalin Bucur <madalin.bucur@nxp.com>
> > Date: Tue Jan 9 14:43:34 2018 +0200
> >
> > of_mdio: avoid MDIO bus removal when a PHY is missing
> >
> > If one of the child devices is missing the of_mdiobus_register_phy()
> > call will return -ENODEV. When a missing device is encountered the
> > registration of the remaining PHYs is stopped and the MDIO bus will
> > fail to register. Propagate all errors except ENODEV to avoid it.
> >
> > Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
> > Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> > Signed-off-by: David S. Miller <davem@davemloft.net>
> >
> >
> > Andrew
>
[-- Attachment #2: Type: text/html, Size: 6388 bytes --]
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: DPAA Ethernet traffice troubles with Linux kernel
@ 2018-01-16 18:39 ` mad skateman
0 siblings, 0 replies; 63+ messages in thread
From: mad skateman @ 2018-01-16 18:39 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: andrew, linuxppc-dev, netdev, madalin.bucur
[-- Attachment #1: Type: text/plain, Size: 4415 bytes --]
Hi,
I have been looking deeper into my wireshark packet captures and found
something that could be helpfull.
I can see using wireshark that the Ethernet NIC at least does something.
ARP BROADCAST traffic is seen.
But i also found some packets...which have LG BITs set to 1 .. when i think
0 should be the correct value..
This has something to do with the MAC adresses being locally administered
.. and since whe can use Uboot and choose any Mac addr we want, this could
make sense..
These types of Logs also apear in my Wireshark Capture files... ( these are
not my org. logs)
Ethernet II, Src: Microchi_8f:c6:a8 (d8:80:39:8f:c6:a8), Dst: Broadcast
(ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Address: Broadcast (ff:ff:ff:ff:ff:ff)
.... ..1. .... .... .... .... = LG bit: Locally administered address (this
is NOT the factory default)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
Source: Microchi_8f:c6:a8 (d8:80:39:8f:c6:a8)
Address: Microchi_8f:c6:a8 (d8:80:39:8f:c6:a8)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory
default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IP (0x0800)
Internet Protocol Version 4, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255
(255.255.255.255)
In the link below some similair Logs and problems regarding DHCP for
example.
Dave
On Tue, Jan 16, 2018 at 6:57 PM, Joakim Tjernlund <
Joakim.Tjernlund@infinera.com> wrote:
> On Thu, 1970-01-01 at 00:00 +0000, Andrew Lunn wrote:
> > CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
> >
> >
> > > Hi, just saw this and thought of a small patch I just wrote for mdio
> bus, o idea
> > > if it is relevant but here goes:
> > >
> > > From fe0b98d54a79779482700676331b4d10a0f3cada Mon Sep 17 00:00:00 2001
> > > From: Joakim Tjernlund <joakim.tjernlund@infinera.com>
> > > Date: Sun, 14 Jan 2018 21:27:20 +0100
> > > Subject: [PATCH] of_mdiobus_register: Continue after error
> > >
> > > of_mdiobus_register unregister itself if one phy fails to register
> > > which is bad for system having all its PHYs on the same MDIO bus.
> > > Just log the error and continue with the remaining PHYs instead.
> > >
> > > Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com>
> >
> > Hi Joakim
> >
> > You appear to be using an old kernel. Take a look at:
>
> Not really, I am using 4.14.x and I don't think that is old. Seems like
> this
> patch hasn't been sent to 4.14.x.
>
> I wonder if I might be missing something else, we just moved to 4.14 and
> notic that all
> our fixed PHYs are non functioning:
> fsl_mac ffe4e2000.ethernet: FMan MEMAC
> fsl_mac ffe4e2000.ethernet: FMan MAC address: 00:06:9c:0b:06:20
> fsl_mac dpaa-ethernet.0: __devm_request_mem_region(mac) failed
> fsl_mac: probe of dpaa-ethernet.0 failed with error -16
> fsl_mac ffe4e4000.ethernet: FMan MEMAC
> fsl_mac ffe4e4000.ethernet: FMan MAC address: 00:06:9c:0b:06:21
> fsl_mac dpaa-ethernet.1: __devm_request_mem_region(mac) failed
> fsl_mac: probe of dpaa-ethernet.1 failed with error -16
> fsl_mac ffe4e6000.ethernet: FMan MEMAC
> fsl_mac ffe4e6000.ethernet: FMan MAC address: 00:06:9c:0b:06:22
> fsl_mac dpaa-ethernet.2: __devm_request_mem_region(mac) failed
> fsl_mac: probe of dpaa-ethernet.2 failed with error -16
> fsl_mac ffe4e8000.ethernet: FMan MEMAC
> fsl_mac ffe4e8000.ethernet: FMan MAC address: 00:06:9c:0b:06:23
> fsl_mac dpaa-ethernet.3: __devm_request_mem_region(mac) failed
> fsl_mac: probe of dpaa-ethernet.3 failed with error -16
>
> Feels like FMAN still think there are real PHYs there ?
> >
> > commit 95f566de0269a0c59fd6a737a147731302136429
> > Author: Madalin Bucur <madalin.bucur@nxp.com>
> > Date: Tue Jan 9 14:43:34 2018 +0200
> >
> > of_mdio: avoid MDIO bus removal when a PHY is missing
> >
> > If one of the child devices is missing the of_mdiobus_register_phy()
> > call will return -ENODEV. When a missing device is encountered the
> > registration of the remaining PHYs is stopped and the MDIO bus will
> > fail to register. Propagate all errors except ENODEV to avoid it.
> >
> > Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
> > Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> > Signed-off-by: David S. Miller <davem@davemloft.net>
> >
> >
> > Andrew
>
[-- Attachment #2: Type: text/html, Size: 6388 bytes --]
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: DPAA Ethernet traffice troubles with Linux kernel
2018-01-16 18:39 ` mad skateman
@ 2018-01-17 5:54 ` Christian Zigotzky
-1 siblings, 0 replies; 63+ messages in thread
From: Christian Zigotzky @ 2018-01-17 5:54 UTC (permalink / raw)
To: mad skateman; +Cc: madalin.bucur, linuxppc-dev, netdev, andrew
[-- Attachment #1: Type: text/plain, Size: 1415 bytes --]
FYI
Sent from my iPhone
> On 17. Jan 2018, at 06:50, Christian Zigotzky <chzigotzky@xenosoft.de> wrote:
>
> Hi Skateman,
>
> Fantastic! Many thanks for testing the RC8 of kernel 4.15 without PAMU support.
>
> @All
> Further information: http://forum.hyperion-entertainment.biz/viewtopic.php?f=58&p=43706#p43706
>
> Cheers,
> Christian
>
> Sent from my iPhone
>
>> On 16. Jan 2018, at 23:05, mad skateman <madskateman@gmail.com> wrote:
>>
>> Fantastic Christian..
>>
>> Your latest kernel makes the NIC work!!!
>>
>> Few tweaks to be done... like the buffer space
>>
>> Brilliant!
>
>
>
>> On 16. Jan 2018, at 21:46, Christian Zigotzky <chzigotzky@xenosoft.de> wrote:
>>
>> FYI
>>
>>> On 16 January 2018 at 9:42PM, Christian Zigotzky wrote:
>>> Hi All,
>>>
>>> I compiled the RC8 of kernel 4.15 for the X5000 without PAMU support today.
>>>
>>> Download: http://www.xenosoft.de/uImage_without_pamu.tar.gz
>>>
>>> Please test it on your AmigaOne X5000.
>>>
>>> Thanks,
>>> Christian
>>>
>>>
>>> On 16 January 2018 at 6:33PM, Madalin-cristian Bucur wrote:
>>>>> The PAMU related errors may be relevant to the issue, if you have incorrect
>>>>> settings you may have no traffic passing through. The PAMU configuration
>>>>> should be made by the bootloader. Can you try to disable CONFIG_FSL_PAMU?
>>>>>
>>>>> Madalin
>>>>>
>>>>>
>>>
[-- Attachment #2: Type: text/html, Size: 7539 bytes --]
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: DPAA Ethernet traffice troubles with Linux kernel
@ 2018-01-17 5:54 ` Christian Zigotzky
0 siblings, 0 replies; 63+ messages in thread
From: Christian Zigotzky @ 2018-01-17 5:54 UTC (permalink / raw)
To: mad skateman
Cc: Joakim Tjernlund, andrew, madalin.bucur, linuxppc-dev, netdev
[-- Attachment #1: Type: text/plain, Size: 1415 bytes --]
FYI
Sent from my iPhone
> On 17. Jan 2018, at 06:50, Christian Zigotzky <chzigotzky@xenosoft.de> wrote:
>
> Hi Skateman,
>
> Fantastic! Many thanks for testing the RC8 of kernel 4.15 without PAMU support.
>
> @All
> Further information: http://forum.hyperion-entertainment.biz/viewtopic.php?f=58&p=43706#p43706
>
> Cheers,
> Christian
>
> Sent from my iPhone
>
>> On 16. Jan 2018, at 23:05, mad skateman <madskateman@gmail.com> wrote:
>>
>> Fantastic Christian..
>>
>> Your latest kernel makes the NIC work!!!
>>
>> Few tweaks to be done... like the buffer space
>>
>> Brilliant!
>
>
>
>> On 16. Jan 2018, at 21:46, Christian Zigotzky <chzigotzky@xenosoft.de> wrote:
>>
>> FYI
>>
>>> On 16 January 2018 at 9:42PM, Christian Zigotzky wrote:
>>> Hi All,
>>>
>>> I compiled the RC8 of kernel 4.15 for the X5000 without PAMU support today.
>>>
>>> Download: http://www.xenosoft.de/uImage_without_pamu.tar.gz
>>>
>>> Please test it on your AmigaOne X5000.
>>>
>>> Thanks,
>>> Christian
>>>
>>>
>>> On 16 January 2018 at 6:33PM, Madalin-cristian Bucur wrote:
>>>>> The PAMU related errors may be relevant to the issue, if you have incorrect
>>>>> settings you may have no traffic passing through. The PAMU configuration
>>>>> should be made by the bootloader. Can you try to disable CONFIG_FSL_PAMU?
>>>>>
>>>>> Madalin
>>>>>
>>>>>
>>>
[-- Attachment #2: Type: text/html, Size: 7539 bytes --]
^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <ABA45EE3-92E3-4706-90F9-516E227646E2@xenosoft.de>]
* Re: DPAA Ethernet traffice troubles with Linux kernel
[not found] ` <ABA45EE3-92E3-4706-90F9-516E227646E2@xenosoft.de>
@ 2018-01-17 7:22 ` Christian Zigotzky
0 siblings, 0 replies; 63+ messages in thread
From: Christian Zigotzky @ 2018-01-17 7:22 UTC (permalink / raw)
To: netdev
Hi Skateman,
Fantastic! Many thanks for testing the RC8 of kernel 4.15 without PAMU support.
@All
Further information: http://forum.hyperion-entertainment.biz/viewtopic.php?f=58&p=43706#p43706
Cheers,
Christian
On 16. Jan 2018, at 23:05, mad skateman <madskateman@gmail.com> wrote:
Fantastic Christian..
Your latest kernel makes the NIC work!!!
Few tweaks to be done... like the buffer space
Brilliant!
On 16 January 2018 at 9:42PM, Christian Zigotzky wrote:
Hi All,
I compiled the RC8 of kernel 4.15 for the X5000 without PAMU support today.
Download: http://www.xenosoft.de/uImage_without_pamu.tar.gz
Please test it on your AmigaOne X5000.
Thanks,
Christian
On 16 January 2018 at 6:33PM, Madalin-cristian Bucur wrote:
The PAMU related errors may be relevant to the issue, if you have incorrect
settings you may have no traffic passing through. The PAMU configuration
should be made by the bootloader. Can you try to disable CONFIG_FSL_PAMU?
Madalin
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: DPAA Ethernet traffice troubles with Linux kernel
2018-01-16 17:57 ` Joakim Tjernlund
` (3 preceding siblings ...)
(?)
@ 2018-01-16 18:44 ` mad skateman
2018-01-16 21:00 ` Andrew Lunn
-1 siblings, 1 reply; 63+ messages in thread
From: mad skateman @ 2018-01-16 18:44 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: andrew, linuxppc-dev, madalin.bucur
[-- Attachment #1: Type: text/plain, Size: 1956 bytes --]
Hi,
I have been looking deeper into my wireshark packet captures and found
something that could be helpfull.
I can see that the Ethernet NIC at least does something. ARP BROADCAST
traffic is seen.
But i also found some packets...which have LG BITs set to 1 .. when i think
0 should be the correct value..something with Octets.
*"the first 3 octets/first-half of a MAC-48/EUI-48 Address, correspond to
the OUI (e.g.: MAC = 06:00:00:xx:xx:xx, OUI = 06:00:00), and the 2nd least
significant bit of its first octet is used to differentiate "Universally"
and "Locally" administered addresses). In other words, if we convert 06
(Hex) to 00000110 (Binary), we can see that the U/L bit is set to one,
which means that it a locally administered address.*
*Given this if we disable that bit, we get the matching "Universally
Administered Address" 00000100 (Binary), 04 (Hex) -> "04:00:00", hence my
question:"*
This has something to do with the MAC adresses being locally administered
.. and since whe can use Uboot and choose any Mac addr we want, this could
make sense..
These types of Logs also apear in my Wireshark Capture files... ( these are
not my org. logs)
Ethernet II, Src: Microchi_8f:c6:a8 (d8:80:39:8f:c6:a8), Dst: Broadcast
(ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Address: Broadcast (ff:ff:ff:ff:ff:ff)
.... ..1. .... .... .... .... = LG bit: Locally administered address (this
is NOT the factory default)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
Source: Microchi_8f:c6:a8 (d8:80:39:8f:c6:a8)
Address: Microchi_8f:c6:a8 (d8:80:39:8f:c6:a8)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory
default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IP (0x0800)
Internet Protocol Version 4, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255
(255.255.255.255)
In the link below some similair Logs and problems regarding DHCP for
example.
Dave
[-- Attachment #2: Type: text/html, Size: 4356 bytes --]
^ permalink raw reply [flat|nested] 63+ messages in thread* Re: DPAA Ethernet traffice troubles with Linux kernel
2018-01-16 18:44 ` mad skateman
@ 2018-01-16 21:00 ` Andrew Lunn
2018-01-16 21:15 ` mad skateman
0 siblings, 1 reply; 63+ messages in thread
From: Andrew Lunn @ 2018-01-16 21:00 UTC (permalink / raw)
To: mad skateman; +Cc: Joakim Tjernlund, linuxppc-dev, madalin.bucur
> *Given this if we disable that bit, we get the matching "Universally
> Administered Address" 00000100 (Binary), 04 (Hex) -> "04:00:00", hence my
> question:"*
>
> This has something to do with the MAC adresses being locally administered
> .. and since whe can use Uboot and choose any Mac addr we want, this could
> make sense..
You cannot just flip this bit. Universally administered addresses are
allocated by the IEEE. You need to purchase them from the IEEE.
Locally administered MAC addresses you can use, and any sane DHCP
server should work with them.
This also does not fit with mii-tool -R observation.
Andrew
^ permalink raw reply [flat|nested] 63+ messages in thread* Re: DPAA Ethernet traffice troubles with Linux kernel
2018-01-16 21:00 ` Andrew Lunn
@ 2018-01-16 21:15 ` mad skateman
0 siblings, 0 replies; 63+ messages in thread
From: mad skateman @ 2018-01-16 21:15 UTC (permalink / raw)
To: Andrew Lunn, Joakim Tjernlund, linuxppc-dev, madalin.bucur,
Christian Zigotzky
[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]
This makes me really start to wonder if the mainboard producer Varisys/AEON
has Purchased MAC`s for these boards at IEEE
Uboot system info gives for both MAC adresses the value NULL ... and i have
checked the mainboard for any stickers regarding the MAC adresses but there
is none..
I also tried to just create a ethaddr, eth1addr and eth2addr as mention on
the Wiki..but no luck
http://wiki.amiga.org/index.php?title=AmigaONE_X5000
On Tue, Jan 16, 2018 at 10:00 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> > *Given this if we disable that bit, we get the matching "Universally
> > Administered Address" 00000100 (Binary), 04 (Hex) -> "04:00:00", hence my
> > question:"*
> >
> > This has something to do with the MAC adresses being locally administered
> > .. and since whe can use Uboot and choose any Mac addr we want, this
> could
> > make sense..
>
> You cannot just flip this bit. Universally administered addresses are
> allocated by the IEEE. You need to purchase them from the IEEE.
> Locally administered MAC addresses you can use, and any sane DHCP
> server should work with them.
>
> This also does not fit with mii-tool -R observation.
>
> Andrew
>
[-- Attachment #2: Type: text/html, Size: 1788 bytes --]
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: DPAA Ethernet traffice troubles with Linux kernel
2018-01-16 17:57 ` Joakim Tjernlund
` (4 preceding siblings ...)
(?)
@ 2018-01-16 20:53 ` Andrew Lunn
2018-01-17 11:47 ` Joakim Tjernlund
-1 siblings, 1 reply; 63+ messages in thread
From: Andrew Lunn @ 2018-01-16 20:53 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev, netdev, madalin.bucur, madskateman
> > You appear to be using an old kernel. Take a look at:
>
> Not really, I am using 4.14.x and I don't think that is old.
Development for 4.14 stopped somewhere around the beginning of
September. So there has been over 4 months of work since then. We are
clearly interested in fixing bugs in that kernel, since it is the
current stable version. But when reporting bugs, please let is know if
the latest version of the network kernel,
it://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git has
the issue.
> Seems like this patch hasn't been sent to 4.14.x.
If it fixes a bug for you, please request the fix is added to stable.
Andrew
^ permalink raw reply [flat|nested] 63+ messages in thread* Re: DPAA Ethernet traffice troubles with Linux kernel
2018-01-16 20:53 ` Andrew Lunn
@ 2018-01-17 11:47 ` Joakim Tjernlund
0 siblings, 0 replies; 63+ messages in thread
From: Joakim Tjernlund @ 2018-01-17 11:47 UTC (permalink / raw)
To: andrew; +Cc: linuxppc-dev, netdev, madalin.bucur, madskateman
On Thu, 1970-01-01 at 00:00 +0000, Andrew Lunn wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
> > > You appear to be using an old kernel. Take a look at:
> >
> > Not really, I am using 4.14.x and I don't think that is old.
>
> Development for 4.14 stopped somewhere around the beginning of
> September. So there has been over 4 months of work since then. We are
> clearly interested in fixing bugs in that kernel, since it is the
> current stable version. But when reporting bugs, please let is know if
> the latest version of the network kernel,
> it://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git has
> the issue.
>
> > Seems like this patch hasn't been sent to 4.14.x.
>
> If it fixes a bug for you, please request the fix is added to stable.
That doesn't work really, having users to hit the bug, debug it, fix it and then
find it fixed already in upstream, then specifically request it to be backported to stable.
I don't need this fix to be backported, already got it. Someone else might though.
I would be interested in bug fixes upstream which fixes:
libphy: Freescale XGMAC MDIO Bus: probed
iommu: Adding device ffe488000.port to group 10
libphy: Freescale XGMAC MDIO Bus: probed
mdio_bus ffe4e1000: Error while reading PHY0 reg at 3.3
iommu: Adding device ffe489000.port to group 22
libphy: Freescale XGMAC MDIO Bus: probed
mdio_bus ffe4e3000: Error while reading PHY0 reg at 3.3
iommu: Adding device ffe48a000.port to group 23
libphy: Freescale XGMAC MDIO Bus: probed
mdio_bus ffe4e5000: Error while reading PHY0 reg at 3.3
iommu: Adding device ffe48b000.port to group 24
libphy: Freescale XGMAC MDIO Bus: probed
mdio_bus ffe4e7000: Error while reading PHY0 reg at 3.3
iommu: Adding device ffe48c000.port to group 25
libphy: Freescale XGMAC MDIO Bus: probed
mdio_bus ffe4e9000: Error while reading PHY0 reg at 3.3
fsl_mac ffe4e2000.ethernet: FMan MEMAC
fsl_mac ffe4e2000.ethernet: FMan MAC address: 00:06:9c:0b:06:20
fsl_mac dpaa-ethernet.0: __devm_request_mem_region(mac) failed
fsl_mac: probe of dpaa-ethernet.0 failed with error -16
fsl_mac ffe4e4000.ethernet: FMan MEMAC
fsl_mac ffe4e4000.ethernet: FMan MAC address: 00:06:9c:0b:06:21
fsl_mac dpaa-ethernet.1: __devm_request_mem_region(mac) failed
fsl_mac: probe of dpaa-ethernet.1 failed with error -16
fsl_mac ffe4e6000.ethernet: FMan MEMAC
fsl_mac ffe4e6000.ethernet: FMan MAC address: 00:06:9c:0b:06:22
fsl_mac dpaa-ethernet.2: __devm_request_mem_region(mac) failed
Every FMAN eth I/F with a fixed link fails mysteriously.
Custom board based on t1040rdb, been over the device tree and I cannot find any significant
changes.
Jocke
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: DPAA Ethernet traffice troubles with Linux kernel
@ 2018-01-17 11:47 ` Joakim Tjernlund
0 siblings, 0 replies; 63+ messages in thread
From: Joakim Tjernlund @ 2018-01-17 11:47 UTC (permalink / raw)
To: andrew; +Cc: linuxppc-dev, netdev, madalin.bucur, madskateman
T24gVGh1LCAxOTcwLTAxLTAxIGF0IDAwOjAwICswMDAwLCBBbmRyZXcgTHVubiB3cm90ZToNCj4g
Q0FVVElPTjogVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0aGUgb3JnYW5p
emF0aW9uLiBEbyBub3QgY2xpY2sgbGlua3Mgb3Igb3BlbiBhdHRhY2htZW50cyB1bmxlc3MgeW91
IHJlY29nbml6ZSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50IGlzIHNhZmUuDQo+IA0K
PiANCj4gPiA+IFlvdSBhcHBlYXIgdG8gYmUgdXNpbmcgYW4gb2xkIGtlcm5lbC4gVGFrZSBhIGxv
b2sgYXQ6DQo+ID4gDQo+ID4gTm90IHJlYWxseSwgSSBhbSB1c2luZyA0LjE0LnggYW5kIEkgZG9u
J3QgdGhpbmsgdGhhdCBpcyBvbGQuDQo+IA0KPiBEZXZlbG9wbWVudCBmb3IgNC4xNCBzdG9wcGVk
IHNvbWV3aGVyZSBhcm91bmQgdGhlIGJlZ2lubmluZyBvZg0KPiBTZXB0ZW1iZXIuIFNvIHRoZXJl
IGhhcyBiZWVuIG92ZXIgNCBtb250aHMgb2Ygd29yayBzaW5jZSB0aGVuLiAgV2UgYXJlDQo+IGNs
ZWFybHkgaW50ZXJlc3RlZCBpbiBmaXhpbmcgYnVncyBpbiB0aGF0IGtlcm5lbCwgc2luY2UgaXQg
aXMgdGhlDQo+IGN1cnJlbnQgc3RhYmxlIHZlcnNpb24uIEJ1dCB3aGVuIHJlcG9ydGluZyBidWdz
LCBwbGVhc2UgbGV0IGlzIGtub3cgaWYNCj4gdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHRoZSBuZXR3
b3JrIGtlcm5lbCwNCj4gaXQ6Ly9naXQua2VybmVsLm9yZy9wdWIvc2NtL2xpbnV4L2tlcm5lbC9n
aXQvZGF2ZW0vbmV0LW5leHQuZ2l0IGhhcw0KPiB0aGUgaXNzdWUuDQo+IA0KPiA+IFNlZW1zIGxp
a2UgdGhpcyBwYXRjaCBoYXNuJ3QgYmVlbiBzZW50IHRvIDQuMTQueC4NCj4gDQo+IElmIGl0IGZp
eGVzIGEgYnVnIGZvciB5b3UsIHBsZWFzZSByZXF1ZXN0IHRoZSBmaXggaXMgYWRkZWQgdG8gc3Rh
YmxlLg0KDQpUaGF0IGRvZXNuJ3Qgd29yayByZWFsbHksIGhhdmluZyB1c2VycyB0byBoaXQgdGhl
IGJ1ZywgZGVidWcgaXQsIGZpeCBpdCBhbmQgdGhlbg0KZmluZCBpdCBmaXhlZCBhbHJlYWR5IGlu
IHVwc3RyZWFtLCB0aGVuIHNwZWNpZmljYWxseSByZXF1ZXN0IGl0IHRvIGJlIGJhY2twb3J0ZWQg
dG8gc3RhYmxlLiANCkkgZG9uJ3QgbmVlZCB0aGlzIGZpeCB0byBiZSBiYWNrcG9ydGVkLCBhbHJl
YWR5IGdvdCBpdC4gU29tZW9uZSBlbHNlIG1pZ2h0IHRob3VnaC4NCg0KSSB3b3VsZCBiZSBpbnRl
cmVzdGVkIGluIGJ1ZyBmaXhlcyB1cHN0cmVhbSB3aGljaCBmaXhlczoNCg0KbGlicGh5OiBGcmVl
c2NhbGUgWEdNQUMgTURJTyBCdXM6IHByb2JlZA0KaW9tbXU6IEFkZGluZyBkZXZpY2UgZmZlNDg4
MDAwLnBvcnQgdG8gZ3JvdXAgMTANCmxpYnBoeTogRnJlZXNjYWxlIFhHTUFDIE1ESU8gQnVzOiBw
cm9iZWQNCm1kaW9fYnVzIGZmZTRlMTAwMDogRXJyb3Igd2hpbGUgcmVhZGluZyBQSFkwIHJlZyBh
dCAzLjMNCmlvbW11OiBBZGRpbmcgZGV2aWNlIGZmZTQ4OTAwMC5wb3J0IHRvIGdyb3VwIDIyDQps
aWJwaHk6IEZyZWVzY2FsZSBYR01BQyBNRElPIEJ1czogcHJvYmVkDQptZGlvX2J1cyBmZmU0ZTMw
MDA6IEVycm9yIHdoaWxlIHJlYWRpbmcgUEhZMCByZWcgYXQgMy4zDQppb21tdTogQWRkaW5nIGRl
dmljZSBmZmU0OGEwMDAucG9ydCB0byBncm91cCAyMw0KbGlicGh5OiBGcmVlc2NhbGUgWEdNQUMg
TURJTyBCdXM6IHByb2JlZA0KbWRpb19idXMgZmZlNGU1MDAwOiBFcnJvciB3aGlsZSByZWFkaW5n
IFBIWTAgcmVnIGF0IDMuMw0KaW9tbXU6IEFkZGluZyBkZXZpY2UgZmZlNDhiMDAwLnBvcnQgdG8g
Z3JvdXAgMjQNCmxpYnBoeTogRnJlZXNjYWxlIFhHTUFDIE1ESU8gQnVzOiBwcm9iZWQNCm1kaW9f
YnVzIGZmZTRlNzAwMDogRXJyb3Igd2hpbGUgcmVhZGluZyBQSFkwIHJlZyBhdCAzLjMNCmlvbW11
OiBBZGRpbmcgZGV2aWNlIGZmZTQ4YzAwMC5wb3J0IHRvIGdyb3VwIDI1DQpsaWJwaHk6IEZyZWVz
Y2FsZSBYR01BQyBNRElPIEJ1czogcHJvYmVkDQptZGlvX2J1cyBmZmU0ZTkwMDA6IEVycm9yIHdo
aWxlIHJlYWRpbmcgUEhZMCByZWcgYXQgMy4zDQpmc2xfbWFjIGZmZTRlMjAwMC5ldGhlcm5ldDog
Rk1hbiBNRU1BQw0KZnNsX21hYyBmZmU0ZTIwMDAuZXRoZXJuZXQ6IEZNYW4gTUFDIGFkZHJlc3M6
IDAwOjA2OjljOjBiOjA2OjIwDQpmc2xfbWFjIGRwYWEtZXRoZXJuZXQuMDogX19kZXZtX3JlcXVl
c3RfbWVtX3JlZ2lvbihtYWMpIGZhaWxlZA0KZnNsX21hYzogcHJvYmUgb2YgZHBhYS1ldGhlcm5l
dC4wIGZhaWxlZCB3aXRoIGVycm9yIC0xNg0KZnNsX21hYyBmZmU0ZTQwMDAuZXRoZXJuZXQ6IEZN
YW4gTUVNQUMNCmZzbF9tYWMgZmZlNGU0MDAwLmV0aGVybmV0OiBGTWFuIE1BQyBhZGRyZXNzOiAw
MDowNjo5YzowYjowNjoyMQ0KZnNsX21hYyBkcGFhLWV0aGVybmV0LjE6IF9fZGV2bV9yZXF1ZXN0
X21lbV9yZWdpb24obWFjKSBmYWlsZWQNCmZzbF9tYWM6IHByb2JlIG9mIGRwYWEtZXRoZXJuZXQu
MSBmYWlsZWQgd2l0aCBlcnJvciAtMTYNCmZzbF9tYWMgZmZlNGU2MDAwLmV0aGVybmV0OiBGTWFu
IE1FTUFDDQpmc2xfbWFjIGZmZTRlNjAwMC5ldGhlcm5ldDogRk1hbiBNQUMgYWRkcmVzczogMDA6
MDY6OWM6MGI6MDY6MjINCmZzbF9tYWMgZHBhYS1ldGhlcm5ldC4yOiBfX2Rldm1fcmVxdWVzdF9t
ZW1fcmVnaW9uKG1hYykgZmFpbGVkDQoNCkV2ZXJ5IEZNQU4gZXRoIEkvRiB3aXRoIGEgZml4ZWQg
bGluayBmYWlscyBteXN0ZXJpb3VzbHkuDQpDdXN0b20gYm9hcmQgYmFzZWQgb24gdDEwNDByZGIs
IGJlZW4gb3ZlciB0aGUgZGV2aWNlIHRyZWUgYW5kIEkgY2Fubm90IGZpbmQgYW55IHNpZ25pZmlj
YW50DQpjaGFuZ2VzLg0KDQogSm9ja2U=
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: DPAA Ethernet traffice troubles with Linux kernel
2018-01-17 11:47 ` Joakim Tjernlund
@ 2018-01-17 12:06 ` mad skateman
-1 siblings, 0 replies; 63+ messages in thread
From: mad skateman @ 2018-01-17 12:06 UTC (permalink / raw)
To: Joakim Tjernlund
Cc: andrew, Christian Zigotzky, madalin.bucur, linuxppc-dev, netdev
[-- Attachment #1: Type: text/plain, Size: 4714 bytes --]
After using the new compiled 4.14 rc8 kernel without PAMU support posted by
Christian Zigotzky the X5000 can use the Network interface with some minor
issues.
I had to give the Eth0 a manual IP due to not responding on DHCP requests.
I can ping my Gateway, and even DNS queries work..
But when i start Netsurf (or generate to much packets)... all traffic
dies.... due to No buffer space available..
64 bytes from 192.168.22.66: icmp_seq=81 ttl=255 time=0.317 ms
64 bytes from 192.168.22.66: icmp_seq=82 ttl=255 time=0.317 ms
64 bytes from 192.168.22.66: icmp_seq=83 ttl=255 time=0.314 ms
64 bytes from 192.168.22.66: icmp_seq=84 ttl=255 time=0.321 ms
64 bytes from 192.168.22.66: icmp_seq=85 ttl=255 time=0.323 ms
64 bytes from 192.168.22.66: icmp_seq=86 ttl=255 time=0.312 ms
64 bytes from 192.168.22.66: icmp_seq=87 ttl=255 time=0.331 ms
64 bytes from 192.168.22.66: icmp_seq=88 ttl=255 time=0.338 ms
64 bytes from 192.168.22.66: icmp_seq=89 ttl=255 time=0.334 ms
64 bytes from 192.168.22.66: icmp_seq=90 ttl=255 time=0.349 ms
64 bytes from 192.168.22.66: icmp_seq=91 ttl=255 time=0.324 ms
64 bytes from 192.168.22.66: icmp_seq=92 ttl=255 time=0.320 ms
64 bytes from 192.168.22.66: icmp_seq=93 ttl=255 time=0.320 ms
64 bytes from 192.168.22.66: icmp_seq=94 ttl=255 time=0.338 ms
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
A workaround to keep Eth0 alive a bit longer.... is the following command
ip link set eth0 qlen 10000
We are making progress!!
On Wed, Jan 17, 2018 at 12:47 PM, Joakim Tjernlund <
Joakim.Tjernlund@infinera.com> wrote:
> On Thu, 1970-01-01 at 00:00 +0000, Andrew Lunn wrote:
> > CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
> >
> >
> > > > You appear to be using an old kernel. Take a look at:
> > >
> > > Not really, I am using 4.14.x and I don't think that is old.
> >
> > Development for 4.14 stopped somewhere around the beginning of
> > September. So there has been over 4 months of work since then. We are
> > clearly interested in fixing bugs in that kernel, since it is the
> > current stable version. But when reporting bugs, please let is know if
> > the latest version of the network kernel,
> > it://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git has
> > the issue.
> >
> > > Seems like this patch hasn't been sent to 4.14.x.
> >
> > If it fixes a bug for you, please request the fix is added to stable.
>
> That doesn't work really, having users to hit the bug, debug it, fix it
> and then
> find it fixed already in upstream, then specifically request it to be
> backported to stable.
> I don't need this fix to be backported, already got it. Someone else might
> though.
>
> I would be interested in bug fixes upstream which fixes:
>
> libphy: Freescale XGMAC MDIO Bus: probed
> iommu: Adding device ffe488000.port to group 10
> libphy: Freescale XGMAC MDIO Bus: probed
> mdio_bus ffe4e1000: Error while reading PHY0 reg at 3.3
> iommu: Adding device ffe489000.port to group 22
> libphy: Freescale XGMAC MDIO Bus: probed
> mdio_bus ffe4e3000: Error while reading PHY0 reg at 3.3
> iommu: Adding device ffe48a000.port to group 23
> libphy: Freescale XGMAC MDIO Bus: probed
> mdio_bus ffe4e5000: Error while reading PHY0 reg at 3.3
> iommu: Adding device ffe48b000.port to group 24
> libphy: Freescale XGMAC MDIO Bus: probed
> mdio_bus ffe4e7000: Error while reading PHY0 reg at 3.3
> iommu: Adding device ffe48c000.port to group 25
> libphy: Freescale XGMAC MDIO Bus: probed
> mdio_bus ffe4e9000: Error while reading PHY0 reg at 3.3
> fsl_mac ffe4e2000.ethernet: FMan MEMAC
> fsl_mac ffe4e2000.ethernet: FMan MAC address: 00:06:9c:0b:06:20
> fsl_mac dpaa-ethernet.0: __devm_request_mem_region(mac) failed
> fsl_mac: probe of dpaa-ethernet.0 failed with error -16
> fsl_mac ffe4e4000.ethernet: FMan MEMAC
> fsl_mac ffe4e4000.ethernet: FMan MAC address: 00:06:9c:0b:06:21
> fsl_mac dpaa-ethernet.1: __devm_request_mem_region(mac) failed
> fsl_mac: probe of dpaa-ethernet.1 failed with error -16
> fsl_mac ffe4e6000.ethernet: FMan MEMAC
> fsl_mac ffe4e6000.ethernet: FMan MAC address: 00:06:9c:0b:06:22
> fsl_mac dpaa-ethernet.2: __devm_request_mem_region(mac) failed
>
> Every FMAN eth I/F with a fixed link fails mysteriously.
> Custom board based on t1040rdb, been over the device tree and I cannot
> find any significant
> changes.
>
> Jocke
[-- Attachment #2: Type: text/html, Size: 6297 bytes --]
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: DPAA Ethernet traffice troubles with Linux kernel
@ 2018-01-17 12:06 ` mad skateman
0 siblings, 0 replies; 63+ messages in thread
From: mad skateman @ 2018-01-17 12:06 UTC (permalink / raw)
To: Joakim Tjernlund
Cc: andrew, linuxppc-dev, netdev, madalin.bucur, Christian Zigotzky
[-- Attachment #1: Type: text/plain, Size: 4714 bytes --]
After using the new compiled 4.14 rc8 kernel without PAMU support posted by
Christian Zigotzky the X5000 can use the Network interface with some minor
issues.
I had to give the Eth0 a manual IP due to not responding on DHCP requests.
I can ping my Gateway, and even DNS queries work..
But when i start Netsurf (or generate to much packets)... all traffic
dies.... due to No buffer space available..
64 bytes from 192.168.22.66: icmp_seq=81 ttl=255 time=0.317 ms
64 bytes from 192.168.22.66: icmp_seq=82 ttl=255 time=0.317 ms
64 bytes from 192.168.22.66: icmp_seq=83 ttl=255 time=0.314 ms
64 bytes from 192.168.22.66: icmp_seq=84 ttl=255 time=0.321 ms
64 bytes from 192.168.22.66: icmp_seq=85 ttl=255 time=0.323 ms
64 bytes from 192.168.22.66: icmp_seq=86 ttl=255 time=0.312 ms
64 bytes from 192.168.22.66: icmp_seq=87 ttl=255 time=0.331 ms
64 bytes from 192.168.22.66: icmp_seq=88 ttl=255 time=0.338 ms
64 bytes from 192.168.22.66: icmp_seq=89 ttl=255 time=0.334 ms
64 bytes from 192.168.22.66: icmp_seq=90 ttl=255 time=0.349 ms
64 bytes from 192.168.22.66: icmp_seq=91 ttl=255 time=0.324 ms
64 bytes from 192.168.22.66: icmp_seq=92 ttl=255 time=0.320 ms
64 bytes from 192.168.22.66: icmp_seq=93 ttl=255 time=0.320 ms
64 bytes from 192.168.22.66: icmp_seq=94 ttl=255 time=0.338 ms
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
A workaround to keep Eth0 alive a bit longer.... is the following command
ip link set eth0 qlen 10000
We are making progress!!
On Wed, Jan 17, 2018 at 12:47 PM, Joakim Tjernlund <
Joakim.Tjernlund@infinera.com> wrote:
> On Thu, 1970-01-01 at 00:00 +0000, Andrew Lunn wrote:
> > CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
> >
> >
> > > > You appear to be using an old kernel. Take a look at:
> > >
> > > Not really, I am using 4.14.x and I don't think that is old.
> >
> > Development for 4.14 stopped somewhere around the beginning of
> > September. So there has been over 4 months of work since then. We are
> > clearly interested in fixing bugs in that kernel, since it is the
> > current stable version. But when reporting bugs, please let is know if
> > the latest version of the network kernel,
> > it://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git has
> > the issue.
> >
> > > Seems like this patch hasn't been sent to 4.14.x.
> >
> > If it fixes a bug for you, please request the fix is added to stable.
>
> That doesn't work really, having users to hit the bug, debug it, fix it
> and then
> find it fixed already in upstream, then specifically request it to be
> backported to stable.
> I don't need this fix to be backported, already got it. Someone else might
> though.
>
> I would be interested in bug fixes upstream which fixes:
>
> libphy: Freescale XGMAC MDIO Bus: probed
> iommu: Adding device ffe488000.port to group 10
> libphy: Freescale XGMAC MDIO Bus: probed
> mdio_bus ffe4e1000: Error while reading PHY0 reg at 3.3
> iommu: Adding device ffe489000.port to group 22
> libphy: Freescale XGMAC MDIO Bus: probed
> mdio_bus ffe4e3000: Error while reading PHY0 reg at 3.3
> iommu: Adding device ffe48a000.port to group 23
> libphy: Freescale XGMAC MDIO Bus: probed
> mdio_bus ffe4e5000: Error while reading PHY0 reg at 3.3
> iommu: Adding device ffe48b000.port to group 24
> libphy: Freescale XGMAC MDIO Bus: probed
> mdio_bus ffe4e7000: Error while reading PHY0 reg at 3.3
> iommu: Adding device ffe48c000.port to group 25
> libphy: Freescale XGMAC MDIO Bus: probed
> mdio_bus ffe4e9000: Error while reading PHY0 reg at 3.3
> fsl_mac ffe4e2000.ethernet: FMan MEMAC
> fsl_mac ffe4e2000.ethernet: FMan MAC address: 00:06:9c:0b:06:20
> fsl_mac dpaa-ethernet.0: __devm_request_mem_region(mac) failed
> fsl_mac: probe of dpaa-ethernet.0 failed with error -16
> fsl_mac ffe4e4000.ethernet: FMan MEMAC
> fsl_mac ffe4e4000.ethernet: FMan MAC address: 00:06:9c:0b:06:21
> fsl_mac dpaa-ethernet.1: __devm_request_mem_region(mac) failed
> fsl_mac: probe of dpaa-ethernet.1 failed with error -16
> fsl_mac ffe4e6000.ethernet: FMan MEMAC
> fsl_mac ffe4e6000.ethernet: FMan MAC address: 00:06:9c:0b:06:22
> fsl_mac dpaa-ethernet.2: __devm_request_mem_region(mac) failed
>
> Every FMAN eth I/F with a fixed link fails mysteriously.
> Custom board based on t1040rdb, been over the device tree and I cannot
> find any significant
> changes.
>
> Jocke
[-- Attachment #2: Type: text/html, Size: 6297 bytes --]
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: DPAA Ethernet traffice troubles with Linux kernel
2018-01-17 11:47 ` Joakim Tjernlund
(?)
(?)
@ 2018-01-17 13:43 ` Andrew Lunn
2018-01-17 14:15 ` Madalin-cristian Bucur
-1 siblings, 1 reply; 63+ messages in thread
From: Andrew Lunn @ 2018-01-17 13:43 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev, netdev, madalin.bucur, madskateman
> That doesn't work really, having users to hit the bug, debug it, fix it and then
> find it fixed already in upstream, then specifically request it to be backported to stable.
> I don't need this fix to be backported, already got it. Someone else might though.
The "someone else might though" is a big point of asking for it to
added to stable. The other reason is it means one less patch you need
to maintain in your build.
> I would be interested in bug fixes upstream which fixes:
Did you try upstream? Does it give the same errors?
Andrew
^ permalink raw reply [flat|nested] 63+ messages in thread* RE: DPAA Ethernet traffice troubles with Linux kernel
2018-01-17 13:43 ` Andrew Lunn
@ 2018-01-17 14:15 ` Madalin-cristian Bucur
0 siblings, 0 replies; 63+ messages in thread
From: Madalin-cristian Bucur @ 2018-01-17 14:15 UTC (permalink / raw)
To: Andrew Lunn, Joakim Tjernlund
Cc: linuxppc-dev, netdev, madskateman, David S . Miller
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Wednesday, January 17, 2018 3:44 PM
> To: Joakim Tjernlund <Joakim.Tjernlund@infinera.com>
> Subject: Re: DPAA Ethernet traffice troubles with Linux kernel
>
> > That doesn't work really, having users to hit the bug, debug it, fix it
> and then
> > find it fixed already in upstream, then specifically request it to be
> backported to stable.
> > I don't need this fix to be backported, already got it. Someone else
> might though.
>
> The "someone else might though" is a big point of asking for it to
> added to stable. The other reason is it means one less patch you need
> to maintain in your build.
I've sent that patch [1] for net but I guess the timing was wrong and
it was merged to net-next.
> > I would be interested in bug fixes upstream which fixes:
>
> Did you try upstream? Does it give the same errors?
>
> Andrew
[1] https://patchwork.kernel.org/patch/10146119/
Madalin
^ permalink raw reply [flat|nested] 63+ messages in thread
* RE: DPAA Ethernet traffice troubles with Linux kernel
@ 2018-01-17 14:15 ` Madalin-cristian Bucur
0 siblings, 0 replies; 63+ messages in thread
From: Madalin-cristian Bucur @ 2018-01-17 14:15 UTC (permalink / raw)
To: Andrew Lunn, Joakim Tjernlund
Cc: linuxppc-dev, netdev, madskateman, David S . Miller
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Wednesday, January 17, 2018 3:44 PM
> To: Joakim Tjernlund <Joakim.Tjernlund@infinera.com>
> Subject: Re: DPAA Ethernet traffice troubles with Linux kernel
>=20
> > That doesn't work really, having users to hit the bug, debug it, fix it
> and then
> > find it fixed already in upstream, then specifically request it to be
> backported to stable.
> > I don't need this fix to be backported, already got it. Someone else
> might though.
>=20
> The "someone else might though" is a big point of asking for it to
> added to stable. The other reason is it means one less patch you need
> to maintain in your build.
I've sent that patch [1] for net but I guess the timing was wrong and
it was merged to net-next.
> > I would be interested in bug fixes upstream which fixes:
>=20
> Did you try upstream? Does it give the same errors?
>=20
> Andrew
[1] https://patchwork.kernel.org/patch/10146119/
Madalin
^ permalink raw reply [flat|nested] 63+ messages in thread
* RE: DPAA Ethernet traffice troubles with Linux kernel
2018-01-17 14:15 ` Madalin-cristian Bucur
@ 2018-01-17 14:24 ` Madalin-cristian Bucur
-1 siblings, 0 replies; 63+ messages in thread
From: Madalin-cristian Bucur @ 2018-01-17 14:24 UTC (permalink / raw)
To: David S . Miller
Cc: linuxppc-dev, netdev, madskateman, Madalin-cristian Bucur,
Andrew Lunn, Joakim Tjernlund
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> On Behalf Of Madalin-cristian Bucur
> Sent: Wednesday, January 17, 2018 4:16 PM
> To: Andrew Lunn <andrew@lunn.ch>; Joakim Tjernlund
> <Joakim.Tjernlund@infinera.com>
> Cc: linuxppc-dev@lists.ozlabs.org; netdev@vger.kernel.org;
> madskateman@gmail.com; David S . Miller <davem@davemloft.net>
> Subject: RE: DPAA Ethernet traffice troubles with Linux kernel
>
> > -----Original Message-----
> > From: Andrew Lunn [mailto:andrew@lunn.ch]
> > Sent: Wednesday, January 17, 2018 3:44 PM
> > To: Joakim Tjernlund <Joakim.Tjernlund@infinera.com>
> > Subject: Re: DPAA Ethernet traffice troubles with Linux kernel
> >
> > > That doesn't work really, having users to hit the bug, debug it, fix
> it
> > and then
> > > find it fixed already in upstream, then specifically request it to be
> > backported to stable.
> > > I don't need this fix to be backported, already got it. Someone else
> > might though.
> >
> > The "someone else might though" is a big point of asking for it to
> > added to stable. The other reason is it means one less patch you need
> > to maintain in your build.
>
> I've sent that patch [1] for net but I guess the timing was wrong and
> it was merged to net-next.
>
> > > I would be interested in bug fixes upstream which fixes:
> >
> > Did you try upstream? Does it give the same errors?
> >
> > Andrew
>
> [1] https://patchwork.kernel.org/patch/10146119/
>
> Madalin
Hi Dave,
Can you please add the fix [1] to stable?
Thank you,
Madalin
^ permalink raw reply [flat|nested] 63+ messages in thread
* RE: DPAA Ethernet traffice troubles with Linux kernel
@ 2018-01-17 14:24 ` Madalin-cristian Bucur
0 siblings, 0 replies; 63+ messages in thread
From: Madalin-cristian Bucur @ 2018-01-17 14:24 UTC (permalink / raw)
To: David S . Miller
Cc: linuxppc-dev, netdev, madskateman, Madalin-cristian Bucur,
Andrew Lunn, Joakim Tjernlund
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> On Behalf Of Madalin-cristian Bucur
> Sent: Wednesday, January 17, 2018 4:16 PM
> To: Andrew Lunn <andrew@lunn.ch>; Joakim Tjernlund
> <Joakim.Tjernlund@infinera.com>
> Cc: linuxppc-dev@lists.ozlabs.org; netdev@vger.kernel.org;
> madskateman@gmail.com; David S . Miller <davem@davemloft.net>
> Subject: RE: DPAA Ethernet traffice troubles with Linux kernel
>=20
> > -----Original Message-----
> > From: Andrew Lunn [mailto:andrew@lunn.ch]
> > Sent: Wednesday, January 17, 2018 3:44 PM
> > To: Joakim Tjernlund <Joakim.Tjernlund@infinera.com>
> > Subject: Re: DPAA Ethernet traffice troubles with Linux kernel
> >
> > > That doesn't work really, having users to hit the bug, debug it, fix
> it
> > and then
> > > find it fixed already in upstream, then specifically request it to be
> > backported to stable.
> > > I don't need this fix to be backported, already got it. Someone else
> > might though.
> >
> > The "someone else might though" is a big point of asking for it to
> > added to stable. The other reason is it means one less patch you need
> > to maintain in your build.
>=20
> I've sent that patch [1] for net but I guess the timing was wrong and
> it was merged to net-next.
>=20
> > > I would be interested in bug fixes upstream which fixes:
> >
> > Did you try upstream? Does it give the same errors?
> >
> > Andrew
>=20
> [1] https://patchwork.kernel.org/patch/10146119/
>=20
> Madalin
Hi Dave,
Can you please add the fix [1] to stable?
Thank you,
Madalin
^ permalink raw reply [flat|nested] 63+ messages in thread
* RE: DPAA Ethernet traffice troubles with Linux kernel
2018-01-17 14:24 ` Madalin-cristian Bucur
@ 2018-01-17 14:43 ` Madalin-cristian Bucur
-1 siblings, 0 replies; 63+ messages in thread
From: Madalin-cristian Bucur @ 2018-01-17 14:43 UTC (permalink / raw)
To: David S . Miller
Cc: linuxppc-dev, netdev, madskateman, Madalin-cristian Bucur,
Andrew Lunn, Joakim Tjernlund
> -----Original Message-----
> From: Madalin-cristian Bucur
> Sent: Wednesday, January 17, 2018 4:25 PM
> To: David S . Miller <davem@davemloft.net>
> Cc: linuxppc-dev@lists.ozlabs.org; netdev@vger.kernel.org;
> madskateman@gmail.com; 'Madalin-cristian Bucur' <madalin.bucur@nxp.com>;
> Andrew Lunn <andrew@lunn.ch>; Joakim Tjernlund
> <Joakim.Tjernlund@infinera.com>
> Subject: RE: DPAA Ethernet traffice troubles with Linux kernel
>
> > -----Original Message-----
> > From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> > On Behalf Of Madalin-cristian Bucur
> > Sent: Wednesday, January 17, 2018 4:16 PM
> > To: Andrew Lunn <andrew@lunn.ch>; Joakim Tjernlund
> > <Joakim.Tjernlund@infinera.com>
> > Cc: linuxppc-dev@lists.ozlabs.org; netdev@vger.kernel.org;
> > madskateman@gmail.com; David S . Miller <davem@davemloft.net>
> > Subject: RE: DPAA Ethernet traffice troubles with Linux kernel
> >
> > > -----Original Message-----
> > > From: Andrew Lunn [mailto:andrew@lunn.ch]
> > > Sent: Wednesday, January 17, 2018 3:44 PM
> > > To: Joakim Tjernlund <Joakim.Tjernlund@infinera.com>
> > > Subject: Re: DPAA Ethernet traffice troubles with Linux kernel
> > >
> > > > That doesn't work really, having users to hit the bug, debug it, fix
> > it
> > > and then
> > > > find it fixed already in upstream, then specifically request it to
> be
> > > backported to stable.
> > > > I don't need this fix to be backported, already got it. Someone else
> > > might though.
> > >
> > > The "someone else might though" is a big point of asking for it to
> > > added to stable. The other reason is it means one less patch you need
> > > to maintain in your build.
> >
> > I've sent that patch [1] for net but I guess the timing was wrong and
> > it was merged to net-next.
> >
> > > > I would be interested in bug fixes upstream which fixes:
> > >
> > > Did you try upstream? Does it give the same errors?
> > >
> > > Andrew
> >
> > [1] https://patchwork.kernel.org/patch/10146119/
> >
> > Madalin
>
> Hi Dave,
>
> Can you please add the fix [1] to stable?
>
> Thank you,
> Madalin
Sorry,
I've provided the wrong link towards the patch (v1 instead of v3),
here's the correct one:
https://patchwork.kernel.org/patch/10151969/
Madalin
^ permalink raw reply [flat|nested] 63+ messages in thread
* RE: DPAA Ethernet traffice troubles with Linux kernel
@ 2018-01-17 14:43 ` Madalin-cristian Bucur
0 siblings, 0 replies; 63+ messages in thread
From: Madalin-cristian Bucur @ 2018-01-17 14:43 UTC (permalink / raw)
To: David S . Miller
Cc: linuxppc-dev, netdev, madskateman, Madalin-cristian Bucur,
Andrew Lunn, Joakim Tjernlund
> -----Original Message-----
> From: Madalin-cristian Bucur
> Sent: Wednesday, January 17, 2018 4:25 PM
> To: David S . Miller <davem@davemloft.net>
> Cc: linuxppc-dev@lists.ozlabs.org; netdev@vger.kernel.org;
> madskateman@gmail.com; 'Madalin-cristian Bucur' <madalin.bucur@nxp.com>;
> Andrew Lunn <andrew@lunn.ch>; Joakim Tjernlund
> <Joakim.Tjernlund@infinera.com>
> Subject: RE: DPAA Ethernet traffice troubles with Linux kernel
>=20
> > -----Original Message-----
> > From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org=
]
> > On Behalf Of Madalin-cristian Bucur
> > Sent: Wednesday, January 17, 2018 4:16 PM
> > To: Andrew Lunn <andrew@lunn.ch>; Joakim Tjernlund
> > <Joakim.Tjernlund@infinera.com>
> > Cc: linuxppc-dev@lists.ozlabs.org; netdev@vger.kernel.org;
> > madskateman@gmail.com; David S . Miller <davem@davemloft.net>
> > Subject: RE: DPAA Ethernet traffice troubles with Linux kernel
> >
> > > -----Original Message-----
> > > From: Andrew Lunn [mailto:andrew@lunn.ch]
> > > Sent: Wednesday, January 17, 2018 3:44 PM
> > > To: Joakim Tjernlund <Joakim.Tjernlund@infinera.com>
> > > Subject: Re: DPAA Ethernet traffice troubles with Linux kernel
> > >
> > > > That doesn't work really, having users to hit the bug, debug it, fi=
x
> > it
> > > and then
> > > > find it fixed already in upstream, then specifically request it to
> be
> > > backported to stable.
> > > > I don't need this fix to be backported, already got it. Someone els=
e
> > > might though.
> > >
> > > The "someone else might though" is a big point of asking for it to
> > > added to stable. The other reason is it means one less patch you need
> > > to maintain in your build.
> >
> > I've sent that patch [1] for net but I guess the timing was wrong and
> > it was merged to net-next.
> >
> > > > I would be interested in bug fixes upstream which fixes:
> > >
> > > Did you try upstream? Does it give the same errors?
> > >
> > > Andrew
> >
> > [1] https://patchwork.kernel.org/patch/10146119/
> >
> > Madalin
>=20
> Hi Dave,
>=20
> Can you please add the fix [1] to stable?
>=20
> Thank you,
> Madalin
Sorry,
I've provided the wrong link towards the patch (v1 instead of v3),
here's the correct one:
https://patchwork.kernel.org/patch/10151969/
Madalin
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: DPAA Ethernet traffice troubles with Linux kernel
2018-01-17 14:43 ` Madalin-cristian Bucur
(?)
@ 2018-02-03 11:54 ` mad skateman
2018-02-06 11:20 ` Christian Zigotzky
-1 siblings, 1 reply; 63+ messages in thread
From: mad skateman @ 2018-02-03 11:54 UTC (permalink / raw)
To: Madalin-cristian Bucur
Cc: linuxppc-dev, Andrew Lunn, Joakim Tjernlund, Christian Zigotzky,
Jamie Krueger
[-- Attachment #1: Type: text/plain, Size: 2898 bytes --]
For those interested... i have recorded a video of my X5000 DPAA Ethernet,
and the weird problems..
In this Video i am also transfering hundereds of megabytes from my NAS to
the X5000.
You will also see pings die... mostly after the 12th packet and giving the
no buffer space error..
Hopefully someone might have a clue about what is happening.
https://drive.google.com/file/d/18RhksfcavRJPr86asQDTzrmsN20D0Xim/view
On Wed, Jan 17, 2018 at 3:43 PM, Madalin-cristian Bucur <
madalin.bucur@nxp.com> wrote:
> > -----Original Message-----
> > From: Madalin-cristian Bucur
> > Sent: Wednesday, January 17, 2018 4:25 PM
> > To: David S . Miller <davem@davemloft.net>
> > Cc: linuxppc-dev@lists.ozlabs.org; netdev@vger.kernel.org;
> > madskateman@gmail.com; 'Madalin-cristian Bucur' <madalin.bucur@nxp.com>;
> > Andrew Lunn <andrew@lunn.ch>; Joakim Tjernlund
> > <Joakim.Tjernlund@infinera.com>
> > Subject: RE: DPAA Ethernet traffice troubles with Linux kernel
> >
> > > -----Original Message-----
> > > From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.
> kernel.org]
> > > On Behalf Of Madalin-cristian Bucur
> > > Sent: Wednesday, January 17, 2018 4:16 PM
> > > To: Andrew Lunn <andrew@lunn.ch>; Joakim Tjernlund
> > > <Joakim.Tjernlund@infinera.com>
> > > Cc: linuxppc-dev@lists.ozlabs.org; netdev@vger.kernel.org;
> > > madskateman@gmail.com; David S . Miller <davem@davemloft.net>
> > > Subject: RE: DPAA Ethernet traffice troubles with Linux kernel
> > >
> > > > -----Original Message-----
> > > > From: Andrew Lunn [mailto:andrew@lunn.ch]
> > > > Sent: Wednesday, January 17, 2018 3:44 PM
> > > > To: Joakim Tjernlund <Joakim.Tjernlund@infinera.com>
> > > > Subject: Re: DPAA Ethernet traffice troubles with Linux kernel
> > > >
> > > > > That doesn't work really, having users to hit the bug, debug it,
> fix
> > > it
> > > > and then
> > > > > find it fixed already in upstream, then specifically request it to
> > be
> > > > backported to stable.
> > > > > I don't need this fix to be backported, already got it. Someone
> else
> > > > might though.
> > > >
> > > > The "someone else might though" is a big point of asking for it to
> > > > added to stable. The other reason is it means one less patch you need
> > > > to maintain in your build.
> > >
> > > I've sent that patch [1] for net but I guess the timing was wrong and
> > > it was merged to net-next.
> > >
> > > > > I would be interested in bug fixes upstream which fixes:
> > > >
> > > > Did you try upstream? Does it give the same errors?
> > > >
> > > > Andrew
> > >
> > > [1] https://patchwork.kernel.org/patch/10146119/
> > >
> > > Madalin
> >
> > Hi Dave,
> >
> > Can you please add the fix [1] to stable?
> >
> > Thank you,
> > Madalin
>
> Sorry,
>
> I've provided the wrong link towards the patch (v1 instead of v3),
> here's the correct one:
>
> https://patchwork.kernel.org/patch/10151969/
>
> Madalin
>
[-- Attachment #2: Type: text/html, Size: 5049 bytes --]
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: DPAA Ethernet traffice troubles with Linux kernel
2018-02-03 11:54 ` mad skateman
@ 2018-02-06 11:20 ` Christian Zigotzky
2018-02-07 21:00 ` mad skateman
0 siblings, 1 reply; 63+ messages in thread
From: Christian Zigotzky @ 2018-02-06 11:20 UTC (permalink / raw)
To: mad skateman, Madalin-cristian Bucur
Cc: Andrew Lunn, linuxppc-dev, Jamie Krueger
Hello,
I have tried to figure out why there is a problem with the buffer space
but unfortunately without any success. Any ideas? Could you please watch
Skateman's video? [1]
Thanks,
Christian
[1] https://drive.google.com/file/d/18RhksfcavRJPr86asQDTzrmsN20D0Xim/view
On 03 February 2018 at 12:54PM, mad skateman wrote:
>
> For those interested... i have recorded a video of my X5000 DPAA
Ethernet, and the weird problems..
> In this Video i am also transfering hundereds of megabytes from my
NAS to the X5000.
> You will also see pings die... mostly after the 12th packet and
giving the no buffer space error..
> Hopefully someone might have a clue about what is happening.
>
> https://drive.google.com/file/d/18RhksfcavRJPr86asQDTzrmsN20D0Xim/view
>
> On Wed, Jan 17, 2018 at 3:43 PM, Madalin-cristian Bucur
<madalin.bucur@nxp.com> wrote:
>
> > -----Original Message-----
> > From: Madalin-cristian Bucur
> > Sent: Wednesday, January 17, 2018 4:25 PM
> > To: David S . Miller <davem@davemloft.net>
> > Cc: linuxppc-dev@lists.ozlabs.org; netdev@vger.kernel.org;
> > madskateman@gmail.com; 'Madalin-cristian Bucur'
<madalin.bucur@nxp.com>;
> > Andrew Lunn <andrew@lunn.ch>; Joakim Tjernlund
> > <Joakim.Tjernlund@infinera.com>
> > Subject: RE: DPAA Ethernet traffice troubles with Linux kernel
> >
> > > -----Original Message-----
> > > From: netdev-owner@vger.kernel.org
[mailto:netdev-owner@vger.kernel.org]
> > > On Behalf Of Madalin-cristian Bucur
> > > Sent: Wednesday, January 17, 2018 4:16 PM
> > > To: Andrew Lunn <andrew@lunn.ch>; Joakim Tjernlund
> > > <Joakim.Tjernlund@infinera.com>
> > > Cc: linuxppc-dev@lists.ozlabs.org; netdev@vger.kernel.org;
> > > madskateman@gmail.com; David S . Miller <davem@davemloft.net>
> > > Subject: RE: DPAA Ethernet traffice troubles with Linux kernel
> > >
> > > > -----Original Message-----
> > > > From: Andrew Lunn [mailto:andrew@lunn.ch]
> > > > Sent: Wednesday, January 17, 2018 3:44 PM
> > > > To: Joakim Tjernlund <Joakim.Tjernlund@infinera.com>
> > > > Subject: Re: DPAA Ethernet traffice troubles with Linux kernel
> > > >
> > > > > That doesn't work really, having users to hit the bug,
debug it, fix
> > > it
> > > > and then
> > > > > find it fixed already in upstream, then specifically
request it to
> > be
> > > > backported to stable.
> > > > > I don't need this fix to be backported, already got it.
Someone else
> > > > might though.
> > > >
> > > > The "someone else might though" is a big point of asking
for it to
> > > > added to stable. The other reason is it means one less
patch you need
> > > > to maintain in your build.
> > >
> > > I've sent that patch [1] for net but I guess the timing was
wrong and
> > > it was merged to net-next.
> > >
> > > > > I would be interested in bug fixes upstream which fixes:
> > > >
> > > > Did you try upstream? Does it give the same errors?
> > > >
> > > > Andrew
> > >
> > > [1] https://patchwork.kernel.org/patch/10146119/
> > >
> > > Madalin
> >
> > Hi Dave,
> >
> > Can you please add the fix [1] to stable?
> >
> > Thank you,
> > Madalin
>
> Sorry,
>
> I've provided the wrong link towards the patch (v1 instead of v3),
> here's the correct one:
>
> https://patchwork.kernel.org/patch/10151969/
>
> Madalin
>
>
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: DPAA Ethernet traffice troubles with Linux kernel
2018-02-06 11:20 ` Christian Zigotzky
@ 2018-02-07 21:00 ` mad skateman
2018-02-07 21:17 ` Andrew Lunn
0 siblings, 1 reply; 63+ messages in thread
From: mad skateman @ 2018-02-07 21:00 UTC (permalink / raw)
To: Christian Zigotzky
Cc: Madalin-cristian Bucur, Andrew Lunn, linuxppc-dev, Jamie Krueger
[-- Attachment #1: Type: text/plain, Size: 4878 bytes --]
Hi,
I just found out that something goes wrong within the ARP table (well thats
what i think). I hope someone has a clue..
When i bootup the AmigaOne X5000 with the Ethernet cable connected, it just
never senses the presence of the UTP cable.
I must run the following command as root: mii-tool -R eth0 ... it Resets
the transceiver and the ethernet connection is ready to go.
But then... it randomly dies....
After some digging i found that in a working situation the ARP table is
filled with the correct info. Router address, and corresponding MAC, C mask
and Interface.
(Working)
skateman@X5000LNX:~$ arp -n
Address HWtype HWaddress Flags Mask
Iface
192.168.22.66 ether 08:5b:0e:fd:db:6a C
eth0
No more traffic..it just suddenly dies...
skateman@X5000LNX:~$ ping www.google.com
ping: unknown host www.google.com
Rechecked the ARP... and found out it has lost the necessary info.
skateman@X5000LNX:~$ arp -n
Address HWtype HWaddress Flags Mask
Iface
192.168.22.66 (incomplete)
eth0
Anyone??? :-)
On Tue, Feb 6, 2018 at 12:20 PM, Christian Zigotzky <chzigotzky@xenosoft.de>
wrote:
> Hello,
>
> I have tried to figure out why there is a problem with the buffer space
> but unfortunately without any success. Any ideas? Could you please watch
> Skateman's video? [1]
>
> Thanks,
> Christian
>
> [1] https://drive.google.com/file/d/18RhksfcavRJPr86asQDTzrmsN20D0Xim/view
>
>
> On 03 February 2018 at 12:54PM, mad skateman wrote:
> >
> > For those interested... i have recorded a video of my X5000 DPAA
> Ethernet, and the weird problems..
> > In this Video i am also transfering hundereds of megabytes from my NAS
> to the X5000.
> > You will also see pings die... mostly after the 12th packet and giving
> the no buffer space error..
> > Hopefully someone might have a clue about what is happening.
> >
> > https://drive.google.com/file/d/18RhksfcavRJPr86asQDTzrmsN20D0Xim/view
> >
> > On Wed, Jan 17, 2018 at 3:43 PM, Madalin-cristian Bucur <
> madalin.bucur@nxp.com> wrote:
> >
> > > -----Original Message-----
> > > From: Madalin-cristian Bucur
> > > Sent: Wednesday, January 17, 2018 4:25 PM
> > > To: David S . Miller <davem@davemloft.net>
> > > Cc: linuxppc-dev@lists.ozlabs.org; netdev@vger.kernel.org;
> > > madskateman@gmail.com; 'Madalin-cristian Bucur' <
> madalin.bucur@nxp.com>;
> > > Andrew Lunn <andrew@lunn.ch>; Joakim Tjernlund
> > > <Joakim.Tjernlund@infinera.com>
> > > Subject: RE: DPAA Ethernet traffice troubles with Linux kernel
> > >
> > > > -----Original Message-----
> > > > From: netdev-owner@vger.kernel.org [mailto:
> netdev-owner@vger.kernel.org]
> > > > On Behalf Of Madalin-cristian Bucur
> > > > Sent: Wednesday, January 17, 2018 4:16 PM
> > > > To: Andrew Lunn <andrew@lunn.ch>; Joakim Tjernlund
> > > > <Joakim.Tjernlund@infinera.com>
> > > > Cc: linuxppc-dev@lists.ozlabs.org; netdev@vger.kernel.org;
> > > > madskateman@gmail.com; David S . Miller <davem@davemloft.net>
> > > > Subject: RE: DPAA Ethernet traffice troubles with Linux kernel
> > > >
> > > > > -----Original Message-----
> > > > > From: Andrew Lunn [mailto:andrew@lunn.ch]
> > > > > Sent: Wednesday, January 17, 2018 3:44 PM
> > > > > To: Joakim Tjernlund <Joakim.Tjernlund@infinera.com>
> > > > > Subject: Re: DPAA Ethernet traffice troubles with Linux kernel
> > > > >
> > > > > > That doesn't work really, having users to hit the bug, debug
> it, fix
> > > > it
> > > > > and then
> > > > > > find it fixed already in upstream, then specifically request
> it to
> > > be
> > > > > backported to stable.
> > > > > > I don't need this fix to be backported, already got it.
> Someone else
> > > > > might though.
> > > > >
> > > > > The "someone else might though" is a big point of asking for
> it to
> > > > > added to stable. The other reason is it means one less patch
> you need
> > > > > to maintain in your build.
> > > >
> > > > I've sent that patch [1] for net but I guess the timing was
> wrong and
> > > > it was merged to net-next.
> > > >
> > > > > > I would be interested in bug fixes upstream which fixes:
> > > > >
> > > > > Did you try upstream? Does it give the same errors?
> > > > >
> > > > > Andrew
> > > >
> > > > [1] https://patchwork.kernel.org/patch/10146119/
> > > >
> > > > Madalin
> > >
> > > Hi Dave,
> > >
> > > Can you please add the fix [1] to stable?
> > >
> > > Thank you,
> > > Madalin
> >
> > Sorry,
> >
> > I've provided the wrong link towards the patch (v1 instead of v3),
> > here's the correct one:
> >
> > https://patchwork.kernel.org/patch/10151969/
> >
> > Madalin
> >
> >
>
>
>
[-- Attachment #2: Type: text/html, Size: 8454 bytes --]
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: DPAA Ethernet traffice troubles with Linux kernel
2018-02-07 21:00 ` mad skateman
@ 2018-02-07 21:17 ` Andrew Lunn
2018-02-07 22:13 ` Christian Zigotzky
0 siblings, 1 reply; 63+ messages in thread
From: Andrew Lunn @ 2018-02-07 21:17 UTC (permalink / raw)
To: mad skateman
Cc: Christian Zigotzky, Madalin-cristian Bucur, linuxppc-dev, Jamie Krueger
On Wed, Feb 07, 2018 at 10:00:45PM +0100, mad skateman wrote:
> Hi,
>
> I just found out that something goes wrong within the ARP table (well thats
> what i think). I hope someone has a clue..
This looks like 'normal' behaviour. It has been reported that the
device runs out of buffers. That means it will fail to receive ARP
replies. So the ARP entry will time out and be removed, as it should.
Fix the buffer problem, and ARP will likely work properly.
Andrew
^ permalink raw reply [flat|nested] 63+ messages in thread* Re: DPAA Ethernet traffice troubles with Linux kernel
2018-02-07 21:17 ` Andrew Lunn
@ 2018-02-07 22:13 ` Christian Zigotzky
0 siblings, 0 replies; 63+ messages in thread
From: Christian Zigotzky @ 2018-02-07 22:13 UTC (permalink / raw)
To: Andrew Lunn
Cc: mad skateman, Madalin-cristian Bucur, linuxppc-dev, Jamie Krueger
[-- Attachment #1: Type: text/plain, Size: 635 bytes --]
Hi Andrew,
How can we fix the buffer problem?
Thanks,
Christian
On 7. Feb 2018, at 22:17, Andrew Lunn <andrew@lunn.ch> wrote:
On Wed, Feb 07, 2018 at 10:00:45PM +0100, mad skateman wrote:
Hi,
I just found out that something goes wrong within the ARP table (well thats
what i think). I hope someone has a clue..
——————
This looks like 'normal' behaviour. It has been reported that the
device runs out of buffers. That means it will fail to receive ARP
replies. So the ARP entry will time out and be removed, as it should.
Fix the buffer problem, and ARP will likely work properly.
Andrew
[-- Attachment #2: Type: text/html, Size: 4964 bytes --]
^ permalink raw reply [flat|nested] 63+ messages in thread
* RE: DPAA Ethernet traffice troubles with Linux kernel
2018-01-16 17:57 ` Joakim Tjernlund
@ 2018-01-17 14:11 ` Madalin-cristian Bucur
-1 siblings, 0 replies; 63+ messages in thread
From: Madalin-cristian Bucur @ 2018-01-17 14:11 UTC (permalink / raw)
To: Joakim Tjernlund, andrew; +Cc: linuxppc-dev, netdev, madskateman
> -----Original Message-----
> From: Joakim Tjernlund [mailto:Joakim.Tjernlund@infinera.com]
> Sent: Tuesday, January 16, 2018 7:58 PM
> To: andrew@lunn.ch
> Subject: Re: DPAA Ethernet traffice troubles with Linux kernel
>
> On Thu, 1970-01-01 at 00:00 +0000, Andrew Lunn wrote:
> >
> > Hi Joakim
> >
> > You appear to be using an old kernel. Take a look at:
>
> Not really, I am using 4.14.x and I don't think that is old. Seems like
> this
> patch hasn't been sent to 4.14.x.
>
> I wonder if I might be missing something else, we just moved to 4.14 and
> notic that all
> our fixed PHYs are non functioning:
> fsl_mac ffe4e2000.ethernet: FMan MEMAC
> fsl_mac ffe4e2000.ethernet: FMan MAC address: 00:06:9c:0b:06:20
> fsl_mac dpaa-ethernet.0: __devm_request_mem_region(mac) failed
> fsl_mac: probe of dpaa-ethernet.0 failed with error -16
> fsl_mac ffe4e4000.ethernet: FMan MEMAC
> fsl_mac ffe4e4000.ethernet: FMan MAC address: 00:06:9c:0b:06:21
> fsl_mac dpaa-ethernet.1: __devm_request_mem_region(mac) failed
> fsl_mac: probe of dpaa-ethernet.1 failed with error -16
> fsl_mac ffe4e6000.ethernet: FMan MEMAC
> fsl_mac ffe4e6000.ethernet: FMan MAC address: 00:06:9c:0b:06:22
> fsl_mac dpaa-ethernet.2: __devm_request_mem_region(mac) failed
> fsl_mac: probe of dpaa-ethernet.2 failed with error -16
> fsl_mac ffe4e8000.ethernet: FMan MEMAC
> fsl_mac ffe4e8000.ethernet: FMan MAC address: 00:06:9c:0b:06:23
> fsl_mac dpaa-ethernet.3: __devm_request_mem_region(mac) failed
> fsl_mac: probe of dpaa-ethernet.3 failed with error -16
>
> Feels like FMAN still think there are real PHYs there ?
Hi Joakim,
These errors are issued when trying to probe the second time the same
MAC node. The issue was introduced by this commit:
commit 4d8ee1935bcd666360311dfdadeee235d682d69a
Author: Florian Fainelli <f.fainelli@gmail.com>
Date: Tue Aug 22 15:24:47 2017 -0700
fsl/man: Inherit parent device and of_node
and was later addressed by this patch set:
http://patchwork.ozlabs.org/project/netdev/list/?series=8462&state=*
Even with these errors printed, all is working fine, it's just the
second probing that fails. Adding the latter patches or reverting
the one above makes the errors prints dissapear.
Madalin
^ permalink raw reply [flat|nested] 63+ messages in thread
* RE: DPAA Ethernet traffice troubles with Linux kernel
@ 2018-01-17 14:11 ` Madalin-cristian Bucur
0 siblings, 0 replies; 63+ messages in thread
From: Madalin-cristian Bucur @ 2018-01-17 14:11 UTC (permalink / raw)
To: Joakim Tjernlund, andrew; +Cc: linuxppc-dev, netdev, madskateman
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2FraW0gVGplcm5sdW5kIFtt
YWlsdG86Sm9ha2ltLlRqZXJubHVuZEBpbmZpbmVyYS5jb21dDQo+IFNlbnQ6IFR1ZXNkYXksIEph
bnVhcnkgMTYsIDIwMTggNzo1OCBQTQ0KPiBUbzogYW5kcmV3QGx1bm4uY2gNCj4gU3ViamVjdDog
UmU6IERQQUEgRXRoZXJuZXQgdHJhZmZpY2UgdHJvdWJsZXMgd2l0aCBMaW51eCBrZXJuZWwNCj4g
DQo+IE9uIFRodSwgMTk3MC0wMS0wMSBhdCAwMDowMCArMDAwMCwgQW5kcmV3IEx1bm4gd3JvdGU6
DQo+ID4NCj4gPiBIaSBKb2FraW0NCj4gPg0KPiA+IFlvdSBhcHBlYXIgdG8gYmUgdXNpbmcgYW4g
b2xkIGtlcm5lbC4gVGFrZSBhIGxvb2sgYXQ6DQo+IA0KPiBOb3QgcmVhbGx5LCBJIGFtIHVzaW5n
IDQuMTQueCBhbmQgSSBkb24ndCB0aGluayB0aGF0IGlzIG9sZC4gU2VlbXMgbGlrZQ0KPiB0aGlz
DQo+IHBhdGNoIGhhc24ndCBiZWVuIHNlbnQgdG8gNC4xNC54Lg0KPiANCj4gSSB3b25kZXIgaWYg
SSBtaWdodCBiZSBtaXNzaW5nIHNvbWV0aGluZyBlbHNlLCB3ZSBqdXN0IG1vdmVkIHRvIDQuMTQg
YW5kDQo+IG5vdGljIHRoYXQgYWxsDQo+IG91ciBmaXhlZCBQSFlzIGFyZSBub24gZnVuY3Rpb25p
bmc6DQo+IGZzbF9tYWMgZmZlNGUyMDAwLmV0aGVybmV0OiBGTWFuIE1FTUFDDQo+IGZzbF9tYWMg
ZmZlNGUyMDAwLmV0aGVybmV0OiBGTWFuIE1BQyBhZGRyZXNzOiAwMDowNjo5YzowYjowNjoyMA0K
PiBmc2xfbWFjIGRwYWEtZXRoZXJuZXQuMDogX19kZXZtX3JlcXVlc3RfbWVtX3JlZ2lvbihtYWMp
IGZhaWxlZA0KPiBmc2xfbWFjOiBwcm9iZSBvZiBkcGFhLWV0aGVybmV0LjAgZmFpbGVkIHdpdGgg
ZXJyb3IgLTE2DQo+IGZzbF9tYWMgZmZlNGU0MDAwLmV0aGVybmV0OiBGTWFuIE1FTUFDDQo+IGZz
bF9tYWMgZmZlNGU0MDAwLmV0aGVybmV0OiBGTWFuIE1BQyBhZGRyZXNzOiAwMDowNjo5YzowYjow
NjoyMQ0KPiBmc2xfbWFjIGRwYWEtZXRoZXJuZXQuMTogX19kZXZtX3JlcXVlc3RfbWVtX3JlZ2lv
bihtYWMpIGZhaWxlZA0KPiBmc2xfbWFjOiBwcm9iZSBvZiBkcGFhLWV0aGVybmV0LjEgZmFpbGVk
IHdpdGggZXJyb3IgLTE2DQo+IGZzbF9tYWMgZmZlNGU2MDAwLmV0aGVybmV0OiBGTWFuIE1FTUFD
DQo+IGZzbF9tYWMgZmZlNGU2MDAwLmV0aGVybmV0OiBGTWFuIE1BQyBhZGRyZXNzOiAwMDowNjo5
YzowYjowNjoyMg0KPiBmc2xfbWFjIGRwYWEtZXRoZXJuZXQuMjogX19kZXZtX3JlcXVlc3RfbWVt
X3JlZ2lvbihtYWMpIGZhaWxlZA0KPiBmc2xfbWFjOiBwcm9iZSBvZiBkcGFhLWV0aGVybmV0LjIg
ZmFpbGVkIHdpdGggZXJyb3IgLTE2DQo+IGZzbF9tYWMgZmZlNGU4MDAwLmV0aGVybmV0OiBGTWFu
IE1FTUFDDQo+IGZzbF9tYWMgZmZlNGU4MDAwLmV0aGVybmV0OiBGTWFuIE1BQyBhZGRyZXNzOiAw
MDowNjo5YzowYjowNjoyMw0KPiBmc2xfbWFjIGRwYWEtZXRoZXJuZXQuMzogX19kZXZtX3JlcXVl
c3RfbWVtX3JlZ2lvbihtYWMpIGZhaWxlZA0KPiBmc2xfbWFjOiBwcm9iZSBvZiBkcGFhLWV0aGVy
bmV0LjMgZmFpbGVkIHdpdGggZXJyb3IgLTE2DQo+IA0KPiBGZWVscyBsaWtlIEZNQU4gc3RpbGwg
dGhpbmsgdGhlcmUgYXJlIHJlYWwgUEhZcyB0aGVyZSA/DQoNCkhpIEpvYWtpbSwNCg0KVGhlc2Ug
ZXJyb3JzIGFyZSBpc3N1ZWQgd2hlbiB0cnlpbmcgdG8gcHJvYmUgdGhlIHNlY29uZCB0aW1lIHRo
ZSBzYW1lDQpNQUMgbm9kZS4gVGhlIGlzc3VlIHdhcyBpbnRyb2R1Y2VkIGJ5IHRoaXMgY29tbWl0
Og0KDQpjb21taXQgNGQ4ZWUxOTM1YmNkNjY2MzYwMzExZGZkYWRlZWUyMzVkNjgyZDY5YQ0KQXV0
aG9yOiBGbG9yaWFuIEZhaW5lbGxpIDxmLmZhaW5lbGxpQGdtYWlsLmNvbT4NCkRhdGU6IFR1ZSBB
dWcgMjIgMTU6MjQ6NDcgMjAxNyAtMDcwMA0KZnNsL21hbjogSW5oZXJpdCBwYXJlbnQgZGV2aWNl
IGFuZCBvZl9ub2RlDQoNCmFuZCB3YXMgbGF0ZXIgYWRkcmVzc2VkIGJ5IHRoaXMgcGF0Y2ggc2V0
Og0KDQpodHRwOi8vcGF0Y2h3b3JrLm96bGFicy5vcmcvcHJvamVjdC9uZXRkZXYvbGlzdC8/c2Vy
aWVzPTg0NjImc3RhdGU9Kg0KDQpFdmVuIHdpdGggdGhlc2UgZXJyb3JzIHByaW50ZWQsIGFsbCBp
cyB3b3JraW5nIGZpbmUsIGl0J3MganVzdCB0aGUNCnNlY29uZCBwcm9iaW5nIHRoYXQgZmFpbHMu
IEFkZGluZyB0aGUgbGF0dGVyIHBhdGNoZXMgb3IgcmV2ZXJ0aW5nDQp0aGUgb25lIGFib3ZlIG1h
a2VzIHRoZSBlcnJvcnMgcHJpbnRzIGRpc3NhcGVhci4NCg0KTWFkYWxpbg0K
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: DPAA Ethernet traffice troubles with Linux kernel
2018-01-17 14:11 ` Madalin-cristian Bucur
@ 2018-01-17 15:00 ` Joakim Tjernlund
-1 siblings, 0 replies; 63+ messages in thread
From: Joakim Tjernlund @ 2018-01-17 15:00 UTC (permalink / raw)
To: madalin.bucur, andrew; +Cc: linuxppc-dev, netdev, madskateman
On Thu, 1970-01-01 at 00:00 +0000, Madalin-cristian Bucur wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
> > -----Original Message-----
> > From: Joakim Tjernlund [mailto:Joakim.Tjernlund@infinera.com]
> > Sent: Tuesday, January 16, 2018 7:58 PM
> > To: andrew@lunn.ch
> > Subject: Re: DPAA Ethernet traffice troubles with Linux kernel
> >
> > On Thu, 1970-01-01 at 00:00 +0000, Andrew Lunn wrote:
> > >
> > > Hi Joakim
> > >
> > > You appear to be using an old kernel. Take a look at:
> >
> > Not really, I am using 4.14.x and I don't think that is old. Seems like
> > this
> > patch hasn't been sent to 4.14.x.
> >
> > I wonder if I might be missing something else, we just moved to 4.14 and
> > notic that all
> > our fixed PHYs are non functioning:
> > fsl_mac ffe4e2000.ethernet: FMan MEMAC
> > fsl_mac ffe4e2000.ethernet: FMan MAC address: 00:06:9c:0b:06:20
> > fsl_mac dpaa-ethernet.0: __devm_request_mem_region(mac) failed
> > fsl_mac: probe of dpaa-ethernet.0 failed with error -16
> > fsl_mac ffe4e4000.ethernet: FMan MEMAC
> > fsl_mac ffe4e4000.ethernet: FMan MAC address: 00:06:9c:0b:06:21
> > fsl_mac dpaa-ethernet.1: __devm_request_mem_region(mac) failed
> > fsl_mac: probe of dpaa-ethernet.1 failed with error -16
> > fsl_mac ffe4e6000.ethernet: FMan MEMAC
> > fsl_mac ffe4e6000.ethernet: FMan MAC address: 00:06:9c:0b:06:22
> > fsl_mac dpaa-ethernet.2: __devm_request_mem_region(mac) failed
> > fsl_mac: probe of dpaa-ethernet.2 failed with error -16
> > fsl_mac ffe4e8000.ethernet: FMan MEMAC
> > fsl_mac ffe4e8000.ethernet: FMan MAC address: 00:06:9c:0b:06:23
> > fsl_mac dpaa-ethernet.3: __devm_request_mem_region(mac) failed
> > fsl_mac: probe of dpaa-ethernet.3 failed with error -16
> >
> > Feels like FMAN still think there are real PHYs there ?
>
> Hi Joakim,
>
> These errors are issued when trying to probe the second time the same
> MAC node. The issue was introduced by this commit:
>
> commit 4d8ee1935bcd666360311dfdadeee235d682d69a
> Author: Florian Fainelli <f.fainelli@gmail.com>
> Date: Tue Aug 22 15:24:47 2017 -0700
> fsl/man: Inherit parent device and of_node
>
> and was later addressed by this patch set:
>
> http://patchwork.ozlabs.org/project/netdev/list/?series=8462&state=*
>
> Even with these errors printed, all is working fine, it's just the
> second probing that fails. Adding the latter patches or reverting
> the one above makes the errors prints dissapear.
>
> Madalin
Ahh, now it starts to look better, reverting "fsl/man: Inherit parent device and of_node" on 4.14 gives:
libphy: Fixed MDIO Bus: probed
tun: Universal TUN/TAP device driver, 1.6
libphy: Freescale XGMAC MDIO Bus: probed
iommu: Adding device ffe488000.port to group 10
libphy: Freescale XGMAC MDIO Bus: probed
mdio_bus ffe4e1000: Error while reading PHY0 reg at 3.3
iommu: Adding device ffe489000.port to group 22
libphy: Freescale XGMAC MDIO Bus: probed
mdio_bus ffe4e3000: Error while reading PHY0 reg at 3.3
iommu: Adding device ffe48a000.port to group 23
libphy: Freescale XGMAC MDIO Bus: probed
mdio_bus ffe4e5000: Error while reading PHY0 reg at 3.3
iommu: Adding device ffe48b000.port to group 24
libphy: Freescale XGMAC MDIO Bus: probed
mdio_bus ffe4e7000: Error while reading PHY0 reg at 3.3
iommu: Adding device ffe48c000.port to group 25
libphy: Freescale XGMAC MDIO Bus: probed
mdio_bus ffe4e9000: Error while reading PHY0 reg at 3.3
fsl_mac ffe4e2000.ethernet: FMan MEMAC
fsl_mac ffe4e2000.ethernet: FMan MAC address: 00:06:9c:0b:06:20
fsl_mac ffe4e4000.ethernet: FMan MEMAC
fsl_mac ffe4e4000.ethernet: FMan MAC address: 00:06:9c:0b:06:21
fsl_mac ffe4e6000.ethernet: FMan MEMAC
fsl_mac ffe4e6000.ethernet: FMan MAC address: 00:06:9c:0b:06:22
fsl_mac ffe4e8000.ethernet: FMan MEMAC
fsl_mac ffe4e8000.ethernet: FMan MAC address: 00:06:9c:0b:06:23
fsl_mac ffe4e0000.ethernet: FMan MEMAC
fsl_mac ffe4e0000.ethernet: FMan MAC address: 00:06:9c:0b:06:1f
fsl_dpa dpaa-ethernet.0 eth0: Probed interface eth0
fsl_dpa dpaa-ethernet.1 eth1: Probed interface eth1
fsl_dpa dpaa-ethernet.2 eth2: Probed interface eth2
fsl_dpa dpaa-ethernet.3 eth3: Probed interface eth3
fsl_dpa dpaa-ethernet.4 eth4: Probed interface eth4
Still some minor errors: mdio_bus ffe4e7000: Error while reading PHY0 reg at 3.3
but this is going the right way(I have not had a chance to try if they work due
to external modules not ported/ready yet)
The other patch series is still to be tested though but I already now wanted
to stress the importance of getting all upstream fixes into stable, ASAP.
You now what they are, I have no idea.
Thanks
Jocke
^ permalink raw reply [flat|nested] 63+ messages in thread* Re: DPAA Ethernet traffice troubles with Linux kernel
@ 2018-01-17 15:00 ` Joakim Tjernlund
0 siblings, 0 replies; 63+ messages in thread
From: Joakim Tjernlund @ 2018-01-17 15:00 UTC (permalink / raw)
To: madalin.bucur, andrew; +Cc: linuxppc-dev, netdev, madskateman
T24gVGh1LCAxOTcwLTAxLTAxIGF0IDAwOjAwICswMDAwLCBNYWRhbGluLWNyaXN0aWFuIEJ1Y3Vy
IHdyb3RlOg0KPiBDQVVUSU9OOiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgZnJvbSBvdXRzaWRlIG9m
IHRoZSBvcmdhbml6YXRpb24uIERvIG5vdCBjbGljayBsaW5rcyBvciBvcGVuIGF0dGFjaG1lbnRz
IHVubGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMg
c2FmZS4NCj4gDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTog
Sm9ha2ltIFRqZXJubHVuZCBbbWFpbHRvOkpvYWtpbS5UamVybmx1bmRAaW5maW5lcmEuY29tXQ0K
PiA+IFNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMTYsIDIwMTggNzo1OCBQTQ0KPiA+IFRvOiBhbmRy
ZXdAbHVubi5jaA0KPiA+IFN1YmplY3Q6IFJlOiBEUEFBIEV0aGVybmV0IHRyYWZmaWNlIHRyb3Vi
bGVzIHdpdGggTGludXgga2VybmVsDQo+ID4gDQo+ID4gT24gVGh1LCAxOTcwLTAxLTAxIGF0IDAw
OjAwICswMDAwLCBBbmRyZXcgTHVubiB3cm90ZToNCj4gPiA+IA0KPiA+ID4gSGkgSm9ha2ltDQo+
ID4gPiANCj4gPiA+IFlvdSBhcHBlYXIgdG8gYmUgdXNpbmcgYW4gb2xkIGtlcm5lbC4gVGFrZSBh
IGxvb2sgYXQ6DQo+ID4gDQo+ID4gTm90IHJlYWxseSwgSSBhbSB1c2luZyA0LjE0LnggYW5kIEkg
ZG9uJ3QgdGhpbmsgdGhhdCBpcyBvbGQuIFNlZW1zIGxpa2UNCj4gPiB0aGlzDQo+ID4gcGF0Y2gg
aGFzbid0IGJlZW4gc2VudCB0byA0LjE0LnguDQo+ID4gDQo+ID4gSSB3b25kZXIgaWYgSSBtaWdo
dCBiZSBtaXNzaW5nIHNvbWV0aGluZyBlbHNlLCB3ZSBqdXN0IG1vdmVkIHRvIDQuMTQgYW5kDQo+
ID4gbm90aWMgdGhhdCBhbGwNCj4gPiBvdXIgZml4ZWQgUEhZcyBhcmUgbm9uIGZ1bmN0aW9uaW5n
Og0KPiA+IGZzbF9tYWMgZmZlNGUyMDAwLmV0aGVybmV0OiBGTWFuIE1FTUFDDQo+ID4gZnNsX21h
YyBmZmU0ZTIwMDAuZXRoZXJuZXQ6IEZNYW4gTUFDIGFkZHJlc3M6IDAwOjA2OjljOjBiOjA2OjIw
DQo+ID4gZnNsX21hYyBkcGFhLWV0aGVybmV0LjA6IF9fZGV2bV9yZXF1ZXN0X21lbV9yZWdpb24o
bWFjKSBmYWlsZWQNCj4gPiBmc2xfbWFjOiBwcm9iZSBvZiBkcGFhLWV0aGVybmV0LjAgZmFpbGVk
IHdpdGggZXJyb3IgLTE2DQo+ID4gZnNsX21hYyBmZmU0ZTQwMDAuZXRoZXJuZXQ6IEZNYW4gTUVN
QUMNCj4gPiBmc2xfbWFjIGZmZTRlNDAwMC5ldGhlcm5ldDogRk1hbiBNQUMgYWRkcmVzczogMDA6
MDY6OWM6MGI6MDY6MjENCj4gPiBmc2xfbWFjIGRwYWEtZXRoZXJuZXQuMTogX19kZXZtX3JlcXVl
c3RfbWVtX3JlZ2lvbihtYWMpIGZhaWxlZA0KPiA+IGZzbF9tYWM6IHByb2JlIG9mIGRwYWEtZXRo
ZXJuZXQuMSBmYWlsZWQgd2l0aCBlcnJvciAtMTYNCj4gPiBmc2xfbWFjIGZmZTRlNjAwMC5ldGhl
cm5ldDogRk1hbiBNRU1BQw0KPiA+IGZzbF9tYWMgZmZlNGU2MDAwLmV0aGVybmV0OiBGTWFuIE1B
QyBhZGRyZXNzOiAwMDowNjo5YzowYjowNjoyMg0KPiA+IGZzbF9tYWMgZHBhYS1ldGhlcm5ldC4y
OiBfX2Rldm1fcmVxdWVzdF9tZW1fcmVnaW9uKG1hYykgZmFpbGVkDQo+ID4gZnNsX21hYzogcHJv
YmUgb2YgZHBhYS1ldGhlcm5ldC4yIGZhaWxlZCB3aXRoIGVycm9yIC0xNg0KPiA+IGZzbF9tYWMg
ZmZlNGU4MDAwLmV0aGVybmV0OiBGTWFuIE1FTUFDDQo+ID4gZnNsX21hYyBmZmU0ZTgwMDAuZXRo
ZXJuZXQ6IEZNYW4gTUFDIGFkZHJlc3M6IDAwOjA2OjljOjBiOjA2OjIzDQo+ID4gZnNsX21hYyBk
cGFhLWV0aGVybmV0LjM6IF9fZGV2bV9yZXF1ZXN0X21lbV9yZWdpb24obWFjKSBmYWlsZWQNCj4g
PiBmc2xfbWFjOiBwcm9iZSBvZiBkcGFhLWV0aGVybmV0LjMgZmFpbGVkIHdpdGggZXJyb3IgLTE2
DQo+ID4gDQo+ID4gRmVlbHMgbGlrZSBGTUFOIHN0aWxsIHRoaW5rIHRoZXJlIGFyZSByZWFsIFBI
WXMgdGhlcmUgPw0KPiANCj4gSGkgSm9ha2ltLA0KPiANCj4gVGhlc2UgZXJyb3JzIGFyZSBpc3N1
ZWQgd2hlbiB0cnlpbmcgdG8gcHJvYmUgdGhlIHNlY29uZCB0aW1lIHRoZSBzYW1lDQo+IE1BQyBu
b2RlLiBUaGUgaXNzdWUgd2FzIGludHJvZHVjZWQgYnkgdGhpcyBjb21taXQ6DQo+IA0KPiBjb21t
aXQgNGQ4ZWUxOTM1YmNkNjY2MzYwMzExZGZkYWRlZWUyMzVkNjgyZDY5YQ0KPiBBdXRob3I6IEZs
b3JpYW4gRmFpbmVsbGkgPGYuZmFpbmVsbGlAZ21haWwuY29tPg0KPiBEYXRlOiBUdWUgQXVnIDIy
IDE1OjI0OjQ3IDIwMTcgLTA3MDANCj4gZnNsL21hbjogSW5oZXJpdCBwYXJlbnQgZGV2aWNlIGFu
ZCBvZl9ub2RlDQo+IA0KPiBhbmQgd2FzIGxhdGVyIGFkZHJlc3NlZCBieSB0aGlzIHBhdGNoIHNl
dDoNCj4gDQo+IGh0dHA6Ly9wYXRjaHdvcmsub3psYWJzLm9yZy9wcm9qZWN0L25ldGRldi9saXN0
Lz9zZXJpZXM9ODQ2MiZzdGF0ZT0qDQo+IA0KPiBFdmVuIHdpdGggdGhlc2UgZXJyb3JzIHByaW50
ZWQsIGFsbCBpcyB3b3JraW5nIGZpbmUsIGl0J3MganVzdCB0aGUNCj4gc2Vjb25kIHByb2Jpbmcg
dGhhdCBmYWlscy4gQWRkaW5nIHRoZSBsYXR0ZXIgcGF0Y2hlcyBvciByZXZlcnRpbmcNCj4gdGhl
IG9uZSBhYm92ZSBtYWtlcyB0aGUgZXJyb3JzIHByaW50cyBkaXNzYXBlYXIuDQo+IA0KPiBNYWRh
bGluDQoNCkFoaCwgbm93IGl0IHN0YXJ0cyB0byBsb29rIGJldHRlciwgcmV2ZXJ0aW5nICJmc2wv
bWFuOiBJbmhlcml0IHBhcmVudCBkZXZpY2UgYW5kIG9mX25vZGUiIG9uIDQuMTQgZ2l2ZXM6DQps
aWJwaHk6IEZpeGVkIE1ESU8gQnVzOiBwcm9iZWQNCnR1bjogVW5pdmVyc2FsIFRVTi9UQVAgZGV2
aWNlIGRyaXZlciwgMS42DQpsaWJwaHk6IEZyZWVzY2FsZSBYR01BQyBNRElPIEJ1czogcHJvYmVk
DQppb21tdTogQWRkaW5nIGRldmljZSBmZmU0ODgwMDAucG9ydCB0byBncm91cCAxMA0KbGlicGh5
OiBGcmVlc2NhbGUgWEdNQUMgTURJTyBCdXM6IHByb2JlZA0KbWRpb19idXMgZmZlNGUxMDAwOiBF
cnJvciB3aGlsZSByZWFkaW5nIFBIWTAgcmVnIGF0IDMuMw0KaW9tbXU6IEFkZGluZyBkZXZpY2Ug
ZmZlNDg5MDAwLnBvcnQgdG8gZ3JvdXAgMjINCmxpYnBoeTogRnJlZXNjYWxlIFhHTUFDIE1ESU8g
QnVzOiBwcm9iZWQNCm1kaW9fYnVzIGZmZTRlMzAwMDogRXJyb3Igd2hpbGUgcmVhZGluZyBQSFkw
IHJlZyBhdCAzLjMNCmlvbW11OiBBZGRpbmcgZGV2aWNlIGZmZTQ4YTAwMC5wb3J0IHRvIGdyb3Vw
IDIzDQpsaWJwaHk6IEZyZWVzY2FsZSBYR01BQyBNRElPIEJ1czogcHJvYmVkDQptZGlvX2J1cyBm
ZmU0ZTUwMDA6IEVycm9yIHdoaWxlIHJlYWRpbmcgUEhZMCByZWcgYXQgMy4zDQppb21tdTogQWRk
aW5nIGRldmljZSBmZmU0OGIwMDAucG9ydCB0byBncm91cCAyNA0KbGlicGh5OiBGcmVlc2NhbGUg
WEdNQUMgTURJTyBCdXM6IHByb2JlZA0KbWRpb19idXMgZmZlNGU3MDAwOiBFcnJvciB3aGlsZSBy
ZWFkaW5nIFBIWTAgcmVnIGF0IDMuMw0KaW9tbXU6IEFkZGluZyBkZXZpY2UgZmZlNDhjMDAwLnBv
cnQgdG8gZ3JvdXAgMjUNCmxpYnBoeTogRnJlZXNjYWxlIFhHTUFDIE1ESU8gQnVzOiBwcm9iZWQN
Cm1kaW9fYnVzIGZmZTRlOTAwMDogRXJyb3Igd2hpbGUgcmVhZGluZyBQSFkwIHJlZyBhdCAzLjMN
CmZzbF9tYWMgZmZlNGUyMDAwLmV0aGVybmV0OiBGTWFuIE1FTUFDDQpmc2xfbWFjIGZmZTRlMjAw
MC5ldGhlcm5ldDogRk1hbiBNQUMgYWRkcmVzczogMDA6MDY6OWM6MGI6MDY6MjANCmZzbF9tYWMg
ZmZlNGU0MDAwLmV0aGVybmV0OiBGTWFuIE1FTUFDDQpmc2xfbWFjIGZmZTRlNDAwMC5ldGhlcm5l
dDogRk1hbiBNQUMgYWRkcmVzczogMDA6MDY6OWM6MGI6MDY6MjENCmZzbF9tYWMgZmZlNGU2MDAw
LmV0aGVybmV0OiBGTWFuIE1FTUFDDQpmc2xfbWFjIGZmZTRlNjAwMC5ldGhlcm5ldDogRk1hbiBN
QUMgYWRkcmVzczogMDA6MDY6OWM6MGI6MDY6MjINCmZzbF9tYWMgZmZlNGU4MDAwLmV0aGVybmV0
OiBGTWFuIE1FTUFDDQpmc2xfbWFjIGZmZTRlODAwMC5ldGhlcm5ldDogRk1hbiBNQUMgYWRkcmVz
czogMDA6MDY6OWM6MGI6MDY6MjMNCmZzbF9tYWMgZmZlNGUwMDAwLmV0aGVybmV0OiBGTWFuIE1F
TUFDDQpmc2xfbWFjIGZmZTRlMDAwMC5ldGhlcm5ldDogRk1hbiBNQUMgYWRkcmVzczogMDA6MDY6
OWM6MGI6MDY6MWYNCmZzbF9kcGEgZHBhYS1ldGhlcm5ldC4wIGV0aDA6IFByb2JlZCBpbnRlcmZh
Y2UgZXRoMA0KZnNsX2RwYSBkcGFhLWV0aGVybmV0LjEgZXRoMTogUHJvYmVkIGludGVyZmFjZSBl
dGgxDQpmc2xfZHBhIGRwYWEtZXRoZXJuZXQuMiBldGgyOiBQcm9iZWQgaW50ZXJmYWNlIGV0aDIN
CmZzbF9kcGEgZHBhYS1ldGhlcm5ldC4zIGV0aDM6IFByb2JlZCBpbnRlcmZhY2UgZXRoMw0KZnNs
X2RwYSBkcGFhLWV0aGVybmV0LjQgZXRoNDogUHJvYmVkIGludGVyZmFjZSBldGg0DQoNClN0aWxs
IHNvbWUgbWlub3IgZXJyb3JzOiBtZGlvX2J1cyBmZmU0ZTcwMDA6IEVycm9yIHdoaWxlIHJlYWRp
bmcgUEhZMCByZWcgYXQgMy4zDQpidXQgdGhpcyBpcyBnb2luZyB0aGUgcmlnaHQgd2F5KEkgaGF2
ZSBub3QgaGFkIGEgY2hhbmNlIHRvIHRyeSBpZiB0aGV5IHdvcmsgZHVlDQp0byBleHRlcm5hbCBt
b2R1bGVzIG5vdCBwb3J0ZWQvcmVhZHkgeWV0KQ0KDQpUaGUgb3RoZXIgcGF0Y2ggc2VyaWVzIGlz
IHN0aWxsIHRvIGJlIHRlc3RlZCB0aG91Z2ggYnV0IEkgYWxyZWFkeSBub3cgd2FudGVkIA0KdG8g
c3RyZXNzIHRoZSBpbXBvcnRhbmNlIG9mIGdldHRpbmcgYWxsIHVwc3RyZWFtIGZpeGVzIGludG8g
c3RhYmxlLCBBU0FQLg0KWW91IG5vdyB3aGF0IHRoZXkgYXJlLCBJIGhhdmUgbm8gaWRlYS4NCg0K
VGhhbmtzIA0KICAgICAgIEpvY2tl
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: DPAA Ethernet traffice troubles with Linux kernel
2018-01-17 15:00 ` Joakim Tjernlund
@ 2018-01-18 9:04 ` Joakim Tjernlund
-1 siblings, 0 replies; 63+ messages in thread
From: Joakim Tjernlund @ 2018-01-18 9:04 UTC (permalink / raw)
To: madalin.bucur, andrew; +Cc: linuxppc-dev, netdev, madskateman
On Thu, 1970-01-01 at 00:00 +0000, Joakim Tjernlund wrote:
> On Thu, 1970-01-01 at 00:00 +0000, Madalin-cristian Bucur wrote:
> > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
> >
> >
> > > -----Original Message-----
> > > From: Joakim Tjernlund [mailto:Joakim.Tjernlund@infinera.com]
> > > Sent: Tuesday, January 16, 2018 7:58 PM
> > > To: andrew@lunn.ch
> > > Subject: Re: DPAA Ethernet traffice troubles with Linux kernel
> > >
> > > On Thu, 1970-01-01 at 00:00 +0000, Andrew Lunn wrote:
> > > >
> > > > Hi Joakim
> > > >
> > > > You appear to be using an old kernel. Take a look at:
> > >
> > > Not really, I am using 4.14.x and I don't think that is old. Seems like
> > > this
> > > patch hasn't been sent to 4.14.x.
> > >
> > > I wonder if I might be missing something else, we just moved to 4.14 and
> > > notic that all
> > > our fixed PHYs are non functioning:
> > > fsl_mac ffe4e2000.ethernet: FMan MEMAC
> > > fsl_mac ffe4e2000.ethernet: FMan MAC address: 00:06:9c:0b:06:20
> > > fsl_mac dpaa-ethernet.0: __devm_request_mem_region(mac) failed
> > > fsl_mac: probe of dpaa-ethernet.0 failed with error -16
> > > fsl_mac ffe4e4000.ethernet: FMan MEMAC
> > > fsl_mac ffe4e4000.ethernet: FMan MAC address: 00:06:9c:0b:06:21
> > > fsl_mac dpaa-ethernet.1: __devm_request_mem_region(mac) failed
> > > fsl_mac: probe of dpaa-ethernet.1 failed with error -16
> > > fsl_mac ffe4e6000.ethernet: FMan MEMAC
> > > fsl_mac ffe4e6000.ethernet: FMan MAC address: 00:06:9c:0b:06:22
> > > fsl_mac dpaa-ethernet.2: __devm_request_mem_region(mac) failed
> > > fsl_mac: probe of dpaa-ethernet.2 failed with error -16
> > > fsl_mac ffe4e8000.ethernet: FMan MEMAC
> > > fsl_mac ffe4e8000.ethernet: FMan MAC address: 00:06:9c:0b:06:23
> > > fsl_mac dpaa-ethernet.3: __devm_request_mem_region(mac) failed
> > > fsl_mac: probe of dpaa-ethernet.3 failed with error -16
> > >
> > > Feels like FMAN still think there are real PHYs there ?
> >
> > Hi Joakim,
> >
> > These errors are issued when trying to probe the second time the same
> > MAC node. The issue was introduced by this commit:
> >
> > commit 4d8ee1935bcd666360311dfdadeee235d682d69a
> > Author: Florian Fainelli <f.fainelli@gmail.com>
> > Date: Tue Aug 22 15:24:47 2017 -0700
> > fsl/man: Inherit parent device and of_node
> >
> > and was later addressed by this patch set:
> >
> > http://patchwork.ozlabs.org/project/netdev/list/?series=8462&state=*
> >
> > Even with these errors printed, all is working fine, it's just the
> > second probing that fails. Adding the latter patches or reverting
> > the one above makes the errors prints dissapear.
> >
> > Madalin
>
> Ahh, now it starts to look better, reverting "fsl/man: Inherit parent device and of_node" on 4.14 gives:
> libphy: Fixed MDIO Bus: probed
> tun: Universal TUN/TAP device driver, 1.6
> libphy: Freescale XGMAC MDIO Bus: probed
> iommu: Adding device ffe488000.port to group 10
> libphy: Freescale XGMAC MDIO Bus: probed
> mdio_bus ffe4e1000: Error while reading PHY0 reg at 3.3
> iommu: Adding device ffe489000.port to group 22
> libphy: Freescale XGMAC MDIO Bus: probed
> mdio_bus ffe4e3000: Error while reading PHY0 reg at 3.3
> iommu: Adding device ffe48a000.port to group 23
> libphy: Freescale XGMAC MDIO Bus: probed
> mdio_bus ffe4e5000: Error while reading PHY0 reg at 3.3
> iommu: Adding device ffe48b000.port to group 24
> libphy: Freescale XGMAC MDIO Bus: probed
> mdio_bus ffe4e7000: Error while reading PHY0 reg at 3.3
> iommu: Adding device ffe48c000.port to group 25
> libphy: Freescale XGMAC MDIO Bus: probed
> mdio_bus ffe4e9000: Error while reading PHY0 reg at 3.3
> fsl_mac ffe4e2000.ethernet: FMan MEMAC
> fsl_mac ffe4e2000.ethernet: FMan MAC address: 00:06:9c:0b:06:20
> fsl_mac ffe4e4000.ethernet: FMan MEMAC
> fsl_mac ffe4e4000.ethernet: FMan MAC address: 00:06:9c:0b:06:21
> fsl_mac ffe4e6000.ethernet: FMan MEMAC
> fsl_mac ffe4e6000.ethernet: FMan MAC address: 00:06:9c:0b:06:22
> fsl_mac ffe4e8000.ethernet: FMan MEMAC
> fsl_mac ffe4e8000.ethernet: FMan MAC address: 00:06:9c:0b:06:23
> fsl_mac ffe4e0000.ethernet: FMan MEMAC
> fsl_mac ffe4e0000.ethernet: FMan MAC address: 00:06:9c:0b:06:1f
> fsl_dpa dpaa-ethernet.0 eth0: Probed interface eth0
> fsl_dpa dpaa-ethernet.1 eth1: Probed interface eth1
> fsl_dpa dpaa-ethernet.2 eth2: Probed interface eth2
> fsl_dpa dpaa-ethernet.3 eth3: Probed interface eth3
> fsl_dpa dpaa-ethernet.4 eth4: Probed interface eth4
>
> Still some minor errors: mdio_bus ffe4e7000: Error while reading PHY0 reg at 3.3
> but this is going the right way(I have not had a chance to try if they work due
> to external modules not ported/ready yet)
>
> The other patch series is still to be tested though but I already now wanted
> to stress the importance of getting all upstream fixes into stable, ASAP.
> You now what they are, I have no idea.
FYI, applied http://patchwork.ozlabs.org/project/netdev/list/?series=8462&state=* on 4.14.x
and I still see:
libphy: Fixed MDIO Bus: probed
tun: Universal TUN/TAP device driver, 1.6
libphy: Freescale XGMAC MDIO Bus: probed
iommu: Adding device ffe488000.port to group 10
libphy: Freescale XGMAC MDIO Bus: probed
mdio_bus ffe4e1000: Error while reading PHY0 reg at 3.3
iommu: Adding device ffe489000.port to group 22
libphy: Freescale XGMAC MDIO Bus: probed
mdio_bus ffe4e3000: Error while reading PHY0 reg at 3.3
iommu: Adding device ffe48a000.port to group 23
libphy: Freescale XGMAC MDIO Bus: probed
mdio_bus ffe4e5000: Error while reading PHY0 reg at 3.3
iommu: Adding device ffe48b000.port to group 24
libphy: Freescale XGMAC MDIO Bus: probed
mdio_bus ffe4e7000: Error while reading PHY0 reg at 3.3
iommu: Adding device ffe48c000.port to group 25
libphy: Freescale XGMAC MDIO Bus: probed
mdio_bus ffe4e9000: Error while reading PHY0 reg at 3.3
Other than that, FMAN appears to be working.
Jocke
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: DPAA Ethernet traffice troubles with Linux kernel
@ 2018-01-18 9:04 ` Joakim Tjernlund
0 siblings, 0 replies; 63+ messages in thread
From: Joakim Tjernlund @ 2018-01-18 9:04 UTC (permalink / raw)
To: madalin.bucur, andrew; +Cc: linuxppc-dev, netdev, madskateman
T24gVGh1LCAxOTcwLTAxLTAxIGF0IDAwOjAwICswMDAwLCBKb2FraW0gVGplcm5sdW5kIHdyb3Rl
Og0KPiBPbiBUaHUsIDE5NzAtMDEtMDEgYXQgMDA6MDAgKzAwMDAsIE1hZGFsaW4tY3Jpc3RpYW4g
QnVjdXIgd3JvdGU6DQo+ID4gQ0FVVElPTjogVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0
c2lkZSBvZiB0aGUgb3JnYW5pemF0aW9uLiBEbyBub3QgY2xpY2sgbGlua3Mgb3Igb3BlbiBhdHRh
Y2htZW50cyB1bmxlc3MgeW91IHJlY29nbml6ZSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250
ZW50IGlzIHNhZmUuDQo+ID4gDQo+ID4gDQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LQ0KPiA+ID4gRnJvbTogSm9ha2ltIFRqZXJubHVuZCBbbWFpbHRvOkpvYWtpbS5UamVybmx1bmRA
aW5maW5lcmEuY29tXQ0KPiA+ID4gU2VudDogVHVlc2RheSwgSmFudWFyeSAxNiwgMjAxOCA3OjU4
IFBNDQo+ID4gPiBUbzogYW5kcmV3QGx1bm4uY2gNCj4gPiA+IFN1YmplY3Q6IFJlOiBEUEFBIEV0
aGVybmV0IHRyYWZmaWNlIHRyb3VibGVzIHdpdGggTGludXgga2VybmVsDQo+ID4gPiANCj4gPiA+
IE9uIFRodSwgMTk3MC0wMS0wMSBhdCAwMDowMCArMDAwMCwgQW5kcmV3IEx1bm4gd3JvdGU6DQo+
ID4gPiA+IA0KPiA+ID4gPiBIaSBKb2FraW0NCj4gPiA+ID4gDQo+ID4gPiA+IFlvdSBhcHBlYXIg
dG8gYmUgdXNpbmcgYW4gb2xkIGtlcm5lbC4gVGFrZSBhIGxvb2sgYXQ6DQo+ID4gPiANCj4gPiA+
IE5vdCByZWFsbHksIEkgYW0gdXNpbmcgNC4xNC54IGFuZCBJIGRvbid0IHRoaW5rIHRoYXQgaXMg
b2xkLiBTZWVtcyBsaWtlDQo+ID4gPiB0aGlzDQo+ID4gPiBwYXRjaCBoYXNuJ3QgYmVlbiBzZW50
IHRvIDQuMTQueC4NCj4gPiA+IA0KPiA+ID4gSSB3b25kZXIgaWYgSSBtaWdodCBiZSBtaXNzaW5n
IHNvbWV0aGluZyBlbHNlLCB3ZSBqdXN0IG1vdmVkIHRvIDQuMTQgYW5kDQo+ID4gPiBub3RpYyB0
aGF0IGFsbA0KPiA+ID4gb3VyIGZpeGVkIFBIWXMgYXJlIG5vbiBmdW5jdGlvbmluZzoNCj4gPiA+
IGZzbF9tYWMgZmZlNGUyMDAwLmV0aGVybmV0OiBGTWFuIE1FTUFDDQo+ID4gPiBmc2xfbWFjIGZm
ZTRlMjAwMC5ldGhlcm5ldDogRk1hbiBNQUMgYWRkcmVzczogMDA6MDY6OWM6MGI6MDY6MjANCj4g
PiA+IGZzbF9tYWMgZHBhYS1ldGhlcm5ldC4wOiBfX2Rldm1fcmVxdWVzdF9tZW1fcmVnaW9uKG1h
YykgZmFpbGVkDQo+ID4gPiBmc2xfbWFjOiBwcm9iZSBvZiBkcGFhLWV0aGVybmV0LjAgZmFpbGVk
IHdpdGggZXJyb3IgLTE2DQo+ID4gPiBmc2xfbWFjIGZmZTRlNDAwMC5ldGhlcm5ldDogRk1hbiBN
RU1BQw0KPiA+ID4gZnNsX21hYyBmZmU0ZTQwMDAuZXRoZXJuZXQ6IEZNYW4gTUFDIGFkZHJlc3M6
IDAwOjA2OjljOjBiOjA2OjIxDQo+ID4gPiBmc2xfbWFjIGRwYWEtZXRoZXJuZXQuMTogX19kZXZt
X3JlcXVlc3RfbWVtX3JlZ2lvbihtYWMpIGZhaWxlZA0KPiA+ID4gZnNsX21hYzogcHJvYmUgb2Yg
ZHBhYS1ldGhlcm5ldC4xIGZhaWxlZCB3aXRoIGVycm9yIC0xNg0KPiA+ID4gZnNsX21hYyBmZmU0
ZTYwMDAuZXRoZXJuZXQ6IEZNYW4gTUVNQUMNCj4gPiA+IGZzbF9tYWMgZmZlNGU2MDAwLmV0aGVy
bmV0OiBGTWFuIE1BQyBhZGRyZXNzOiAwMDowNjo5YzowYjowNjoyMg0KPiA+ID4gZnNsX21hYyBk
cGFhLWV0aGVybmV0LjI6IF9fZGV2bV9yZXF1ZXN0X21lbV9yZWdpb24obWFjKSBmYWlsZWQNCj4g
PiA+IGZzbF9tYWM6IHByb2JlIG9mIGRwYWEtZXRoZXJuZXQuMiBmYWlsZWQgd2l0aCBlcnJvciAt
MTYNCj4gPiA+IGZzbF9tYWMgZmZlNGU4MDAwLmV0aGVybmV0OiBGTWFuIE1FTUFDDQo+ID4gPiBm
c2xfbWFjIGZmZTRlODAwMC5ldGhlcm5ldDogRk1hbiBNQUMgYWRkcmVzczogMDA6MDY6OWM6MGI6
MDY6MjMNCj4gPiA+IGZzbF9tYWMgZHBhYS1ldGhlcm5ldC4zOiBfX2Rldm1fcmVxdWVzdF9tZW1f
cmVnaW9uKG1hYykgZmFpbGVkDQo+ID4gPiBmc2xfbWFjOiBwcm9iZSBvZiBkcGFhLWV0aGVybmV0
LjMgZmFpbGVkIHdpdGggZXJyb3IgLTE2DQo+ID4gPiANCj4gPiA+IEZlZWxzIGxpa2UgRk1BTiBz
dGlsbCB0aGluayB0aGVyZSBhcmUgcmVhbCBQSFlzIHRoZXJlID8NCj4gPiANCj4gPiBIaSBKb2Fr
aW0sDQo+ID4gDQo+ID4gVGhlc2UgZXJyb3JzIGFyZSBpc3N1ZWQgd2hlbiB0cnlpbmcgdG8gcHJv
YmUgdGhlIHNlY29uZCB0aW1lIHRoZSBzYW1lDQo+ID4gTUFDIG5vZGUuIFRoZSBpc3N1ZSB3YXMg
aW50cm9kdWNlZCBieSB0aGlzIGNvbW1pdDoNCj4gPiANCj4gPiBjb21taXQgNGQ4ZWUxOTM1YmNk
NjY2MzYwMzExZGZkYWRlZWUyMzVkNjgyZDY5YQ0KPiA+IEF1dGhvcjogRmxvcmlhbiBGYWluZWxs
aSA8Zi5mYWluZWxsaUBnbWFpbC5jb20+DQo+ID4gRGF0ZTogVHVlIEF1ZyAyMiAxNToyNDo0NyAy
MDE3IC0wNzAwDQo+ID4gZnNsL21hbjogSW5oZXJpdCBwYXJlbnQgZGV2aWNlIGFuZCBvZl9ub2Rl
DQo+ID4gDQo+ID4gYW5kIHdhcyBsYXRlciBhZGRyZXNzZWQgYnkgdGhpcyBwYXRjaCBzZXQ6DQo+
ID4gDQo+ID4gaHR0cDovL3BhdGNod29yay5vemxhYnMub3JnL3Byb2plY3QvbmV0ZGV2L2xpc3Qv
P3Nlcmllcz04NDYyJnN0YXRlPSoNCj4gPiANCj4gPiBFdmVuIHdpdGggdGhlc2UgZXJyb3JzIHBy
aW50ZWQsIGFsbCBpcyB3b3JraW5nIGZpbmUsIGl0J3MganVzdCB0aGUNCj4gPiBzZWNvbmQgcHJv
YmluZyB0aGF0IGZhaWxzLiBBZGRpbmcgdGhlIGxhdHRlciBwYXRjaGVzIG9yIHJldmVydGluZw0K
PiA+IHRoZSBvbmUgYWJvdmUgbWFrZXMgdGhlIGVycm9ycyBwcmludHMgZGlzc2FwZWFyLg0KPiA+
IA0KPiA+IE1hZGFsaW4NCj4gDQo+IEFoaCwgbm93IGl0IHN0YXJ0cyB0byBsb29rIGJldHRlciwg
cmV2ZXJ0aW5nICJmc2wvbWFuOiBJbmhlcml0IHBhcmVudCBkZXZpY2UgYW5kIG9mX25vZGUiIG9u
IDQuMTQgZ2l2ZXM6DQo+IGxpYnBoeTogRml4ZWQgTURJTyBCdXM6IHByb2JlZA0KPiB0dW46IFVu
aXZlcnNhbCBUVU4vVEFQIGRldmljZSBkcml2ZXIsIDEuNg0KPiBsaWJwaHk6IEZyZWVzY2FsZSBY
R01BQyBNRElPIEJ1czogcHJvYmVkDQo+IGlvbW11OiBBZGRpbmcgZGV2aWNlIGZmZTQ4ODAwMC5w
b3J0IHRvIGdyb3VwIDEwDQo+IGxpYnBoeTogRnJlZXNjYWxlIFhHTUFDIE1ESU8gQnVzOiBwcm9i
ZWQNCj4gbWRpb19idXMgZmZlNGUxMDAwOiBFcnJvciB3aGlsZSByZWFkaW5nIFBIWTAgcmVnIGF0
IDMuMw0KPiBpb21tdTogQWRkaW5nIGRldmljZSBmZmU0ODkwMDAucG9ydCB0byBncm91cCAyMg0K
PiBsaWJwaHk6IEZyZWVzY2FsZSBYR01BQyBNRElPIEJ1czogcHJvYmVkDQo+IG1kaW9fYnVzIGZm
ZTRlMzAwMDogRXJyb3Igd2hpbGUgcmVhZGluZyBQSFkwIHJlZyBhdCAzLjMNCj4gaW9tbXU6IEFk
ZGluZyBkZXZpY2UgZmZlNDhhMDAwLnBvcnQgdG8gZ3JvdXAgMjMNCj4gbGlicGh5OiBGcmVlc2Nh
bGUgWEdNQUMgTURJTyBCdXM6IHByb2JlZA0KPiBtZGlvX2J1cyBmZmU0ZTUwMDA6IEVycm9yIHdo
aWxlIHJlYWRpbmcgUEhZMCByZWcgYXQgMy4zDQo+IGlvbW11OiBBZGRpbmcgZGV2aWNlIGZmZTQ4
YjAwMC5wb3J0IHRvIGdyb3VwIDI0DQo+IGxpYnBoeTogRnJlZXNjYWxlIFhHTUFDIE1ESU8gQnVz
OiBwcm9iZWQNCj4gbWRpb19idXMgZmZlNGU3MDAwOiBFcnJvciB3aGlsZSByZWFkaW5nIFBIWTAg
cmVnIGF0IDMuMw0KPiBpb21tdTogQWRkaW5nIGRldmljZSBmZmU0OGMwMDAucG9ydCB0byBncm91
cCAyNQ0KPiBsaWJwaHk6IEZyZWVzY2FsZSBYR01BQyBNRElPIEJ1czogcHJvYmVkDQo+IG1kaW9f
YnVzIGZmZTRlOTAwMDogRXJyb3Igd2hpbGUgcmVhZGluZyBQSFkwIHJlZyBhdCAzLjMNCj4gZnNs
X21hYyBmZmU0ZTIwMDAuZXRoZXJuZXQ6IEZNYW4gTUVNQUMNCj4gZnNsX21hYyBmZmU0ZTIwMDAu
ZXRoZXJuZXQ6IEZNYW4gTUFDIGFkZHJlc3M6IDAwOjA2OjljOjBiOjA2OjIwDQo+IGZzbF9tYWMg
ZmZlNGU0MDAwLmV0aGVybmV0OiBGTWFuIE1FTUFDDQo+IGZzbF9tYWMgZmZlNGU0MDAwLmV0aGVy
bmV0OiBGTWFuIE1BQyBhZGRyZXNzOiAwMDowNjo5YzowYjowNjoyMQ0KPiBmc2xfbWFjIGZmZTRl
NjAwMC5ldGhlcm5ldDogRk1hbiBNRU1BQw0KPiBmc2xfbWFjIGZmZTRlNjAwMC5ldGhlcm5ldDog
Rk1hbiBNQUMgYWRkcmVzczogMDA6MDY6OWM6MGI6MDY6MjINCj4gZnNsX21hYyBmZmU0ZTgwMDAu
ZXRoZXJuZXQ6IEZNYW4gTUVNQUMNCj4gZnNsX21hYyBmZmU0ZTgwMDAuZXRoZXJuZXQ6IEZNYW4g
TUFDIGFkZHJlc3M6IDAwOjA2OjljOjBiOjA2OjIzDQo+IGZzbF9tYWMgZmZlNGUwMDAwLmV0aGVy
bmV0OiBGTWFuIE1FTUFDDQo+IGZzbF9tYWMgZmZlNGUwMDAwLmV0aGVybmV0OiBGTWFuIE1BQyBh
ZGRyZXNzOiAwMDowNjo5YzowYjowNjoxZg0KPiBmc2xfZHBhIGRwYWEtZXRoZXJuZXQuMCBldGgw
OiBQcm9iZWQgaW50ZXJmYWNlIGV0aDANCj4gZnNsX2RwYSBkcGFhLWV0aGVybmV0LjEgZXRoMTog
UHJvYmVkIGludGVyZmFjZSBldGgxDQo+IGZzbF9kcGEgZHBhYS1ldGhlcm5ldC4yIGV0aDI6IFBy
b2JlZCBpbnRlcmZhY2UgZXRoMg0KPiBmc2xfZHBhIGRwYWEtZXRoZXJuZXQuMyBldGgzOiBQcm9i
ZWQgaW50ZXJmYWNlIGV0aDMNCj4gZnNsX2RwYSBkcGFhLWV0aGVybmV0LjQgZXRoNDogUHJvYmVk
IGludGVyZmFjZSBldGg0DQo+IA0KPiBTdGlsbCBzb21lIG1pbm9yIGVycm9yczogbWRpb19idXMg
ZmZlNGU3MDAwOiBFcnJvciB3aGlsZSByZWFkaW5nIFBIWTAgcmVnIGF0IDMuMw0KPiBidXQgdGhp
cyBpcyBnb2luZyB0aGUgcmlnaHQgd2F5KEkgaGF2ZSBub3QgaGFkIGEgY2hhbmNlIHRvIHRyeSBp
ZiB0aGV5IHdvcmsgZHVlDQo+IHRvIGV4dGVybmFsIG1vZHVsZXMgbm90IHBvcnRlZC9yZWFkeSB5
ZXQpDQo+IA0KPiBUaGUgb3RoZXIgcGF0Y2ggc2VyaWVzIGlzIHN0aWxsIHRvIGJlIHRlc3RlZCB0
aG91Z2ggYnV0IEkgYWxyZWFkeSBub3cgd2FudGVkIA0KPiB0byBzdHJlc3MgdGhlIGltcG9ydGFu
Y2Ugb2YgZ2V0dGluZyBhbGwgdXBzdHJlYW0gZml4ZXMgaW50byBzdGFibGUsIEFTQVAuDQo+IFlv
dSBub3cgd2hhdCB0aGV5IGFyZSwgSSBoYXZlIG5vIGlkZWEuDQoNCkZZSSwgYXBwbGllZCBodHRw
Oi8vcGF0Y2h3b3JrLm96bGFicy5vcmcvcHJvamVjdC9uZXRkZXYvbGlzdC8/c2VyaWVzPTg0NjIm
c3RhdGU9KiBvbiA0LjE0LngNCmFuZCBJIHN0aWxsIHNlZToNCmxpYnBoeTogRml4ZWQgTURJTyBC
dXM6IHByb2JlZA0KdHVuOiBVbml2ZXJzYWwgVFVOL1RBUCBkZXZpY2UgZHJpdmVyLCAxLjYNCmxp
YnBoeTogRnJlZXNjYWxlIFhHTUFDIE1ESU8gQnVzOiBwcm9iZWQNCmlvbW11OiBBZGRpbmcgZGV2
aWNlIGZmZTQ4ODAwMC5wb3J0IHRvIGdyb3VwIDEwDQpsaWJwaHk6IEZyZWVzY2FsZSBYR01BQyBN
RElPIEJ1czogcHJvYmVkDQptZGlvX2J1cyBmZmU0ZTEwMDA6IEVycm9yIHdoaWxlIHJlYWRpbmcg
UEhZMCByZWcgYXQgMy4zDQppb21tdTogQWRkaW5nIGRldmljZSBmZmU0ODkwMDAucG9ydCB0byBn
cm91cCAyMg0KbGlicGh5OiBGcmVlc2NhbGUgWEdNQUMgTURJTyBCdXM6IHByb2JlZA0KbWRpb19i
dXMgZmZlNGUzMDAwOiBFcnJvciB3aGlsZSByZWFkaW5nIFBIWTAgcmVnIGF0IDMuMw0KaW9tbXU6
IEFkZGluZyBkZXZpY2UgZmZlNDhhMDAwLnBvcnQgdG8gZ3JvdXAgMjMNCmxpYnBoeTogRnJlZXNj
YWxlIFhHTUFDIE1ESU8gQnVzOiBwcm9iZWQNCm1kaW9fYnVzIGZmZTRlNTAwMDogRXJyb3Igd2hp
bGUgcmVhZGluZyBQSFkwIHJlZyBhdCAzLjMNCmlvbW11OiBBZGRpbmcgZGV2aWNlIGZmZTQ4YjAw
MC5wb3J0IHRvIGdyb3VwIDI0DQpsaWJwaHk6IEZyZWVzY2FsZSBYR01BQyBNRElPIEJ1czogcHJv
YmVkDQptZGlvX2J1cyBmZmU0ZTcwMDA6IEVycm9yIHdoaWxlIHJlYWRpbmcgUEhZMCByZWcgYXQg
My4zDQppb21tdTogQWRkaW5nIGRldmljZSBmZmU0OGMwMDAucG9ydCB0byBncm91cCAyNQ0KbGli
cGh5OiBGcmVlc2NhbGUgWEdNQUMgTURJTyBCdXM6IHByb2JlZA0KbWRpb19idXMgZmZlNGU5MDAw
OiBFcnJvciB3aGlsZSByZWFkaW5nIFBIWTAgcmVnIGF0IDMuMw0KDQpPdGhlciB0aGFuIHRoYXQs
IEZNQU4gYXBwZWFycyB0byBiZSB3b3JraW5nLg0KDQogSm9ja2U=
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: DPAA Ethernet traffice troubles with Linux kernel
2018-01-17 14:11 ` Madalin-cristian Bucur
@ 2018-01-19 8:00 ` Joakim Tjernlund
-1 siblings, 0 replies; 63+ messages in thread
From: Joakim Tjernlund @ 2018-01-19 8:00 UTC (permalink / raw)
To: madalin.bucur, andrew; +Cc: linuxppc-dev, netdev, madskateman
On Thu, 1970-01-01 at 00:00 +0000, Madalin-cristian Bucur wrote:
>
> > -----Original Message-----
> > From: Joakim Tjernlund [mailto:Joakim.Tjernlund@infinera.com]
> > Sent: Tuesday, January 16, 2018 7:58 PM
> > To: andrew@lunn.ch
> > Subject: Re: DPAA Ethernet traffice troubles with Linux kernel
> >
> > On Thu, 1970-01-01 at 00:00 +0000, Andrew Lunn wrote:
> > >
> > > Hi Joakim
> > >
> > > You appear to be using an old kernel. Take a look at:
> >
> > Not really, I am using 4.14.x and I don't think that is old. Seems like
> > this
> > patch hasn't been sent to 4.14.x.
> >
> > I wonder if I might be missing something else, we just moved to 4.14 and
> > notic that all
> > our fixed PHYs are non functioning:
> > fsl_mac ffe4e2000.ethernet: FMan MEMAC
> > fsl_mac ffe4e2000.ethernet: FMan MAC address: 00:06:9c:0b:06:20
> > fsl_mac dpaa-ethernet.0: __devm_request_mem_region(mac) failed
> > fsl_mac: probe of dpaa-ethernet.0 failed with error -16
> > fsl_mac ffe4e4000.ethernet: FMan MEMAC
> > fsl_mac ffe4e4000.ethernet: FMan MAC address: 00:06:9c:0b:06:21
> > fsl_mac dpaa-ethernet.1: __devm_request_mem_region(mac) failed
> > fsl_mac: probe of dpaa-ethernet.1 failed with error -16
> > fsl_mac ffe4e6000.ethernet: FMan MEMAC
> > fsl_mac ffe4e6000.ethernet: FMan MAC address: 00:06:9c:0b:06:22
> > fsl_mac dpaa-ethernet.2: __devm_request_mem_region(mac) failed
> > fsl_mac: probe of dpaa-ethernet.2 failed with error -16
> > fsl_mac ffe4e8000.ethernet: FMan MEMAC
> > fsl_mac ffe4e8000.ethernet: FMan MAC address: 00:06:9c:0b:06:23
> > fsl_mac dpaa-ethernet.3: __devm_request_mem_region(mac) failed
> > fsl_mac: probe of dpaa-ethernet.3 failed with error -16
> >
> > Feels like FMAN still think there are real PHYs there ?
>
> Hi Joakim,
>
> These errors are issued when trying to probe the second time the same
> MAC node. The issue was introduced by this commit:
>
> commit 4d8ee1935bcd666360311dfdadeee235d682d69a
> Author: Florian Fainelli <f.fainelli@gmail.com>
> Date: Tue Aug 22 15:24:47 2017 -0700
> fsl/man: Inherit parent device and of_node
>
> and was later addressed by this patch set:
>
> http://patchwork.ozlabs.org/project/netdev/list/?series=8462&state=*
>
> Even with these errors printed, all is working fine, it's just the
> second probing that fails. Adding the latter patches or reverting
> the one above makes the errors prints dissapear.
Looking at the above patch seriers I see it is in state Accepted and has been there
since 2017-10-16
That seems like a awful long to wait in before getting into Linux, is there something
holding these patches back ?
Jocke
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: DPAA Ethernet traffice troubles with Linux kernel
@ 2018-01-19 8:00 ` Joakim Tjernlund
0 siblings, 0 replies; 63+ messages in thread
From: Joakim Tjernlund @ 2018-01-19 8:00 UTC (permalink / raw)
To: madalin.bucur, andrew; +Cc: linuxppc-dev, netdev, madskateman
T24gVGh1LCAxOTcwLTAxLTAxIGF0IDAwOjAwICswMDAwLCBNYWRhbGluLWNyaXN0aWFuIEJ1Y3Vy
IHdyb3RlOg0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IEpv
YWtpbSBUamVybmx1bmQgW21haWx0bzpKb2FraW0uVGplcm5sdW5kQGluZmluZXJhLmNvbV0NCj4g
PiBTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDE2LCAyMDE4IDc6NTggUE0NCj4gPiBUbzogYW5kcmV3
QGx1bm4uY2gNCj4gPiBTdWJqZWN0OiBSZTogRFBBQSBFdGhlcm5ldCB0cmFmZmljZSB0cm91Ymxl
cyB3aXRoIExpbnV4IGtlcm5lbA0KPiA+IA0KPiA+IE9uIFRodSwgMTk3MC0wMS0wMSBhdCAwMDow
MCArMDAwMCwgQW5kcmV3IEx1bm4gd3JvdGU6DQo+ID4gPiANCj4gPiA+IEhpIEpvYWtpbQ0KPiA+
ID4gDQo+ID4gPiBZb3UgYXBwZWFyIHRvIGJlIHVzaW5nIGFuIG9sZCBrZXJuZWwuIFRha2UgYSBs
b29rIGF0Og0KPiA+IA0KPiA+IE5vdCByZWFsbHksIEkgYW0gdXNpbmcgNC4xNC54IGFuZCBJIGRv
bid0IHRoaW5rIHRoYXQgaXMgb2xkLiBTZWVtcyBsaWtlDQo+ID4gdGhpcw0KPiA+IHBhdGNoIGhh
c24ndCBiZWVuIHNlbnQgdG8gNC4xNC54Lg0KPiA+IA0KPiA+IEkgd29uZGVyIGlmIEkgbWlnaHQg
YmUgbWlzc2luZyBzb21ldGhpbmcgZWxzZSwgd2UganVzdCBtb3ZlZCB0byA0LjE0IGFuZA0KPiA+
IG5vdGljIHRoYXQgYWxsDQo+ID4gb3VyIGZpeGVkIFBIWXMgYXJlIG5vbiBmdW5jdGlvbmluZzoN
Cj4gPiBmc2xfbWFjIGZmZTRlMjAwMC5ldGhlcm5ldDogRk1hbiBNRU1BQw0KPiA+IGZzbF9tYWMg
ZmZlNGUyMDAwLmV0aGVybmV0OiBGTWFuIE1BQyBhZGRyZXNzOiAwMDowNjo5YzowYjowNjoyMA0K
PiA+IGZzbF9tYWMgZHBhYS1ldGhlcm5ldC4wOiBfX2Rldm1fcmVxdWVzdF9tZW1fcmVnaW9uKG1h
YykgZmFpbGVkDQo+ID4gZnNsX21hYzogcHJvYmUgb2YgZHBhYS1ldGhlcm5ldC4wIGZhaWxlZCB3
aXRoIGVycm9yIC0xNg0KPiA+IGZzbF9tYWMgZmZlNGU0MDAwLmV0aGVybmV0OiBGTWFuIE1FTUFD
DQo+ID4gZnNsX21hYyBmZmU0ZTQwMDAuZXRoZXJuZXQ6IEZNYW4gTUFDIGFkZHJlc3M6IDAwOjA2
OjljOjBiOjA2OjIxDQo+ID4gZnNsX21hYyBkcGFhLWV0aGVybmV0LjE6IF9fZGV2bV9yZXF1ZXN0
X21lbV9yZWdpb24obWFjKSBmYWlsZWQNCj4gPiBmc2xfbWFjOiBwcm9iZSBvZiBkcGFhLWV0aGVy
bmV0LjEgZmFpbGVkIHdpdGggZXJyb3IgLTE2DQo+ID4gZnNsX21hYyBmZmU0ZTYwMDAuZXRoZXJu
ZXQ6IEZNYW4gTUVNQUMNCj4gPiBmc2xfbWFjIGZmZTRlNjAwMC5ldGhlcm5ldDogRk1hbiBNQUMg
YWRkcmVzczogMDA6MDY6OWM6MGI6MDY6MjINCj4gPiBmc2xfbWFjIGRwYWEtZXRoZXJuZXQuMjog
X19kZXZtX3JlcXVlc3RfbWVtX3JlZ2lvbihtYWMpIGZhaWxlZA0KPiA+IGZzbF9tYWM6IHByb2Jl
IG9mIGRwYWEtZXRoZXJuZXQuMiBmYWlsZWQgd2l0aCBlcnJvciAtMTYNCj4gPiBmc2xfbWFjIGZm
ZTRlODAwMC5ldGhlcm5ldDogRk1hbiBNRU1BQw0KPiA+IGZzbF9tYWMgZmZlNGU4MDAwLmV0aGVy
bmV0OiBGTWFuIE1BQyBhZGRyZXNzOiAwMDowNjo5YzowYjowNjoyMw0KPiA+IGZzbF9tYWMgZHBh
YS1ldGhlcm5ldC4zOiBfX2Rldm1fcmVxdWVzdF9tZW1fcmVnaW9uKG1hYykgZmFpbGVkDQo+ID4g
ZnNsX21hYzogcHJvYmUgb2YgZHBhYS1ldGhlcm5ldC4zIGZhaWxlZCB3aXRoIGVycm9yIC0xNg0K
PiA+IA0KPiA+IEZlZWxzIGxpa2UgRk1BTiBzdGlsbCB0aGluayB0aGVyZSBhcmUgcmVhbCBQSFlz
IHRoZXJlID8NCj4gDQo+IEhpIEpvYWtpbSwNCj4gDQo+IFRoZXNlIGVycm9ycyBhcmUgaXNzdWVk
IHdoZW4gdHJ5aW5nIHRvIHByb2JlIHRoZSBzZWNvbmQgdGltZSB0aGUgc2FtZQ0KPiBNQUMgbm9k
ZS4gVGhlIGlzc3VlIHdhcyBpbnRyb2R1Y2VkIGJ5IHRoaXMgY29tbWl0Og0KPiANCj4gY29tbWl0
IDRkOGVlMTkzNWJjZDY2NjM2MDMxMWRmZGFkZWVlMjM1ZDY4MmQ2OWENCj4gQXV0aG9yOiBGbG9y
aWFuIEZhaW5lbGxpIDxmLmZhaW5lbGxpQGdtYWlsLmNvbT4NCj4gRGF0ZTogVHVlIEF1ZyAyMiAx
NToyNDo0NyAyMDE3IC0wNzAwDQo+IGZzbC9tYW46IEluaGVyaXQgcGFyZW50IGRldmljZSBhbmQg
b2Zfbm9kZQ0KPiANCj4gYW5kIHdhcyBsYXRlciBhZGRyZXNzZWQgYnkgdGhpcyBwYXRjaCBzZXQ6
DQo+IA0KPiBodHRwOi8vcGF0Y2h3b3JrLm96bGFicy5vcmcvcHJvamVjdC9uZXRkZXYvbGlzdC8/
c2VyaWVzPTg0NjImc3RhdGU9Kg0KPiANCj4gRXZlbiB3aXRoIHRoZXNlIGVycm9ycyBwcmludGVk
LCBhbGwgaXMgd29ya2luZyBmaW5lLCBpdCdzIGp1c3QgdGhlDQo+IHNlY29uZCBwcm9iaW5nIHRo
YXQgZmFpbHMuIEFkZGluZyB0aGUgbGF0dGVyIHBhdGNoZXMgb3IgcmV2ZXJ0aW5nDQo+IHRoZSBv
bmUgYWJvdmUgbWFrZXMgdGhlIGVycm9ycyBwcmludHMgZGlzc2FwZWFyLg0KDQpMb29raW5nIGF0
IHRoZSBhYm92ZSBwYXRjaCBzZXJpZXJzIEkgc2VlIGl0IGlzIGluIHN0YXRlIEFjY2VwdGVkIGFu
ZCBoYXMgYmVlbiB0aGVyZQ0Kc2luY2UgMjAxNy0xMC0xNg0KVGhhdCBzZWVtcyBsaWtlIGEgYXdm
dWwgbG9uZyB0byB3YWl0IGluIGJlZm9yZSBnZXR0aW5nIGludG8gTGludXgsIGlzIHRoZXJlIHNv
bWV0aGluZw0KaG9sZGluZyB0aGVzZSBwYXRjaGVzIGJhY2sgPw0KDQogSm9ja2Ug
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: DPAA Ethernet traffice troubles with Linux kernel
2018-01-19 8:00 ` Joakim Tjernlund
(?)
@ 2018-01-19 13:22 ` Andrew Lunn
2018-01-19 13:42 ` Joakim Tjernlund
2018-02-04 16:47 ` PA Semi PWRficient Gigabit Ethernet doesn't work anymore since the first networking updates for the kernel 4.16 Christian Zigotzky
-1 siblings, 2 replies; 63+ messages in thread
From: Andrew Lunn @ 2018-01-19 13:22 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: madalin.bucur, linuxppc-dev, netdev, madskateman
> > commit 4d8ee1935bcd666360311dfdadeee235d682d69a
> > Author: Florian Fainelli <f.fainelli@gmail.com>
> > Date: Tue Aug 22 15:24:47 2017 -0700
> > fsl/man: Inherit parent device and of_node
> >
> > and was later addressed by this patch set:
> >
> > http://patchwork.ozlabs.org/project/netdev/list/?series=8462&state=*
> >
> > Even with these errors printed, all is working fine, it's just the
> > second probing that fails. Adding the latter patches or reverting
> > the one above makes the errors prints dissapear.
>
> Looking at the above patch seriers I see it is in state Accepted and has been there
> since 2017-10-16
> That seems like a awful long to wait in before getting into Linux, is there something
> holding these patches back ?
They are in Linux, have been since October 16th. But at the moment,
they are only in v4.15, not v4.14.
These patches probably don't fit the stable rules, for getting them
added to v4.14.
https://github.com/torvalds/linux/blob/master/Documentation/process/stable-kernel-rules.rst
What is needed is a minimal fix. Or just wait until Sunday, when there
is a good chance v4.15 will be released.
Andrew
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: DPAA Ethernet traffice troubles with Linux kernel
2018-01-19 13:22 ` Andrew Lunn
@ 2018-01-19 13:42 ` Joakim Tjernlund
2018-02-04 16:47 ` PA Semi PWRficient Gigabit Ethernet doesn't work anymore since the first networking updates for the kernel 4.16 Christian Zigotzky
1 sibling, 0 replies; 63+ messages in thread
From: Joakim Tjernlund @ 2018-01-19 13:42 UTC (permalink / raw)
To: andrew; +Cc: linuxppc-dev, netdev, madalin.bucur, madskateman
On Thu, 1970-01-01 at 00:00 +0000, Andrew Lunn wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
> > > commit 4d8ee1935bcd666360311dfdadeee235d682d69a
> > > Author: Florian Fainelli <f.fainelli@gmail.com>
> > > Date: Tue Aug 22 15:24:47 2017 -0700
> > > fsl/man: Inherit parent device and of_node
> > >
> > > and was later addressed by this patch set:
> > >
> > > http://patchwork.ozlabs.org/project/netdev/list/?series=8462&state=*
> > >
> > > Even with these errors printed, all is working fine, it's just the
> > > second probing that fails. Adding the latter patches or reverting
> > > the one above makes the errors prints dissapear.
> >
> > Looking at the above patch seriers I see it is in state Accepted and has been there
> > since 2017-10-16
> > That seems like a awful long to wait in before getting into Linux, is there something
> > holding these patches back ?
>
> They are in Linux, have been since October 16th. But at the moment,
> they are only in v4.15, not v4.14.
Now I see them in 4.15, must have looked in the wrong branch.
>
> These patches probably don't fit the stable rules, for getting them
> added to v4.14.
>
> https://github.com/torvalds/linux/blob/master/Documentation/process/stable-kernel-rules.rst
Stuff needs to work, whatever needed to make that happen is allowed. Even backporting
some new infra structure if need be to simplify fixing bugs.
>
> What is needed is a minimal fix. Or just wait until Sunday, when there
> is a good chance v4.15 will be released.
You seem to think everyone always upgrade to linux latest but this is not so.
We do product development here and appreciate the stable kernels so we can work in
peace and not chasing the latest kernel.
Jocke
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: DPAA Ethernet traffice troubles with Linux kernel
@ 2018-01-19 13:42 ` Joakim Tjernlund
0 siblings, 0 replies; 63+ messages in thread
From: Joakim Tjernlund @ 2018-01-19 13:42 UTC (permalink / raw)
To: andrew; +Cc: linuxppc-dev, netdev, madalin.bucur, madskateman
T24gVGh1LCAxOTcwLTAxLTAxIGF0IDAwOjAwICswMDAwLCBBbmRyZXcgTHVubiB3cm90ZToNCj4g
Q0FVVElPTjogVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0aGUgb3JnYW5p
emF0aW9uLiBEbyBub3QgY2xpY2sgbGlua3Mgb3Igb3BlbiBhdHRhY2htZW50cyB1bmxlc3MgeW91
IHJlY29nbml6ZSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50IGlzIHNhZmUuDQo+IA0K
PiANCj4gPiA+IGNvbW1pdCA0ZDhlZTE5MzViY2Q2NjYzNjAzMTFkZmRhZGVlZTIzNWQ2ODJkNjlh
DQo+ID4gPiBBdXRob3I6IEZsb3JpYW4gRmFpbmVsbGkgPGYuZmFpbmVsbGlAZ21haWwuY29tPg0K
PiA+ID4gRGF0ZTogVHVlIEF1ZyAyMiAxNToyNDo0NyAyMDE3IC0wNzAwDQo+ID4gPiBmc2wvbWFu
OiBJbmhlcml0IHBhcmVudCBkZXZpY2UgYW5kIG9mX25vZGUNCj4gPiA+IA0KPiA+ID4gYW5kIHdh
cyBsYXRlciBhZGRyZXNzZWQgYnkgdGhpcyBwYXRjaCBzZXQ6DQo+ID4gPiANCj4gPiA+IGh0dHA6
Ly9wYXRjaHdvcmsub3psYWJzLm9yZy9wcm9qZWN0L25ldGRldi9saXN0Lz9zZXJpZXM9ODQ2MiZz
dGF0ZT0qDQo+ID4gPiANCj4gPiA+IEV2ZW4gd2l0aCB0aGVzZSBlcnJvcnMgcHJpbnRlZCwgYWxs
IGlzIHdvcmtpbmcgZmluZSwgaXQncyBqdXN0IHRoZQ0KPiA+ID4gc2Vjb25kIHByb2JpbmcgdGhh
dCBmYWlscy4gQWRkaW5nIHRoZSBsYXR0ZXIgcGF0Y2hlcyBvciByZXZlcnRpbmcNCj4gPiA+IHRo
ZSBvbmUgYWJvdmUgbWFrZXMgdGhlIGVycm9ycyBwcmludHMgZGlzc2FwZWFyLg0KPiA+IA0KPiA+
IExvb2tpbmcgYXQgdGhlIGFib3ZlIHBhdGNoIHNlcmllcnMgSSBzZWUgaXQgaXMgaW4gc3RhdGUg
QWNjZXB0ZWQgYW5kIGhhcyBiZWVuIHRoZXJlDQo+ID4gc2luY2UgMjAxNy0xMC0xNg0KPiA+IFRo
YXQgc2VlbXMgbGlrZSBhIGF3ZnVsIGxvbmcgdG8gd2FpdCBpbiBiZWZvcmUgZ2V0dGluZyBpbnRv
IExpbnV4LCBpcyB0aGVyZSBzb21ldGhpbmcNCj4gPiBob2xkaW5nIHRoZXNlIHBhdGNoZXMgYmFj
ayA/DQo+IA0KPiBUaGV5IGFyZSBpbiBMaW51eCwgaGF2ZSBiZWVuIHNpbmNlIE9jdG9iZXIgMTZ0
aC4gQnV0IGF0IHRoZSBtb21lbnQsDQo+IHRoZXkgYXJlIG9ubHkgaW4gdjQuMTUsIG5vdCB2NC4x
NC4NCg0KTm93IEkgc2VlIHRoZW0gaW4gNC4xNSwgbXVzdCBoYXZlIGxvb2tlZCBpbiB0aGUgd3Jv
bmcgYnJhbmNoLg0KDQo+IA0KPiBUaGVzZSBwYXRjaGVzIHByb2JhYmx5IGRvbid0IGZpdCB0aGUg
c3RhYmxlIHJ1bGVzLCBmb3IgZ2V0dGluZyB0aGVtDQo+IGFkZGVkIHRvIHY0LjE0Lg0KPiANCj4g
aHR0cHM6Ly9naXRodWIuY29tL3RvcnZhbGRzL2xpbnV4L2Jsb2IvbWFzdGVyL0RvY3VtZW50YXRp
b24vcHJvY2Vzcy9zdGFibGUta2VybmVsLXJ1bGVzLnJzdA0KDQpTdHVmZiBuZWVkcyB0byB3b3Jr
LCB3aGF0ZXZlciBuZWVkZWQgdG8gbWFrZSB0aGF0IGhhcHBlbiBpcyBhbGxvd2VkLiBFdmVuIGJh
Y2twb3J0aW5nDQpzb21lIG5ldyBpbmZyYSBzdHJ1Y3R1cmUgaWYgbmVlZCBiZSB0byBzaW1wbGlm
eSBmaXhpbmcgYnVncy4NCg0KPiANCj4gV2hhdCBpcyBuZWVkZWQgaXMgYSBtaW5pbWFsIGZpeC4g
T3IganVzdCB3YWl0IHVudGlsIFN1bmRheSwgd2hlbiB0aGVyZQ0KPiBpcyBhIGdvb2QgY2hhbmNl
IHY0LjE1IHdpbGwgYmUgcmVsZWFzZWQuDQoNCllvdSBzZWVtIHRvIHRoaW5rIGV2ZXJ5b25lIGFs
d2F5cyB1cGdyYWRlIHRvIGxpbnV4IGxhdGVzdCBidXQgdGhpcyBpcyBub3Qgc28uDQpXZSBkbyBw
cm9kdWN0IGRldmVsb3BtZW50IGhlcmUgYW5kIGFwcHJlY2lhdGUgdGhlIHN0YWJsZSBrZXJuZWxz
IHNvIHdlIGNhbiB3b3JrIGluDQpwZWFjZSBhbmQgbm90IGNoYXNpbmcgdGhlIGxhdGVzdCBrZXJu
ZWwuDQoNCiBKb2NrZQ==
^ permalink raw reply [flat|nested] 63+ messages in thread
* PA Semi PWRficient Gigabit Ethernet doesn't work anymore since the first networking updates for the kernel 4.16
2018-01-19 13:22 ` Andrew Lunn
2018-01-19 13:42 ` Joakim Tjernlund
@ 2018-02-04 16:47 ` Christian Zigotzky
2018-02-04 17:16 ` Andrew Lunn
1 sibling, 1 reply; 63+ messages in thread
From: Christian Zigotzky @ 2018-02-04 16:47 UTC (permalink / raw)
To: netdev, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1851 bytes --]
Hello,
The PA Semi PWRficient Gigabit Ethernet doesn't work anymore since the
first networking updates [1] for the kernel 4.16.
Error messages:
[ 0.634241] libphy: pasemi gpio mdio bus: probed
[ 0.634749] pasemi gpio mdio bus: Cannot register as MDIO bus, err -38
[ 2.311496] pasemi_mac 0000:00:14.0: runtime IRQ mapping not provided
by arch
[ 2.311554] pasemi_mac 0000:00:14.1: runtime IRQ mapping not provided
by arch
[ 2.311599] pasemi_mac 0000:00:14.2: runtime IRQ mapping not provided
by arch
[ 2.311641] pasemi_mac 0000:00:14.3: runtime IRQ mapping not provided
by arch
[ 2.312276] pasemi_mac 0000:00:15.0: runtime IRQ mapping not provided
by arch
[ 2.312903] pasemi_mac 0000:00:15.1: runtime IRQ mapping not provided
by arch
[ 3.817420] i2c-pasemi 0000:00:1c.0: runtime IRQ mapping not provided
by arch
[ 3.817616] i2c-pasemi 0000:00:1c.1: runtime IRQ mapping not provided
by arch
[ 3.817809] i2c-pasemi 0000:00:1c.2: runtime IRQ mapping not provided
by arch
[ 4.299984] pasemi_edac 0000:00:04.0: runtime IRQ mapping not
provided by arch
[ 4.300281] pasemi_edac 0000:00:05.0: runtime IRQ mapping not
provided by arch
[ 39.633565] pasemi_mac 0000:00:14.3: PHY init failed: -19.
[ 39.633569] pasemi_mac 0000:00:14.3: Defaulting to 1Gbit full duplex
I figured out that the problematic code is in the mdio bus changes of
the networking updates. [1]
I found the problematic code in the file 'drivers/net/phy/mdio_bus.c'. I
created a patch which solves the problem with the PA Semi PWRficient
Gigabit Ethernet. (attached)
Could you please check the changes in the file 'drivers/net/phy/mdio_bus.c'?
Thanks,
Christian
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b2fe5fa68642860e7de76167c3111623aa0d5de1
[-- Attachment #2: mdio_bus.patch --]
[-- Type: text/x-patch, Size: 1052 bytes --]
--- a/drivers/net/phy/mdio_bus.c 2018-02-03 17:34:46.973045321 +0100
+++ b/drivers/net/phy/mdio_bus.c 2018-02-04 11:03:14.909093360 +0100
@@ -47,41 +47,11 @@
#include "mdio-boardinfo.h"
-static int mdiobus_register_gpiod(struct mdio_device *mdiodev)
-{
- struct gpio_desc *gpiod = NULL;
-
- /* Deassert the optional reset signal */
- if (mdiodev->dev.of_node)
- gpiod = fwnode_get_named_gpiod(&mdiodev->dev.of_node->fwnode,
- "reset-gpios", 0, GPIOD_OUT_LOW,
- "PHY reset");
- if (PTR_ERR(gpiod) == -ENOENT)
- gpiod = NULL;
- else if (IS_ERR(gpiod))
- return PTR_ERR(gpiod);
-
- mdiodev->reset = gpiod;
-
- /* Assert the reset signal again */
- mdio_device_reset(mdiodev, 1);
-
- return 0;
-}
-
int mdiobus_register_device(struct mdio_device *mdiodev)
{
- int err;
-
if (mdiodev->bus->mdio_map[mdiodev->addr])
return -EBUSY;
- if (mdiodev->flags & MDIO_DEVICE_FLAG_PHY) {
- err = mdiobus_register_gpiod(mdiodev);
- if (err)
- return err;
- }
-
mdiodev->bus->mdio_map[mdiodev->addr] = mdiodev;
return 0;
^ permalink raw reply [flat|nested] 63+ messages in thread* Re: PA Semi PWRficient Gigabit Ethernet doesn't work anymore since the first networking updates for the kernel 4.16
2018-02-04 16:47 ` PA Semi PWRficient Gigabit Ethernet doesn't work anymore since the first networking updates for the kernel 4.16 Christian Zigotzky
@ 2018-02-04 17:16 ` Andrew Lunn
2018-02-04 20:01 ` Florian Fainelli
2018-02-05 9:38 ` Christian Zigotzky
0 siblings, 2 replies; 63+ messages in thread
From: Andrew Lunn @ 2018-02-04 17:16 UTC (permalink / raw)
To: Christian Zigotzky; +Cc: netdev, linuxppc-dev
On Sun, Feb 04, 2018 at 05:47:03PM +0100, Christian Zigotzky wrote:
> Hello,
>
> The PA Semi PWRficient Gigabit Ethernet doesn't work anymore since the first
> networking updates [1] for the kernel 4.16.
>
> Error messages:
>
> [ 0.634241] libphy: pasemi gpio mdio bus: probed
> [ 0.634749] pasemi gpio mdio bus: Cannot register as MDIO bus, err -38
-38 is ENOSYS.
> --- a/drivers/net/phy/mdio_bus.c 2018-02-03 17:34:46.973045321 +0100
> +++ b/drivers/net/phy/mdio_bus.c 2018-02-04 11:03:14.909093360 +0100
> @@ -47,41 +47,11 @@
>
> #include "mdio-boardinfo.h"
>
> -static int mdiobus_register_gpiod(struct mdio_device *mdiodev)
> -{
> - struct gpio_desc *gpiod = NULL;
> -
> - /* Deassert the optional reset signal */
> - if (mdiodev->dev.of_node)
> - gpiod = fwnode_get_named_gpiod(&mdiodev->dev.of_node->fwnode,
> - "reset-gpios", 0, GPIOD_OUT_LOW,
> - "PHY reset");
So i think you don't have GPIOLIB enabled. Hence you are hitting
http://elixir.free-electrons.com/linux/latest/source/include/linux/gpio/consumer.h#L470
static inline
struct gpio_desc *fwnode_get_named_gpiod(struct fwnode_handle *fwnode,
const char *propname, int index,
enum gpiod_flags dflags,
const char *label)
{
return ERR_PTR(-ENOSYS);
}
So rather than just deleting all this code, breaking other platforms
that need this gpio, lets try a real fix. Please try this. If it
works, i will formally submit it.
Andrew
>From a4210ba306948497d7360927c1e532eb903c58b2 Mon Sep 17 00:00:00 2001
From: Andrew Lunn <andrew@lunn.ch>
Date: Sun, 4 Feb 2018 11:09:20 -0600
Subject: [PATCH] net: phy: Handle not having GPIO enabled in the kernel
If CONFIG_GPIOLIB is disabled, fwnode_get_named_gpiod() becomes a stub
function, which return -ENOSYS. Handle this in the same way as
-ENOENT, i.e. assume there is no GPIO used to reset the PHYs.
Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/phy/mdio_bus.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index 88272b3ac2e2..24b5511222c8 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -56,7 +56,8 @@ static int mdiobus_register_gpiod(struct mdio_device *mdiodev)
gpiod = fwnode_get_named_gpiod(&mdiodev->dev.of_node->fwnode,
"reset-gpios", 0, GPIOD_OUT_LOW,
"PHY reset");
- if (PTR_ERR(gpiod) == -ENOENT)
+ if (PTR_ERR(gpiod) == -ENOENT ||
+ PTR_ERR(gpiod) == -ENOSYS)
gpiod = NULL;
else if (IS_ERR(gpiod))
return PTR_ERR(gpiod);
--
2.15.1
^ permalink raw reply related [flat|nested] 63+ messages in thread* Re: PA Semi PWRficient Gigabit Ethernet doesn't work anymore since the first networking updates for the kernel 4.16
2018-02-04 17:16 ` Andrew Lunn
@ 2018-02-04 20:01 ` Florian Fainelli
2018-02-05 9:38 ` Christian Zigotzky
1 sibling, 0 replies; 63+ messages in thread
From: Florian Fainelli @ 2018-02-04 20:01 UTC (permalink / raw)
To: Andrew Lunn, Christian Zigotzky; +Cc: netdev, linuxppc-dev
On 02/04/2018 09:16 AM, Andrew Lunn wrote:
> On Sun, Feb 04, 2018 at 05:47:03PM +0100, Christian Zigotzky wrote:
>> Hello,
>>
>> The PA Semi PWRficient Gigabit Ethernet doesn't work anymore since the first
>> networking updates [1] for the kernel 4.16.
>>
>> Error messages:
>>
>> [ 0.634241] libphy: pasemi gpio mdio bus: probed
>> [ 0.634749] pasemi gpio mdio bus: Cannot register as MDIO bus, err -38
>
> -38 is ENOSYS.
>
>> --- a/drivers/net/phy/mdio_bus.c 2018-02-03 17:34:46.973045321 +0100
>> +++ b/drivers/net/phy/mdio_bus.c 2018-02-04 11:03:14.909093360 +0100
>> @@ -47,41 +47,11 @@
>>
>> #include "mdio-boardinfo.h"
>>
>> -static int mdiobus_register_gpiod(struct mdio_device *mdiodev)
>> -{
>> - struct gpio_desc *gpiod = NULL;
>> -
>> - /* Deassert the optional reset signal */
>> - if (mdiodev->dev.of_node)
>> - gpiod = fwnode_get_named_gpiod(&mdiodev->dev.of_node->fwnode,
>> - "reset-gpios", 0, GPIOD_OUT_LOW,
>> - "PHY reset");
>
> So i think you don't have GPIOLIB enabled. Hence you are hitting
>
> http://elixir.free-electrons.com/linux/latest/source/include/linux/gpio/consumer.h#L470
>
> static inline
> struct gpio_desc *fwnode_get_named_gpiod(struct fwnode_handle *fwnode,
> const char *propname, int index,
> enum gpiod_flags dflags,
> const char *label)
> {
> return ERR_PTR(-ENOSYS);
> }
>
> So rather than just deleting all this code, breaking other platforms
> that need this gpio, lets try a real fix. Please try this. If it
> works, i will formally submit it.
>
> Andrew
>
> From a4210ba306948497d7360927c1e532eb903c58b2 Mon Sep 17 00:00:00 2001
> From: Andrew Lunn <andrew@lunn.ch>
> Date: Sun, 4 Feb 2018 11:09:20 -0600
> Subject: [PATCH] net: phy: Handle not having GPIO enabled in the kernel
>
> If CONFIG_GPIOLIB is disabled, fwnode_get_named_gpiod() becomes a stub
> function, which return -ENOSYS. Handle this in the same way as
> -ENOENT, i.e. assume there is no GPIO used to reset the PHYs.
>
> Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Fixes: bafbdd527d56 ("phylib: Add device reset GPIO support")
> ---
> drivers/net/phy/mdio_bus.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
> index 88272b3ac2e2..24b5511222c8 100644
> --- a/drivers/net/phy/mdio_bus.c
> +++ b/drivers/net/phy/mdio_bus.c
> @@ -56,7 +56,8 @@ static int mdiobus_register_gpiod(struct mdio_device *mdiodev)
> gpiod = fwnode_get_named_gpiod(&mdiodev->dev.of_node->fwnode,
> "reset-gpios", 0, GPIOD_OUT_LOW,
> "PHY reset");
> - if (PTR_ERR(gpiod) == -ENOENT)
> + if (PTR_ERR(gpiod) == -ENOENT ||
> + PTR_ERR(gpiod) == -ENOSYS)
> gpiod = NULL;
> else if (IS_ERR(gpiod))
> return PTR_ERR(gpiod);
>
--
Florian
^ permalink raw reply [flat|nested] 63+ messages in thread* PA Semi PWRficient Gigabit Ethernet doesn't work anymore since the first networking updates for the kernel 4.16
2018-02-04 17:16 ` Andrew Lunn
2018-02-04 20:01 ` Florian Fainelli
@ 2018-02-05 9:38 ` Christian Zigotzky
2018-02-05 14:29 ` Andrew Lunn
1 sibling, 1 reply; 63+ messages in thread
From: Christian Zigotzky @ 2018-02-05 9:38 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, linuxppc-dev
Hello Andrew,
Many thanks for your patch. I compiled the latest git kernel today and
the PA Semi PWRficient Gigabit Ethernet works with your patch.
Have a nice week!
Thanks,
Christian
On 04 February 2018 at 6:16PM, Andrew Lunn wrote:
> On Sun, Feb 04, 2018 at 05:47:03PM +0100, Christian Zigotzky wrote:
>> Hello,
>>
>> The PA Semi PWRficient Gigabit Ethernet doesn't work anymore since
the first
>> networking updates [1] for the kernel 4.16.
>>
>> Error messages:
>>
>> [ 0.634241] libphy: pasemi gpio mdio bus: probed
>> [ 0.634749] pasemi gpio mdio bus: Cannot register as MDIO bus,
err -38
>
> -38 is ENOSYS.
>
>> --- a/drivers/net/phy/mdio_bus.c 2018-02-03 17:34:46.973045321 +0100
>> +++ b/drivers/net/phy/mdio_bus.c 2018-02-04 11:03:14.909093360 +0100
>> @@ -47,41 +47,11 @@
>>
>> #include "mdio-boardinfo.h"
>>
>> -static int mdiobus_register_gpiod(struct mdio_device *mdiodev)
>> -{
>> - struct gpio_desc *gpiod = NULL;
>> -
>> - /* Deassert the optional reset signal */
>> - if (mdiodev->dev.of_node)
>> - gpiod = fwnode_get_named_gpiod(&mdiodev->dev.of_node->fwnode,
>> - "reset-gpios", 0, GPIOD_OUT_LOW,
>> - "PHY reset");
>
> So i think you don't have GPIOLIB enabled. Hence you are hitting
>
>
http://elixir.free-electrons.com/linux/latest/source/include/linux/gpio/consumer.h#L470
>
> static inline
> struct gpio_desc *fwnode_get_named_gpiod(struct fwnode_handle *fwnode,
> const char *propname, int index,
> enum gpiod_flags dflags,
> const char *label)
> {
> return ERR_PTR(-ENOSYS);
> }
>
> So rather than just deleting all this code, breaking other platforms
> that need this gpio, lets try a real fix. Please try this. If it
> works, i will formally submit it.
>
> Andrew
>
> >From a4210ba306948497d7360927c1e532eb903c58b2 Mon Sep 17 00:00:00 2001
> From: Andrew Lunn <andrew@lunn.ch>
> Date: Sun, 4 Feb 2018 11:09:20 -0600
> Subject: [PATCH] net: phy: Handle not having GPIO enabled in the kernel
>
> If CONFIG_GPIOLIB is disabled, fwnode_get_named_gpiod() becomes a stub
> function, which return -ENOSYS. Handle this in the same way as
> -ENOENT, i.e. assume there is no GPIO used to reset the PHYs.
>
> Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
> drivers/net/phy/mdio_bus.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
> index 88272b3ac2e2..24b5511222c8 100644
> --- a/drivers/net/phy/mdio_bus.c
> +++ b/drivers/net/phy/mdio_bus.c
> @@ -56,7 +56,8 @@ static int mdiobus_register_gpiod(struct
mdio_device *mdiodev)
> gpiod = fwnode_get_named_gpiod(&mdiodev->dev.of_node->fwnode,
> "reset-gpios", 0, GPIOD_OUT_LOW,
> "PHY reset");
> - if (PTR_ERR(gpiod) == -ENOENT)
> + if (PTR_ERR(gpiod) == -ENOENT ||
> + PTR_ERR(gpiod) == -ENOSYS)
> gpiod = NULL;
> else if (IS_ERR(gpiod))
> return PTR_ERR(gpiod);
^ permalink raw reply [flat|nested] 63+ messages in thread* Re: PA Semi PWRficient Gigabit Ethernet doesn't work anymore since the first networking updates for the kernel 4.16
2018-02-05 9:38 ` Christian Zigotzky
@ 2018-02-05 14:29 ` Andrew Lunn
2018-02-05 15:27 ` Christian Zigotzky
0 siblings, 1 reply; 63+ messages in thread
From: Andrew Lunn @ 2018-02-05 14:29 UTC (permalink / raw)
To: Christian Zigotzky; +Cc: netdev, linuxppc-dev
On Mon, Feb 05, 2018 at 10:38:34AM +0100, Christian Zigotzky wrote:
> Hello Andrew,
>
> Many thanks for your patch. I compiled the latest git kernel today and the
> PA Semi PWRficient Gigabit Ethernet works with your patch.
Great.
Can i add a tested-by:
Thanks
Andrew
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: PA Semi PWRficient Gigabit Ethernet doesn't work anymore since the first networking updates for the kernel 4.16
2018-02-05 14:29 ` Andrew Lunn
@ 2018-02-05 15:27 ` Christian Zigotzky
0 siblings, 0 replies; 63+ messages in thread
From: Christian Zigotzky @ 2018-02-05 15:27 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, linuxppc-dev
Yes, you can.
Christian
On 05 February 2018 at 3:29PM, Andrew Lunn wrote:
> On Mon, Feb 05, 2018 at 10:38:34AM +0100, Christian Zigotzky wrote:
>> Hello Andrew,
>>
>> Many thanks for your patch. I compiled the latest git kernel today and the
>> PA Semi PWRficient Gigabit Ethernet works with your patch.
> Great.
>
> Can i add a tested-by:
>
> Thanks
> Andrew
>
^ permalink raw reply [flat|nested] 63+ messages in thread
