Modify

Opened 9 years ago

Closed 7 years ago

Last modified 20 months ago

#3124 closed defect (fixed)

AR7 r10425: Ethernet doesn't work

Reported by: nabcore Owned by: florian
Priority: highest Milestone: Barrier Breaker 14.07
Component: kernel Version:
Keywords: AR7 ethernet cpmac Cc:

Description

Sorry for the vague description, but I cannot see or generate any traffic on the eth0 interface. The only differences I see here are:

Broken

cpmac: device eth0 (regs: 08612800, irq: 41, phy: 0:10, mac: 00:0f:b5:db:f6:8d)
cpmac: device eth1 (regs: 08610000, irq: 27, phy: 0:1f, mac: 00:0f:b5:db:f6:8c)

Working

cpmac: device eth0 (regs: 08612800, irq: 41, phy: fixed@100:1, mac: 00:0f:b5:db:f6:8d)
cpmac: device eth1 (regs: 08610000, irq: 27, phy: 0:1f, mac: 00:0f:b5:db:f6:8c)

Attachments (10)

fix.diff (2.8 KB) - added by matteo 8 years ago.
Anton's fix
Bootlog504T.txt (8.0 KB) - added by War3333 8 years ago.
Bootlog 504T with r10581
cpmachack.diff (697 bytes) - added by matteo 8 years ago.
900-fixed_phy.diff (2.6 KB) - added by matteo 8 years ago.
cpmac_eth_fix.patch.txt (1.7 KB) - added by beistin@… 8 years ago.
cpmac_eth_fix.patch (1.7 KB) - added by matteo 8 years ago.
why .txt?
cpmac_eth_fix.2.patch (1.1 KB) - added by matteo 8 years ago.
remove useless chunks
170-cpmac_fixed_phy.patch (1.8 KB) - added by narge-openwrt@… 8 years ago.
An attempt to fix PHY detection in cpmac
910-cpmac_fixed_phy.patch (2.7 KB) - added by narge-openwrt@… 7 years ago.
Updated patch for 2.6.26
93098967.png (11.1 KB) - added by Smartmiltoys 7 months ago.
http://smartmiltoys.com/kidkraft-train-table/

Download all attachments as: .zip

Change History (70)

comment:1 follow-up: Changed 9 years ago by nabcore

In an attempt to debug this, I decided to drop the 140-cpmac_fix.patch and see if the vanilla cpmac code would compile. This was not so:

scripts/kconfig/conf -s arch/mips/Kconfig
drivers/net/Kconfig:1836:warning: 'select' used by config symbol 'CPMAC' refers to undefined s                    ymbol 'FIXED_MII_100_FDX'
make[5]: Leaving directory `/scratch/openwrt/trunk/build_dir/linux-ar7/linux-2.6.24'
make[5]: Entering directory `/scratch/openwrt/trunk/build_dir/linux-ar7/linux-2.6.24'
  CHK     include/linux/version.h
  CHK     include/linux/utsrelease.h
  CALL    scripts/checksyscalls.sh
  CHK     include/linux/compile.h
  CC      drivers/net/cpmac.o
drivers/net/cpmac.c: In function 'cpmac_start_xmit':
drivers/net/cpmac.c:461: warning: comparison of distinct pointer types lacks a cast
drivers/net/cpmac.c: In function 'cpmac_clear_tx':
drivers/net/cpmac.c:637: warning: passing argument 2 of 'netif_subqueue_stopped' makes pointer                     from integer without a cast
drivers/net/cpmac.c: In function 'cpmac_tx_timeout':
drivers/net/cpmac.c:706: warning: unused variable 'i'
drivers/net/cpmac.c: In function 'cpmac_probe':
drivers/net/cpmac.c:1071: error: 'MAX_PHY_AMNT' undeclared (first use in this function)
drivers/net/cpmac.c:1071: error: (Each undeclared identifier is reported only once
drivers/net/cpmac.c:1071: error: for each function it appears in.)
drivers/net/cpmac.c:1072: error: implicit declaration of function 'fixed_mdio_get_phydev'
drivers/net/cpmac.c:1072: warning: assignment makes pointer from integer without a cast
drivers/net/cpmac.c:1075: error: dereferencing pointer to incomplete type
drivers/net/cpmac.c:1077: error: dereferencing pointer to incomplete type
drivers/net/cpmac.c:1079: error: implicit declaration of function 'fixed_mdio_set_link_update'
drivers/net/cpmac.c:1079: error: dereferencing pointer to incomplete type
drivers/net/cpmac.c:1146:2: warning: #warning FIXME: unhardcode gpio&reset bits
make[7]: *** [drivers/net/cpmac.o] Error 1
make[6]: *** [drivers/net] Error 2
make[5]: *** [drivers] Error 2

