search for: uncache

...e01d5000-0xe01dd000 write-combining @ 0xe01dd000-0xe01e5000 write-combining @ 0xe01e5000-0xe01ed000 write-combining @ 0xe01ed000-0xe01f5000 write-combining @ 0xe01f5000-0xe01fd000 write-combining @ 0xe01fd000-0xe0205000 write-combining @ 0xe0205000-0xe020d000 write-combining @ 0xe020d000-0xe0215000 uncached-minus @ 0xed000000-0xed200000 write-combining @ 0xed800000-0xee000000 uncached-minus @ 0xee000000-0xef000000 uncached-minus @ 0xef200000-0xef400000 uncached-minus @ 0xef400000-0xef401000 uncached-minus @ 0xef404000-0xef405000 uncached-minus @ 0xef510000-0xef520000 uncached-minus @ 0xef528000-0xef5...

...@ 0xe01dd000-0xe01e5000 > write-combining @ 0xe01e5000-0xe01ed000 > write-combining @ 0xe01ed000-0xe01f5000 > write-combining @ 0xe01f5000-0xe01fd000 > write-combining @ 0xe01fd000-0xe0205000 > write-combining @ 0xe0205000-0xe020d000 > write-combining @ 0xe020d000-0xe0215000 > uncached-minus @ 0xed000000-0xed200000 > write-combining @ 0xed800000-0xee000000 > uncached-minus @ 0xee000000-0xef000000 > uncached-minus @ 0xef200000-0xef400000 > uncached-minus @ 0xef400000-0xef401000 > uncached-minus @ 0xef404000-0xef405000 > uncached-minus @ 0xef510000-0xef520000 &gt...

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 uncached<->uncached-minus [ 32.344434] reserve_memtype failed 0xfd000000-0xfe000000, track uncached, req wr...

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, track un...

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

...come from CI systems, which pulled apt repo > for every and each downstream commit without any caching / checking > whether the mainline changed. We would certainly try to limit such > behavior if / when new APT mirror will be established. > I believe many projects have now switched to uncached downloads from llvm.org/releases (Boost.Hana also does this uncached atm.). Caching on e.g. Travis and CircleCI is not easily available for APT repositories; I think that's why noone bothered. For simple file downloads it is much easier, so perhaps a little explaining text can be added to the...

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: 16842, comm: mcelog Tainted: G W 3.7.0-rc5-20121116-reverted-pers...

...tiveRecord 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| ActiveRecord::Base.connection.uncached do self.items.create!(:file => f) unless f.blank? end end --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-t...

...ystem_groups_user=workinguser^Iuid=47077^Igid=100^Ihome=/home/d/w/workinguser^Imaster_user=masteruser > Oct 8 13:44:32 postamt dovecot: imap-login: Login: user=<workinguser>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=28224, secured > > So why does the masteruser login for an UNCACHED user fail? Right now I'm having a hard time migrating my users because the masteruser login fails. Anybody? -- Ralf Hildebrandt Gesch?ftsbereich IT | Abteilung Netzwerk Charit? - Universit?tsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450...

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

...Iworkinguser^Isystem_groups_user=workinguser^Iuid=47077^Igid=100^Ihome=/home/d/w/workinguser^Imaster_user=masteruser Oct 8 13:44:32 postamt dovecot: imap-login: Login: user=<workinguser>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=28224, secured So why does the masteruser login for an UNCACHED user fail? auth_debug = yes auth_debug_passwords = yes auth_mechanisms = plain login disable_plaintext_auth = no auth_master_user_separator = * # fuer user*masteruser logins passdb { args = /usr/dovecot-2/etc/dovecot/dovecot.masteruser driver = passwd-file master = yes pass = yes } # A...

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: nouveau at lists.freedesktop.org --- drivers/gpu/drm/nouveau/nouveau_fence.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git...

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

...>>>>>> The offending nouveau_bo_rd32 is done over an IO-mapped BO, e.g. a BO >>>>>> mapped through the BAR. >>>>>> >>>>> Um wait, this memory is behind an already mapped bar? I think ioremap on >>>>> ARM defaults to uncached mappings, so if you want to access the memory >>>>> behind this bar as WC you need to map the BAR as a whole as WC by using >>>>> ioremap_wc. >>>> >>>> Tried mapping the BAR using ioremap_wc(), but to no avail. On the other >>>> han...

...syscall+0x0/0x30 >> >> >> >> The offending nouveau_bo_rd32 is done over an IO-mapped BO, e.g. a BO >> >> mapped through the BAR. >> >> >> > Um wait, this memory is behind an already mapped bar? I think ioremap on >> > ARM defaults to uncached mappings, so if you want to access the memory >> > behind this bar as WC you need to map the BAR as a whole as WC by using >> > ioremap_wc. >> >> Tried mapping the BAR using ioremap_wc(), but to no avail. On the other >> hand, could it be that VRAM BOs end up cr...

...gt;> (SyS_ioctl) from [<c000e6e0>] (ret_fast_syscall+0x0/0x30 >> >> The offending nouveau_bo_rd32 is done over an IO-mapped BO, e.g. a BO >> mapped through the BAR. >> > Um wait, this memory is behind an already mapped bar? I think ioremap on > ARM defaults to uncached mappings, so if you want to access the memory > behind this bar as WC you need to map the BAR as a whole as WC by using > ioremap_wc. Tried mapping the BAR using ioremap_wc(), but to no avail. On the other hand, could it be that VRAM BOs end up creating a mapping over an already-mapped re...

...s? (yes|no) After a reload I noticed that the registration came through when I executed "sip show registrations". This realtime works. But I then get a lot of the following messages : / [Aug 2 20:05:05] WARNING[29850]: chan_sip.c:18187 build_peer: Qualify is incompatible with dynamic uncached realtime. Please either turn rtcachefriends on or turn qualify off on peer 'user2' [Aug 2 20:05:05] WARNING[29850]: chan_sip.c:18187 build_peer: Qualify is incompatible with dynamic uncached realtime. Please either turn rtcachefriends on or turn qualify off on peer 'user2'/...

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: