On Fri, Sep 23, 2011 at 7:24 AM, Jan Beulich <[email protected]> wrote: >>>> On 22.09.11 at 17:44, "Kulkarni, Shanti" <[email protected]> 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 <[email protected]> wrote: >>>>>> On 22.09.11 at 15:40, "Kulkarni, Shanti" <[email protected]> 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: [email protected] >> For additional commands, e-mail: [email protected] > > > -- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
