Re: kernel crashes because crypto unloading?

[Paul Goyette <paul%whooppee.com@localhost>]

I guess you are not using a GENERIC kernel?  The GENERIC kernel should 
have the crypto module (and all of its dependencies) built-in.

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.

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.

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  |
-------------------------------------------------------------------------