Googling on FIXED_MII_100_FDX, turned up this: http://ozlabs.org/pipermail/linuxppc-dev/2008-January/050330.html . Later in this thread it suggests a patch for convert to new Fixed PHY infrastructure, which later appears in Linus' tree: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8353ec7b0d6666c0674ca978379c55234609dae8

comment:2 Changed 9 years ago by NRForbes <nick.forbes@…>

On my DG834Gv1, the cpmac driver works OK with r10423. Could this be because r10424 no longer patches drivers/net/Kconfig to remove FIXED_PHY and FIXED_MII_100_FDX which appear to no longer be supported? If I remove these then it seems to work OK for me using r10424, though I have not tested this under load.

Here is a diff to 140-cpmac_fix.patch which reinstates the Kconfig section as it was in r10423.

Index: target/linux/ar7/patches-2.6.24/140-cpmac_fix.patch
===================================================================
--- target/linux/ar7/patches-2.6.24/140-cpmac_fix.patch (revision 10424)
+++ target/linux/ar7/patches-2.6.24/140-cpmac_fix.patch (working copy)
@@ -1,3 +1,14 @@
+--- linux-2.6.24/drivers/net/Kconfig    2008-01-25 02:20:37.000000000 +0100
++++ linux-2.6.24/drivers/net/Kconfig    2008-02-08 18:12:02.000000000 +0100
+@@ -1832,8 +1832,6 @@
+       tristate "TI AR7 CPMAC Ethernet support (EXPERIMENTAL)"
+       depends on NET_ETHERNET && EXPERIMENTAL && AR7
+       select PHYLIB
+-      select FIXED_PHY
+-      select FIXED_MII_100_FDX
+       help
+         TI AR7 CPMAC Ethernet support
+
 --- linux-2.6.24/drivers/net/cpmac.c   2008-01-25 02:20:37.000000000 +0100
 +++ linux-2.6.24/drivers/net/cpmac.c   2008-02-08 20:04:58.000000000 +0100
 @@ -38,6 +38,7 @@

I don't have a serial cable for my DG834Gv2 so I can't test this myself but perhaps this will help?

comment:3 Changed 9 years ago by nabcore

Farnz via IRC has made the useful suggestion that the Ethernet is working, but there is no fixed phy, so it's not seeing link (as the switch isn't reporting link back to the CPMAC).

comment:4 Changed 9 years ago by nabcore

More useful information from Farnz: "cpmac handled phys in a way the Fixed PHY developers didn't expect; the new infrastructure breaks cpmac as a result."

comment:5 Changed 9 years ago by nabcore

Just tried with r10512 and noticed that ethernet does work, but ONLY on port 4 of the unit. Very weird.

comment:6 Changed 9 years ago by NRForbes <nick.forbes@…>

I can confirm this is the case with the DG834Gv1 as well.

I had always been connected via port 4 and never experienced this issue so this explains a great deal!

comment:7 Changed 9 years ago by rlim

on my dsl-g604t, r10481, the ethernet port seems to be unable to transmit anything, but receiving works. at least the rx byte count is increasing, when i ping my router, txqueuelen seems to stagnate at 1000:

root@OpenWrt:/# ifconfig
eth0 Link encap:Ethernet HWaddr 00:0F:3D:FA:C6:D9

inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:71 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5202 (5.0 KiB) TX bytes:0 (0.0 B)
Interrupt:41

eth0 Link encap:Ethernet HWaddr 00:0F:3D:FA:C6:D9

inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:72 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5262 (5.1 KiB) TX bytes:0 (0.0 B)
Interrupt:41

eth0 Link encap:Ethernet HWaddr 00:0F:3D:FA:C6:D9

inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:73 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5322 (5.1 KiB) TX bytes:0 (0.0 B)
Interrupt:41

