Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #62066 > unrolled thread

Bug#908438: cubietruck wifi reversion

Back to article view | Back to linux.debian.kernel

Contents

  Bug#908438: cubietruck wifi reversion Joey Hess <id@joeyh.name> - 2018-09-10 00:40 +0200
    Bug#908438: cubietruck wifi reversion Romain Perier <romain.perier@gmail.com> - 2018-09-27 14:00 +0200
      Bug#908438: cubietruck wifi reversion Joey Hess <id@joeyh.name> - 2018-09-28 23:40 +0200
    Bug#908438: Info received (Bug#908438: cubietruck wifi reversion) Joey Hess <id@joeyh.name> - 2018-09-29 06:50 +0200
    Bug#908438: cubietruck wifi reversion Hans de Goede <hdegoede@redhat.com> - 2018-09-30 17:10 +0200
      Bug#908438: cubietruck wifi reversion Salvatore Bonaccorso <carnil@debian.org> - 2019-12-18 23:00 +0100
        Bug#908438: cubietruck wifi reversion Hans de Goede <hdegoede@redhat.com> - 2019-12-20 12:20 +0100
          Bug#908438: cubietruck wifi reversion Salvatore Bonaccorso <carnil@debian.org> - 2019-12-21 23:10 +0100
            Bug#908438: Still there on 5.4.19-1~bpo10+1 (Was: Bug#908438: cubietruck wifi reversion) Jakob Haufe <sur5r@debian.org> - 2020-04-21 14:30 +0200
    Bug#908438: same problem on buster/testing Axel <axel.scheepers76@gmail.com> - 2019-02-21 20:40 +0100
    Bug#908438: [PATCH resend] ARM: dts: sun7i: Disable OOB IRQ for brcm wifi on Cubietruck and Banana Pro Helmut Grohne <helmut@subdivi.de> - 2019-12-18 18:10 +0100
    Processed: Re: [PATCH resend] ARM: dts: sun7i: Disable OOB IRQ  for brcm wifi on Cubietruck and Banana Pro "Debian Bug Tracking System" <owner@bugs.debian.org> - 2019-12-18 18:10 +0100

#62066 — Bug#908438: cubietruck wifi reversion

[Multipart message — attachments visible in raw view] — view raw

Source: linux
Version: 4.17.17-1
Severity: normal

On a cubietruck board, the linux-image-4.17.0-3-armmp-lpae kernel kernel
fails to enable the builtin wifi:

Sep 09 17:52:52 honeybee kernel: brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43362-sdio for chip BCM43362/1
Sep 09 17:52:52 honeybee kernel: usbcore: registered new interface driver brcmfmac
Sep 09 17:52:52 honeybee kernel: brcmfmac mmc1:0001:1: firmware: direct-loading firmware brcm/brcmfmac43362-sdio.bin
Sep 09 17:52:52 honeybee kernel: brcmfmac mmc1:0001:1: firmware: direct-loading firmware brcm/brcmfmac43362-sdio.txt
Sep 09 17:52:55 honeybee kernel: brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
Sep 09 17:52:55 honeybee kernel: brcmfmac: brcmf_bus_started: failed: -110
Sep 09 17:52:55 honeybee kernel: brcmfmac: brcmf_attach: dongle is not responding: err=-110
Sep 09 17:52:55 honeybee kernel: brcmfmac: brcmf_sdio_firmware_callback: brcmf_attach failed

This was working using linux-image-4.14.0-3-armmp-lpae and earlier kernels
including stable's, so seems to be a reversion.

I have firmware-brcm80211 installed. I tried downgrading it to the same
version I was using with the older kernel (20170823-1), but that did not help,
so I don't think it's a problem with the firmware.

Here it is working with the older kernel, for comparison:

Sep 09 18:06:10 honeybee kernel: brcmfmac: brcmf_fw_map_chip_to_name: using brcm/brcmfmac43362-sdio.bin for chip 0x00a962(43362) rev 0x000001
Sep 09 18:06:10 honeybee kernel: usbcore: registered new interface driver brcmfmac
Sep 09 18:06:10 honeybee kernel: brcmfmac mmc1:0001:1: firmware: direct-loading firmware brcm/brcmfmac43362-sdio.bin
Sep 09 18:06:10 honeybee kernel: brcmfmac mmc1:0001:1: firmware: direct-loading firmware brcm/brcmfmac43362-sdio.txt
Sep 09 18:06:10 honeybee kernel: brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d

-- 
see shy jo

[toc] | [next] | [standalone]

#62242

Hello,

Could you retry with linux-image-4.18.0-1-armmp-lpae, please ?

Thanks,
Regards,
Romain

On Sun, Sep 09, 2018 at 06:24:41PM -0400, Joey Hess wrote:
> Source: linux
> Version: 4.17.17-1
> Severity: normal
> 
> On a cubietruck board, the linux-image-4.17.0-3-armmp-lpae kernel kernel
> fails to enable the builtin wifi:
> 
> Sep 09 17:52:52 honeybee kernel: brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43362-sdio for chip BCM43362/1
> Sep 09 17:52:52 honeybee kernel: usbcore: registered new interface driver brcmfmac
> Sep 09 17:52:52 honeybee kernel: brcmfmac mmc1:0001:1: firmware: direct-loading firmware brcm/brcmfmac43362-sdio.bin
> Sep 09 17:52:52 honeybee kernel: brcmfmac mmc1:0001:1: firmware: direct-loading firmware brcm/brcmfmac43362-sdio.txt
> Sep 09 17:52:55 honeybee kernel: brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
> Sep 09 17:52:55 honeybee kernel: brcmfmac: brcmf_bus_started: failed: -110
> Sep 09 17:52:55 honeybee kernel: brcmfmac: brcmf_attach: dongle is not responding: err=-110
> Sep 09 17:52:55 honeybee kernel: brcmfmac: brcmf_sdio_firmware_callback: brcmf_attach failed
> 
> This was working using linux-image-4.14.0-3-armmp-lpae and earlier kernels
> including stable's, so seems to be a reversion.
> 
> I have firmware-brcm80211 installed. I tried downgrading it to the same
> version I was using with the older kernel (20170823-1), but that did not help,
> so I don't think it's a problem with the firmware.
> 
> Here it is working with the older kernel, for comparison:
> 
> Sep 09 18:06:10 honeybee kernel: brcmfmac: brcmf_fw_map_chip_to_name: using brcm/brcmfmac43362-sdio.bin for chip 0x00a962(43362) rev 0x000001
> Sep 09 18:06:10 honeybee kernel: usbcore: registered new interface driver brcmfmac
> Sep 09 18:06:10 honeybee kernel: brcmfmac mmc1:0001:1: firmware: direct-loading firmware brcm/brcmfmac43362-sdio.bin
> Sep 09 18:06:10 honeybee kernel: brcmfmac mmc1:0001:1: firmware: direct-loading firmware brcm/brcmfmac43362-sdio.txt
> Sep 09 18:06:10 honeybee kernel: brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d
> 
> -- 
> see shy jo

[toc] | [prev] | [next] | [standalone]

#62245

[Multipart message — attachments visible in raw view] — view raw

linux-image-4.18.0-1-armmp-lpae has the same problem.

-- 
see shy jo

[toc] | [prev] | [next] | [standalone]

#62246 — Bug#908438: Info received (Bug#908438: cubietruck wifi reversion)

[Multipart message — attachments visible in raw view] — view raw

Tried with a different cubietruck and it did not have this problem.

Also, 4.14 failed on the cubietruck that I had been using, and I think
it was the same failure I was seeing with the newer kernel there.

So, I think this may be a case of somehow failing hardware on my
cubietruck.

Here it is working on the new cubietruck with 4.17.0:

Jun 22 07:11:53 honeybee kernel: brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43362-sdio for chip BCM43362/1
Jun 22 07:11:53 honeybee kernel: usbcore: registered new interface driver brcmfmac
Jun 22 07:11:53 honeybee kernel: brcmfmac mmc1:0001:1: firmware: direct-loading firmware brcm/brcmfmac43362-sdio.bin
Jun 22 07:11:53 honeybee kernel: brcmfmac mmc1:0001:1: firmware: direct-loading firmware brcm/brcmfmac43362-sdio.txt
Jun 22 07:11:53 honeybee kernel: brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43362-sdio for chip BCM43362/1
Jun 22 07:11:53 honeybee kernel: brcmfmac mmc1:0001:1: firmware: failed to load brcm/brcmfmac43362-sdio.clm_blob (-2)
Jun 22 07:11:53 honeybee kernel: brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43362-sdio.clm_blob failed with error -2
Jun 22 07:11:53 honeybee kernel: brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
Jun 22 07:11:53 honeybee kernel: brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43362/1 wl0: Oct 23 2017 10:33:17 version 5.90.240 FWID 01-0

-- 
see shy jo

[toc] | [prev] | [next] | [standalone]

#62252

[Multipart message — attachments visible in raw view] — view raw

Hi all,

I've hit this problem myself this weekend on both a
Cubietruck and on a "LeMaker Banana Pro.

For me the problem was intermittent on both devices, once
it happened it seems to require a power-cycle to fix.

Once things work one can safely reboot without hitting
the issue.

I'm attaching a patch which fixes this problem for me,
it is more of a workaround but it does not have much of
a downside. Using an OOB IRQ instead of the sdio-IRQ
mechanism is mostly important to allow the MMC controller
to go into runtime-suspend which is not really an issue
on these boards since they are (usually) not battery
powered.

Regards,

Hans

[toc] | [prev] | [next] | [standalone]

#65883

Hi Hans,

On Sun, Sep 30, 2018 at 05:07:39PM +0200, Hans de Goede wrote:
> Hi all,
> 
> I've hit this problem myself this weekend on both a
> Cubietruck and on a "LeMaker Banana Pro.
> 
> For me the problem was intermittent on both devices, once
> it happened it seems to require a power-cycle to fix.
> 
> Once things work one can safely reboot without hitting
> the issue.
> 
> I'm attaching a patch which fixes this problem for me,
> it is more of a workaround but it does not have much of
> a downside. Using an OOB IRQ instead of the sdio-IRQ
> mechanism is mostly important to allow the MMC controller
> to go into runtime-suspend which is not really an issue
> on these boards since they are (usually) not battery
> powered.
> 
> Regards,
> 
> Hans
> 

