Well, at least it tried! ;)
request_resource: root: (PCI mem) [0, ffffffffffffffff], new: (reserved) [fec00000, ffffffff] conflict 1
I can see that the resources are not recorded in the tree properly, but
this kernel was still able to boot without hanging. Is it enough that
the memory region was already marked as busy, or do these resource
structures need to be in the tree for other purposes?
On the suggestion of Ilpo Järvinen, I tried to delay the printk's long
enough to see them using CONFIG_BOOT_PRINTK_DELAY. Unfortunately, I was
stung by what the help text for that option warns of: the
CONFIG_BOOT_PRINTK_DELAY option can cause the kernel to hang on SMP
machines.
That is exactly what happens: the kernel hangs pretty much immediately,
with only about a half dozen lines printed.
I did try my own suggestion: change KERN_DEBUG to KERN_WARNING in your patch,
and boot with "loglevel=5". This worked, and almost the only lines printed
were those from your patch. However, without the printk delay everything
just scrolled away too fast to read... until the kernel hung.
I believe I can find a workaround to print this output in a more compact way...
your formatting takes up 2 lines for each printk. However, I am busy this
morning and I have to work this afternoon. I may not be able to provide
the entire output until tonight or tomorrow.
For now, I can only report that the last lines printed were the same as
these from the working kernel's 'dmesg' output:
========
request_resource: root: (PCI IO) [0, ffff], new: (0000:00:14.1) [3f6, 3f6] conflict 0
request_resource: root: (PCI IO) [0, ffff], new: (0000:00:14.1) [170, 177] conflict 0
request_resource: root: (PCI IO) [0, ffff], new: (0000:00:14.1) [376, 376] conflict 0
request_resource: root: (PCI IO) [0, ffff], new: (0000:00:14.1) [f900, f90f] conflict 0
request_resource: root: (PCI mem) [0, ffffffffffffffff], new: (0000:00:14.2) [fe020000, fe023fff] conflict 0
request_resource: root: (PCI Bus #01) [d8000000, dfffffff], new: (0000:01:05.0) [d8000000, dfffffff] conflict 0
request_resource: root: (PCI Bus #01) [fdd00000, fdefffff], new: (0000:01:05.0) [fdee0000, fdeeffff] conflict 0
request_resource: root: (PCI Bus #01) [e000, efff], new: (0000:01:05.0) [ee00, eeff] conflict 0
request_resource: root: (PCI Bus #01) [fdd00000, fdefffff], new: (0000:01:05.0) [fdd00000, fddfffff] conflict 0
request_resource: root: (PCI Bus #01) [fdd00000, fdefffff], new: (0000:01:05.2) [fdefc000, fdefffff] conflict 0
request_resource: root: (PCI Bus #02) [d000, dfff], new: (0000:02:05.0) [de00, deff] conflict 0
request_resource: root: (PCI Bus #02) [fdc00000, fdcfffff], new: (0000:02:05.0) [fdcff000, fdcff0ff] conflict 0
========
The only differences were trivial: the "PCI Bus" strings now print in a
different format, like "PCI Bus 0000:01".
I will try to provide the entire output tonight or tomorrow. It will be
difficult, though: it looks like I have to try to fit the info from about
60 of the printk's in your patch onto the 80x25 VGA screen, and still
make it understandable enough to be useful.
BTW, in a previous message, I recursed the iomem_resource tree and printed
all of the elements that end up there. This was not sufficient, right? You
also want to see what is rejected and not stored in the tree, which your
patch's printks do show?
Thanks,
Dave W.
--