eth0 Link encap:Ethernet HWaddr 00:0F:3D:FA:C6:D9

inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:74 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5382 (5.2 KiB) TX bytes:0 (0.0 B)
Interrupt:41

eth0 Link encap:Ethernet HWaddr 00:0F:3D:FA:C6:D9

inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:75 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5442 (5.3 KiB) TX bytes:0 (0.0 B)
Interrupt:41

comment:8 Changed 9 years ago by matteo

  • Owner changed from developers to matteo
  • Status changed from new to assigned

comment:9 Changed 9 years ago by matteo

  • Component changed from packages to kernel
  • Keywords ethernet added

comment:10 Changed 9 years ago by matteo

  • Priority changed from high to highest
  • Summary changed from AR7 r10425: Ethernet seems not be working to AR7 r10425: Ethernet doesn't works

comment:11 follow-up: Changed 9 years ago by matteo

  • Summary changed from AR7 r10425: Ethernet doesn't works to AR7 r10425: Ethernet doesn't work

comment:12 in reply to: ↑ 11 ; follow-up: Changed 9 years ago by anonymous

i dont know, whether this helps:
i put some printk's to cpmac.c and found out, that netif_start_queue(dev) is never called (in cpmac_adjust_link) because priv->phy->link is always 0. when i call netif_start_queue(dev) manually (without chek), i am able to ping the router.

comment:13 in reply to: ↑ 12 Changed 8 years ago by matteo

Replying to anonymous:

i dont know, whether this helps:
i put some printk's to cpmac.c and found out, that netif_start_queue(dev) is never called (in cpmac_adjust_link) because priv->phy->link is always 0. when i call netif_start_queue(dev) manually (without chek), i am able to ping the router.

Where did you call "netif_start_queue(dev)"?

comment:14 Changed 8 years ago by matteo

link is ALWAYS 0:

[/]# ifconfig eth0 down
[/]# ifconfig eth0 up
ADDRCONF(NETDEV_UP): eth0: link is not ready
[CPMAC]: priv->phy->link: 0
[/]# 

comment:15 in reply to: ↑ 1 ; follow-up: Changed 8 years ago by anonymous

Replying to nabcore:

In an attempt to debug this, I decided to drop the 140-cpmac_fix.patch and see if the vanilla cpmac code would compile. This was not so:

[...]

Googling on FIXED_MII_100_FDX, turned up this: http://ozlabs.org/pipermail/linuxppc-dev/2008-January/050330.html . Later in this thread it suggests a patch for convert to new Fixed PHY infrastructure, which later appears in Linus' tree: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8353ec7b0d6666c0674ca978379c55234609dae8

Hi,

Here is patch to show an idea how to "fix" cpmac fixed phys usage:
http://paste.lisp.org/display/56853/raw

