With gentoo-sources 2.6.19-r3 all works fine. With the new gentoo-sources 2.6.19-r4 I get this in dmesg: PCI: Using configuration type 1 //This line is identical in both kernels pci_get_subsys() called while pci_devices is still empty pci_get_subsys() called while pci_devices is still empty pci_get_subsys() called while pci_devices is still empty pci_get_subsys() called while pci_devices is still empty pci_get_subsys() called while pci_devices is still empty pci_get_subsys() called while pci_devices is still empty pci_get_subsys() called while pci_devices is still empty pci_get_subsys() called while pci_devices is still empty pci_get_subsys() called while pci_devices is still empty ... (There are total of 32 "pci_get_subsys..." lines). Otherwise dmesg outputs are identical. I have not encountered other symptoms. Reproducible: Always Steps to Reproduce: 1.Just boot. 2. 3.
Please ignore, or remove all ide-related kernel command line arguments.
I'd hate to just ignore those ugly lines which never showed before :) I don't think I have any ide-related command line parameters. This is all I have: kernel /kernel-2.6.19-gentoo-r4 root=/dev/sdb3 So is this really INVALID?
it might be, but let's investigate and see where they come from anyway. will post a patch when I next have some time
Created attachment 108154 [details, diff] patch please apply this patch and then post new output - should include some stack dumps
Thanks for helping. Here is the output: -------------- PCI: Using configuration type 1 pci_get_subsys() called while pci_devices is still empty Call Trace: [<ffffffff802edcf5>] [<ffffffff80481e2b>] [<ffffffff8025800e>] [<ffffffff80251748>] [<ffffffff80307302>] [<ffffffff80257edc>] [<ffffffff8025173e>] ---------- All 32 instances are identical. I also wonder if the next patch in 2.6.20.rc4 is related: commit 6ae4adf50380d0fc5176a76d98d324f8fa491a8f Author: Ard van Breemen <ard@telegraafnet.nl> Date: Fri Jan 5 16:36:21 2007 -0800 [PATCH] PCI: prevent down_read when pci_devices is empty The pci_find_subsys gets called very early by obsolete ide setup parameters. This is a bogus call since pci is not initialized yet, so the list is empty. But in the mean time, interrupts get enabled by down_read. This can result in a kernel panic when the irq controller gets initialized. This patch checks if the device list is empty before taking the semaphore, and hence will not enable irq's. Furthermore it will inform that it is called while pci_devices is empty as a reminder that the ide code needs to be fixed. The pci_get_subsys can get called in the same manner, and as such is patched in the same manner.
That patch is part of the same bug fix and is related. It is also included in gentoo-sources. Please enable CONFIG_KALLSYMS so that the stack dumps are usable.
Here it is a bit more readable: Call Trace: [<ffffffff802eec90>] pci_get_subsys+0x73/0x112 [<ffffffff804b1e53>] mod_init+0x29/0x251 [<ffffffff8025802e>] init+0x142/0x2f9 [<ffffffff80251758>] child_rip+0xa/0x12 [<ffffffff803082ad>] acpi_ds_init_one_object+0x0/0x80 [<ffffffff80257eec>] init+0x0/0x2f9 [<ffffffff8025174e>] child_rip+0x0/0x12
Please attach kernel .config
Never mind, this must be the RNG drivers.
You are 100% correct. I disabled "HW_RANDOM_INTEL" and the problem is now gone. When I enabled it I missed the fact that it is related to mobo, not processor. I don't have an Intel i8xx-based mobo. Now, should the messages have shown in spite of me not having i8xx mobo or is this still a bug?
It's expected to be shown, as it was looking for any RNG devices on your system. It also is a bug in that it would not have found one even if it was present.
Ok. Many thanks for your time. I'll leave this open so you can close as you seem fit.
fixed in gentoo-sources-2.6.19-r6
