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
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:21 UTC