[opensuse-factory] Bug in asynchronous firmware loading for wireless driver b43 in Leap 42.3

newer
[opensuse-factory] download repos...

older
[opensuse-factory] Tumbleweed -...

Larry Finger

6 Aug 2017 6 Aug '17

19:47

In bsc#1052060 Freek de Kruij reports a bug in firmware loading at bootup for b43 with Leap 42.3. I have confirmed the problem, and verified that Leap 42.2 and Tumbleweed work correctly. This is not a kernel problem as my tests were all done with a 4.13-rcX kernel. I suspect a udev problem; however, TW and 42.3 appear to be using the same revision for udev. Can anyone tell me to whom the bug should be reassigned? Thanks, Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Show replies by date

Takashi Iwai

6 Aug 6 Aug

20:26

On Sun, 06 Aug 2017 21:47:18 +0200, Larry Finger wrote:

...

In bsc#1052060 Freek de Kruij reports a bug in firmware loading at bootup for b43 with Leap 42.3. I have confirmed the problem, and verified that Leap 42.2 and Tumbleweed work correctly.

This is not a kernel problem as my tests were all done with a 4.13-rcX kernel. I suspect a udev problem; however, TW and 42.3 appear to be using the same revision for udev. Can anyone tell me to whom the bug should be reassigned?

Likely a dup of bug#1052060, a dracut problem. Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Takashi Iwai

20:28

On Sun, 06 Aug 2017 22:26:19 +0200, Takashi Iwai wrote:

...

On Sun, 06 Aug 2017 21:47:18 +0200, Larry Finger wrote:

...
In bsc#1052060 Freek de Kruij reports a bug in firmware loading at bootup for b43 with Leap 42.3. I have confirmed the problem, and verified that Leap 42.2 and Tumbleweed work correctly.

This is not a kernel problem as my tests were all done with a 4.13-rcX kernel. I suspect a udev problem; however, TW and 42.3 appear to be using the same revision for udev. Can anyone tell me to whom the bug should be reassigned?

Likely a dup of bug#1052060, a dracut problem.

Gah, a copy & paste error, I meant bug#1037344. Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Larry Finger

21:29

On 08/06/2017 03:28 PM, Takashi Iwai wrote:

...

On Sun, 06 Aug 2017 22:26:19 +0200, Takashi Iwai wrote:

...
On Sun, 06 Aug 2017 21:47:18 +0200, Larry Finger wrote:

...
In bsc#1052060 Freek de Kruij reports a bug in firmware loading at bootup for b43 with Leap 42.3. I have confirmed the problem, and verified that Leap 42.2 and Tumbleweed work correctly.

This is not a kernel problem as my tests were all done with a 4.13-rcX kernel. I suspect a udev problem; however, TW and 42.3 appear to be using the same revision for udev. Can anyone tell me to whom the bug should be reassigned?

Likely a dup of bug#1052060, a dracut problem.

Gah, a copy & paste error, I meant bug#1037344.

Takeshi, I agree that the two bugs are the same. I just checked, and 42.2 does not include b43.ko in initrd the way that 42.3 does. Is there a quick way to modify the list of drivers included in initrd? I think it would be better to get b43 out of initrd than to include all the firmware in kernel macros. There are a lot of firmware files, and any given card only needs a few of them. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Andrei Borzenkov

7 Aug 7 Aug

03:57

07.08.2017 00:29, Larry Finger пишет:

...

On 08/06/2017 03:28 PM, Takashi Iwai wrote:

...
On Sun, 06 Aug 2017 22:26:19 +0200, Takashi Iwai wrote:

...
On Sun, 06 Aug 2017 21:47:18 +0200, Larry Finger wrote:

...
In bsc#1052060 Freek de Kruij reports a bug in firmware loading at bootup for b43 with Leap 42.3. I have confirmed the problem, and verified that Leap 42.2 and Tumbleweed work correctly.

This is not a kernel problem as my tests were all done with a 4.13-rcX kernel. I suspect a udev problem; however, TW and 42.3 appear to be using the same revision for udev. Can anyone tell me to whom the bug should be reassigned?

Likely a dup of bug#1052060, a dracut problem.

Gah, a copy & paste error, I meant bug#1037344.

Takeshi,

I agree that the two bugs are the same. I just checked, and 42.2 does not include b43.ko in initrd the way that 42.3 does.

Is there a quick way to modify the list of drivers included in initrd? I

For testing - omit_drivers, but it wrong to unconditionally do it in package. You cannot know whether this driver may be needed.

...

think it would be better to get b43 out of initrd than to include all the firmware in kernel macros. There are a lot of firmware files, and any given card only needs a few of them.

1. Any chance that dracut now creates host-independent initrd by default? I do not see anything in dracut changelog, OTOH in 13.2 (I do not have 42.2 handy) there was dracut.conf.d snippet that explicitly set hostonly mode. 2. The problem with b43 is that it does not really list all possible firmware files in module at all, nor does it even load them from the place it indicates in module. So - assuming that monster initrd is indeed intentional - it requires special handling, you cannot simply feet all firmware files indicated by module. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Larry Finger

04:44

On 08/06/2017 10:57 PM, Andrei Borzenkov wrote:

...

07.08.2017 00:29, Larry Finger пишет:

...
On 08/06/2017 03:28 PM, Takashi Iwai wrote:

...
On Sun, 06 Aug 2017 22:26:19 +0200, Takashi Iwai wrote:

...
On Sun, 06 Aug 2017 21:47:18 +0200, Larry Finger wrote:

...
In bsc#1052060 Freek de Kruij reports a bug in firmware loading at bootup for b43 with Leap 42.3. I have confirmed the problem, and verified that Leap 42.2 and Tumbleweed work correctly.

This is not a kernel problem as my tests were all done with a 4.13-rcX kernel. I suspect a udev problem; however, TW and 42.3 appear to be using the same revision for udev. Can anyone tell me to whom the bug should be reassigned?

Likely a dup of bug#1052060, a dracut problem.

Gah, a copy & paste error, I meant bug#1037344.

Takeshi,

I agree that the two bugs are the same. I just checked, and 42.2 does not include b43.ko in initrd the way that 42.3 does.

Is there a quick way to modify the list of drivers included in initrd? I

For testing - omit_drivers, but it wrong to unconditionally do it in package. You cannot know whether this driver may be needed.

If I omitted b43 from my configuration, how would I test for the bug?

...

...
think it would be better to get b43 out of initrd than to include all the firmware in kernel macros. There are a lot of firmware files, and any given card only needs a few of them.

1. Any chance that dracut now creates host-independent initrd by default? I do not see anything in dracut changelog, OTOH in 13.2 (I do not have 42.2 handy) there was dracut.conf.d snippet that explicitly set hostonly mode.

2. The problem with b43 is that it does not really list all possible firmware files in module at all, nor does it even load them from the place it indicates in module. So - assuming that monster initrd is indeed intentional - it requires special handling, you cannot simply feet all firmware files indicated by module.

I do not understand the "nor does it even load them from the place it indicates in module" comment. All regular firmware is loaded from /lib/firmware/b43/. There is a possibility of loading open-source firmware from a different directory, but that kind of fw is available for only a couple of antiquated cards. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Andrei Borzenkov

08:29

On Mon, Aug 7, 2017 at 7:44 AM, Larry Finger wrote:

...

On 08/06/2017 10:57 PM, Andrei Borzenkov wrote:

...
07.08.2017 00:29, Larry Finger пишет:

...
On 08/06/2017 03:28 PM, Takashi Iwai wrote:

...
On Sun, 06 Aug 2017 22:26:19 +0200, Takashi Iwai wrote:

...
On Sun, 06 Aug 2017 21:47:18 +0200, Larry Finger wrote:

...
In bsc#1052060 Freek de Kruij reports a bug in firmware loading at bootup for b43 with Leap 42.3. I have confirmed the problem, and verified that Leap 42.2 and Tumbleweed work correctly.

This is not a kernel problem as my tests were all done with a 4.13-rcX kernel. I suspect a udev problem; however, TW and 42.3 appear to be using the same revision for udev. Can anyone tell me to whom the bug should be reassigned?

Likely a dup of bug#1052060, a dracut problem.

Gah, a copy & paste error, I meant bug#1037344.

Takeshi,

I agree that the two bugs are the same. I just checked, and 42.2 does not include b43.ko in initrd the way that 42.3 does.

Is there a quick way to modify the list of drivers included in initrd? I

For testing - omit_drivers, but it wrong to unconditionally do it in package. You cannot know whether this driver may be needed.

If I omitted b43 from my configuration, how would I test for the bug?

Not sure I understand the question. You asked how to modify list of drivers included in initrd; omit_drivers makes dracut to skip named kernel modules. Was not it what you wanted?

...

...
...
think it would be better to get b43 out of initrd than to include all the firmware in kernel macros. There are a lot of firmware files, and any given card only needs a few of them.

1. Any chance that dracut now creates host-independent initrd by default? I do not see anything in dracut changelog, OTOH in 13.2 (I do not have 42.2 handy) there was dracut.conf.d snippet that explicitly set hostonly mode.

2. The problem with b43 is that it does not really list all possible firmware files in module at all, nor does it even load them from the place it indicates in module. So - assuming that monster initrd is indeed intentional - it requires special handling, you cannot simply feet all firmware files indicated by module.

I do not understand the "nor does it even load them from the place it indicates in module" comment. All regular firmware is loaded from /lib/firmware/b43/. There is a possibility of loading open-source firmware from a different directory, but that kind of fw is available for only a couple of antiquated cards.

It does not matter whether it is done for one or dozen cards - either you are going to support it or not. If you are going to support it, it cannot be done by mechanically including all "firmware" lines in module description. That's all. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Roger Oberholtzer

16 Aug 16 Aug

06:29

On Mon, Aug 7, 2017 at 10:29 AM, Andrei Borzenkov wrote:

...

...
...
...
...
Gah, a copy & paste error, I meant bug#1037344.

I just installed Tumbleweed on an iMac (vintage 2008) and, for the most part, all seemed to go well (very well, in fact!). Except I have been bitten by this bug. There are a number of suggestions about solutions, but all are based on the idea that the b43 driver is being loaded before the firmware files are available. Unfortunately, the solution to unload and reload the b43 driver seemed not to solve the problem for me. Or, maybe I am looking at it in the wrong way. If I unload and reload the b43 driver with: morprobe -r b43 modprobe b43 shouldn't this result in the interface showing up in, say, 'ip addr', or in yast? This I do not see. Maybe there is more to it that just re-loading that module? So, I am not sure I want to try an experimental dracut to allow removal of b43 from the initrd image when the manual method is not working. BTW, this is the first time I have run Linux on an iMac. So I probably have some other things to learn as well. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Larry Finger

17:32

On 08/16/2017 01:29 AM, Roger Oberholtzer wrote:

...

On Mon, Aug 7, 2017 at 10:29 AM, Andrei Borzenkov wrote:

...
...
...
...
...
Gah, a copy & paste error, I meant bug#1037344.

I just installed Tumbleweed on an iMac (vintage 2008) and, for the most part, all seemed to go well (very well, in fact!). Except I have been bitten by this bug. There are a number of suggestions about solutions, but all are based on the idea that the b43 driver is being loaded before the firmware files are available. Unfortunately, the solution to unload and reload the b43 driver seemed not to solve the problem for me. Or, maybe I am looking at it in the wrong way. If I unload and reload the b43 driver with:

morprobe -r b43 modprobe b43

shouldn't this result in the interface showing up in, say, 'ip addr', or in yast? This I do not see. Maybe there is more to it that just re-loading that module?

So, I am not sure I want to try an experimental dracut to allow removal of b43 from the initrd image when the manual method is not working.

BTW, this is the first time I have run Linux on an iMac. So I probably have some other things to learn as well.

Have you installed the b43 firmware? Check that /lib/firmware/b43 exists and contains files. If not, you need to run /usr/sbin/install_bcm43xx_firmware. This step is needed because Broadcom refuses to allow redistribution of their firmware, thus openSUSE must extract the necessary files from a binary blob that is distributable. If that does not work, the output of the dmesg command might be helpful in diagnosing this problem. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Roger Oberholtzer

17 Aug 17 Aug

06:24

On Wed, Aug 16, 2017 at 7:32 PM, Larry Finger wrote:

...

Have you installed the b43 firmware? Check that /lib/firmware/b43 exists and contains files. If not, you need to run /usr/sbin/install_bcm43xx_firmware. This step is needed because Broadcom refuses to allow redistribution of their firmware, thus openSUSE must extract the necessary files from a binary blob that is distributable.

If that does not work, the output of the dmesg command might be helpful in diagnosing this problem.

I do have the files installed. The RPM that the message pointed to was surprisingly old and referenced (i.e., the RPM name containred) older openSUSE releases. But the .fw files seem to have been extracted to the correct location. I will attach the dmesg log when I am next at the machine. As the machine has no networking until this is corrected, the is a slower process that is usually the case. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Roger Oberholtzer

18 Aug 18 Aug

06:23

On Thu, Aug 17, 2017 at 8:24 AM, Roger Oberholtzer wrote:

...

As the machine has no networking until this is corrected, the is a slower process that is usually the case.

I now get the message that "Dual-core devices are not supported" Seems this means that the firmware I am using is not correct. I do not know why. I have the files in place and they are obviously loaded as I no longer get that complaint. I see a discussion of this here: https://forums.opensuse.org/content.php/157-Broadcom-firmware-is-needed-for-... I will next try that. How it is different from the manual method described elsewhere in the openSUSE wiki is unclear. Are there different versions of the firmware, and perhaps I am using the wrong RPM? -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Larry Finger

10:24

On 08/18/2017 01:23 AM, Roger Oberholtzer wrote:

...

On Thu, Aug 17, 2017 at 8:24 AM, Roger Oberholtzer wrote:

...
As the machine has no networking until this is corrected, the is a slower process that is usually the case.

I now get the message that "Dual-core devices are not supported"

Seems this means that the firmware I am using is not correct. I do not know why. I have the files in place and they are obviously loaded as I no longer get that complaint.

I see a discussion of this here:

https://forums.opensuse.org/content.php/157-Broadcom-firmware-is-needed-for-...

I will next try that. How it is different from the manual method described elsewhere in the openSUSE wiki is unclear. Are there different versions of the firmware, and perhaps I am using the wrong RPM?

Your problem is NOT firmware now. I need to see the output of dmesg, particularly the part where the ssb cores are enumerated. It sounds as if your particular device may have more than one 802.11 core attached. I would also like to see the output of 'lspci -nn'. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Roger Oberholtzer

19 Aug 19 Aug

11:40

On Fri, Aug 18, 2017 at 12:24 PM, Larry Finger wrote:

...

Your problem is NOT firmware now. I need to see the output of dmesg, particularly the part where the ssb cores are enumerated. It sounds as if your particular device may have more than one 802.11 core attached. I would also like to see the output of 'lspci -nn'.

This is on a 2008 vintage iMac. I now have the wired network connected. In fact, I think everything (sound, bluetooth, graphics) are working excellent. The wifi is the only holdout.. And all is faster than the last MacOS that was installed (it needed too much RAM just to be running...). lspci -nn reports: 00:00.0 Host bridge [0600]: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub [8086:2a00] (rev 03) 00:01.0 PCI bridge [0604]: Intel Corporation Mobile PM965/GM965/GL960 PCI Express Root Port [8086:2a01] (rev 03) 00:1a.0 USB controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 [8086:2834] (rev 03) 00:1a.1 USB controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 [8086:2835] (rev 03) 00:1a.7 USB controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 [8086:283a] (rev 03) 00:1b.0 Audio device [0403]: Intel Corporation 82801H (ICH8 Family) HD Audio Controller [8086:284b] (rev 03) 00:1c.0 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 [8086:283f] (rev 03) 00:1c.3 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) PCI Express Port 4 [8086:2845] (rev 03) 00:1c.4 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 [8086:2847] (rev 03) 00:1c.5 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) PCI Express Port 6 [8086:2849] (rev 03) 00:1d.0 USB controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 [8086:2830] (rev 03) 00:1d.1 USB controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 [8086:2831] (rev 03) 00:1d.2 USB controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 [8086:2832] (rev 03) 00:1d.7 USB controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 [8086:2836] (rev 03) 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev f3) 00:1f.0 ISA bridge [0601]: Intel Corporation 82801HM (ICH8M) LPC Interface Controller [8086:2815] (rev 03) 00:1f.1 IDE interface [0101]: Intel Corporation 82801HM/HEM (ICH8M/ICH8M-E) IDE Controller [8086:2850] (rev 03) 00:1f.2 SATA controller [0106]: Intel Corporation 82801HM/HEM (ICH8M/ICH8M-E) SATA Controller [AHCI mode] [8086:2829] (rev 03) 00:1f.3 SMBus [0c05]: Intel Corporation 82801H (ICH8 Family) SMBus Controller [8086:283e] (rev 03) 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] RV630/M76 [Mobility Radeon HD 2600 XT/2700] [1002:9583] 03:00.0 FireWire (IEEE 1394) [0c00]: LSI Corporation FW643 [TrueFire] PCIe 1394b Controller [11c1:5901] (rev 06) 04:00.0 Network controller [0280]: Broadcom Limited BCM4321 802.11a/b/g/n [14e4:4328] (rev 05) 05:00.0 Ethernet controller [0200]: Marvell Technology Group Ltd. 88E8058 PCI-E Gigabit Ethernet Controller [11ab:436a] (rev 13) I only see the wired and wireless Ethernet devices. I do not know if the bcm4321 is a dual port.. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Larry Finger

13:54

On 08/19/2017 06:40 AM, Roger Oberholtzer wrote:

...

04:00.0 Network controller [0280]: Broadcom Limited BCM4321 802.11a/b/g/n [14e4:4328] (rev 05)

I only see the wired and wireless Ethernet devices. I do not know if the bcm4321 is a dual port..

From https://wireless.wiki.kernel.org/en/users/Drivers/b43, we get the definitive answer. You will need to use the wl hybrid driver from the Broadcom site. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Roger Oberholtzer

20 Aug 20 Aug

11:12

On Sat, Aug 19, 2017 at 3:54 PM, Larry Finger wrote:

...

On 08/19/2017 06:40 AM, Roger Oberholtzer wrote:

...
04:00.0 Network controller [0280]: Broadcom Limited BCM4321 802.11a/b/g/n [14e4:4328] (rev 05)

I only see the wired and wireless Ethernet devices. I do not know if the bcm4321 is a dual port..

From https://wireless.wiki.kernel.org/en/users/Drivers/b43, we get the definitive answer. You will need to use the wl hybrid driver from the Broadcom site.

Great. I have located the Linux® STA 64-bit driver (10/01/2015) from https://www.broadcom.com/support/download-search/?pf=Wireless+LAN+Infrastruc... which claims support for the chipset. Next is to install the bits needed to be able to compile it. I am going the dkms way. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Roger Oberholtzer

13:01

On Sun, Aug 20, 2017 at 1:12 PM, Roger Oberholtzer wrote:

...

On Sat, Aug 19, 2017 at 3:54 PM, Larry Finger wrote:

...
On 08/19/2017 06:40 AM, Roger Oberholtzer wrote:

...
04:00.0 Network controller [0280]: Broadcom Limited BCM4321 802.11a/b/g/n [14e4:4328] (rev 05)

I only see the wired and wireless Ethernet devices. I do not know if the bcm4321 is a dual port..

From https://wireless.wiki.kernel.org/en/users/Drivers/b43, we get the definitive answer. You will need to use the wl hybrid driver from the Broadcom site.

Great. I have located the Linux® STA 64-bit driver (10/01/2015) from https://www.broadcom.com/support/download-search/?pf=Wireless+LAN+Infrastruc... which claims support for the chipset. Next is to install the bits needed to be able to compile it. I am going the dkms way.

-- Roger Oberholtzer

After locating some patches (by Arch Linux) for newer kernels, I got the module to compile. No real complaints at that point. I installed the module and ran depmod. The module loaded without complaint. modprobe -r b43 modprobe wl But, alas, I still have no device. And no messages at all that I see. # modinfo wl filename: /lib/modules/4.12.7-1-default/kernel/drivers/net/wireless/wl.ko license: Mixed/Proprietary license: MIXED/Proprietary srcversion: FCF63BEFFC5C0C767ACD715 alias: pci:v*d*sv*sd*bc02sc80i* depends: cfg80211 vermagic: 4.12.7-1-default SMP preempt mod_unload modversions parm: passivemode:int parm: wl_txq_thresh:int parm: oneonly:int parm: piomode:int parm: instance_base:int parm: nompc:int parm: intf_name:string -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Roger Oberholtzer

13:20

On Sun, Aug 20, 2017 at 3:01 PM, Roger Oberholtzer wrote: I see a discussion about this for Leap 42.3 at http://opensuse-guide.org/wlan.php It suggests installing the wl driver from Packman. So I removed mine and installed that one. No difference. No new device and no complaint made. # modinfo wl filename: /lib/modules/4.12.7-1-default/updates/wl.ko license: MIXED/Proprietary srcversion: 5BB635453C1327C0D98D3C0 alias: pci:v*d*sv*sd*bc02sc80i* depends: cfg80211 vermagic: 4.12.7-1-default SMP preempt mod_unload modversions signat: X509 signer: Essentials OBS Project sig_key: 80:5C:97:C9:2B:53:FE:45:14:7D:05:00:9D:65:F2:82:6B:98:9A:B4 sig_hashalgo: sha256 parm: passivemode:int parm: wl_txq_thresh:int parm: oneonly:int parm: piomode:int parm: instance_base:int parm: nompc:int parm: intf_name:string -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Malcolm

14:40

New subject: [opensuse-factory] Re: Bug in asynchronous firmware loading for wireless driver b43 in Leap 42.3

On Sun 20 Aug 2017 03:20:47 PM CDT, Roger Oberholtzer wrote:

...

On Sun, Aug 20, 2017 at 3:01 PM, Roger Oberholtzer wrote:

I see a discussion about this for Leap 42.3 at http://opensuse-guide.org/wlan.php

It suggests installing the wl driver from Packman. So I removed mine and installed that one.

No difference. No new device and no complaint made.

# modinfo wl filename: /lib/modules/4.12.7-1-default/updates/wl.ko license: MIXED/Proprietary srcversion: 5BB635453C1327C0D98D3C0 alias: pci:v*d*sv*sd*bc02sc80i* depends: cfg80211 vermagic: 4.12.7-1-default SMP preempt mod_unload modversions signat: X509 signer: Essentials OBS Project sig_key: 80:5C:97:C9:2B:53:FE:45:14:7D:05:00:9D:65:F2:82:6B:98:9A:B4 sig_hashalgo: sha256 parm: passivemode:int parm: wl_txq_thresh:int parm: oneonly:int parm: piomode:int parm: instance_base:int parm: nompc:int parm: intf_name:string

Hi You need to rebuild initrd (mkinitrd) so the blacklist will kick in for b43 etc -- Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890) openSUSE Leap 42.2 | GNOME 3.20.2 | 4.4.79-18.26-default HP 255 G4 Notebook | A6-6310 X4 @ 1.80 GHz | AMD Radeon R4 up 2 days 11:01, 1 user, load average: 0.86, 0.57, 0.46 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Roger Oberholtzer

14:55

New subject: [opensuse-factory] Re: Bug in asynchronous firmware loading for wireless driver b43 in Leap 42.3

On Sun, Aug 20, 2017 at 4:40 PM, Malcolm wrote:

...

Hi You need to rebuild initrd (mkinitrd) so the blacklist will kick in for b43 etc

I thought that the wl driver install RPM (from Packman) might do that Seems not. So I blacklisted these (based on info in the wl driver source): blacklist b43 blacklist ssb blacklist bcma blacklist brcmsmac blacklist brcmfmac and rebuilt the initramfs with dracut. After a reboot it is working! So happy to be able to use this iMac again! So the solution was: 1. Install broadcom-wl from Packman. 2. Blacklist the b43 and related drivers. 3. Rebuild the initramfs. 4. Reboot. Thanks to all who helped. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Malcolm

15:31

New subject: [opensuse-factory] Re: Bug in asynchronous firmware loading for wireless driver b43 in Leap 42.3

On Sun 20 Aug 2017 04:55:14 PM CDT, Roger Oberholtzer wrote:

...

On Sun, Aug 20, 2017 at 4:40 PM, Malcolm wrote:

...
Hi You need to rebuild initrd (mkinitrd) so the blacklist will kick in for b43 etc

I thought that the wl driver install RPM (from Packman) might do that Seems not. So I blacklisted these (based on info in the wl driver source):

blacklist b43 blacklist ssb blacklist bcma blacklist brcmsmac blacklist brcmfmac

and rebuilt the initramfs with dracut.

After a reboot it is working!

So happy to be able to use this iMac again!

So the solution was:

1. Install broadcom-wl from Packman. 2. Blacklist the b43 and related drivers. 3. Rebuild the initramfs. 4. Reboot.

Thanks to all who helped.

Hi If you install the two packages broadcom-wl and broadcom-wl-kmp-default and then just run mkinitrd it's all taken care of.... Now if your system has a fan... search for mbpfan on OBS ;) -- Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890) openSUSE Leap 42.2 | GNOME 3.20.2 | 4.4.79-18.26-default HP 255 G4 Notebook | A6-6310 X4 @ 1.80 GHz | AMD Radeon R4 up 2 days 11:50, 1 user, load average: 0.52, 0.51, 0.49 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Roger Oberholtzer

16:31

New subject: [opensuse-factory] Re: Bug in asynchronous firmware loading for wireless driver b43 in Leap 42.3

On Sun, Aug 20, 2017 at 5:31 PM, Malcolm wrote:

...

If you install the two packages broadcom-wl and broadcom-wl-kmp-default and then just run mkinitrd it's all taken care of....

Seems I was not accurate in naming the RPM with the needed driver. It is actually called broadcom-wl-kmp-default. There is no broadcom-wl that I see. Sorry for the confusion. I am fairly certain that installing the RPM resulted in both the wl and b43 drivers being loaded after a reboot. Which sounds odd. I had to remove them from the initramfs to get this all to work.

...

Now if your system has a fan... search for mbpfan on OBS ;)

One would think it has a fan. But the enclosure is rather closed so I have never heard anything. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Malcolm

16:46

New subject: [opensuse-factory] Re: Bug in asynchronous firmware loading for wireless driver b43 in Leap 42.3

On Sun 20 Aug 2017 06:31:50 PM CDT, Roger Oberholtzer wrote:

...

On Sun, Aug 20, 2017 at 5:31 PM, Malcolm wrote:

...
If you install the two packages broadcom-wl and broadcom-wl-kmp-default and then just run mkinitrd it's all taken care of....

Seems I was not accurate in naming the RPM with the needed driver. It is actually called broadcom-wl-kmp-default. There is no broadcom-wl that I see. Sorry for the confusion.

Hi There is.... broadcom-wl (has the blacklist etc) http://packman.links2linux.org/package/broadcom-wl/815227 broadcom-wl-kmp-default (kernel driver) http://packman.links2linux.org/package/broadcom-wl/815226 -- Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890) openSUSE Leap 42.2 | GNOME 3.20.2 | 4.4.79-18.26-default HP 255 G4 Notebook | A6-6310 X4 @ 1.80 GHz | AMD Radeon R4 up 2 days 13:05, 1 user, load average: 1.32, 0.79, 0.51 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Roman Bysh

21:09

New subject: [opensuse-factory] Re: Bug in asynchronous firmware loading for wireless driver b43 in Leap 42.3

On 20/08/17 10:55 AM, Roger Oberholtzer wrote:

...

On Sun, Aug 20, 2017 at 4:40 PM, Malcolm wrote:

...
Hi You need to rebuild initrd (mkinitrd) so the blacklist will kick in for b43 etc

I thought that the wl driver install RPM (from Packman) might do that Seems not. So I blacklisted these (based on info in the wl driver source):

blacklist b43 blacklist ssb blacklist bcma blacklist brcmsmac blacklist brcmfmac

and rebuilt the initramfs with dracut.

After a reboot it is working!

So happy to be able to use this iMac again!

So the solution was:

1. Install broadcom-wl from Packman. 2. Blacklist the b43 and related drivers. 3. Rebuild the initramfs. 4. Reboot.

Thanks to all who helped.

Which iMac are you using? How old is it and are you using it for openSUSE only? Cheers! Roman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Roger Oberholtzer

21 Aug 21 Aug

06:05

New subject: [opensuse-factory] Re: Bug in asynchronous firmware loading for wireless driver b43 in Leap 42.3

On Sun, Aug 20, 2017 at 11:09 PM, Roman Bysh wrote:

...

Which iMac are you using? How old is it and are you using it for openSUSE only?

It is from 2008. I had been running the latest MacOS. But it keeps increasing the minimum RAM needed, to the point that even logging in results in no free RAM and the start of caching hell. I installed an app to clean the Mac and tried to eliminate everything that was optional. But still too little RAM. It only has 2 GB. So now I run Tumbleweed. And it is working great. The only hiccough was the wireless, which turned out to have a simple solution. Everything else seems to be working. And even with KDE things are snappy. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Roman Bysh

20:11

New subject: [opensuse-factory] Re: Bug in asynchronous firmware loading for wireless driver b43 in Leap 42.3

On 21/08/17 02:05 AM, Roger Oberholtzer wrote:

...

On Sun, Aug 20, 2017 at 11:09 PM, Roman Bysh wrote:

...
Which iMac are you using? How old is it and are you using it for openSUSE only?

It is from 2008. I had been running the latest MacOS. But it keeps increasing the minimum RAM needed, to the point that even logging in results in no free RAM and the start of caching hell. I installed an app to clean the Mac and tried to eliminate everything that was optional. But still too little RAM. It only has 2 GB.

So now I run Tumbleweed. And it is working great. The only hiccough was the wireless, which turned out to have a simple solution. Everything else seems to be working.

And even with KDE things are snappy.

Tumbleweed is a great release. I tend to have more freeze ups with Snapper and Leap. Your problem with the RAM could be an issue withe kernel. Because it is one of the latest releases I would increase the RAM to 8 GB. I use the the Mac Cleaner app. Work great on cleaning out a lot of space. I'm running Yosemite on an Asus P5Q mobo. All I needed were two kexts for the audio and the Atheros Gigabit card "atl1e" for my Internet. -- Cheers! Roman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Roger Oberholtzer

22 Aug 22 Aug

07:51

New subject: [opensuse-factory] Re: Bug in asynchronous firmware loading for wireless driver b43 in Leap 42.3

On Mon, Aug 21, 2017 at 10:11 PM, Roman Bysh wrote:

...

Your problem with the RAM could be an issue withe kernel. Because it is one of the latest releases I would increase the RAM to 8 GB.

I use the the Mac Cleaner app. Work great on cleaning out a lot of space. I'm running Yosemite on an Asus P5Q mobo. All I needed were two kexts for the audio and the Atheros Gigabit card "atl1e" for my Internet.

The problem with RAM was with MacOS. With Tumbleweed I have no problem. All is quite snappy. At least for how I am currently using this machine. The machine has 2 GB. I can replace that RAM to get 4 GB, which is the max this machine supports. I have not done this because I am guessing it will not be inexpensive. I also used MacCleaner. When it cam to RAM, it would clean it up. But after a minute or so it was once again all used. Even though I am not running any stuff beyond the OS and Safari. And just logging in to get to where I could run MacCleaner took forever. So I decided that was a dead end. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Roman Bysh

16:21

New subject: [opensuse-factory] Re: Bug in asynchronous firmware loading for wireless driver b43 in Leap 42.3

On 22/08/17 03:51 AM, Roger Oberholtzer wrote:

...

On Mon, Aug 21, 2017 at 10:11 PM, Roman Bysh wrote:

...
Your problem with the RAM could be an issue withe kernel. Because it is one of the latest releases I would increase the RAM to 8 GB.

I use the the Mac Cleaner app. Work great on cleaning out a lot of space. I'm running Yosemite on an Asus P5Q mobo. All I needed were two kexts for the audio and the Atheros Gigabit card "atl1e" for my Internet.

The problem with RAM was with MacOS. With Tumbleweed I have no problem. All is quite snappy. At least for how I am currently using this machine.

The machine has 2 GB. I can replace that RAM to get 4 GB, which is the max this machine supports. I have not done this because I am guessing it will not be inexpensive.

I also used MacCleaner. When it cam to RAM, it would clean it up. But after a minute or so it was once again all used. Even though I am not running any stuff beyond the OS and Safari. And just logging in to get to where I could run MacCleaner took forever. So I decided that was a dead end.

I like to add the "Activity Monitor" to the dock (found in the "Utilities" folder). -- Cheers! Roman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Larry Finger

18 Aug 18 Aug

14:59

On 08/18/2017 01:23 AM, Roger Oberholtzer wrote:

...

On Thu, Aug 17, 2017 at 8:24 AM, Roger Oberholtzer wrote:

...
As the machine has no networking until this is corrected, the is a slower process that is usually the case.

I now get the message that "Dual-core devices are not supported"

Seems this means that the firmware I am using is not correct. I do not know why. I have the files in place and they are obviously loaded as I no longer get that complaint.

I see a discussion of this here:

https://forums.opensuse.org/content.php/157-Broadcom-firmware-is-needed-for-...

I will next try that. How it is different from the manual method described elsewhere in the openSUSE wiki is unclear. Are there different versions of the firmware, and perhaps I am using the wrong RPM?

I found a little more background on your problem. That message about dual cores was submitted as commit 8f15e28703d1 ("b43: ssb: refuse to support more than one IEEE 802.11 core"). The above patch was applied to kernel 3.16. You stated that you had not used your device for some time. Obviously, previous use was with kernel 3.15 or older. Driver b43 never supported the 5G band in any of the devices. Some, including yours, were dual band with a separate 802.11 core for each band. Handling them was tricky, thus the rejection of any such devices. I have Cc'd the author of that patch to see if he can think of a way to get your device working. Reverting that patch would restore the old behavior, but that would probably affect a lot more users. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Stefan Bruens

9 Sep 9 Sep

21:31

On Freitag, 18. August 2017 16:59:25 CEST Larry Finger wrote:

...

On 08/18/2017 01:23 AM, Roger Oberholtzer wrote:

...
On Thu, Aug 17, 2017 at 8:24 AM, Roger Oberholtzer

wrote:

...
As the machine has no networking until this is corrected, the is a slower process that is usually the case.

I now get the message that "Dual-core devices are not supported"

Seems this means that the firmware I am using is not correct. I do not know why. I have the files in place and they are obviously loaded as I no longer get that complaint.

I see a discussion of this here:

https://forums.opensuse.org/content.php/157-Broadcom-firmware-is-needed-fo r-b43-but-I-have-no-network-an-easierwork-around

I will next try that. How it is different from the manual method described elsewhere in the openSUSE wiki is unclear. Are there different versions of the firmware, and perhaps I am using the wrong RPM?

I found a little more background on your problem. That message about dual cores was submitted as commit 8f15e28703d1 ("b43: ssb: refuse to support more than one IEEE 802.11 core").

The above patch was applied to kernel 3.16. You stated that you had not used your device for some time. Obviously, previous use was with kernel 3.15 or older. Driver b43 never supported the 5G band in any of the devices. Some, including yours, were dual band with a separate 802.11 core for each band. Handling them was tricky, thus the rejection of any such devices.

I have Cc'd the author of that patch to see if he can think of a way to get your device working. Reverting that patch would restore the old behavior, but that would probably affect a lot more users.

Larry

This seems to be some regression introduced between last Leap 42.2 kernel and current 42.3 kernel. The 42.2 kernel was 4.4.74-18.20, currently installed kernel is 4.4.85-22. The regression happens with two different Dell-branded Broadcom wireless cards, the 4322 is from November 2009, the 4312 from March 2010: b43-phy0: Broadcom 4312 WLAN found (core revision 15) b43-phy0: Found PHY: Analog 6, Type 5 (LP), Revision 1 b43-phy0: Found Radio: Manuf 0x17F, ID 0x2062, Revision 2, Version 0 Broadcom 43xx driver loaded [ Features: PNLS ] b43-phy0: Broadcom 4322 WLAN found (core revision 16) b43-phy0: Found PHY: Analog 8, Type 4 (N), Revision 4 b43-phy0: Found Radio: Manuf 0x17F, ID 0x2056, Revision 3, Version 0 Broadcom 43xx driver loaded [ Features: PNLS ] So although the "Dual-core not supported" message is from kernel 3.16, there seems to be something else that causes this regression. Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Mikel Rychliski

22:06

On Saturday, September 9, 2017 5:31:58 PM EDT Stefan Bruens wrote:

...

On Freitag, 18. August 2017 16:59:25 CEST Larry Finger wrote:

...
On 08/18/2017 01:23 AM, Roger Oberholtzer wrote:

...
On Thu, Aug 17, 2017 at 8:24 AM, Roger Oberholtzer

wrote:

...
As the machine has no networking until this is corrected, the is a slower process that is usually the case.

I now get the message that "Dual-core devices are not supported"

Seems this means that the firmware I am using is not correct. I do not know why. I have the files in place and they are obviously loaded as I no longer get that complaint.

I see a discussion of this here:

https://forums.opensuse.org/content.php/157-Broadcom-firmware-is-needed-> > > fo r-b43-but-I-have-no-network-an-easierwork-around

I will next try that. How it is different from the manual method described elsewhere in the openSUSE wiki is unclear. Are there different versions of the firmware, and perhaps I am using the wrong RPM?

I found a little more background on your problem. That message about dual cores was submitted as commit 8f15e28703d1 ("b43: ssb: refuse to support more than one IEEE 802.11 core").

The above patch was applied to kernel 3.16. You stated that you had not used your device for some time. Obviously, previous use was with kernel 3.15 or older. Driver b43 never supported the 5G band in any of the devices. Some, including yours, were dual band with a separate 802.11 core for each band. Handling them was tricky, thus the rejection of any such devices.

I have Cc'd the author of that patch to see if he can think of a way to get your device working. Reverting that patch would restore the old behavior, but that would probably affect a lot more users.

Larry

This seems to be some regression introduced between last Leap 42.2 kernel and current 42.3 kernel.

