>>> 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 > 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]