It should work fine, but I didn't test it (no hardware).. and I didn't
compile test it (don't have mips cross tools handy ;-).

Thanks,

p.s.
This patch is against today's openwrt/target/linux/ar7/.
I.e. 2.6.24 + ar7/files + patches-2.6.24.

comment:16 in reply to: ↑ 15 Changed 8 years ago by anonymous

Replying to anonymous:

Replying to nabcore:

...

This patch is against today's openwrt/target/linux/ar7/.
I.e. 2.6.24 + ar7/files + patches-2.6.24.

Oh, and of course, plus fixed phy rework patches already in mainline:

commit a79d8e93d300adb84cccc38ac396cfb118c238ad
Date: Fri Dec 7 01:51:22 2007 +0300

phy/fixed.c: rework to not duplicate PHY layer functionality

commit 8353ec7b0d6666c0674ca978379c55234609dae8
Date: Mon Jan 21 23:49:53 2008 +0300

cpmac: convert to new Fixed PHY infrastructure

comment:17 Changed 8 years ago by matteo

  • Resolution set to fixed
  • Status changed from assigned to closed

fixed in r10545

comment:18 Changed 8 years ago by nabcore

  • Resolution fixed deleted
  • Status changed from closed to reopened

I've just tested the patch at http://paste.lisp.org/display/56853/raw and it works. Matteo, why have you decided not to apply this patch and instead use a dirty hack as in r10545 ?

comment:19 Changed 8 years ago by nabcore

With the working patch at http://paste.lisp.org/display/56853/raw , the only strange thing is that the dmesg link status:

PHY: 0:10 - Link is Down
PHY: 0:10 - Link is Up - 100/Full

only gets reported upon plugging a machine into port 4 of the router, even though the other ports now function.

Changed 8 years ago by matteo

Anton's fix

comment:20 Changed 8 years ago by matteo

Let's try...

comment:21 follow-up: Changed 8 years ago by War3333

On a 504T none of the 4 ethernet port work.
If you need some test I have a serial connection on my device.

veguerr at tin it

comment:22 in reply to: ↑ 21 Changed 8 years ago by rlim

on a g664t i get these errors at boot time:

Jan 1 00:00:06 OpenWrt user.info kernel: Fixed MDIO Bus: probed
Jan 1 00:00:06 OpenWrt user.warn kernel: sysfs: duplicate filename '0:00' can not be created
Jan 1 00:00:06 OpenWrt user.warn kernel: WARNING: at fs/sysfs/dir.c:424 sysfs_add_one()
Jan 1 00:00:06 OpenWrt user.warn kernel: Call Trace:
Jan 1 00:00:06 OpenWrt user.warn kernel: [<94108340>] dump_stack+0x8/0x34
Jan 1 00:00:06 OpenWrt user.warn kernel: [<941c9b5c>] sysfs_add_one+0x64/0x18c
Jan 1 00:00:06 OpenWrt user.warn kernel: [<941cb468>] sysfs_create_link+0x138/0x300
Jan 1 00:00:06 OpenWrt user.warn kernel: [<94234100>] bus_add_device+0xd4/0x144
Jan 1 00:00:06 OpenWrt user.warn kernel: [<942325ac>] device_add+0x274/0x5d8
Jan 1 00:00:06 OpenWrt user.warn kernel: [<9423df44>] mdiobus_register+0xfc/0x178
Jan 1 00:00:06 OpenWrt user.warn kernel: [<94240fac>] cpmac_init+0x28c/0x380
Jan 1 00:00:06 OpenWrt user.warn kernel: [<94365680>] kernel_init+0xec/0x310
Jan 1 00:00:06 OpenWrt user.warn kernel: [<94103ce0>] kernel_thread_helper+0x10/0x18
Jan 1 00:00:06 OpenWrt user.warn kernel:
Jan 1 00:00:06 OpenWrt user.err kernel: phy 0 failed to register
Jan 1 00:00:06 OpenWrt user.info kernel: cpmac-mii: probed
Jan 1 00:00:06 OpenWrt user.err kernel: cpmac cpmac.1: no PHY present
Jan 1 00:00:06 OpenWrt user.info kernel: cpmac: device eth0 (regs: 08610000, irq: 27, phy: 0:1f, mac: 00:0f:3d:fa:c6:d9)

Changed 8 years ago by War3333

Bootlog 504T with r10581

comment:23 Changed 8 years ago by nabcore

rlim, can you use the code formatting?

This is a piece of code....

I can't easily read what you've pasted..

Changed 8 years ago by matteo

comment:24 follow-up: Changed 8 years ago by anonymous

Formatted output from my D-Link DSL G684T with r10590. No network (not even port 4) works. RX/TX count and interrupt count in /proc/interrupts not incrementing.

{{{Fixed MDIO Bus: probed
sysfs: duplicate filename '0:00' can not be created
WARNING: at fs/sysfs/dir.c:424 sysfs_add_one()
Call Trace:
[<94108340>] dump_stack+0x8/0x34
[<941c9b5c>] sysfs_add_one+0x64/0x18c
[<941cb468>] sysfs_create_link+0x138/0x300
[<94234100>] bus_add_device+0xd4/0x144
[<942325ac>] device_add+0x274/0x5d8
[<9423df44>] mdiobus_register+0xfc/0x178
[<94241614>] cpmac_init+0x288/0x3b4
[<94365680>] kernel_init+0xec/0x310
[<94103ce0>] kernel_thread_helper+0x10/0x18

phy 0 failed to register
cpmac-mii: probed
cpmac cpmac.1: no PHY present
cpmac: device eth0 (regs: 08610000, irq: 27, phy: 0:1f, mac: 00:19:5b:99:51:9b)
}}}

comment:25 in reply to: ↑ 24 Changed 8 years ago by anonymous

Replying to anonymous:
For some strange reason I now hate WikiFormatting...

Fixed MDIO Bus: probed
sysfs: duplicate filename '0:00' can not be created
WARNING: at fs/sysfs/dir.c:424 sysfs_add_one()
Call Trace:
[<94108340>] dump_stack+0x8/0x34
[<941c9b5c>] sysfs_add_one+0x64/0x18c
[<941cb468>] sysfs_create_link+0x138/0x300
[<94234100>] bus_add_device+0xd4/0x144
[<942325ac>] device_add+0x274/0x5d8
[<9423df44>] mdiobus_register+0xfc/0x178
[<94241614>] cpmac_init+0x288/0x3b4
[<94365680>] kernel_init+0xec/0x310
[<94103ce0>] kernel_thread_helper+0x10/0x18

phy 0 failed to register
cpmac-mii: probed
cpmac cpmac.1: no PHY present
cpmac: device eth0 (regs: 08610000, irq: 27, phy: 0:1f, mac: 00:19:5b:99:51:9b)

comment:26 Changed 8 years ago by nabcore

Ok, noticed something quite subtle. Initially in this ticket I discovered that ethernet would only work on port 4 of the router comment:5 and then with comment:19 I said that the problem had been resolved. Well, this is not quite true. Basically the other ports ONLY work if something is plugged into port 4. This is a little different from the initial behavior since no other ports except port 4 would work. Looking at the tcpdump (and dmesg) output when we pull port 4 and try to access a web page from a machine (192.168.0.2) on port 3:

PHY: 0:10 - Link is Down
br-lan: port 1(eth0) entering disabled state

22:21:23.078875 arp who-has 192.168.0.1 tell 192.168.0.2
22:21:27.068590 arp who-has 192.168.0.1 tell 192.168.0.2

Now plugging port 4 back in:

PHY: 0:10 - Link is Up - 100/Full
br-lan: port 1(eth0) entering learning state
br-lan: topology change detected, propagating
br-lan: port 1(eth0) entering forwarding state
---some traffic related to port 4's DHCP request----
22:22:28.715278 arp who-has 192.168.0.1 tell 192.168.0.2
22:22:28.715732 arp reply 192.168.0.1 is-at 00:0f:xx:xx:xx:xx (oui Unknown)
22:22:28.716040 IP 192.168.0.2.1056 > 192.168.0.1.53: 31521+ A? www.google.co.uk. (34)
22:22:28.734320 IP 192.168.0.1.53 > 192.168.0.2.1056: 31521 5/0/0 CNAME[|domain]
22:22:28.741212 IP 192.168.0.2.1225 > nf-in-f147.google.com.80: S 80901393:80901393(0) win 25200 <mss 1460,nop,nop,sackOK>

This is all very weird and not good.

comment:27 Changed 8 years ago by matteo

Not good, but neither so weird.
Now we know that fixed phy is broken and detect links on port 4 instead of every single port.

Changed 8 years ago by matteo

comment:28 Changed 8 years ago by beistin@…

Hi,

I have the same issue with my DSL624T. The ethernet is not activated at boot time.

According to the posts above, there is a conflict during registration of the driver, so I tried to fix it.
And here it comes the patch that allowed me to have my cpmac eth0 up and running.
As I am not an experiment kernel hacker, this may be not the good way to do it, but a least, it look more like what other drivers do :)

