Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752577AbdGRXQu (ORCPT ); Tue, 18 Jul 2017 19:16:50 -0400 Received: from mail-ua0-f172.google.com ([209.85.217.172]:33601 "EHLO mail-ua0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751513AbdGRXQs (ORCPT ); Tue, 18 Jul 2017 19:16:48 -0400 MIME-Version: 1.0 In-Reply-To: References: <20170718060909.5280-1-airlied@redhat.com> <20170718143404.omgxrujngj2rhiya@redhat.com> From: Dave Airlie Date: Wed, 19 Jul 2017 09:16:46 +1000 Message-ID: Subject: Re: [PATCH] efifb: allow user to disable write combined mapping. To: Linus Torvalds Cc: Peter Jones , "the arch/x86 maintainers" , Dave Airlie , Bartlomiej Zolnierkiewicz , "linux-fbdev@vger.kernel.org" , Linux Kernel Mailing List , Andrew Lutomirski , Peter Anvin Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4985 Lines: 99 On 19 July 2017 at 09:16, Dave Airlie wrote: > On 19 July 2017 at 08:22, Linus Torvalds wrote: >> On Tue, Jul 18, 2017 at 2:21 PM, Dave Airlie wrote: >>> >>> Oh and just FYI, the machine I've tested this on has an mgag200 server >>> graphics card backing the framebuffer, but with just efifb loaded. >> >> Yeah, it looks like it needs special hardware - and particularly the >> kind of garbage hardware that people only have on servers. >> >> Why do server people continually do absolute sh*t hardware? It's crap, >> crap, crap across the board outside the CPU. Nasty and bad hacky stuff >> that nobody else would touch with a ten-foot pole, and the "serious >> enterprise" people lap it up like it was ambrosia. >> >> It's not just "graphics is bad anyway since we don't care". It's all >> the things they ostensibly _do_ care about too, like the disk and the >> fabric infrastructure. Buggy nasty crud. > > I've tried to reproduce now on: > Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz > using some address space from > 02:00.0 3D controller: NVIDIA Corporation GM108M [GeForce 940MX] (rev a2) > > And I don't see the issue. > > I'll try and track down some more efi compatible mga or other wierd server chips > stuff if I can. > >> Anyway, rant over. I wonder if we could show this without special >> hardware by just mapping some region that doesn't even have hardware >> in it as WC. Do we even expose the PAT settings to user space, though, >> or do we always have to have some fake module to create the PAT stuff? > > I do wonder wtf the hw could be doing that would cause this, but I've no idea > how to tell what difference a write combined PCI transaction would have on the > bus side of things, and what the device could generate that would cause such > a horrible slowdown. > > Dave. 01:00.1 VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200EH (rev 01) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company iLO4 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR-