vga and 64-bit memcpy's

vga and 64-bit memcpy's

[Dave Airlie]

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.

Re: vga and 64-bit memcpy's

[Alan Cox]

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

Re: vga and 64-bit memcpy's

[Dave Airlie]

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.

Re: vga and 64-bit memcpy's

[Linus Torvalds]

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

Re: vga and 64-bit memcpy's

[Dave Airlie]

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

Re: vga and 64-bit memcpy's

[Linus Torvalds]

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