On Fri, Sep 23, 2011 at 7:24 AM, Jan Beulich
On 22.09.11 at 17:44, "Kulkarni, Shanti"
wrote: It works properly using the last OS 11.2 2.6.31 kernel on top of 11.4, so I opened a bug (https://bugzilla.novell.com/show_bug.cgi?id=719858). Thanks for your help. Seems like I was wrong with the assumption that this would be a problem with the native kernel too. There was a resource handling change in 2.6.37 that isn't compatible with the Xen kernel's memory handling, which precludes resource re-assignment on any system with (roughly) memory extending past the 4G boundary.
Jan
My system has 8G, so that would explain it. Thank you. I assume I'll have to remove memory or keep my kernel < 2.6.37 for the time being, but do you know if it's likely that this situation will change with the 3.0-final kernel now that Xen's been merged into it?
On Thu, Sep 22, 2011 at 9:07 AM, Jan Beulich
wrote: On 22.09.11 at 15:40, "Kulkarni, Shanti"
wrote: Here is the kernel log for the new kernel (2.6.37). You're correct that I no longer have the old kernel installed. From my limited research on the subject I think the entry "[ 0.188870] pci 0000:04:00.1: reg 10: [mem 0xfe6fec00-0xfe6fecff]" means that the offending device is not being realigned, otherwise it would start on a multiple of 0x1000. You didn't read on - the message stating that the code doing the alignment got triggered follows immediately.
[ 0.180274] pci 0000:00:14.2: [1002:4383] type 0 class 0x000403 [ 0.180296] pci 0000:00:14.2: reg 10: [mem 0xfe2f8000-0xfe2fbfff 64bit] [ 0.180341] pci 0000:00:14.2: Disabling memory decoding and releasing memory resources. [ 0.180435] pci 0000:00:14.2: PME# supported from D0 D3hot D3cold [ 0.180439] pci 0000:00:14.2: PME# disabled ... [ 0.188602] pci 0000:04:00.0: [1033:0035] type 0 class 0x000c03 [ 0.188627] pci 0000:04:00.0: reg 10: [mem 0xfe6ff000-0xfe6fffff] [ 0.188711] pci 0000:04:00.0: Disabling memory decoding and releasing memory resources. [ 0.188814] pci 0000:04:00.0: supports D1 D2 [ 0.188816] pci 0000:04:00.0: PME# supported from D0 D1 D2 D3hot [ 0.188821] pci 0000:04:00.0: PME# disabled [ 0.188844] pci 0000:04:00.1: [1033:00e0] type 0 class 0x000c03 [ 0.188870] pci 0000:04:00.1: reg 10: [mem 0xfe6fec00-0xfe6fecff] [ 0.188953] pci 0000:04:00.1: Disabling memory decoding and releasing memory resources.
(namely here)
[ 0.189038] pci 0000:04:00.1: Rounding up size of resource #0 to 0x1000.
(and here)
[ 0.189126] pci 0000:04:00.1: supports D1 D2 [ 0.189127] pci 0000:04:00.1: PME# supported from D0 D1 D2 D3hot [ 0.189132] pci 0000:04:00.1: PME# disabled [ 0.189166] pci 0000:04:01.0: [1033:00e7] type 0 class 0x000c00 [ 0.189192] pci 0000:04:01.0: reg 10: [mem 0xfe6fd000-0xfe6fdfff] [ 0.189275] pci 0000:04:01.0: Disabling memory decoding and releasing memory resources. [ 0.189393] pci 0000:04:01.0: supports D1 D2 [ 0.189394] pci 0000:04:01.0: PME# supported from D0 D1 D2 D3hot [ 0.189399] pci 0000:04:01.0: PME# disabled ...
And then:
[ 0.227832] pci 0000:00:14.2: BAR 0: can't assign mem (size 0x4000) ...
and further
[ 0.228453] pci 0000:04:00.0: BAR 0: can't assign mem (size 0x1000) [ 0.228516] pci 0000:04:00.1: BAR 0: can't assign mem (size 0x1000) [ 0.228579] pci 0000:04:01.0: BAR 0: can't assign mem (size 0x1000)
That seems to be a problem not only with the Xen kernel (just try passing the same options to the native kernel and see whether you get the same errors), and is certainly dependent on how the BIOS does its original resource assignment.
I'd suggest opening a bug (as it should minimally be able to re-use the BIOS-assigned memory ranges that already were 4k-aligned), but you should expect being asked to supply information documenting that this in fact worked on 2.6.31 (for this to be considered a regression).
Jan
-- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-virtual+help@opensuse.org
-- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-virtual+help@opensuse.org