> >From 34de386e5a1113360c967ba9f76901282e46a415 Mon Sep 17 00:00:00 2001
> From: Hans de Goede <hdegoede@redhat.com>
> Date: Sun, 30 Sep 2018 16:58:52 +0200
> Subject: [PATCH resend] ARM: dts: sun7i: Disable OOB IRQ for brcm wifi on
>  Cubietruck and Banana Pro
> 
> While doing some brcmfmac driver work I needed to test this also on some
> devicetree based boards. So I fired up the good old Cubietruck and when
> that would not work a Banana Pro.
> 
> With an unmodified 4.17 kernel both boards intermittently would come up
> with non working wifi with the following errors:
> 
>  brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
>  brcmfmac: brcmf_bus_started: failed: -110
>  brcmfmac: brcmf_attach: dongle is not responding: err=-110
>  brcmfmac: brcmf_sdio_firmware_callback: brcmf_attach failed
> 
> They would come up this way more often then with actual working wifi,
> once this problem happens it seems to require a power-cycle to fix.
> Once things work one can safely reboot without hitting the issue.
> 
> I've found that disabling OOB interrupts fixes this. This really is more
> of a workaround then a proper fix, but it makes the wifi reliable again
> and it does not have much of a downside.
> 
> Using an OOB IRQ instead of the sdio-IRQ mechanism is mostly important to
> allow the MMC controller to go into runtime-suspend which is not really an
> issue on these boards since they are (usually) not battery powered.
> 
> I've looked at recent brcmfmac and mmc-core changes which may explain this
> and I've not found anything. So the most likely culprit is the A20 external
> interrupt handling e.g. perhaps it is set to edge instead of level? Either
> way I do not have time to further investigate this.
> 
> BugLink: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908438
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
>  arch/arm/boot/dts/sun7i-a20-bananapro.dts  | 16 +++++++++++++---
>  arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 16 +++++++++++++---
>  2 files changed, 26 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/sun7i-a20-bananapro.dts b/arch/arm/boot/dts/sun7i-a20-bananapro.dts
> index 0898eb6162f5..0e1ddd998b20 100644
> --- a/arch/arm/boot/dts/sun7i-a20-bananapro.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-bananapro.dts
> @@ -174,9 +174,19 @@
>  	brcmf: wifi@1 {
>  		reg = <1>;
>  		compatible = "brcm,bcm4329-fmac";
> -		interrupt-parent = <&pio>;
> -		interrupts = <7 15 IRQ_TYPE_LEVEL_LOW>;
> -		interrupt-names = "host-wake";
> +		/*
> +		 * OOB interrupt support is broken ATM, often the first irq
> +		 * does not get seen resulting in the drv probe failing with:
> +		 *
> +		 * brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
> +		 * brcmfmac: brcmf_bus_started: failed: -110
> +		 * brcmfmac: brcmf_attach: dongle is not responding: err=-110
> +		 * brcmfmac: brcmf_sdio_firmware_callback: brcmf_attach failed
> +		 *
> +		 * interrupt-parent = <&pio>;
> +		 * interrupts = <7 15 IRQ_TYPE_LEVEL_LOW>;
> +		 * interrupt-names = "host-wake";
> +		 */
>  	};
>  };
>  
> diff --git a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
> index 5649161de1d7..a837516db6f9 100644
> --- a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
> @@ -222,9 +222,19 @@
>  	brcmf: wifi@1 {
>  		reg = <1>;
>  		compatible = "brcm,bcm4329-fmac";
> -		interrupt-parent = <&pio>;
> -		interrupts = <7 10 IRQ_TYPE_LEVEL_LOW>; /* PH10 / EINT10 */
> -		interrupt-names = "host-wake";
> +		/*
> +		 * OOB interrupt support is broken ATM, often the first irq
> +		 * does not get seen resulting in the drv probe failing with:
> +		 *
> +		 * brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
> +		 * brcmfmac: brcmf_bus_started: failed: -110
> +		 * brcmfmac: brcmf_attach: dongle is not responding: err=-110
> +		 * brcmfmac: brcmf_sdio_firmware_callback: brcmf_attach failed
> +		 *
> +		 * interrupt-parent = <&pio>;
> +		 * interrupts = <7 10 IRQ_TYPE_LEVEL_LOW>; /* PH10 / EINT10 */
> +		 * interrupt-names = "host-wake";
> +		 */
>  	};
>  };

Can you report this to upstream directly? (Please keep the Debian bug
into the loop).

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#65888

On 18-12-2019 22:46, Salvatore Bonaccorso wrote:
> Can you report this to upstream directly? (Please keep the Debian bug
> into the loop).

I have submitted the patch upstream at the same time I added a comment
to the Debian bug. Upstream did not accept the patch back then because
the were hoping a real fix would show up soon.

If people are still hitting this issue, it might be a good idea if
someone re-tests and if the patch still helps re-submits it upstream.

[toc] | [prev] | [next] | [standalone]

#65892

Hi Hans,

On Fri, Dec 20, 2019 at 11:53:43AM +0100, Hans de Goede wrote:
> On 18-12-2019 22:46, Salvatore Bonaccorso wrote:
> > Can you report this to upstream directly? (Please keep the Debian bug
> > into the loop).
> 
> I have submitted the patch upstream at the same time I added a comment
> to the Debian bug. Upstream did not accept the patch back then because
> the were hoping a real fix would show up soon.

Right, I missed to check on upstream list, so
https://lore.kernel.org/linux-arm-kernel/20180930150927.12076-1-hdegoede@redhat.com/
.
 
> If people are still hitting this issue, it might be a good idea if
> someone re-tests and if the patch still helps re-submits it upstream.

Helmut was reporting to see the issue on buster, but we would need
confirmation that the issue is seen still at least on 5.4.6 or ideally
as well on 5.5-rc2.

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#66853 — Bug#908438: Still there on 5.4.19-1~bpo10+1 (Was: Bug#908438: cubietruck wifi reversion)

[Multipart message — attachments visible in raw view] — view raw

On Sat, 21 Dec 2019 23:04:30 +0100 Salvatore Bonaccorso <carnil@debian.org> wrote:
>
> Helmut was reporting to see the issue on buster, but we would need
> confirmation that the issue is seen still at least on 5.4.6 or ideally
> as well on 5.5-rc2.

As stated in the subject: This is still an issue on 5.4.19-1~bpo10+1.
Patching the DT as mentioned earlier makes Wifi work.

Cheers,
sur5r

-- 
ceterum censeo microsoftem esse delendam

[toc] | [prev] | [next] | [standalone]

#63419 — Bug#908438: same problem on buster/testing

Hi,

As my cubietruck went down because of a kernel bug in stretch i tought
it was maybe better to upgrade to buster since that's around the corner.
However now wifi stopped working:

[   16.871534] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
[   16.877576] brcmfmac: brcmf_bus_started: failed: -110
[   16.928040] brcmfmac: brcmf_attach: dongle is not responding:
err=-110
[   16.972120] brcmfmac: brcmf_sdio_firmware_callback: brcmf_attach
failed

A powercycle doesn't help in my case. Reports of similar issues mention
a firmware problem. This is what's currently installed on it:

ii  firmware-brcm80211              20190114-1                   all
Binary firmware for Broadcom/Cypress 802.11 wireless cards

ii  linux-image-4.19.0-2-armmp-lpae 4.19.16-1                    armhf
Linux 4.19 for ARMv7 multiplatform compatible SoCs supporting LPAE

Kind regards,
Axel

[toc] | [prev] | [next] | [standalone]

#65881 — Bug#908438: [PATCH resend] ARM: dts: sun7i: Disable OOB IRQ for brcm wifi on Cubietruck and Banana Pro

Control: tags -1 + patch

Hi,

On Sun, Sep 30, 2018 at 04:58:52PM +0200, Hans de Goede wrote:
> While doing some brcmfmac driver work I needed to test this also on some
> devicetree based boards. So I fired up the good old Cubietruck and when
> that would not work a Banana Pro.
> 
> With an unmodified 4.17 kernel both boards intermittently would come up
> with non working wifi with the following errors:
> 
>  brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
>  brcmfmac: brcmf_bus_started: failed: -110
>  brcmfmac: brcmf_attach: dongle is not responding: err=-110
>  brcmfmac: brcmf_sdio_firmware_callback: brcmf_attach failed

I confirm the observation on a Banana Pro booting the buster 4.19
kernel. The problem happend reliably for me. I also confirm that your
workaround solves the symptoms on my board.

> Using an OOB IRQ instead of the sdio-IRQ mechanism is mostly important to
> allow the MMC controller to go into runtime-suspend which is not really an
> issue on these boards since they are (usually) not battery powered.

I agree that this is a reasonable trade-off (power saving vs working
device).

Helmut

[toc] | [prev] | [next] | [standalone]

#65882 — Processed: Re: [PATCH resend] ARM: dts: sun7i: Disable OOB IRQ for brcm wifi on Cubietruck and Banana Pro

Processing control commands:

> tags -1 + patch
Bug #908438 [src:linux] cubietruck wifi reversion
Added tag(s) patch.

-- 
908438: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908438
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web