The 42.2 kernel was 4.4.74-18.20, currently installed kernel is 4.4.85-22.

The regression happens with two different Dell-branded Broadcom wireless cards, the 4322 is from November 2009, the 4312 from March 2010:

b43-phy0: Broadcom 4312 WLAN found (core revision 15) b43-phy0: Found PHY: Analog 6, Type 5 (LP), Revision 1 b43-phy0: Found Radio: Manuf 0x17F, ID 0x2062, Revision 2, Version 0 Broadcom 43xx driver loaded [ Features: PNLS ]

b43-phy0: Broadcom 4322 WLAN found (core revision 16) b43-phy0: Found PHY: Analog 8, Type 4 (N), Revision 4 b43-phy0: Found Radio: Manuf 0x17F, ID 0x2056, Revision 3, Version 0 Broadcom 43xx driver loaded [ Features: PNLS ]

So although the "Dual-core not supported" message is from kernel 3.16, there seems to be something else that causes this regression.

Kind regards,

Stefan

I'm getting the "Dual-core devices are not supported" error when trying to reinsert the b43 module after the firmware load in initrd failed. The error message "probe of ssb0:0 failed with error -524" is also logged by the same module. Removing the ssb_hcd and ssb modules (with rmmod) before reinserting b43 (with modprobe) resolved the issue for me. Mikel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Stefan Bruens

23:17

On Sonntag, 10. September 2017 00:06:19 CEST Mikel Rychliski wrote:

...

On Saturday, September 9, 2017 5:31:58 PM EDT Stefan Bruens wrote:

...
On Freitag, 18. August 2017 16:59:25 CEST Larry Finger wrote:

...
On 08/18/2017 01:23 AM, Roger Oberholtzer wrote:

...
On Thu, Aug 17, 2017 at 8:24 AM, Roger Oberholtzer

wrote:

...
As the machine has no networking until this is corrected, the is a slower process that is usually the case.

I now get the message that "Dual-core devices are not supported"

Seems this means that the firmware I am using is not correct. I do not know why. I have the files in place and they are obviously loaded as I no longer get that complaint.

I see a discussion of this here:

https://forums.opensuse.org/content.php/157-Broadcom-firmware-is-neede d-> > > fo r-b43-but-I-have-no-network-an-easierwork-around

I will next try that. How it is different from the manual method described elsewhere in the openSUSE wiki is unclear. Are there different versions of the firmware, and perhaps I am using the wrong RPM?

I found a little more background on your problem. That message about dual cores was submitted as commit 8f15e28703d1 ("b43: ssb: refuse to support more than one IEEE 802.11 core").

The above patch was applied to kernel 3.16. You stated that you had not used your device for some time. Obviously, previous use was with kernel 3.15 or older. Driver b43 never supported the 5G band in any of the devices. Some, including yours, were dual band with a separate 802.11 core for each band. Handling them was tricky, thus the rejection of any such devices.

I have Cc'd the author of that patch to see if he can think of a way to get your device working. Reverting that patch would restore the old behavior, but that would probably affect a lot more users.

Larry

This seems to be some regression introduced between last Leap 42.2 kernel and current 42.3 kernel.

The 42.2 kernel was 4.4.74-18.20, currently installed kernel is 4.4.85-22.

The regression happens with two different Dell-branded Broadcom wireless cards, the 4322 is from November 2009, the 4312 from March 2010:

b43-phy0: Broadcom 4312 WLAN found (core revision 15) b43-phy0: Found PHY: Analog 6, Type 5 (LP), Revision 1 b43-phy0: Found Radio: Manuf 0x17F, ID 0x2062, Revision 2, Version 0 Broadcom 43xx driver loaded [ Features: PNLS ]

b43-phy0: Broadcom 4322 WLAN found (core revision 16) b43-phy0: Found PHY: Analog 8, Type 4 (N), Revision 4 b43-phy0: Found Radio: Manuf 0x17F, ID 0x2056, Revision 3, Version 0 Broadcom 43xx driver loaded [ Features: PNLS ]

So although the "Dual-core not supported" message is from kernel 3.16, there seems to be something else that causes this regression.

Kind regards,

Stefan

I'm getting the "Dual-core devices are not supported" error when trying to reinsert the b43 module after the firmware load in initrd failed. The error message "probe of ssb0:0 failed with error -524" is also logged by the same module.

Removing the ssb_hcd and ssb modules (with rmmod) before reinserting b43 (with modprobe) resolved the issue for me.

Mikel

Thanks, its working again now! To force dracut to include *all* required fwfiles for the b43 (not only the ones explicitly listed by b43.ko), I added the following: $> cat /etc/dracut.conf.d/b43_fwfiles.conf install_items+="/lib/firmware/b43/*init*" This adds the lp0inivals* resp. n0initvals* files to the initrd. As all the initvals are just ~20kByte (compressed), maybe its a good idea to add this to the default install, or at least to the b43-fwcutter package. Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Cristian Rodríguez

7 Aug 7 Aug

02:53

El 06-08-2017 a las 15:47, Larry Finger escribió: I suspect a udev problem; however, TW and 42.3 appear to be

...

using the same revision for udev. Can anyone tell me to whom the bug should be reassigned?

HI Larry, No, udev is no longer in the firmware loading business.. the code that used to load firmware is just not there anymore so it cannot be messing up stuff. Cheers. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

2428

Age (days ago)

2462

Last active (days ago)

List overview

Download

31 comments

9 participants

participants (9)

Andrei Borzenkov
Cristian Rodríguez
Larry Finger
Malcolm
Mikel Rychliski
Roger Oberholtzer
Roman Bysh
Stefan Bruens
Takashi Iwai