Bug 7730
| Summary: | intel-rng does not work when built into the kernel not as a module | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Ominousfate |
| Component: | Other | Assignee: | Michael Buesch (mb) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | low | CC: | jbeulich, mb |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.19 (and 2.6.18-gentoo-r4) | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
| Attachments: |
output for "lspci -n"
dmesg output when intel-rng is built-in dmesg output when intel-rng is a module |
||
|
Description
Ominousfate
2006-12-21 22:02:39 UTC
I cannot reproduce this. Could you check boot.msg for RNG related messages, or possibly attach it here? Could you please also clarify whether the 2.6.18-* kernel you're referring to is plain 2.6.18 based, or which of the 2.6.18.x ones it is based on? Finally (and just to be sure), could you please also attach lspci -n output? Created attachment 9940 [details]
output for "lspci -n"
Created attachment 9941 [details]
dmesg output when intel-rng is built-in
Unmodified 2.6.18.1 from kernel.org.
Created attachment 9942 [details]
dmesg output when intel-rng is a module
Unmodified 2.6.18.1 kernel from kernel.org
Also when trying to recreate the bug by having the module built-in; if you have intel-rng.ko sitting in /lib/modules/$kernel-version from a previous kernel compile where it was set as a module and you did "make modules_install", be sure it is not loading. Probably a clearer way to explain how I recreated the bug: Delete /lib/modules/$kernel-version. Then configure your kernel so that intel-rng is built-in. Then do make and make modules_install to recreate the /lib/modules/$kernel-version tree (intel-rng.ko should not be in the tree). Copy System.map and bzImage to /boot and update the bootloader and reboot. This must then be a result of the splitting of hw_random, although I can't yet see why. Michael, do you have any idea? Originator (no clue what your name is), can you perhaps add a printk to the top of drivers/char/hw_random/intel-rng.c:mod_init(), so we know whether this routine is being called at all. Also, am I right in assuming that the sole difference between the two kernels you posted the messages for is the CONFIG_HW_RANDOM_INTEL setting? I think we shouldn't be using subsys_initcall(). Can you change it to module_init() and try again? I don't remember why we did subsys_initcall() in the first place. I think every RNG driver should use module_init(). This really seems to be a bug in every RNG driver. I added a printk message at the top of the mod_init() function and compiled with
the module as built in. The message displayed on boot up so mod_init() is being
called.
Not sure if this helps but I also tried changing this:
if (!pci_dev_present(pci_tbl))
goto out; /* Device not found. */
to this
if (!pci_dev_present(pci_tbl))
{
printk("*** !pci_dev_present(pci_tbl) evaluated true ***\n");
goto out; /* Device not found. */
}
to see if pci_dev_present(pci_tbl) evaluates to false and indeed it did as I saw
the inserted printk message on bootup.
Also the 2 dmesg outputs I attached are from the same exact kernel sources,
2.6.18.1, (consecutive compiles actually as the uname info at the top show #1
and #2, first with built in and then as a module)so yes the only difference is
the CONFIG_HW_RANDOM_INTEL setting.
*Michael's suggestion fixes the problem.
By replacing this at the bottom of intel-rng.c:
subsys_initcall(mod_init);
with this
module_init(mod_init);
the device is detected and works when it is also built in. Also I tested it as
a module just in case and it still works as a module.
I will do a patch and submit it upstream. Huh, and I was getting ready to submit a patch to make the OMAP RNG use subsys_initcall, along with other fixes. Obviously, that RNG does not have PCI-derived constraints. Agreed that PCI init sequence requirements must be obeyed, but not that doing such late initialization is preferred. In the general case, drivers and subsystems may need to access RNG functionality themselves, so doing that init as early as practical is safest ... ensuring that randomness is there. No you are wrong. Nobody can use the _hardware_ RNG before userspace is up and rngd it running. And that is damn late... |