New user's registration have been closed due to high spamming and low trafic on this forum. Please contact forum admins directly if you need an account. Thanks !

Problem with B3 WiFi in linux 4.0.0 - any ideas?

Discuss development on Bubba
Post Reply
sakaki
Posts: 172
Joined: 15 Aug 2014, 11:20

Problem with B3 WiFi in linux 4.0.0 - any ideas?

Post by sakaki »

Hello,

when I updated the ArchLinux live-USB kernel recently (starting from a vanilla 1.1.3 live-USB), to version 4.0-1 (via pacman -Syu), the B3's WiFi adaptor failed to start up. To check this wasn't a kexec (or systemd)-related issue, I then built kernel 4.0.0 on the vanilla (1.3.2) Gentoo image (from gentoo-sources-4.0.0), and experienced exactly the same problem.

If I run (on Gentoo; I get the same on Arch):

Code: Select all

b3 ~ # uname -a
Linux b3 4.0.0-gentoo-b3 #1 Fri Apr 24 17:40:02 BST 2015 armv5tel Marvell Kirkwood (Flattened Device Tree) GNU/Linux
b3 ~ # dmesg | grep -C 1 ath
[   13.196776] pci 0000:00:01.0: enabling device (0140 -> 0142)
[   13.196830] ath9k 0000:01:00.0: enabling device (0140 -> 0142)
[   13.307852] ath: phy0: Couldn't reset chip
[   13.307877] ath: phy0: Unable to initialize hardware; initialization status: -5
[   13.307904] ath9k 0000:01:00.0: Failed to initialize device
[   13.308014] ath9k: probe of 0000:01:00.0 failed with error -5
[   13.352647] cfg80211: World regulatory domain updated:
However, the WiFi adaptor is detected on the PCI bus:

Code: Select all

