[ndis] "panic: IRQL_NOT_GREATER_THAN" - triggered by heavy wlan0 activity

From: Glen Barber <gjb_at_FreeBSD.org>
Date: Fri, 25 Nov 2011 00:08:49 -0500
Hi,

I'm running 9-STABLE on a MacBook Pro (late 2009, I think):

schism % uname -a
FreeBSD schism 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #7 r227746:
  Thu Nov 24 13:05:31 EST 2011 gjb_at_kaos:/usr/obj/usr/src/sys/MACBOOK
  amd64

The integrated wireless chipset is a Broadcom bcm4322, which is
currently not supported by bwi(4) or bwm(4), however ndisgen(8) with
Windows XP 64-bit drivers gets the card in an operational state.

There are just a few oddities:

1.)  If I load the driver (bcmwl564_sys) with loader.conf, the machine
crashes partway through booting, sometime before invoking rc(8).  I
can't tell where specifically this happens, because the machine
completely resets whent his happens.

2.)  If the machine boots without the driver automatically loaded
between sometime rc(8) invocation and a login prompt, the ndis(4) wlan0
interface never gets assigned an IP (automatically, or by dhclient(8)
manually).  Calling kldload(8) from rc.conf.local seems to mostly solve
this, but I have seen occasional panics if the wlan0 device does not
obtain a DHCP lease within a, as of now, indeterminite amount of time.

3.)  This is the one I can actually give a whole bunch of information.
Under heavy network load, the machine panics.  vmcore, KERNCONF, and
dmesg are all attached.  I've observed the heavy load panics on a few
occasions, but finally stumbled on a way to trigger it (somewhat
reproducibly, but overall irrelevant, I guess) today.

The panics in this case are from sys/compat/ndis/subr_hal.c,
specifically:

% 410 void
% 411 KfLowerIrql(uint8_t oldirql)
% 412 {
% 413         if (oldirql == DISPATCH_LEVEL)
% 414                 return;
% 415 
% 416         if (KeGetCurrentIrql() != DISPATCH_LEVEL)
% 417                 panic("IRQL_NOT_GREATER_THAN");
% 418 
% 419         mtx_unlock(&disp_lock[curthread->td_oncpu]);
% 420         sched_unpin();
% 421 }

An (admittedly quick) Google search didn't turn up anything fruitful
with that particular panic reason.  'svn annotate' on subr_hal.c shows
the following from 2004:

% kaos % svn log -r128295
% ------------------------------------------------------------------------
% r128295 | wpaul | 2004-04-15 20:04:28 -0400 (Thu, 15 Apr 2004) | 13 lines
% 
% - Use memory barrier with atomic operations in ntoskrnl_lock_dpc() and
%   ntoskrnl_unlocl_dpc().
% - hal_raise_irql(), hal_lower_irql() and hal_irql() didn't work right
%   on SMP (priority inheritance makes things... interesting). For now,
%   use only two states: DISPATCH_LEVEL (PI_REALTIME) and PASSIVE_LEVEL
%   (everything else). Tested on a dual PIII box.
%   [...]

So, at this point, I'm a bit stuck with where to go from here.  If I am
interpreting reason the panic() call was added in r128295 correctly,
this could potentially be an issue with SMP, as oldirql is not available
in the backtrace.  That is, of course, assuming it's not a problem with
the XP drivers for the wireless NIC.

Any thoughts on where to go from here would be appreciated.

Thanks.

Glen

-- 
Glen Barber | gjb_at_FreeBSD.org
FreeBSD Documentation Project


Received on Fri Nov 25 2011 - 04:08:52 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:21 UTC