Kirkwood DT kernel 4.20 - r8189 driver failed with error -5

Problems with packages? Post here, using [tags] of the package name.

Kirkwood DT kernel 4.20 - r8189 driver failed with error -5

Postby arti74 » Tue Jan 29, 2019 8:18 pm

Hello everyone.
On my Zyxel NSA 310 device, the wired network stopped working after upgrade from 4.19.9 kernel - to 4.20. Even 4.20.4-1-ARCH upgrade did not help.
$this->bbcode_second_pass_quote('', 'r')torrent@zyxel ~]$ dmesg | grep r8169
[ 1.839771] r8169 0000:01:00.0: enabling device (0140 -> 0143)
[ 1.846456] r8169 0000:01:00.0 (unnamed net_device) (uninitialized): rtl_ph 0 (loop: 20, delay: 25).
[ 1.856836] r8160000:01:00.0 failed with error -5

The only solution is to downgrade my kernel ( core/linux-kirkwood-dt 4.20.4-1he Linux Kernel and modules - Marvell Kirkwood DT) to the 4.19 version.
$this->bbcode_second_pass_quote('', 'd')mesg | grep r8169:
phy_addr=r8169-100:00, irq=IGNORE)0000:01:00.ink is Down
[ 1.620968] r8169 0000:01:0g device (0140 -> 0143): r8169: probed
[ 1.638409] r8169 0000:01:00.0 eth0: features [frames: 9200 ko]
[ 17.788723] r8169 0000:01:00.0 enp1s0: renamed frigabit Ethernet r8169-100:00: attached PHY driver [RTL8211B Gigabit Ethernet] (mii_bus:phy_a00:00, irq=IGNORE)
[ 19.062706] r8169 0000:01:00.0 enp Down
[ 21.412117] r1:00.0 enp1s0: Link is Up - 1Gbps/Fcontrol rx/tx

Now I noticed even newer DT kernel - version 4.20.5-1, but installing this and adding r8169aspm-dkms package (thought it could fix something), resulted with this:
$this->bbcode_second_pass_quote('', '[') 1.840543]: enabling device (0140 -> 0143)
[ 1.847230] r8169 0000:01:00.0 (unnamed net_device) (uninitialized): rtl_phyar_cond == 0 (loop: 20, delay: 25).
[ 1.857607] r8169: probe of 0000:01:00.0 failed with error -5
[ 20.146505] r8169_aspm: loading out-of-tree module taints kernel.
[ 20.161331] Error: Driver 'r8169' is already registered, aborting...

It seems my serial console does't display all messages properly - sorry for that.
Looking for any help with a solution.
Thanks
Last edited by arti74 on Thu Feb 14, 2019 1:46 pm, edited 2 times in total.
arti74
 
Posts: 75
Joined: Tue Apr 17, 2018 10:33 am
Top

Re: Kirkwood DT kernel 4.20 - r8189 driver failed with error

Postby summers » Tue Jan 29, 2019 8:29 pm

Odd, I have a NSA325v2 and thought take except for the 1/2 HDD slots they were the same. Anyway I'm on: $this->bbcode_second_pass_code('', 'Linux nas 4.20.4-1-ARCH #1 PREEMPT Wed Jan 23 02:54:42 UTC 2019 armv5tel GNU/Linux') but my main ethernet is $this->bbcode_second_pass_code('', '[ 1.623904] mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4
[ 1.631143] mv643xx_eth_port mv643xx_eth_port.0: DMA mask not set
[ 1.638434] mv643xx_eth_port mv643xx_eth_port.0 eth0: port 0 with MAC address 12:23:45:67:89
[ 27.577709] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 1000 Mb/s, full duplex, flow control disabled') so sounds like I have a different ethernet chip to you .... how strange ...
summers
 
Posts: 995
Joined: Sat Sep 06, 2014 12:56 pm

Re: Kirkwood DT kernel 4.20 - r8189 driver failed with error

Postby arti74 » Tue Jan 29, 2019 9:04 pm

