On Sun, 19 Jan 2014 08:18:19 -0800 (PST) Paul Goyette <[email protected]> wrote:
> I guess you are not using a GENERIC kernel? The GENERIC kernel should > have the crypto module (and all of its dependencies) built-in. You're right, and I shuold have mentioned that. > In any case, the fact that you're backtrace shows you came from > module_thread() indicates that the crypto module had been automatically > loaded (presumably as a result of an attempt to open /dev/crypto) and > the 10-second auto-unload timer has expired. Yeah, I guess something in my x session will use openssl or so. > I would have expected config_cfdata_detach() to fail (with EBUSY) if the > device was still open by someone. So I'm not sure who/what still owns > allocations from the module's memory pool. > > In any case, please set 'sysctl -w kern.module.verbose=1' and re-run > your tests so we can see all of the module load/unload activity. I will, once my build finishes... (My machine isn't as fast as yours. :) kind regards dieter > > On Sun, 19 Jan 2014, dieter roelants wrote: > > > > > Hi all, and I think Paul in particular ;) > > > > After updating my kernel to current -current yesterday, I had 3 crashes > > while compiling userland. I have no info about the first crash, but ran > > my system with serial console afterwards, so I have cores and > > backtraces of the next 2. Anyway, they seemed kinda random to me, so > > today I built the same kernel config with DEBUG and DIAGNOSTIC enabled. > > > > Now the kernel cleanly panics (instead of uvm faults) with the message > > "pool_destroy: pool busy: still out: 2" a few seconds after starting X > > (reproducable). The backtrace looks like this: > > > > breakpoint() at breakpoint+0x5 > > vpanic() at vpanic+0x136 > > printf_nolog() at printf_nolog > > pool_destroy() at pool_destroy+0x363 > > crypto_detach() at crypto_detach+0x10 > > config_detach() at config_detach+0xda > > config_cfdata_detach() at config_cfdata_detach+0xd9 > > crypto_modcmd() at crypto_modcmd+0x55 > > module_do_unload() at module_do_unload+0x7c > > module_thread() at module_thread+0xfc > > > > Looking at yesterdays' kernel messages; I noticed that they contain > > "crypto0: detached" about 12 seconds after starting X (which I can tell > > from the (radeon)drm messages), which is probably odd because it never > > attached in the first place (or at least there's no trace of it in the > > logging). > > > > The workaround I'm using so far successfully, is to modload crypto > > manually before starting X. > > > > Anyway, I'll send a PR for this soonish, unless a fix is committed > > earlier. :) > > > > kind reagrds > > dieter > > > > !DSPAM:52dbf644199161306698748! > > > > > > ------------------------------------------------------------------------- > | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | > | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | > | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | > | Kernel Developer | | pgoyette at netbsd.org | > -------------------------------------------------------------------------