I sent the patch to the linux-mips mailing list.

Changed 8 years ago by beistin@…

comment:29 Changed 8 years ago by nabcore

hmmm, now the dmesg related cpmac messages are as follows (in r10690)

root@Bunny:/# dmesg  | grep cpmac
cpmac-mii: probed
cpmac: device eth0 (regs: 08612800, irq: 41, phy: , mac: 00:0f:b5:db:f6:8d)
cpmac: device eth1 (regs: 08610000, irq: 27, phy: , mac: 00:0f:b5:db:f6:8c)

comment:30 Changed 8 years ago by crowm@…

Hi all,

I have a Linksys AG241v2 EU and the network work but :-( "Kernel bug detected"
works under 36h aprox. and then...

root@OpenWrt:/# uptime
 08:15:27 up 1 day,  8:15, load average: 0.00, 0.00, 0.00
root@OpenWrt:/# Kernel bug detected[#1]:
Cpu 0
$ 0   : 00000000 10008401 00000001 a8610000
$ 4   : 0000001b 94c633d8 004a8a55 00000000
$ 8   : 00989680 00000000 00000008 fffffffc
$12   : 23c34600 00021e76 943b0000 3b9aca00
$16   : 00000000 94c63000 00000000 94c63380
$20   : 00000000 00010000 0040b550 004f54cd
$24   : 00008000 94100b4c
$28   : 94362000 94363d38 01000000 9414f570
Hi    : 00000000
Lo    : 00000000
epc   : 942407b4 cpmac_irq+0x53c/0x5f8     Not tainted
ra    : 9414f570 handle_IRQ_event+0x64/0xd4
Status: 10008403    KERNEL EXL IE
Cause : 30800034
PrId  : 00018448 (MIPS 4KEc)
Modules linked in: sch_red sch_sfq sch_hfsc cls_fw tiatm nf_nat_tftp nf_conntrac
k_tftp nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_conntrack_ftp ipt_TOS ipt_TTL x
t_MARK ipt_ECN xt_CLASSIFY ipt_ttl ipt_tos ipt_time xt_tcpmss xt_statistic xt_ma
rk xt_mac xt_length ipt_ecn xt_DSCP xt_dscp imq ipt_IMQ xt_string ipt_ipp2p xt_N
OTRACK xt_CONNMARK ipt_recent xt_helper xt_conntrack xt_connmark xt_connbytes at
mtcp arptable_filter arpt_mangle arp_tables ppp_async ppp_generic slhc crc_ccitt
 br2684 atm
Process swapper (pid: 0, threadinfo=94362000, task=94364160)
Stack : 016ec494 943b0000 94363d80 943a0000 9413ecec 9459ea80 9491d780 00000000
        00000000 0000001b 00004000 00000100 9414f570 9413ed60 00000000 943b1e90
        2887fa00 00021e76 9436b0d8 0000001b 0000000a 943a0000 9415150c 9414681c
        00021e76 239cd475 2887fa00 00021e76 00000013 9439cba3 94100ae4 94100ab4
        a3008000 a3008040 239cd475 00021e76 94363ed0 94101b64 94363e58 00000001
        ...
Call Trace:
[<942407b4>] cpmac_irq+0x53c/0x5f8
[<9414f570>] handle_IRQ_event+0x64/0xd4
[<9415150c>] handle_level_irq+0xa4/0x118
[<94100ae4>] plat_irq_dispatch+0x98/0x100
[<94101b64>] ret_from_irq+0x0/0x4
[<9412895c>] __do_softirq+0x44/0x100
[<94128a74>] do_softirq+0x5c/0x94
[<94128fe8>] irq_exit+0x40/0x8c
[<94101b64>] ret_from_irq+0x0/0x4
[<941015f8>] r4k_wait+0x4/0xc
[<94103f94>] cpu_idle+0x2c/0x54
[<9437ad64>] start_kernel+0x4c0/0x4f4


Code: 26650058  38420001  30420001 <00028036> 3c02943a  8c42c968  3c030001  0043
1024  10400009
Kernel panic - not syncing: Fatal exception in interrupt
Rebooting in 3 seconds..free space start: 0xb0010000
free space end: 0xb0400000

Basic POST completed...     Success.
Last reset cause: Software reset (memory controller also reset)

comment:31 Changed 8 years ago by matteo

  • Resolution set to fixed
  • Status changed from reopened to closed

Seems to be fixed now, try latest rev

comment:32 Changed 8 years ago by anonymous

  • Resolution fixed deleted
  • Status changed from closed to reopened

This appears to still be broken in r10845. I have a DLink DSL-G604T/UK V.A1

Stack trace that I get is below, and symptoms are that PHY never comes up, though ifconfig reports that eth0 is up, and routing is non-existant.

sysfs: duplicate filename '0:00' can not be created
WARNING: at fs/sysfs/dir.c:424 sysfs_add_one()
Call Trace:
[<94108300>] dump_stack+0x8/0x34
[<941c914c>] sysfs_add_one+0x64/0x18c
[<941caa58>] sysfs_create_link+0x138/0x300
[<94233660>] bus_add_device+0xd4/0x144
[<94231b0c>] device_add+0x274/0x5d8
[<9423d4a4>] mdiobus_register+0xfc/0x178
[<94240a24>] cpmac_init+0x288/0x3a4
[<94368680>] kernel_init+0xec/0x310
[<94103ca0>] kernel_thread_helper+0x10/0x18
 
phy 0 failed to register

comment:33 Changed 8 years ago by tomsimnett@…

To add to the the above comment, dmesg | grep cpmac is shown below

root@OpenWrt:/# dmesg | grep cpmac
[<94240a24>] cpmac_init+0x288/0x3a4
cpmac-mii: probed
cpmac cpmac.1: no PHY present
cpmac: device eth0 (regs: 08610000, irq: 27, phy: 0:1f, mac: 00:0f:3d:b9:c2:5f)

comment:34 Changed 8 years ago by anonymous

Continuing on this thread, having pasted the last two comments, I have a working setup using r10156. The cpmac dump from the previous comment now shows:

root@adsl:/etc# dmesg | grep cpmac
cpmac-mii: probed
cpmac: device eth0 (regs: 08612800, irq: 41, phy: fixed@100:1, mac: 00:0f:3d:b9:c2:5f)
cpmac: device eth1 (regs: 08610000, irq: 27, phy: 0:1f, mac: 00:0f:3d:b9:c2:5f)

comment:35 Changed 8 years ago by beistin@…

May I suggest you use the patch I posted in this thread?
It used to be in the trunk, but was recently removed.

comment:36 Changed 8 years ago by anonymous

The patch you suggest no longer relates to the latest rev in trunk, and now only the last hunk patches successfully. is that all that's needed?

comment:37 Changed 8 years ago by sst@…

version 10857
two last hook of cpmac_eth_fix.patch.txt applied (manually)
uploaded on a DSL524T

=> the 2 cpmac devices are OK, and the 4 ethernet port too

I suggest that you integrate this patch in openwrt for good :)

