new problem with memcpy_mck routines
Using the latest memcpy_mck (20020622 + Ken's 7/10 patch) I'm seeing
problems with screen corruption on VGA. Here's the test; on a VGA console, start vim (colorized syntax highlighting and all), edit a large file (several screens). Scroll down through the file. You'll notice the screen gets corrupted, appears to be columns down the screen that scroll faster than others. I'm using an HP McKinley system and have light switched tested by building w/ the old Itanium routines. Other apps like less, nvi, etc... don't seem to trigger this. Thanks,
Alex
I've run into this too on the console of the McKinley SDV machines. A Control-L cleans it up, but it's really annoying nonetheless.
Jesse
Quoted 17 lines · Alex Williamson
Using the latest memcpy_mck (20020622 + Ken's 7/10 patch) I'm seeingproblems with screen corruption on VGA. Here's the test; on a VGA console, start vim (colorized syntax highlighting and all), edit a large file (several screens). Scroll down through the file. You'll notice the screen gets corrupted, appears to be columns down the screen that scroll faster than others. I'm using an HP McKinley system and have light switched tested by building w/ the old Itanium routines. Other apps like less, nvi, etc... don't seem to trigger this. Thanks,
Alex
_______________________________________________
Linux-IA64 mailing list
[email protected]
http://lists.linuxia64.org/lists/listinfo/linux-ia64
It turns out that the screen corruption that Jesse and Alex saw was due to a bug in generic console vga code. The scrup() functions uses memcpy to copy overlapping memory area. By definition, memcpy() must not be used for overlapping memory areas. This patch changed that to memmove() which handles overlapping areas gracefully. This also fixes the same screen corruption when switching from X server to text mode.
There is nothing wrong with new memcpy function.
char/console.c renamed from char/console.c.orig +1 -1
@@ -259,7 +259,7 @@return ; d = (unsigned short *) (origin+video_size_row*t); s = (unsigned short *) (origin+video_size_row*(t+nr)); -scr_memcpyw (d, s, (b-t-nr) * video_size_row); +scr_memmovew (d, s, (b-t-nr) * video_size_row); scr_memsetw(d + (b-t-nr) * video_num_columns, video_erase_char,
video_size_row*nr);
}
One other question, who is the maintainer for the console code? This should go into the base as it is not ia64 specific and could potentially trigger on other architectures.
- Ken Chen
-----Original Message-----
From: Jesse Barnes [mailto:[email protected]]
Sent: Friday, July 19, 2002 9:37 AM
To: [email protected]
Cc: IA64 mailinglist; Chen, Kenneth W
Subject: Re: [Linux-ia64] new problem with memcpy_mck routines
I've run into this too on the console of the McKinley SDV machines. A Control-L cleans it up, but it's really annoying nonetheless.
Jesse
Quoted 11 lines · Alex Williamson
Using the latest memcpy_mck (20020622 + Ken's 7/10 patch) I'm seeingproblems with screen corruption on VGA. Here's the test; on a VGA console, start vim (colorized syntax highlighting and all), edit a large file (several screens). Scroll down through the file. You'll notice the screen gets corrupted, appears to be columns down the screen that scroll faster than others. I'm using an HP McKinley system and have light switched tested by building w/ the old Itanium routines. Other apps like less, nvi, etc... don't seem to trigger this. Thanks,
Alex
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · Kenneth W
Ken> It turns out that the screen corruption that Jesse and Alex saw Ken> was due to a bug in generic console vga code. The scrup() Ken> functions uses memcpy to copy overlapping memory area. By Ken> definition, memcpy() must not be used for overlapping memory Ken> areas. This patch changed that to memmove() which handles Ken> overlapping areas gracefully. This also fixes the same screen Ken> corruption when switching from X server to text mode.
Ken> There is nothing wrong with new memcpy function.
Ah, that's good! Thanks for confirming this.
Ken> One other question, who is the maintainer for the console code? Ken> This should go into the base as it is not ia64 specific and Ken> could potentially trigger on other architectures.
Have you tried Martin Mares? He is listed as SVGA maintainer and has at least on occasion hacked on that file. In any case, I'd definitely cc lkml so that others can see this report, too.
--david