b3 ~ # lspci -v
00:01.0 PCI bridge: Marvell Technology Group Ltd. 88F6281 [Kirkwood] ARM SoC (rev 03) (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	Memory behind bridge: e0000000-e00fffff
	Prefetchable memory behind bridge: 00000000-000fffff

01:00.0 Network controller: Qualcomm Atheros AR928X Wireless Network Adapter (PCI-Express) (rev 01)
	Subsystem: Qualcomm Atheros Device 309a
	Flags: fast devsel, IRQ 85
	Memory at e0000000 (64-bit, non-prefetchable) [size=64K]
	Capabilities: [40] Power Management version 2
	Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit-
	Capabilities: [60] Express Legacy Endpoint, MSI 00
	Capabilities: [90] MSI-X: Enable- Count=1 Masked-
	Capabilities: [100] Advanced Error Reporting
	Capabilities: [140] Virtual Channel
	Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00
	Kernel modules: ath9k
For reference, here's the same commands, but under 3.18.6 (Gentoo), where the WiFi adaptor comes up fine:

Code: Select all

b3 ~ # uname -a
Linux b3 3.18.6-gentoo-b3 #4 Tue Feb 10 14:42:20 GMT 2015 armv5tel Marvell Kirkwood (Flattened Device Tree) GNU/Linux
b3 ~ # dmesg | grep -C 1 ath
[   12.947406] pci 0000:00:01.0: enabling device (0140 -> 0142)
[   12.947460] ath9k 0000:01:00.0: enabling device (0140 -> 0142)
[   13.373798] ath: EEPROM regdomain: 0x60
[   13.373818] ath: EEPROM indicates we should expect a direct regpair map
[   13.373849] ath: Country alpha2 being used: 00
[   13.373864] ath: Regpair used: 0x60
[   13.412364] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[   13.413361] ieee80211 phy0: Atheros AR9280 Rev:2 mem=0xe1ea0000, irq=85
[   13.432889] ath9k 0000:01:00.0 wlp1s0: renamed from wlan0
[   13.433837] systemd-udevd[916]: renamed network interface wlan0 to wlp1s0
and

Code: Select all

b3 linux # dmesg | grep -C 5 ath
[   11.566271] input: gpio-keys as /devices/platform/gpio-keys/input/input0
01:00.0 Network controller: Qualcomm Atheros AR928X Wireless Network Adapter (PCI-Express) (rev 01)
        Subsystem: Qualcomm Atheros Device 309a
        Flags: bus master, fast devsel, latency 0, IRQ 85
        Memory at e0000000 (64-bit, non-prefetchable) [size=64K]
        Capabilities: [40] Power Management version 2
        Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit-
        Capabilities: [60] Express Legacy Endpoint, MSI 00
        Capabilities: [90] MSI-X: Enable- Count=1 Masked-
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [140] Virtual Channel
        Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00
        Kernel driver in use: ath9k
        Kernel modules: ath9k
(Everything else seems to be running OK under 4.0.0, in both Gentoo and Arch).

Does anyone have any ideas? I'm afraid I'm a bit swamped with RISC-V stuff at the moment >< However, since Arch Linux live-USB users will automatically get the new kernel if they run pacman -Syu, and thereby find that their WiFi has stopped working, I'm keen to get a fix out for them (or at least a temporary version pin for the kernel and headers via an IgnorePkg stanza in /etc/pacman.conf...).

The (Gentoo) 4.0.0 kernel's .config I generated using make olddefconfig from the 1.3.2 image's version (3.18.6 kernel). That old (3.18.6) .config (where WiFi works fine) is available here. The 4.0.0 .config is available here, and a simple diff between them here.

Any help much appreciated!!

best,

sakaki
Gordon
Posts: 1461
Joined: 10 Aug 2011, 03:18

Re: Problem with B3 WiFi in linux 4.0.0 - any ideas?

Post by Gordon »

Seems to be some kind of persistent error that has been around for at least two years. I found the following on launchpad:
This bug is (most probably) related to power_save issues of the Ath9K module.

WORKAROUND: Disabling power saving mode (iw dev wlan0 set power_save off) fixed the problem. I added the following udev rule to set it right:

/etc/udev/rules.d/70-wifi-ath9k.rules

## DISABLE POWERSAVE for Atheros 9K Wireless Network Adapters
ACTION=="add", SUBSYSTEM=="net", KERNEL=="wlan*" DRIVERS=="ath9k" RUN+="/sbin/iw dev %k set power_save off"
sakaki
Posts: 172
Joined: 15 Aug 2014, 11:20

Re: Problem with B3 WiFi in linux 4.0.0 - any ideas?

Post by sakaki »

Hi,

so, I decided to run a kernel bisect to get to the bottom of this yesterday. Turns out the cause is commit a0b5cd4, "bus: mvebu-mbus: use automatic I/O synchronization barriers ". I've further confirmed that reverting this commit (which affects just 1 file) on a vanilla 4.0 kernel allows WiFi to start up OK.

Now, it is entirely possible that the ath9k driver is non-PCI compliant in some fashion, which this change exposes, but I don't really have the necessary knowledge to debug it. I've contacted the commit's author (Thomas Petazzoni, of "Device Tree for Dummies" fame) by email with a full report, so we'll see what develops (failing that, I'll start posting bug reports).

In the meantime, if you are building 4.0 yourself (e.g., for Gentoo), revert this commit if running from git, or if using a kernel.org tarball, you can patch with:

Code: Select all

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index fb9ec62..f4fb19b 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -70,7 +70,6 @@
  */
 #define WIN_CTRL_OFF		0x0000
 #define   WIN_CTRL_ENABLE       BIT(0)
-#define   WIN_CTRL_SYNCBARRIER  BIT(1)
 #define   WIN_CTRL_TGT_MASK     0xf0
 #define   WIN_CTRL_TGT_SHIFT    4
 #define   WIN_CTRL_ATTR_MASK    0xff00
@@ -84,9 +83,6 @@
 #define   WIN_REMAP_LOW         0xffff0000
 #define WIN_REMAP_HI_OFF	0x000c
 
-#define UNIT_SYNC_BARRIER_OFF   0x84
-#define   UNIT_SYNC_BARRIER_ALL 0xFFFF
-
 #define ATTR_HW_COHERENCY	(0x1 << 4)
 
 #define DDR_BASE_CS_OFF(n)	(0x0000 + ((n) << 3))
@@ -323,7 +319,6 @@ static int mvebu_mbus_setup_window(struct mvebu_mbus_state *mbus,
 	ctrl = ((size - 1) & WIN_CTRL_SIZE_MASK) |
 		(attr << WIN_CTRL_ATTR_SHIFT)    |
 		(target << WIN_CTRL_TGT_SHIFT)   |
-		WIN_CTRL_SYNCBARRIER             |
 		WIN_CTRL_ENABLE;
 
 	writel(base & WIN_BASE_LOW, addr + WIN_BASE_OFF);
@@ -1003,8 +998,7 @@ static int __init mvebu_mbus_common_init(struct mvebu_mbus_state *mbus,
 					 phys_addr_t sdramwins_phys_base,
 					 size_t sdramwins_size,
 					 phys_addr_t mbusbridge_phys_base,
-					 size_t mbusbridge_size,
-					 bool is_coherent)
+					 size_t mbusbridge_size)
 {
 	int win;
 
@@ -1036,10 +1030,6 @@ static int __init mvebu_mbus_common_init(struct mvebu_mbus_state *mbus,
 
 	mbus->soc->setup_cpu_target(mbus);
 
-	if (is_coherent)
-		writel(UNIT_SYNC_BARRIER_ALL,
-		       mbus->mbuswins_base + UNIT_SYNC_BARRIER_OFF);
-
 	register_syscore_ops(&mvebu_mbus_syscore_ops);
 
 	return 0;
@@ -1067,7 +1057,7 @@ int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base,
 			mbuswins_phys_base,
 			mbuswins_size,
 			sdramwins_phys_base,
-			sdramwins_size, 0, 0, false);
+			sdramwins_size, 0, 0);
 }
 
 #ifdef CONFIG_OF
@@ -1269,8 +1259,7 @@ int __init mvebu_mbus_dt_init(bool is_coherent)
 				     sdramwins_res.start,
 				     resource_size(&sdramwins_res),
 				     mbusbridge_res.start,
-				     resource_size(&mbusbridge_res),
-				     is_coherent);
+				     resource_size(&mbusbridge_res));
 	if (ret)
 		return ret;
 