Hi Summers - it's nice to see you here!
Anyway - your mobo is different - and better most likely.
Ok, again the log from the working 4.19.9-1-ARCH kernel:
$this->bbcode_second_pass_quote('', '[')rtorrent@zyxel ~]$ dmesg | grep r8169
[ 1.620860] r8169 0000:01:00.0: enabling device (0140 -> 0143)
[ 1.634144] libphy: r8169: probed
[ 1.638369] r8169 0000:01:00.0 eth0: RTL8168d/8111d, 00:00:00:00:00:30, XID 283000c0, IRQ 35
[ 1.646944] r8169 0000:01:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]
[ 17.564006] r8169 0000:01:00.0 enp1s0: renamed from eth0
[ 18.248678] RTL8211B Gigabit Ethernet r8169-100:00: attached PHY driver [RTL8211B Gigabit Ethernet] (mii_bus:phy_addr=r8169-100:00, irq=IGNORE)
[ 18.813893] r8169 0000:01:00.0 enp1s0: Link is Down
[ 21.064628] r8169 0000:01:00.0 enp1s0: Link is Up - 1Gbps/Full - flow control rx/tx
arti74
 
Posts: 75
Joined: Tue Apr 17, 2018 10:33 am
Top

Re: Kirkwood DT kernel 4.20 - r8169 driver failed with error

Postby arti74 » Wed Jan 30, 2019 9:53 pm

Update - tried r8168 driver, and it is recognized:
$this->bbcode_second_pass_quote('', 'd')mesg | grep r8168
[ 17.686061] r8168: loading out-of-tree module taints kernel.
[ 17.741822] r8168 Gigabit Ethernet driver 8.046.00-NAPI loaded
[ 17.867120] r8168 0000:01:00.0: no MSI. Back to INTx.
[ 18.098273] r8168 0000:01:00.0 (unnamed net_device) (uninitialized): Invalid ether addr 00:00:00:00:00:00
[ 18.205340] r8168 0000:01:00.0 (unnamed net_device) (uninitialized): Random ether addr 0e:d5:0c:f7:73:74
[ 18.296110] r8168: This product is covered by one or more of the following patents: US6,570,884, US6,115,776, and US6,327,625.
[ 18.378499] r8168 Copyright (C) 2018 Realtek NIC software team <nicfae@realtek.com>
[ 18.947740] r8168 0000:01:00.0 enp1s0: renamed from eth0

As you see the mac address is not set, network isn't up. Did it manually with:
ifconfig enp1s0 hw ether CC:5D:4E:C9:..:.. and:
ip address add 192.168.1.74/24 broadcast 192.168.1.255 dev enp1s0
then ifconfig -a shows:
$this->bbcode_second_pass_quote('', 'e')np1s0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 192.168.1.74 netmask 255.255.255.0 broadcast 192.168.1.255
ether cc:5d:4e:c9:...... txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 35 base 0xe000
...

ip link set enp1s0 up -- and it's up, however can ping only to itself, nothing else...
part of lspci -vvnn:
$this->bbcode_second_pass_quote('', '0')1:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 03)
Subsystem: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller [10ec:8168]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 35
Region 0: I/O ports at 10000 [size=256]
Region 2: Memory at e0014000 (64-bit, prefetchable) [size=4K]
Region 4: Memory at e0010000 (64-bit, prefetchable) [size=16K]
[virtual] Expansion ROM at e0000000 [disabled] [size=64K]
Capabilities: <access denied>
Kernel driver in use: r8168
Kernel modules: r8168