Changed 8 years ago by matteo

why .txt?

Changed 8 years ago by matteo

remove useless chunks

comment:38 Changed 8 years ago by matteo

module_init() functions does NOT accept arguments IIRC.
go read the kernel documentation

comment:39 Changed 8 years ago by anonymous

This appears to work correctly now - I'm patched up on 10857 and it works without problems. can this be included in trunk please?

comment:40 Changed 8 years ago by matteo

applied in r10896

comment:41 Changed 8 years ago by tomsimnett@…

Following a discussion with matteo in IRC about module_init() not accepting args, I thought I'd try and remove the last hunk of the patch to see if it still worked, given that this should be NULL. It doesn't work, and both parts as applied in r10896 are needed it seems.

Benoit, could you explain how this patch works in these circumstances?

comment:42 Changed 8 years ago by beistin@…

Matteo is right, the init function does not take any parameter.

If you have a look to the implementation of the function mdiobus_register(), you will see that the function create the device name based on the information supplied in the struct mii_bus. As the ID is not set, the name generated conflict with another entry in the sys.

So why does it work you wonder? Simply because it initialized the id of the cpmac_mii with something different from 0. But this value is totally random and should not be supplied this way, as state by Matteo.

I tried to figure out how the ID should be set and/or define, but I did not found anything in other drivers. Matteo any idea?