In the meantime, users of the Arch Linux live-USB should hold off upgrading their kernel to version 4 (which will otherwise happen automatically, next time you run "pacman -Syu"), by issuing:

Code: Select all

[root@archb3 ~] nano -w /etc/pacman.conf
and uncommenting the IgnorePkg line, then modifying it so it reads:

Code: Select all

IgnorePkg = linux-kirkwood-dt linux-api-headers
Save, and close nano.

I'll update the Arch live-USB with this small change shortly, and an explanatory note.

Once this is fixed upstream, either in the mvebu-mbus or ath drivers, it'll be safe to remove the IgnorePkg stanza, and let your kernel upgrade.

Best

sakaki

Modified to clarify that the IgnorePkg line should be uncommented in place, not simply added to the end of the /etc/pacman.conf file (which will fail).
Last edited by sakaki on 01 May 2015, 05:50, edited 1 time in total.
sakaki
Posts: 172
Joined: 15 Aug 2014, 11:20

Re: Problem with B3 WiFi in linux 4.0.0 - any ideas?

Post by sakaki »

Quick update - Thomas has kindly pointed me to this patch, which I have confirmed fixes the issue on the B3, and which is on its way into the mainline kernel.

For those interested, the comment to the patch reads:

Code: Select all

Commit a0b5cd4ac2d6 ("bus: mvebu-mbus: use automatic I/O
synchronization barriers") enabled the usage of automatic I/O
synchronization barriers by enabling bit WIN_CTRL_SYNCBARRIER in the
control registers of MBus windows, but on non io-coherent platforms
(orion5x, kirkwood and dove) the WIN_CTRL_SYNCBARRIER bit in
the window control register is either reserved (all windows except 6
and 7) or enables read-only protection (windows 6 and 7).
So hopefully this issue will be closed shortly.

best

sakaki
sakaki
Posts: 172
Joined: 15 Aug 2014, 11:20

Re: Problem with B3 WiFi in linux 4.0.0 - any ideas?

Post by sakaki »

The archlinuxarm.org release kernel has now been patched, so PCIe / WiFi is working again (thanks to llsth for testing).

Accordingly, I have released a version 1.1.5 of the Arch Linux live-USB (here); users of earlier releases, who 'pinned' their 3.19.3-2 kernel in place by editing IgnorePkg in /etc/pacman.conf, can safely undo that edit now, and pull in an updated kernel with a "pacman -Syu". For full instructions, please see the release notes to version 1.1.5 (here).

best

sakaki
Post Reply