And finally:
$this->bbcode_second_pass_code('', 'ip link show dev enp1s0
2: enp1s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
link/ether cc:5d:4e:c9:f5:4a brd ff:ff:ff:ff:ff:ff
')
Can't get it to work somehow :|
Some hints please?
.....
EDIT: I give up... - it's something with the new kernel, and therefore way above my skills to fix it.
I'll try in the future with the new dt-kernel revisions (although it's already 4.20.5 version and no fix, so my hopes are getting lower)
:(
arti74
 
Posts: 75
Joined: Tue Apr 17, 2018 10:33 am
Top

Re: Kirkwood DT kernel 4.20 - r8189 driver failed with error

Postby arti74 » Sun Feb 24, 2019 6:04 pm

I tried every updated kernel and it's still the same...
Currently on:
$this->bbcode_second_pass_code('', 'uname -rv
4.20.11-1-ARCH #1 PREEMPT Thu Feb 21 02:24:52 UTC 2019')
$this->bbcode_second_pass_code('', 'dmesg | grep r816
[ 2.019287] r8169 0000:01:00.0: enabling device (0140 -> 0143)
[ 2.025973] r8169 0000:01:00.0 (unnamed net_device) (uninitialized): rtl_phyar_cond == 0 (loop: 20, delay: 25).
[ 2.036347] r8169: probe of 0000:01:00.0 failed with error -5')
Tried to load module by hand: modprobe -f r8169 (went without any error, however modinfo or lsmod does not present any r8169...
On the Debian forum, a guy with the same device as mine (Zyxel NSA310), confirmed the exactly the same error.
https://forum.doozan.com/read.php?2,776 ... #msg-77889
Where can I report this - it's an obvious driver bug.
:?
arti74
 
Posts: 75
Joined: Tue Apr 17, 2018 10:33 am

Re: Kirkwood DT kernel 4.20 - r8189 driver failed with error

Postby summers » Sun Feb 24, 2019 7:47 pm

@bodhi is an expert on these things - he knows far more than me.

So think if you are in contact with @bodhi and he'll solve uboot issues.

Main kernel is a different issue, taking time to look into the kernel takes time to see what has changed. This goes beyond the time I have available, at the moment. Alas occupied on TinkerBoard these days. But keeping an eye on this as I need my NSA325 to stay up ...
summers
 
Posts: 995
Joined: Sat Sep 06, 2014 12:56 pm

Re: Kirkwood DT kernel 4.20 - r8189 driver failed with error

Postby arti74 » Sat Mar 23, 2019 8:43 pm

No any improve in the recent kernel 5.0.3-1, so finally I've submitted a bug to the kernel.org - I should do it much earlier...
https://bugzilla.kernel.org/show_bug.cgi?id=203025
arti74
 
Posts: 75
Joined: Tue Apr 17, 2018 10:33 am

Re: Kirkwood DT kernel 4.20 - r8189 driver failed with error

Postby summers » Sun Mar 24, 2019 10:00 am

Dug a bit this morning - looks like the kernel module is https://github.com/torvalds/linux/blob/master/drivers/net/ethernet/realtek/r8169.c there were along of changes to r8169.c between 4.19 and 4.20. Full diff is
$this->bbcode_second_pass_code('', 'diff linux-4.19/drivers/net/ethernet/realtek/r8169.c linux-4.20/drivers/net/ethernet/realtek/r8169.c
80,81d79
< #define RTL8169_TX_TIMEOUT (6*HZ)
<
636d633
< RTL_FLAG_TASK_SLOW_PENDING,
1357c1354,1355
< rtl_ack_events(tp, RTL_EVENT_NAPI | tp->event_slow);
---
> rtl_ack_events(tp, 0xffff);
> /* PCI commit */
4051,4058c4049
< netif_dbg(tp, drv, dev,
< "Set MAC Reg C+CR Offset 0x82h = 0x01h\n");
< RTL_W8(tp, 0x82, 0x01);
< }
<
< pci_write_config_byte(tp->pci_dev, PCI_LATENCY_TIMER, 0x40);
<
< if (tp->mac_version <= RTL_GIGA_MAC_VER_06)
---
> pci_write_config_byte(tp->pci_dev, PCI_LATENCY_TIMER, 0x40);
4060,4061d4050
<
< if (tp->mac_version == RTL_GIGA_MAC_VER_02) {
4065,4067d4053
< netif_dbg(tp, drv, dev,
< "Set PHY Reg 0x0bh = 0x00h\n");
< rtl_writephy(tp, 0x0b, 0x0000); //w 0x0b 15 0 0
4178c4164,4166
< if (!netif_running(tp->dev) || !__rtl8169_get_wol(tp))
---
> struct phy_device *phydev;
>
> if (!__rtl8169_get_wol(tp))
4181c4169,4172
< phy_speed_down(tp->dev->phydev, false);
---
> /* phydev may not be attached to netdevice */
> phydev = mdiobus_get_phy(tp->mii_bus, 0);
>
> phy_speed_down(phydev, false);
4569,4581c4560
< static const struct rtl_cfg2_info {
< u32 mac_version;
< u32 clk;
< u32 val;
< } cfg2_info [] = {
< { RTL_GIGA_MAC_VER_05, PCI_Clock_33MHz, 0x000fff00 }, // 8110SCd
< { RTL_GIGA_MAC_VER_05, PCI_Clock_66MHz, 0x000fffff },
< { RTL_GIGA_MAC_VER_06, PCI_Clock_33MHz, 0x00ffff00 }, // 8110SCe
< { RTL_GIGA_MAC_VER_06, PCI_Clock_66MHz, 0x00ffffff }
< };
< const struct rtl_cfg2_info *p = cfg2_info;
< unsigned int i;
< u32 clk;
---
> u32 val;
4583,4589c4562,4572
< clk = RTL_R8(tp, Config2) & PCI_Clock_66MHz;
< for (i = 0; i < ARRAY_SIZE(cfg2_info); i++, p++) {
< if ((p->mac_version == mac_version) && (p->clk == clk)) {
< RTL_W32(tp, 0x7c, p->val);
< break;
< }
< }
---
> if (tp->mac_version == RTL_GIGA_MAC_VER_05)
> val = 0x000fff00;
> else if (tp->mac_version == RTL_GIGA_MAC_VER_06)
> val = 0x00ffff00;
> else
> return;
>
> if (RTL_R8(tp, Config2) & PCI_Clock_66MHz)
> val |= 0xff;
>
> RTL_W32(tp, 0x7c, val);
5875a5859
> netdev_reset_queue(tp->dev);
6177a6162,6163
> netdev_sent_queue(dev, skb->len);
>
6276c6262
< unsigned int dirty_tx, tx_left;
---
> unsigned int dirty_tx, tx_left, bytes_compl = 0, pkts_compl = 0;
6300,6303c6286,6287
< u64_stats_update_begin(&tp->tx_stats.syncp);
< tp->tx_stats.packets++;
< tp->tx_stats.bytes += tx_skb->skb->len;
< u64_stats_update_end(&tp->tx_stats.syncp);
---
> pkts_compl++;
> bytes_compl += tx_skb->skb->len;
6311a6296,6302
> netdev_completed_queue(dev, pkts_compl, bytes_compl);
>
> u64_stats_update_begin(&tp->tx_stats.syncp);
> tp->tx_stats.packets += pkts_compl;
> tp->tx_stats.bytes += bytes_compl;
> u64_stats_update_end(&tp->tx_stats.syncp);
>
6476,6488c6467,6470
< rtl_irq_disable(tp);
< napi_schedule_irqoff(&tp->napi);
<
< return IRQ_HANDLED;
< }
<
< /*
< * Workqueue context.
< */
< static void rtl_slow_event_work(struct rtl8169_private *tp)
< {
< struct net_device *dev = tp->dev;
< u16 status;
---
> if (unlikely(status & SYSErr)) {
> rtl8169_pcierr_interrupt(tp->dev);
> goto out;
> }
6490,6491c6472,6473
< status = rtl_get_events(tp) & tp->event_slow;
< rtl_ack_events(tp, status);
---
> if (status & LinkChg && tp->dev->phydev)
> phy_mac_interrupt(tp->dev->phydev);
6493,6502c6475,6479
< if (unlikely(status & RxFIFOOver)) {
< switch (tp->mac_version) {
< /* Work around for rx fifo overflow */
< case RTL_GIGA_MAC_VER_11:
< netif_stop_queue(dev);
< /* XXX - Hack alert. See rtl_task(). */
< set_bit(RTL_FLAG_TASK_RESET_PENDING, tp->wk.flags);
< default:
< break;
< }
---
> if (unlikely(status & RxFIFOOver &&
> tp->mac_version == RTL_GIGA_MAC_VER_11)) {
> netif_stop_queue(tp->dev);
> /* XXX - Hack alert. See rtl_task(). */
> set_bit(RTL_FLAG_TASK_RESET_PENDING, tp->wk.flags);
6505,6509c6482,6487
< if (unlikely(status & SYSErr))
< rtl8169_pcierr_interrupt(dev);
<
< if (status & LinkChg)
< phy_mac_interrupt(dev->phydev);
---
> if (status & RTL_EVENT_NAPI) {
> rtl_irq_disable(tp);
> napi_schedule_irqoff(&tp->napi);
> }
> out:
> rtl_ack_events(tp, status);
6511c6489
< rtl_irq_enable_all(tp);
---
> return IRQ_HANDLED;
6520,6521d6497
< /* XXX - keep rtl_slow_event_work() as first element. */
< { RTL_FLAG_TASK_SLOW_PENDING, rtl_slow_event_work },
6551d6526
< u16 enable_mask = RTL_EVENT_NAPI | tp->event_slow;
6553,6556d6527
< u16 status;
<
< status = rtl_get_events(tp);
< rtl_ack_events(tp, status & ~tp->event_slow);
6562,6567d6532
< if (status & tp->event_slow) {
< enable_mask &= ~tp->event_slow;
<
< rtl_schedule_task(tp, RTL_FLAG_TASK_SLOW_PENDING);
< }
<
6571c6536
< rtl_irq_enable(tp, enable_mask);
---
> rtl_irq_enable_all(tp);
6847d6811
< netif_stop_queue(dev);
7361,7365c7325,7327
< if ((sizeof(dma_addr_t) > 4) &&
< (use_dac == 1 || (use_dac == -1 && pci_is_pcie(pdev) &&
< tp->mac_version >= RTL_GIGA_MAC_VER_18)) &&
< !pci_set_dma_mask(pdev, DMA_BIT_MASK(64)) &&
< !pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64))) {
---
> if (sizeof(dma_addr_t) > 4 && (use_dac == 1 || (use_dac == -1 &&
> tp->mac_version >= RTL_GIGA_MAC_VER_18)) &&
> !dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64))) {
7381c7343
< rtl_irq_disable(tp);
---
> rtl8169_irq_mask_and_ack(tp);
7387,7388d7348
< rtl_ack_events(tp, 0xffff);
<
7428d7387
< dev->watchdog_timeo = RTL8169_TX_TIMEOUT;
')
Have to see if can trace down the patches involved. All I can think of is slowly taking the patches off - so you can identify what caused the problem.

I do note that the module takes the debug that can be set to 16 if you want many messages.
summers
 
Posts: 995
Joined: Sat Sep 06, 2014 12:56 pm

Re: Kirkwood DT kernel 4.20 - r8189 driver failed with error

Postby summers » Sun Mar 24, 2019 5:07 pm

summers
 
Posts: 995
Joined: Sat Sep 06, 2014 12:56 pm

Re: Kirkwood DT kernel 4.20 - r8189 driver failed with error

Postby arti74 » Mon Mar 25, 2019 10:03 pm

Problem solved in 5.0.4-1-ARCH #1 PREEMPT Sun Mar 24 23:39:21 UTC 2019 ! Network is fully working on the new kernel.
It was connected to the pci bus issue, like mr Heiner Kallweit from kernel.org pointed out.
https://bugzilla.kernel.org/show_bug.cgi?id=203025
Thanks to all!
arti74
 
Posts: 75
Joined: Tue Apr 17, 2018 10:33 am


Return to Packages

Who is online

Users browsing this forum: No registered users and 6 guests