On 5/11/09, Chris Whitehouse <cwhi...@onetel.com> wrote: > Paul B. Mahol wrote: >> On 5/8/09, Chris Whitehouse <cwhi...@onetel.com> wrote: >>> Paul B. Mahol wrote: >>>> On 5/7/09, Chris Whitehouse <cwhi...@onetel.com> wrote: >>>> >>>>> In the meantime I've tried the three possible drivers (XP, NT and an >>>>> unlabelled one). I've also installed a recent 8-current snapshot, >>>>> updated to latest source and built world, and tried the XP driver. >>>>> Still >>>>> get interrupt storms everywhere, also a panic (I think) in 8-current. >>>>> >>>>> Should I give up or are there other things to try? >>>> Panic should not happen. Please provide backtrace(or crashdump or >>>> textdump) >>> `fetch http://www.fishercroft.plus.com/vmcore.1.gz' should get a >>> crashdump from a non-debug kernel, see below. It's about 17mb >>> >>> I built a driver with the XP driver using ndisgen and the same source as >>> my recent build world. >>> >>> I kldload the driver module which also loads ndis.ko and if_ndis.ko. >>> >>> I've got >>> wlans_ndis0="wlan0" >>> in rc.conf and I get ndis0 and wlan0 created when I plug in the card. >>> >>> The interrupt storm starts when I do >>> >>> # ifconfig wlan0 <ip addr> >>> >>> The panic occurs maybe a minute or two after the ifconfig. >>> >>> I got a panic but I couldn't get a crashdump with the GENERIC kernel >>> (nothing relevant to dumpon or savecore happened at all, no boot >>> messages, nothing in /var/crash). >>> I did get a bunch of stuff on ttyv0, I can post a photo somewhere if >>> required. Or is there a way to get the screen output in text format? >>> >>> I built a kernel with the following changes >>> >>> #cpu I486_CPU >>> #cpu I586_CPU >>> >>> #makeoptions DEBUG=-g # Build kernel with gdb(1) debug >> >> Oh nooooo, crash dump is useless with that option commented in kernel. >> [You can alway just look at documentation installed in /usr/share/doc/, >> for example developers handbook] >> >>> symbols >>> >>> #options KDB # Enable kernel debugger support. >>> #options DDB # Support DDB. >>> #options GDB # Support remote GDB. >>> #options INVARIANTS # Enable calls of extra sanity >>> checking >>> #options INVARIANT_SUPPORT # Extra sanity checks of >>> internal structures, required by INVARIANTS >>> #options WITNESS # Enable checks to detect >>> deadlocks and cycles >>> #options WITNESS_SKIPSPIN # Don't run witness on spinlocks >>> for speed >> Both KDB, DDB, GDB, WITNESS and INVARIANTS are usefull in debugging >> kernel. >> So please uncomment all that debugging support. >> After all you can build two kernels, and use boot loader command or >> nextboot(8) >> > I tried with GENERIC and with my no-debug kernel. The panic happened > with both but there was no crashdump with the GENERIC. All other > settings were the same, eg no change to rc.conf. My setup seems to be > right according to the developers handbook section 10.1. > > Is there something special I have to do with -CURRENT to get the crashdump?
Just typing bt on db prompt for now should be enough. > >>> >>> >>> I got on ttyv0: >>> >>> interrupt storm detected on "irq11:"; throttling interrupt source >>> >>> repeated about 20 times then >>> >>> Sleeping thread (tid 100084, pid 0) owns a non-sleepable lock >> >> Heh, thats is bug, now only remains to find where it is caused. >> > I got this screendump (copied and pasted) from ttyv0 before the panic > with GENERIC. It was repeated maybe 20 times then dropped to db> prompt. > > interrupt storm detected on "irq11:"; throttling interrupt source > Waiting on "KeWFS" with the following non-sleepable locks held: > exclusive sleep mutex ndis0 (network driver) r = 0 (0xc34fd06c) locked @ > /usr/sr > c/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c:3432 > KDB: stack backtrace: > db_trace_self_wrapper(c0c40c0b,d40e3ac0,c089d245,c3888072,d68,...) at > db_trace_s > elf_wrapper+0x26 > kdb_backtrace(c3888072,d68,ffffffff,c0eca774,d40e3af8,...) at > kdb_backtrace+0x29 > > _witness_debugger(c0c42f9c,d40e3b0c,4,1,0,...) at _witness_debugger+0x25 > witness_warn(5,c38a24d0,c0c37d7c,c389ea81,d40e3b3c,...) at > witness_warn+0x1fd > _cv_timedwait(d40e3b6c,c38a24d0,1389,ffffffff,c38cafc8,...) at > _cv_timedwait+0xc > 6 > KeWaitForSingleObject(c38cafc0,0,0,0,d40e3bbc,...) at > KeWaitForSingleObject+0x1b > 0 > ndis_set_info(c34fd000,d01011a,0,d40e3bf8,c37b2524,...) at > ndis_set_info+0x1c8 > ndis_scan_start(c3a14000,0,c0c5286b,36e,80246,...) at ndis_scan_start+0xe8 > scan_task(c3a04800,1,c0c42357,54,c38c485c,...) at scan_task+0x150 > taskqueue_run(c38c4840,c38c485c,0,c0c33ff4,0,...) at taskqueue_run+0x10b > taskqueue_thread_loop(c3a14074,d40e3d38,c0c39438,333,c0d88ca0,...) at > taskqueue_ > thread_loop+0x68 > fork_exit(c08963e0,c3a14074,d40e3d38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xd40e3d70, ebp = 0 --- > interrupt storm detected on "irq11:"; throttling interrupt source Thats is something. >>> panic: sleeping thread >>> cpuid = 0 >>> Uptime:17m26s >>> Physical memory: 434 MB >>> Dumping 79 MB: 64 48 32 16 >>> Dump complete >>> >>> (The above typed by hand) >>> >>> Let me know if there is more I can do but (caveat) I'm not a developer >>> and I only put CURRENT on the machine to test if the problem had been >>> fixed, ie please don't flame me if you ask me really difficult stuff and >>> I don't understand it :) >> >> You can always ask me off list for anything that you don't understand. > thanks :) -- Paul _______________________________________________ firstname.lastname@example.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"