search for: reg00

On Tue, Sep 4, 2018 at 2:43 PM, Mika Westerberg <mika.westerberg at linux.intel.com> wrote: > Yes, can you check if the failing device BAR is included in any of the > above entries? If not then it is probably not related. mtrr again for reference: reg00: base=0x0c0000000 ( 3072MB), size= 1024MB, count=1: uncachable reg01: base=0x0a0000000 ( 2560MB), size= 512MB, count=1: uncachable reg02: base=0x090000000 ( 2304MB), size= 256MB, count=1: uncachable reg03: base=0x08c000000 ( 2240MB), size= 64MB, count=1: uncachable reg04: base=0x08b800000 ( 223...

...egister or something like that. It may not be > related at all but it could be worth a try to dump out MTRR registers of > one of the affected systems and see if the memory areas are listed there > (and if the attributes are somehow wrong if found). >From Asus X542UQ: # cat /proc/mtrr reg00: base=0x0c0000000 ( 3072MB), size= 1024MB, count=1: uncachable reg01: base=0x0a0000000 ( 2560MB), size= 512MB, count=1: uncachable reg02: base=0x090000000 ( 2304MB), size= 256MB, count=1: uncachable reg03: base=0x08c000000 ( 2240MB), size= 64MB, count=1: uncachable reg04: base=0x08b800000 ( 223...

...ew: >>>>>>>>>> write-combining >>>>>>>>>> mtrr: type mismatch for e0000000,10000000 old: uncachable new: >>>>>>>>>> write-combining when run IDL with simple draw function, got segmentation fault /proc/mtrr: reg00: base=0xdff00000 (3583MB), size= 1MB: uncachable, count=1 reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1 Then I switched another ATI RV370, the mtrr error is gone, but still got segmentation fault But 2. on T3400 with dual-core, CentOS5.5, same ATI RV370 video card and IDL 7...

On Tue, Sep 04, 2018 at 09:52:02AM +0800, Daniel Drake wrote: > # cat /proc/mtrr > reg00: base=0x0c0000000 ( 3072MB), size= 1024MB, count=1: uncachable > reg01: base=0x0a0000000 ( 2560MB), size= 512MB, count=1: uncachable > reg02: base=0x090000000 ( 2304MB), size= 256MB, count=1: uncachable > reg03: base=0x08c000000 ( 2240MB), size= 64MB, count=1: uncachable > reg04: ba...

On Sat, Sep 1, 2018 at 3:12 AM, Bjorn Helgaas <helgaas at kernel.org> wrote: > If true, this sounds like some sort of erratum, so it would be good to > get some input from Intel, and I cc'd a few Intel folks. Yes, it would be great to get their input. > It's interesting that all the systems below are from Asus. That makes > me think there's some BIOS or SMM

...: 2G num_reg: 3 lose cover RAM: 1015M Apr 11 17:25:36 kernel: gran_size: 2G chunk_size: 2G num_reg: 2 lose cover RAM: 2039M Apr 11 17:25:36 kernel: mtrr_cleanup: can not find optimal value Apr 11 17:25:36 kernel: please specify mtrr_gran_size/mtrr_chunk_size cat /proc/mtrr reg00: base=0x0d0000000 ( 3328MB), size= 256MB, count=1: uncachable reg01: base=0x0e0000000 ( 3584MB), size= 512MB, count=1: uncachable reg02: base=0x000000000 ( 0MB), size= 8192MB, count=1: write-back reg03: base=0x200000000 ( 8192MB), size= 512MB, count=1: write-back reg04: base=0x220000000 ( 870...