search for: uncacheable

On Mon, Sep 3, 2018 at 8:12 PM, Mika Westerberg <mika.westerberg at linux.intel.com> wrote: > We have seen one similar issue with LPSS devices when BIOS assigns > device BARs above 4G (which is not the case here) and it turned out to > be misconfigured MTRR register or something like that. It may not be > related at all but it could be worth a try to dump out MTRR registers of

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:

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

First the following errors are logged in dmesg: [ 31.891848] mtrr: base(0xc0000000) is not aligned on a size(0xff00000) boundary [ 32.343580] Xorg:3090 conflicting memory types c0000000-cff00000 uncached<->uncached-minus [ 32.343585] reserve_memtype failed 0xc0000000-0xcff00000, track uncached, req write-back [ 32.344431] Xorg:3090 conflicting memory types fd000000-fe000000

I just noticed these messages in my logs : modprobe:1998 conflicting memory types e8000000-e8010000 uncached-minus<->write-combining reserve_memtype failed 0xe8000000-0xe8010000, track uncached-minus, req uncached-minus ioremap reserve_memtype failed -16 Xorg:5078 conflicting memory types e8000000-e8010000 uncached-minus<->write-combining reserve_memtype failed 0xe8000000-0xe8010000,

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

I need your help and DEL's tech support doesn't provide any help on this one. We have a lot of different type of DELL desktops from old-type hyper-thread cpu, to dual-core and quad-core cpus (most are Xeons). We run all versions of CentOS, but most are latest 5.5 (also up-to-date) and are very happy about that. The primary software on those Linux systems is IDL, which uses OpenGL

On Mon, Jun 20, 2016 at 10:01 AM, Anton Korobeynikov via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > P.S.: On a similar note, are there any news regarding llvm.org/apt? > We are working on it. Note, however, that it seems that the majority > of bogus load seemed to come from CI systems, which pulled apt repo > for every and each downstream commit without any caching /

Hi Konrad, Sometime ago i reported this one at boot up: [ 3009.778974] mcelog:16842 map pfn expected mapping type write-back for [mem 0x0009f000-0x000a0fff], got uncached-minus [ 3009.788570] ------------[ cut here ]------------ [ 3009.798175] WARNING: at arch/x86/mm/pat.c:774 untrack_pfn+0xa1/0xb0() [ 3009.807966] Hardware name: MS-7640 [ 3009.817677] Modules linked in: [ 3009.827524] Pid:

I am inserting rows into a MS SQL Server table from a Rails 2.0 application. However, when ActiveRecord issues a "SELECT @@IDENTITY AS Ident" after each insert, it only ever returns the values of the initial SELECT. (The log shows it''s hitting cache.) Is this the proper way to disable caching for these inserts? files.each do |f|

Vielen Dank f?r Ihre Email! Ich bin heute leider nicht im B?ro, erhalte Ihre Email aber trotzdem. In dringenden F?llen k?nnen Sie mich auch per Handy erreichen: 0177-7372923. Mit freundlichen Gr??en aus Sarstedt Hauke Hagedorn -- Hagedorn Internet- & Veranstaltungsdienstleistungen Wenderter Str. 37d 31157 Sarstedt Ust-Id DE 256037115 Tel: +49 5066 917 339 1 Fax: +49 5066 917 339 9

On Sun, Jun 03, 2012 at 05:31:32PM +1000, aorchis@gmail.com wrote: > Hi Jeremy and Konrad, CC-ing xen-devel. > > Basically the driver NVIDIA provided is a binary blob and recent > versions does not work with the PAT layout of XEN so it falls back to > MTRR to provide write combining (please correct me if I''m wrong). OK? Which is still OK. Are you using a v3.4 kernel

a "masteruser" login fails: Oct 8 15:12:54 postamt dovecot: auth: Debug: auth(masteruser,141.42.206.38,master): Master user lookup for login: nonworkinguser Oct 8 15:12:54 postamt dovecot: auth: passdb(masteruser,141.42.206.38,master): Master user logging in as nonworkinguser Oct 8 15:12:54 postamt dovecot: auth: Debug: cache(nonworkinguser,141.42.206.38): expired Oct 8 15:12:54

If the fence context has notifies enabled, each of the fences' FENCE_FLAG_SIGNALED_BIT will be updated from the interrupt. We can rely on this status for reporting the current fence_is_signaled() and so avoid an expensive uncached read. Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk> Cc: Ben Skeggs <bskeggs at redhat.com> Cc: dri-devel at lists.freedesktop.org Cc:

After fresh installation of CentOS 6.2 on my server, I get following errors in my dmesg output: ------- MTRR default type: uncachable MTRR fixed ranges enabled: 00000-9FFFF write-back A0000-BFFFF uncachable C0000-D7FFF write-protect D8000-E7FFF uncachable E8000-FFFFF write-protect MTRR variable ranges enabled: 0 base 000000000 mask C00000000 write-back 1 base 400000000 mask

On 05/23/2014 06:24 PM, Lucas Stach wrote: > Am Freitag, den 23.05.2014, 16:10 +0900 schrieb Alexandre Courbot: >> On Mon, May 19, 2014 at 7:16 PM, Lucas Stach <l.stach at pengutronix.de> wrote: >>> Am Montag, den 19.05.2014, 19:06 +0900 schrieb Alexandre Courbot: >>>> On 05/19/2014 06:57 PM, Lucas Stach wrote: >>>>> Am Montag, den 19.05.2014,

On Mon, May 19, 2014 at 7:16 PM, Lucas Stach <l.stach at pengutronix.de> wrote: > Am Montag, den 19.05.2014, 19:06 +0900 schrieb Alexandre Courbot: >> On 05/19/2014 06:57 PM, Lucas Stach wrote: >> > Am Montag, den 19.05.2014, 18:46 +0900 schrieb Alexandre Courbot: >> >> This patch is not meant to be merged, but rather to try and understand >> >> why

On 05/19/2014 06:57 PM, Lucas Stach wrote: > Am Montag, den 19.05.2014, 18:46 +0900 schrieb Alexandre Courbot: >> This patch is not meant to be merged, but rather to try and understand >> why this is needed and what a more suitable solution could be. >> >> Allowing BOs to be write-cached results in the following happening when >> trying to run any program on

Hello list, scrambling different pieces of info together I've come with the following : I want to have my "register =>" statements in a MySQL-database, so I've made the following table. table ast_config : id 1 cat_metric 0 var_metric 0 commented 0 filename sip.conf category general var_name register var_val username:password at sip.provider.net In ext_config

Good Day All, Today I looked at the dmesg log and I notice that the following messages regarding mtrr_gran_size/mtrr_chunk_size. I am currently running CentOS 6.3 and I installed CentOS 6.2 and 6.1 and I was seeing the same errors. When I installed CentOS 5.8 on the same laptop I do not see these errors. $ lsb_release -a LSB Version: