Re: kernel crashes because crypto unloading?

[dieter roelants <dieter.NetBSD%pandora.be@localhost>]

On Sun, 19 Jan 2014 08:18:19 -0800 (PST)
Paul Goyette <paul%whooppee.com@localhost> 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  |
> -------------------------------------------------------------------------