* vga and 64-bit memcpy's @ 2014-09-12 3:57 Dave Airlie 2014-09-12 10:26 ` Alan Cox 0 siblings, 1 reply; 6+ messages in thread From: Dave Airlie @ 2014-09-12 3:57 UTC (permalink / raw) To: LKML, Alan Cox, Linus Torvalds Got an bug report from someone using a silicon motion video card in VGA mode about corruption that they tracked down to 64-bit memory operations not being supported by the video card, it appears that we probably shouldn't be using > 32-bit copies on VGA memory. The include/linux/vt_buffer.h defaults scr_memcpyw defaults to using memcpy, which on 64-bit x86 machines ends up as rep movsq. Is there any way to make this use a 32-bit memcpy instead? Dave. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: vga and 64-bit memcpy's 2014-09-12 3:57 vga and 64-bit memcpy's Dave Airlie @ 2014-09-12 10:26 ` Alan Cox 2014-09-12 10:48 ` Dave Airlie 0 siblings, 1 reply; 6+ messages in thread From: Alan Cox @ 2014-09-12 10:26 UTC (permalink / raw) To: Dave Airlie; +Cc: LKML, Linus Torvalds On Fri, 12 Sep 2014 13:57:20 +1000 Dave Airlie <airlied@gmail.com> wrote: > Got an bug report from someone using a silicon motion video card in > VGA mode about corruption that they tracked down to 64-bit memory > operations not being supported by the video card, it appears that we > probably shouldn't be using > 32-bit copies on VGA memory. VGA memory is write combining usually so the answer in general would be no. You may also find its a combination of bridge and card and one or the other is somehow out of spec. > The include/linux/vt_buffer.h defaults scr_memcpyw defaults to using > memcpy, which on 64-bit x86 machines ends up as rep movsq. Is there > any way to make this use a 32-bit memcpy instead? Please don't - you'll reduce performance for everyone else with saner video cards. Alan ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: vga and 64-bit memcpy's 2014-09-12 10:26 ` Alan Cox @ 2014-09-12 10:48 ` Dave Airlie 2014-09-12 15:11 ` Linus Torvalds 0 siblings, 1 reply; 6+ messages in thread From: Dave Airlie @ 2014-09-12 10:48 UTC (permalink / raw) To: Alan Cox; +Cc: LKML, Linus Torvalds On 12 September 2014 20:26, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: > On Fri, 12 Sep 2014 13:57:20 +1000 > Dave Airlie <airlied@gmail.com> wrote: > >> Got an bug report from someone using a silicon motion video card in >> VGA mode about corruption that they tracked down to 64-bit memory >> operations not being supported by the video card, it appears that we >> probably shouldn't be using > 32-bit copies on VGA memory. > > VGA memory is write combining usually so the answer in general would be > no. You may also find its a combination of bridge and card and one or the > other is somehow out of spec. Well I'm not shocked that an SMI GPU is out of spec, just not sure how we can workaround it. Dave. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: vga and 64-bit memcpy's 2014-09-12 10:48 ` Dave Airlie @ 2014-09-12 15:11 ` Linus Torvalds 2014-10-21 4:30 ` Dave Airlie 0 siblings, 1 reply; 6+ messages in thread From: Linus Torvalds @ 2014-09-12 15:11 UTC (permalink / raw) To: Dave Airlie; +Cc: Alan Cox, LKML On Fri, Sep 12, 2014 at 3:48 AM, Dave Airlie <airlied@gmail.com> wrote: > > Well I'm not shocked that an SMI GPU is out of spec, just not sure how > we can workaround it. Try just removing the #define scr_memcpyw(d, s, c) memcpy(d, s, c) #define VT_BUF_HAVE_MEMCPYW (and perhaps MEMMOVEW case too) from the default implementation, and see if doing things 16-bit words at a time using the fallbacks ends up working. As Alan said, write combining might defeat that, but quite frankly, we already do this for the MEMSETW case (probably because we forgot, possibly because it's not as performance-sensitive) My gut feel is that we don't care deeply about performance here, because (a) true text-modes are less common anyway and (b) true text modes are pretty damn fast anyway compared to the more usual "write the whole glyph as graphics" fbcon case. And *maybe* it works. And maybe that SMI GPU is a piece of shit that isn't worth worrying about in VGA text-mode. Where the hell are they found anyway? Linus ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: vga and 64-bit memcpy's 2014-09-12 15:11 ` Linus Torvalds @ 2014-10-21 4:30 ` Dave Airlie 2014-10-21 19:53 ` Linus Torvalds 0 siblings, 1 reply; 6+ messages in thread From: Dave Airlie @ 2014-10-21 4:30 UTC (permalink / raw) To: Linus Torvalds; +Cc: Alan Cox, LKML On 13 September 2014 01:11, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Fri, Sep 12, 2014 at 3:48 AM, Dave Airlie <airlied@gmail.com> wrote: >> >> Well I'm not shocked that an SMI GPU is out of spec, just not sure how >> we can workaround it. > > Try just removing the > > #define scr_memcpyw(d, s, c) memcpy(d, s, c) > #define VT_BUF_HAVE_MEMCPYW > > (and perhaps MEMMOVEW case too) from the default implementation, and > see if doing things 16-bit words at a time using the fallbacks ends up > working. As Alan said, write combining might defeat that, but quite > frankly, we already do this for the MEMSETW case (probably because we > forgot, possibly because it's not as performance-sensitive) > > My gut feel is that we don't care deeply about performance here, > because (a) true text-modes are less common anyway and (b) true text > modes are pretty damn fast anyway compared to the more usual "write > the whole glyph as graphics" fbcon case. > > And *maybe* it works. And maybe that SMI GPU is a piece of shit that > isn't worth worrying about in VGA text-mode. Where the hell are they > found anyway? Sorry I let this fall off the planet, some huawei x86 server has this behaviour, works with RHEL5 32-bit, fails with RHEL6 64-bit. //#define scr_memcpyw(d, s, c) memcpy(d, s, c) //#define scr_memmovew(d, s, c) memmove(d, s, c) //#define VT_BUF_HAVE_MEMCPYW //#define VT_BUF_HAVE_MEMMOVEW was tested and found to work, just a question if we care enough to fix it I suppose. Dave. The info I have > > Linus ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: vga and 64-bit memcpy's 2014-10-21 4:30 ` Dave Airlie @ 2014-10-21 19:53 ` Linus Torvalds 0 siblings, 0 replies; 6+ messages in thread From: Linus Torvalds @ 2014-10-21 19:53 UTC (permalink / raw) To: Dave Airlie; +Cc: Alan Cox, LKML On Mon, Oct 20, 2014 at 9:30 PM, Dave Airlie <airlied@gmail.com> wrote: > > was tested and found to work, just a question if we care enough to fix > it I suppose. Well, we might not care deeply, but at the same time I also do think that we don't care deeply about the alleged performance advantages of having that special scr_memmovew() hack. So I think I'd apply a real (and tested) patch to just remove the special VT_BUF_HAVE_MEM{CPY|MOVE}W if I got one. Linus ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-10-21 19:53 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-09-12 3:57 vga and 64-bit memcpy's Dave Airlie 2014-09-12 10:26 ` Alan Cox 2014-09-12 10:48 ` Dave Airlie 2014-09-12 15:11 ` Linus Torvalds 2014-10-21 4:30 ` Dave Airlie 2014-10-21 19:53 ` Linus Torvalds
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®