On Tue, 21 Jun 2011 15:04:39 +0200, gbe (via DragonFly issue tracker)
<sinknull@leaf.dragonflybsd.org> wrote:
New submission from gbe <gbe+dragonfly@ring0.de>:
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
Updated by 
Updated by