On Thu, 2010-11-04 at 22:52 +0100, Didier Raboud wrote:
> Package: firmware-brcm80211

What has this got to do with the firmware?

> Version: 0.27
> Severity: critical
> Tags: patch
> Justification: breaks the whole system

No it doesn't.

> Hi,
>
> Booting the "HP Mini 5103" with the firmware-brcm80211 package installed leads
> to a 100% reproducible Kernel Panic. (Squeeze's 2.6.32 and experimental
> 2.6.36-trunk are affected).
>
> >From the http://linuxwireless.org/en/users/Drivers/brcm80211 homepage, the fix
> is to load the module with maxcpus=1.
>
> So a simple patch would be to ship a /etc/modprobe.d/brcm80211.conf containing
>
> options brcm80211 maxcpus=1

Why would we provide a modprobe file when we can change default module
parameters directly? And how would this work when multiple kernel image
packages are installed?

> I tested that here and it works.
[...]

That's odd because this module doesn't have such an option. 'maxcpus=1'
is a kernel command-line parameter, and strangely enough we do not want
to use it.

Ben.

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

tags 602444 -patch
thanks

Hi Ben, and thanks for your answer,

Le jeudi 4 novembre 2010 23:37:48 Ben Hutchings, vous avez écrit :
> On Thu, 2010-11-04 at 22:52 +0100, Didier Raboud wrote:
> > Package: firmware-brcm80211
>
> What has this got to do with the firmware?

The observable facts I could get is that:

* the boot completes when the package is not installed
* the boot stop with a Kernel Panic (or an Oops, I could not see exactly) when
the package is installed.

I don't know the details of how it works internally, so I directed my suspicion
against the firmware-* package. Thanks to you and Julien for the re-assigning.

> > Justification: breaks the whole system
>
> No it doesn't.

I don't intend to play severity ping-pong, but "Impossible to boot, Kernel Panic
at each boot" doesn't sound below RC to me.

> > I tested that here and it works.
>
> [...]
>
> That's odd because this module doesn't have such an option. 'maxcpus=1'
> is a kernel command-line parameter, and strangely enough we do not want
> to use it.

Yeah, I completely overlooked that; sorry. My approach was plain wrong.

Now I conducted a more precise investigation, _with_ the firmware-brcm80211
package installed. I booted in "single" mode, hence getting a root console. No
problem so far; the module is loaded. Running "iwlist scan" from that "single"
root console leads to 100% reproducible oops.

So my guess is that Network-Manager uses the driver, eventually triggering a
scan and then kernel oopses at that moment, leading to a non-completed boot.
Would you need more information ? Of what sort ?

For now, I uninstalled the firmware package and will try with the broadcom-sta
stack, unfortunately from non-free.

Cheers,

OdyX

--
Didier Raboud, proud Debian Maintainer (DM).
CH-1020 Renens
didier@raboud.com

On Fri, 2010-11-05 at 10:23 +0100, Didier 'OdyX' Raboud wrote:
> tags 602444 -patch
> thanks
>
> Hi Ben, and thanks for your answer,
>
> Le jeudi 4 novembre 2010 23:37:48 Ben Hutchings, vous avez écrit :
> > On Thu, 2010-11-04 at 22:52 +0100, Didier Raboud wrote:
> > > Package: firmware-brcm80211
> >
> > What has this got to do with the firmware?
>
> The observable facts I could get is that:
>
> * the boot completes when the package is not installed

True, but only because the driver fails to initialise.

[...]
> So my guess is that Network-Manager uses the driver, eventually triggering a
> scan and then kernel oopses at that moment, leading to a non-completed boot.
> Would you need more information ? Of what sort ?
[...]

Please use a serial console or netconsole to provide the 'oops' message.

There have been a huge number of cleanups and other fixes to this driver
since the initial release into staging, which I'll apply to our package.
I hope these will fix this bug.

Ben.

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.