Bug #2091

wpi causes kernel crash

Added by gbe about 3 years ago. Updated 7 months ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

I'm running DragonFly-Current (2.10.1) x86_64 here and the wpi driver causes a
kernel crash. After loading if_wpi.ko, everything appears to be fine, but when I
do `ifconfig wpi0 up`, the screen fills with a few lines of garbage (yes, really
garbage, looks like random memory contents) and I'm dropped into the debugger.
The bug seems to be reproducible.

I'll boot the machine later today and trigger the bug again. I'll attach the
dmesg and a photo of the screen content then.

FWIW, I installed wpi-firmware2 (haven't yet tested with wpi-firmware) using
pkg_radd without modifying any settings (the installation is a fresh one done on
a USB stick).


Related issues

Duplicates Bug #2473: Kernel crash when trying to up the wpi0 device (Dfly v3.3... New 12/14/2012

History

#1 Updated by gbe about 3 years ago

Pardon me, I made an error, of course it's DragonFly-RELEASE. I haven't yet tried
a snapshot.

#2 Updated by swildner about 3 years ago

On Tue, 21 Jun 2011 15:04:39 +0200, gbe (via DragonFly issue tracker)
<> wrote:

>
> New submission from gbe <>:
>
> I'm running DragonFly-Current (2.10.1) x86_64 here and the wpi driver
> causes a
> kernel crash. After loading if_wpi.ko, everything appears to be fine,
> but when I
> do `ifconfig wpi0 up`, the screen fills with a few lines of garbage
> (yes, really
> garbage, looks like random memory contents) and I'm dropped into the
> debugger.
> The bug seems to be reproducible.

The garbage is from our ddb traces being occasionally trashy.

Can you, next time, do a "call dumpsys" at the db> prompt next time you
have the panic?

After it wrote the core (numbers counting down and you're back to the db>
prompt), reboot and you'll find some files in /var/crash (vmcore.xy,
kern.xy, etc.).

Can you please put up these files somewhere (as a tar.bz2 or so)?

>
> I'll boot the machine later today and trigger the bug again. I'll attach
> the
> dmesg and a photo of the screen content then.

Yeah, dmesg is useful too, make sure it's a verbose boot (select 'v' from
the loader menu).

> FWIW, I installed wpi-firmware2 (haven't yet tested with wpi-firmware)
> using
> pkg_radd without modifying any settings (the installation is a fresh one
> done on
> a USB stick).

You should not need this, since our wpi(4) comes with its own firmware
(the wpifw.ko module) that should be automatically loaded when you load
if_wip.ko.

Can you also do the following things:

* Uninstall the pkgsrc firmware.

* When you kldload if_wpi.ko, watch the console for any messages about the
firmware. It might be that wpi's firmware is one where you have to agree
to some license terms by setting a tunable. Check if there are any
messages telling you something along these lines.

Of course it still shouldn't crash, even if that last thing applies to wpi
and you didn't set the tunable.

Regards,
Sascha

#3 Updated by gbe about 3 years ago

Sorry for taking so long to respond, but for the life of me I couldn't get the
kernel do dump a core. After calling dumpsys, the only number that is displayed
is a zero and /var/crash is empty after I reboot. Is there some sort of debug
options (kind of like a kernels ulimit -c unlimited) I have to turn on in order
to activate core dumps?

I also had a look over the kernel messages after a verbose boot and kldload
if_wpi.ko, but neither with nor without wpi-firmware2 I was asked to accept a
license.

#4 Updated by swildner about 3 years ago

Ok,

is dumpdev properly set in /etc/rc.conf?

#5 Updated by swildner 7 months ago

  • Duplicates Bug #2473: Kernel crash when trying to up the wpi0 device (Dfly v3.3.0.758.g47388-DEVELOPMENT) added

#6 Updated by swildner 7 months ago

  • Description updated (diff)
  • Status changed from New to Closed
  • Assignee deleted (0)

Closing this one, please see my comment in the similar/identical #2473.

Also available in: Atom PDF