DragonFlyBSD

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

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

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.

Ok,

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