> pnp 00:0d: mem resource (0xfed00000-0xfed000ff) overlaps 0000:00:14.0
> BAR 1 (0xfed00000-0xfed003ff), disabling
> request_resource: root: (PCI IO) [0, ffff], new: (0000:00:14.0) [fa00,
> fa0f] conflict 0
> request_resource: root: (PCI mem) [0, ffffffffffffffff], new:
> (0000:00:14.0) [fed00000, fed003ff] conflict 1
> pci 0000:00:14.0: BAR 1: can't allocate resource
> piix4_smbus 0000:00:14.0: SMBus Host Controller at 0xfa00, revision 0
>
>
> because (0000:00:14.0) [fed00000, fed003ff] conflicts to (reserved)
> [fec00000, ffffffff] from e820.
[...]
> so old kernel lapic 0xfee0000, is insert at first, it will prevent
> 0xfec, ... 0xfffffff from e820 to be registered,
> then (0000:00:14.0) [fed00000, fed003ff] got chance to be
> registered..., timer will work...
>
>
> root cause could be the chipset BAR1
> request_resource: root: (PCI mem) [0, ffffffffffffffff], new:
> (0000:00:14.0) [fed00000, fed003ff] conflict 1
> is not handled properly...
>
> guess when it can not get request_resource, it could clear that
> BAR1...may need one quirk to save that.
> just like we trust IO APIC addr in BAR for some devices.
Ahh, thank you for reviewing that with me. It looks like you are
getting very close to a fix.
FYI, I have asked the other user who first reported a similar problem
(back in May) to try booting his kernel with "hpet=disable" and
report his results here. We cannot be sure that his problem is
identical to mine, but I believe he has been compiling his own
kernels since May by manually reverting commit number 3def3d6d.
I'm hoping that he will be able to help us test patches which attempt
to fix the problem, but my understanding is that he is using the
machine quite heavily... so he may not be willing to do as much
testing as I.
I do know that his kernel hangs at a different point in the kernel
sources: mine hangs before inet_init() returns, while his hangs
in ide_scan_pcibus() [or pci_init(), if he tried to add printk's
to the previous function, trying to get more info].
I'm hoping that the changes in 3def3d6d aren't going to force the
kernel team to create a different quirk for each motherboard that
experiences kernel hangs! Once 2.6.26, there is some possibility
that you will start seeing a lot more reports of it. (I'm hoping
not, though.)
Thanks,
Dave W.