Am 14.05.2007 um 00:21 schrieb Kris Kennaway: > On Mon, May 14, 2007 at 12:17:28AM +0200, Stefan Bethke wrote: >> >> Am 13.05.2007 um 21:45 schrieb Attilio Rao: >> >>> 2007/5/11, Stefan Bethke <stb_at_lassitu.de>: >>>> >>>> Am 11.05.2007 um 22:33 schrieb Andre Oppermann: >>>> >>>>> Stefan Bethke wrote: >>>>>> Got this reproducable panic on AMD64 on a couple of days old - >>>>>> current when I try to copy a file off a ZFS dataset via >>>>>> netatalk's afpd (via TCP, no actual AppleTalk involved). >>>>> >>>>> This is a recursive leak of the INP_INFO_LOCK() you've hit here. >>>>> We don't >>>>> know yet where it gets leaked but we're working on it. >>>> >>>> Hhm. I can trigger it very easily. I don't have a serial >>>> console on >>>> this box, but I could try a few things in a debugger if anyone >>>> wants >>>> me to look at anything in particular. >>> >>> Hello Stefan, >>> can you please recompile your kernel with INVARIANTS, DDB and KTR >>> support? >>> >>> Just add those lines: >>> options INVARIANTS >>> options INVARIANT_SUPPORT >>> options KDB >>> options DDB >>> options KTR >>> options KTR_COMPILE=(KTR_LOCK) >>> options KTR_ENTRIES=65534 >>> >>> and possibly remove kbdmux from your config file (not sure if it has >>> still problems with our syscons, though). >>> >>> Then, when you hit that panic you should just be redirected to ddb. >>> At that point please write 'show ktr' in the ddb prompt and report >>> what it shows. >> >> Left kbdmux in for the moment. Hit the panic, and show ktr shows >> nothings: >> >> db> show ktr >> --- End of trace buffer --- >> db> >> >> If you think it's useful, I can remove kdbmux as well and try again. > > You also need KTR_MASK=(KTR_LOCK) (or set debug.ktr.mask at runtime), > this filters the events that are logged. Nothing still. -- Stefan Bethke <stb_at_lassitu.de> Fon +49 170 346 0140Received on Sun May 13 2007 - 20:55:44 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:10 UTC