Otherwise I can supply another patch I did yesterday that set a default value for the id, and define a module parameter to set it.

comment:43 Changed 8 years ago by anonymous

is this bug resolved?
I'm still having trouble with DSL-G604T.

comment:44 Changed 8 years ago by anonymous

Are you using r10896 or above? If so, what errors are you seeing? Try:

dmesg | grep cpmac

and post the results

comment:45 follow-up: Changed 8 years ago by anonymous

Just tried r10896 on my dsl-524t and ethernet still dont work. :(

cpmac-mii: probed
cpmac cpmac.1: no PHY present
cpmac: device eth0 (regs: 08610000, irq: 27, phy: , mac: 00:19:5b:39:3d:fb)
PHY: 0:1f - Link is Down

comment:46 in reply to: ↑ 45 Changed 8 years ago by rlim

latest version r11266 did only work on my dlink g604t when i removed target/linux/ar7/patches-2.6.25/150-cpmac_up_and_running.diff

comment:47 Changed 8 years ago by nail@…

Still broken for me in r11854, tried removing the "up_and_running" diff, but that did not help.

comment:48 Changed 8 years ago by narge-openwrt@…

I ran into this while debugging #3782. There seem to be at least three causes:

  • As someone pointed out above, cpmac_mii uses id 0, which the fixed PHY is already using. I'm not really sure how to fix this properly, but using id 1 works for me.
  • cpmac_init polls too quickly when waiting for PHYs on cpmac_mii. Often only one PHY will appear between polls, and then the driver will fail to detect the external switch. Sleeping 10ms between polls works for me, but might not be long enough.
  • cpmac_probe always tries to find a PHY on cpmac_mii, even if external_switch or dumb_switch is set. If it finds one, it will use it instead of the fixed PHY. This is why it only works if something is plugged into port 4: that's the port whose PHY is being monitored for link status by the driver. Doing the external_switch test before the loop seems to fix this, though it might break when there are multiple cpmacs (since only one is attached to the switch).

I will attach a patch against 2.6.25 that fixes it for me, on a DG834v3. It replaces 170-cpmac_eth_fix.patch, and should make 900-temporary_cpmac_hack.patch unnecessary. There's a good chance that it will break devices that have multiple cpmacs or don't have a switch, so please test it if you have one of those.

Changed 8 years ago by narge-openwrt@…

An attempt to fix PHY detection in cpmac

comment:49 Changed 8 years ago by nail@…

Confirmed working on D-Link DSL-G684T with 170-cpmac_eth_fix.patch and 900-temporary_cpmac_hack.patch removed, and 170-cpmac_fixed_phy.patch applied.
Revision r11910

comment:50 Changed 8 years ago by anonymous

does not work on wag354g

comment:51 Changed 8 years ago by florian

What does not work on wag354g ? Did you try removing 170-cpmac_eth_fix.patch and 900-temporary_cpmac_hack.patch and use 170-cpmac_fixed_phy.patch instead ?

comment:52 Changed 8 years ago by nas@…

It doesn't work for me.

I tried both r11910 and r11844 with no success. And yes, I was removing 900-temporary_cpmac_hack.patch and 170-cpmac_eth_fix.patch from ./trunk/target/ar7/patches-2.5.25 and after building and flashing patched image the ethernet is not working on mine D834v3.

comment:53 Changed 7 years ago by narge-openwrt@…

The DG834v3 has another bug that breaks ethernet (#3782), in addition to this one. To get that specific device to work, you also need the patch I just attached to that bug.

comment:54 Changed 7 years ago by narge-openwrt@…

My patch no longer works with current openwrt svn and kernel 2.6.26, because:

  • 170-cpmac_eth_fix.patch has been applied to the kernel mainline as of 2.6.26. This makes cpmac_probe even more broken; the change it makes to the phys_attach call will cause a panic when selecting a fixed phy.
  • 2.6.26 changes the type of mii bus IDs from int to char*.
  • fix.diff has been half applied to the kernel mainline and half deleted (in r12436), leaving no calls to fixed_phy_add.

I will attach an updated patch for 2.6.26. To get this to work, you need to restore 150-cpmac_up_and_running.diff, deleted in r12436.

Changed 7 years ago by narge-openwrt@…

Updated patch for 2.6.26

comment:55 Changed 7 years ago by florian

  • Owner changed from matteo to florian
  • Status changed from reopened to new

comment:56 Changed 7 years ago by SiNiESTrO

Last patch works for me. I have one Linksys WAG54Gv2 and only I had to add "cpmac.dumb_switch=1" to Kernel command line after restoring 150-cpma_up_and_running.diff as narge-openwrt said.

comment:57 Changed 7 years ago by SiNiESTrO

I forgot to say that this patch works for me in rev17079.

comment:58 Changed 7 years ago by florian

  • Resolution set to fixed
  • Status changed from new to closed

Applied in [17107], will move everything that is required into platform_data later.

comment:59 Changed 2 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

comment:60 Changed 20 months ago by anonymous

This ticket might maybe be closed now that Backfire is using Luci 0.10. (At least for my ar71xx based WNDR3700 the Wifi scan works now nicely in Backfire.)
Agen Bola

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.