Screen corruption in 2.4.18

Screen corruption in 2.4.18

[Danijel Schiavuzzi]

Hi.

Some two weeks ago I posted here a kernel bug report regarding
a screen corruption issue. You can find it here:
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0203.0/1577.html

As I didn't know if it's my hardware that is the cause of corruption,
searched over the Internet and found that Thomas Brehm is also
having the same problem, and he has the same motherboard as me
(MSI MS-6340M, VIA KM133 chipset - VT8365 north + VIA686B south bridge).

Short problem description: 2.4.17 kernel works fine, but any kernel
higher than this makes the screen corrupted in any text or VESA fb
mode. In standard text mode, the screen gets filled with vertical
lines. In vesafb mode, random horizontal lines appear on the screen.

However, I made up the 2.4.18 kernel to boot up properly by 
replacing the file

	./linux/arch/i386/pci-pc.c

with that from the 2.4.17 kernel. The kernel runs fine now.

So, what seems to make the screen corruption?

						-- Danijel

P.S.  Here is a diff between the two pci-pc.c files:

------------------------- begin -------------------------

1112c1112,1113
<  * Nobody seems to know what this does. Damn.
---
>  * Addresses issues with problems in the memory write queue timer in
>  * certain VIA Northbridges.  This bugfix is per VIA's specifications.
1114,1118c1115,1118
<  * But it does seem to fix some unspecified problem
<  * with 'movntq' copies on Athlons.
<  *
<  * VIA 8363 chipset:
<  *  - bit 7 at offset 0x55: Debug (RW)
---
>  * VIA 8363,8622,8361 Northbridges:
>  *  - bits  5, 6, 7 at offset 0x55 need to be turned off
>  * VIA 8367 (KT266x) Northbridges:
>  *  - bits  5, 6, 7 at offset 0x95 need to be turned off
1120c1120
< static void __init pci_fixup_via_athlon_bug(struct pci_dev *d)
---
> static void __init pci_fixup_via_northbridge_bug(struct pci_dev *d)
1123,1127c1123,1134
< 	pci_read_config_byte(d, 0x55, &v);
< 	if (v & 0x80) {
< 		printk("Trying to stomp on Athlon bug...\n");
< 		v &= 0x7f; /* clear bit 55.7 */
< 		pci_write_config_byte(d, 0x55, v);
---
> 	int where = 0x55;
> 
> 	if (d->device == PCI_DEVICE_ID_VIA_8367_0) {
> 		where = 0x95; /* the memory write queue timer register is 
> 				 different for the kt266x's: 0x95 not 0x55 */
> 	}
> 
> 	pci_read_config_byte(d, where, &v);
> 	if (v & 0xe0) {
> 		printk("Disabling VIA memory write queue: [%02x] %02x->%02x\n", where, v, 
v & 0x1f);
> 		v &= 0x1f; /* clear bits 5, 6, 7 */
> 		pci_write_config_byte(d, where, v);
1140c1147,1150
< 	{ PCI_FIXUP_HEADER,	PCI_VENDOR_ID_VIA,	PCI_DEVICE_ID_VIA_8363_0,	
pci_fixup_via_athlon_bug },
---
> 	{ PCI_FIXUP_HEADER,	PCI_VENDOR_ID_VIA,	PCI_DEVICE_ID_VIA_8363_0,	
pci_fixup_via_northbridge_bug },
> 	{ PCI_FIXUP_HEADER,	PCI_VENDOR_ID_VIA,	PCI_DEVICE_ID_VIA_8622,	        
pci_fixup_via_northbridge_bug },
> 	{ PCI_FIXUP_HEADER,	PCI_VENDOR_ID_VIA,	PCI_DEVICE_ID_VIA_8361,	        
pci_fixup_via_northbridge_bug },
> 	{ PCI_FIXUP_HEADER,	PCI_VENDOR_ID_VIA,	PCI_DEVICE_ID_VIA_8367_0,	
pci_fixup_via_northbridge_bug },

------------------------------ end ------------------------------

Re: Screen corruption in 2.4.18

[Steven Walter]

On Tue, Mar 19, 2002 at 10:12:18PM +0100, Danijel Schiavuzzi wrote:
> Hi.
> 
> Some two weeks ago I posted here a kernel bug report regarding
> a screen corruption issue. You can find it here:
> http://www.uwsg.indiana.edu/hypermail/linux/kernel/0203.0/1577.html
> 
> As I didn't know if it's my hardware that is the cause of corruption,
> searched over the Internet and found that Thomas Brehm is also
> having the same problem, and he has the same motherboard as me
> (MSI MS-6340M, VIA KM133 chipset - VT8365 north + VIA686B south bridge).
> 
> Short problem description: 2.4.17 kernel works fine, but any kernel
> higher than this makes the screen corrupted in any text or VESA fb
> mode. In standard text mode, the screen gets filled with vertical
> lines. In vesafb mode, random horizontal lines appear on the screen.
> 
> However, I made up the 2.4.18 kernel to boot up properly by 
> replacing the file
> 
> 	./linux/arch/i386/pci-pc.c
> 
> with that from the 2.4.17 kernel. The kernel runs fine now.
> 
> So, what seems to make the screen corruption?

I also experienced this problem on a VIA board.  I tried removing my
chipset from the list of those which need the fix-up from pci-pc.c, and
this elimiated all the corruption.  It would seem that this chip, at
least on our specific boards, does not need the fix-up, and in fact it
is detrimental.
-- 
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
			-- George Orwell
He's alive.  He's alive!  Oh, that fellow at RadioShack said I was mad!
Well, who's mad now?
			-- Montgomery C. Burns

Re: Screen corruption in 2.4.18

[Steven Walter]

> > On Wed, Mar 20, 2002 at 04:06:29PM +0100, Danijel Schiavuzzi wrote:
> > > Hm, I'm using the VIA VT8365 northbridge and I haven't found any '8365'
> > > entry in pci-pc.c, only this:
[...]

But it does show the "Disabling VIA Write Queue" during boot, yes?  If
not, then maybe it /does/ need to be added.  If it does, then try
commenting all but one of the device lines and see which one is causing
your system to run the fixup.  Then you can try commenting /it/ out, and
see if the screen corruption goes away.  Additionally, you could change
the "v &= 0x1f;" to "v &= 0x7f;" on line 1209 to only clear bit 7.

Let me know how that goes.
-- 
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
			-- George Orwell
He's alive.  He's alive!  Oh, that fellow at RadioShack said I was mad!
Well, who's mad now?
			-- Montgomery C. Burns

Re: Screen corruption in 2.4.18

[Steven Walter]

On Fri, Mar 22, 2002 at 08:49:02PM +0100, Danijel Schiavuzzi wrote:
> In 2.4.18, unmodified (with 0x1f value), it shows:
> 	Disabling VIA memory write queue: [55] 38->18
> 
> In 2.4.18, modified (changed 0x1f to 0x7f), it shows:
> 	 Disabling VIA memory write queue: [55] 38->38
> 
> The modified kernel runs *fine*.

Aha.  Excellent.

> lspci tells:
> 
> 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 81)
                                              ^^^^^^
I think you actually do have an 8363, and so some sort of fix is
probably needed.

> 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP]
> 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 
> 40)
> /cut/
> 
> But in fact mine is a *VT8365* (KM133) Northbridge.
> 
> from pci-pc.c:
>         { PCI_FIXUP_HEADER,     PCI_VENDOR_ID_VIA,      
> PCI_DEVICE_ID_VIA_8363_0,       pci_fixup_via_northbridge_bug },
> 		^^^^^^^^
>         { PCI_FIXUP_HEADER,     PCI_VENDOR_ID_VIA,      
> PCI_DEVICE_ID_VIA_8622,         pci_fixup_via_northbridge_bug },
>         { PCI_FIXUP_HEADER,     PCI_VENDOR_ID_VIA,      
> PCI_DEVICE_ID_VIA_8361,         pci_fixup_via_northbridge_bug },
>         { PCI_FIXUP_HEADER,     PCI_VENDOR_ID_VIA,      
> PCI_DEVICE_ID_VIA_8367_0,       pci_fixup_via_northbridge_bug },
>         { 0 }
> 
> Maybe because of this, the kernel thinks mine is a 8363, and applies the fix, 
> but in fact it doesn't need to be applied, or does it? I'm confused %:I

I think your system does need the fix, but only bit 7 needs clearing.
Not all of it.  If memory serves me, clearing bit 7 was the
experimentally-determined fix for the bug, however, VIA said that all 3
bit needed clearing.  Perhaps this should be looked into, as I
experienced the same screen corruption bug on the same chipset.  I have
yet to try my own proposed fix on it, however :-/

I'll do this within the next week or so, and if it works for me, I'll
propose a patch to only clear bit 7, at least on these chips.  Sound
good to you?
-- 
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
			-- George Orwell
He's alive.  He's alive!  Oh, that fellow at RadioShack said I was mad!
Well, who's mad now?
			-- Montgomery C. Burns

Re: Screen corruption in 2.4.18

[Steven Walter]

On Sat, Mar 23, 2002 at 04:25:55PM +0100, Danijel Schiavuzzi wrote:
> > I think you actually do have an 8363, and so some sort of fix is
> > probably needed.
> 
> Don't get it wrong. I *do have* an VT8365. VT8365 (ProSavage KM133) is 
> somewhat the same as VT8363 (KT133), except that 8365 has an integrated 
> Savage graphics card (which *I use*).

Aha... I see.  And in thinking about it, I realize that my motherboard
also has this integrated graphics card.  Perhaps this is the difference?
Unfortunately, it seems they both report the same PCI id, so I don't
really know of a way to differentiate them.

[...]
> In the KM133 datasheet (find it here: http://www.fae.com.tw/serv02.htm ;) it 
> is said that the offset 55 is for "Debug (Do Not Program)"... Can you look at 
> it, maybe it can help.

I looked at that datasheet, and the datasheet for the 8363.  Both said
not to program offset 55, and both said the bits we are clearing are
"reserved."  Perhaps we should contact VIA directly, tell them the
problem we're having with their current fix, tell them our theory, and
ask if we're right.
-- 
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
			-- George Orwell
He's alive.  He's alive!  Oh, that fellow at RadioShack said I was mad!
Well, who's mad now?
			-- Montgomery C. Burns

VIA technical contact [was Screen corruption in 2.4.18]

[Steven Walter]

On Sat, Mar 23, 2002 at 06:41:31PM +0100, Danijel Schiavuzzi wrote:
> On Saturday 23 March 2002 17:06, you wrote:
> > > In the KM133 datasheet (find it here: http://www.fae.com.tw/serv02.htm ;)
> > > it is said that the offset 55 is for "Debug (Do Not Program)"... Can you
> > > look at it, maybe it can help.
> >
> > I looked at that datasheet, and the datasheet for the 8363.  Both said
> > not to program offset 55, and both said the bits we are clearing are
> > "reserved."  Perhaps we should contact VIA directly, tell them the
> > problem we're having with their current fix, tell them our theory, and
> > ask if we're right.
> 
> I think so, too. But what e-mail address do they have? When I was trying to 
> reach VIA in the past for various things, I've never got a reply from them 
> from any e-mail address I've mailed...

I don't know.  Does anyone have a technical contact at VIA towards whom
this question could be directed?
-- 
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
			-- George Orwell
He's alive.  He's alive!  Oh, that fellow at RadioShack said I was mad!
Well, who's mad now?
			-- Montgomery C. Burns

Re: Screen corruption in 2.4.18

[Andre Pang]

On Sat, Mar 23, 2002 at 10:06:47AM -0600, Steven Walter wrote:

> > Don't get it wrong. I *do have* an VT8365. VT8365 (ProSavage KM133) is 
> > somewhat the same as VT8363 (KT133), except that 8365 has an integrated 
> > Savage graphics card (which *I use*).
> 
> Aha... I see.  And in thinking about it, I realize that my motherboard
> also has this integrated graphics card.  Perhaps this is the difference?
> Unfortunately, it seems they both report the same PCI id, so I don't
> really know of a way to differentiate them.

I can verify Danijel's report -- I have the same setup
(VT8363+VT8353, a.k.a. ProSavage KM133), and I experience the
same screen corruption.  Clearing only bit 7 of register 55 fixes
the problem; clearing bits 5 and 6 causes the video to go all
borky.  There's been another thread about it on lkml over the
last week or so.

> I looked at that datasheet, and the datasheet for the 8363.  Both said
> not to program offset 55, and both said the bits we are clearing are
> "reserved."  Perhaps we should contact VIA directly, tell them the
> problem we're having with their current fix, tell them our theory, and
> ask if we're right.

Heh, a VIA contact who knows what the hell that register does
would be nice :).

In the meantime, I'd probably suggest a patch which looks for
clears only bit 7 of Rx55 if an 8363 and an 8365 is found.  I'll
whip one up later today.


-- 
#ozone/algorithm <ozone@algorithm.com.au>          - trust.in.love.to.save

[PATCH] Re: Screen corruption in 2.4.18

[Steven Walter]

On Sun, Mar 24, 2002 at 06:05:16PM +1100, Andre Pang wrote:
> On Sat, Mar 23, 2002 at 10:06:47AM -0600, Steven Walter wrote:
> 
> > > Don't get it wrong. I *do have* an VT8365. VT8365 (ProSavage KM133) is 
> > > somewhat the same as VT8363 (KT133), except that 8365 has an integrated 
> > > Savage graphics card (which *I use*).
> > 
> > Aha... I see.  And in thinking about it, I realize that my motherboard
> > also has this integrated graphics card.  Perhaps this is the difference?
> > Unfortunately, it seems they both report the same PCI id, so I don't
> > really know of a way to differentiate them.
> 
> I can verify Danijel's report -- I have the same setup
> (VT8363+VT8353, a.k.a. ProSavage KM133), and I experience the
> same screen corruption.  Clearing only bit 7 of register 55 fixes
> the problem; clearing bits 5 and 6 causes the video to go all
> borky.  There's been another thread about it on lkml over the
> last week or so.
> 
> > I looked at that datasheet, and the datasheet for the 8363.  Both said
> > not to program offset 55, and both said the bits we are clearing are
> > "reserved."  Perhaps we should contact VIA directly, tell them the
> > problem we're having with their current fix, tell them our theory, and
> > ask if we're right.
> 
> Heh, a VIA contact who knows what the hell that register does
> would be nice :).
> 
> In the meantime, I'd probably suggest a patch which looks for
> clears only bit 7 of Rx55 if an 8363 and an 8365 is found.  I'll
> whip one up later today.

Alright.  Two seperate verifications are enough for me.  I have a patch,
but had been sitting on it for the time.  But, here it is.  Comments are
welcome, I'd like to see this included in 2.4.x and 2.5.x

Thanks
-- 
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
			-- George Orwell
He's alive.  He's alive!  Oh, that fellow at RadioShack said I was mad!
Well, who's mad now?
			-- Montgomery C. Burns

--- pci-pc.c~	Sat Mar 23 15:01:37 2002
+++ pci-pc.c	Sat Mar 23 15:03:45 2002
@@ -1197,16 +1197,19 @@
 {
 	u8 v;
 	int where = 0x55;
+	int mask = 0x7f; /* Don't clear bits 5 and 6 on the KT133!  It
+			  * causes strange screen corruption... */
 
 	if (d->device == PCI_DEVICE_ID_VIA_8367_0) {
 		where = 0x95; /* the memory write queue timer register is 
 				 different for the kt266x's: 0x95 not 0x55 */
+		mask = 0x1f; /* clear bits 5, 6, 7 */
 	}
 
 	pci_read_config_byte(d, where, &v);
 	if (v & 0xe0) {
-		printk("Disabling VIA memory write queue: [%02x] %02x->%02x\n", where, v, v & 0x1f);
-		v &= 0x1f; /* clear bits 5, 6, 7 */
+		printk("Disabling VIA memory write queue: [%02x] %02x->%02x\n", where, v, v & mask);
+		v &= mask;
 		pci_write_config_byte(d, where, v);
 	}
 }

[PATCH] Re: Screen corruption in 2.4.18

[Steven Walter]

This patch fixes a screen corruption bug seen on VIA KM133 mainboards.
As it stands, we disable bits 5, 6, and 7 of register offset 55 in order
to disable the memory write queue, which was causing us trouble before.
However, the clearing of bits 5 and 6 is causing us trouble now.  Whenever 
they're cleared, the screen gets static across it, roughly corresponding 
to IDE/PCI activity.  I spoke to one of the developers involved in the 
original fix, and he suggested that we go ahead and not clear bits 5 and 6 
on these boards, and that he was aware of several instances where clearing 
them causes trouble.

Here is a patch which should apply cleanly to everyone's tree, which
only clears bit 7 on all chips except the KT266.  No problems have been
reported there, so I'm leaving well enough alone.  Please apply.

Thanks
-- 
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
			-- George Orwell
He's alive.  He's alive!  Oh, that fellow at RadioShack said I was mad!
Well, who's mad now?
			-- Montgomery C. Burns

--- linux/arch/i386/kernel/pci-pc.c~	Sun Mar 24 09:43:14 2002
+++ linux/arch/i386/kernel/pci-pc.c	Sun Mar 24 09:43:23 2002
@@ -1197,16 +1197,19 @@
 {
 	u8 v;
 	int where = 0x55;
+	int mask = 0x7f; /* Clearing bits 5 and 6 on the ProSavage KM133 
+			  * causes strange screen corruption, so we don't */
 
 	if (d->device == PCI_DEVICE_ID_VIA_8367_0) {
 		where = 0x95; /* the memory write queue timer register is 
 				 different for the kt266x's: 0x95 not 0x55 */
+		mask = 0x1f; /* clear bits 5, 6, 7 */
 	}
 
 	pci_read_config_byte(d, where, &v);
 	if (v & 0xe0) {
-		printk("Disabling VIA memory write queue: [%02x] %02x->%02x\n", where, v, v & 0x1f);
-		v &= 0x1f; /* clear bits 5, 6, 7 */
+		printk("Disabling VIA memory write queue: [%02x] %02x->%02x\n", where, v, v & mask);
+		v &= mask;
 		pci_write_config_byte(d, where, v);
 	}
 }

Re: [PATCH] Re: Screen corruption in 2.4.18

[Alan Cox]

> Here is a patch which should apply cleanly to everyone's tree, which
> only clears bit 7 on all chips except the KT266.  No problems have been
> reported there, so I'm leaving well enough alone.  Please apply.

No. Not until someone explains to me why VIA specifically told me I must
clear the 3 bits. If you get that wrong you get slow and insidious disk
corruption. Its hard to test and I'm not going to use other people's
hardware as target practice for a hunch.

Re: [PATCH] Re: Screen corruption in 2.4.18

[Steven Walter]

On Sun, Mar 24, 2002 at 04:48:20PM +0000, Alan Cox wrote:
> > Here is a patch which should apply cleanly to everyone's tree, which
> > only clears bit 7 on all chips except the KT266.  No problems have been
> > reported there, so I'm leaving well enough alone.  Please apply.
> 
> No. Not until someone explains to me why VIA specifically told me I must
> clear the 3 bits. If you get that wrong you get slow and insidious disk
> corruption. Its hard to test and I'm not going to use other people's
> hardware as target practice for a hunch.

I've contacted someone at VIA about it, but have yet to hear back.
You'll be the first to know when I do.
-- 
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
			-- George Orwell
He's alive.  He's alive!  Oh, that fellow at RadioShack said I was mad!
Well, who's mad now?
			-- Montgomery C. Burns

Re: [PATCH] Re: Screen corruption in 2.4.18

[Andre Pang]

On Sun, Mar 24, 2002 at 09:59:30AM -0600, Steven Walter wrote:

> Here is a patch which should apply cleanly to everyone's tree, which
> only clears bit 7 on all chips except the KT266.  No problems have been
> reported there, so I'm leaving well enough alone.  Please apply.

I don't think the patch should be that generic; we're into dragon
territory here already.  We should follow VIA's fix by default
(clear bits 5, 6, 7), and clear bit 7 only if a VT8365 is
detected.

Even then, I personally want to do some checking to see that the
VT8365 is the real culprit, before firing off a patch which could
affect all other VIA users.  I don't want hate mail coming into
my inbox 8).


-- 
#ozone/algorithm <ozone@algorithm.com.au>          - trust.in.love.to.save

Re: Screen corruption in 2.4.18

[Danijel Schiavuzzi]

On Sunday 24 March 2002 08:05, you wrote:
> On Sat, Mar 23, 2002 at 10:06:47AM -0600, Steven Walter wrote:
> > > Don't get it wrong. I *do have* an VT8365. VT8365 (ProSavage KM133) is
> > > somewhat the same as VT8363 (KT133), except that 8365 has an integrated
> > > Savage graphics card (which *I use*).
> >
> > Aha... I see.  And in thinking about it, I realize that my motherboard
> > also has this integrated graphics card.  Perhaps this is the difference?
> > Unfortunately, it seems they both report the same PCI id, so I don't
> > really know of a way to differentiate them.
>
> I can verify Danijel's report -- I have the same setup
> (VT8363+VT8353, a.k.a. ProSavage KM133), and I experience the

Actually the *northbridge is VT8365* (ProSavage KM133), while it can be 
combined with other southbridges like VIA VT86c686A or VT86c686B (I'm using 
the B one.) VT8363 (KT133) is a similar chipset to KM133, and the only 
difference should be the integrated Savage graphics card in KM133.

> same screen corruption.  Clearing only bit 7 of register 55 fixes

Well, we're not the only ones with this problem. BTW, which motherboard do 
you have? Maybe it's a mainboard failure (mine is a MSI MS-6340M V1). I know 
one more Linux user with this problem on the same M/B.

> the problem; clearing bits 5 and 6 causes the video to go all
> borky.  There's been another thread about it on lkml over the
> last week or so.
>
> > I looked at that datasheet, and the datasheet for the 8363.  Both said
> > not to program offset 55, and both said the bits we are clearing are
> > "reserved."  Perhaps we should contact VIA directly, tell them the
> > problem we're having with their current fix, tell them our theory, and
> > ask if we're right.
>
> Heh, a VIA contact who knows what the hell that register does
> would be nice :).
>
> In the meantime, I'd probably suggest a patch which looks for
> clears only bit 7 of Rx55 if an 8363 and an 8365 is found.  I'll
> whip one up later today.

Yes, should implement some autodetection to detect VT8365 and clear only bit 
7 and include it in the kernel *as soon as possible* (I don't have any kernel 
programming experience, so don't ask me to do so, although it should be 
something trivial ;))

BTW, find KM133 and KT133 datasheets here ;)
	* VT8363: http://www.fae.com.tw/datasheet/8363kt/DS8363040.pdf
	* VT8365: http://www.fae.com.tw/datasheet/8365/DS8365030.pdf

Regards,

Danijel

Re: Screen corruption in 2.4.18

[Alan Cox]

> > same screen corruption.  Clearing only bit 7 of register 55 fixes
> 
> Well, we're not the only ones with this problem. BTW, which motherboard do 
> you have? Maybe it's a mainboard failure (mine is a MSI MS-6340M V1). I know 
> one more Linux user with this problem on the same M/B.

Does everyone who sees this problem have the 8363/5 combination with the
onboard Pro-Savage

Alan

Re: Screen corruption in 2.4.18

[Danijel Schiavuzzi]

On Sunday 24 March 2002 17:51, you wrote:
> > > same screen corruption.  Clearing only bit 7 of register 55 fixes
> >
> > Well, we're not the only ones with this problem. BTW, which motherboard
> > do you have? Maybe it's a mainboard failure (mine is a MSI MS-6340M V1).
> > I know one more Linux user with this problem on the same M/B.
>
> Does everyone who sees this problem have the 8363/5 combination with the
> onboard Pro-Savage
>
> Alan

Hi,

AFAIK, these people are having these problems and using VT8365 (KM133) 
(ProSavage graphics is integrated in this northbridge):

me <dschiavu@jagor.srce.hr>
Tom Brehm <BrehmTomB@aol.com>
Andre Pang <ozone@algorithm.com.au>
Steven Walter <srwalter@yahoo.com>
Tom Eastep <teastep@shorewall.net>

Regards,

Danijel

Re: Screen corruption in 2.4.18

[Andre Pang]

On Sun, Mar 24, 2002 at 04:07:31PM +0100, Danijel Schiavuzzi wrote:

> > In the meantime, I'd probably suggest a patch which looks for
> > clears only bit 7 of Rx55 if an 8363 and an 8365 is found.  I'll
> > whip one up later today.
> 
> Yes, should implement some autodetection to detect VT8365 and clear only bit 
> 7 and include it in the kernel *as soon as possible* (I don't have any kernel 
> programming experience, so don't ask me to do so, although it should be 
> something trivial ;))

I've had a quick look at the pci-pc.c file which handles the PCI
fixups, but I can't see of a way to say "if this chip is detected
_and_ that chip is detected, modify this bit in the first chip."
It's possible, but not without some real ugly hackery.

Assuming that _only_ the integrated KT133+KM133 chipset uses the
VT8365 PCI ID (0x8305), it'd be easy to make a special-case patch
for it.  My only worry is that other chipsets (like the 'normal'
KT133 without the KM133) use the same PCI ID; we should avoid
modifying the fix for the other chipsets, if possible.

Can somebody with a KT133/KT133A do a "lspci -n" and grep for
'8305'?  If it doesn't appear, I'll send off my patch.


-- 
#ozone/algorithm <ozone@algorithm.com.au>          - trust.in.love.to.save

Re: Screen corruption in 2.4.18

[Steven Walter]

On Mon, Mar 25, 2002 at 12:43:18PM +1100, Andre Pang wrote:
> I've had a quick look at the pci-pc.c file which handles the PCI
> fixups, but I can't see of a way to say "if this chip is detected
> _and_ that chip is detected, modify this bit in the first chip."
> It's possible, but not without some real ugly hackery.
> 
> Assuming that _only_ the integrated KT133+KM133 chipset uses the
> VT8365 PCI ID (0x8305), it'd be easy to make a special-case patch
> for it.  My only worry is that other chipsets (like the 'normal'
> KT133 without the KM133) use the same PCI ID; we should avoid
> modifying the fix for the other chipsets, if possible.
> 
> Can somebody with a KT133/KT133A do a "lspci -n" and grep for
> '8305'?  If it doesn't appear, I'll send off my patch.

I fear this as well.  In fact, I'm relatively certain that they /do/
both use the same PCI ID.  Hence why lspci lists KT133/KM133.  But I
hope to big mistaken.  If not, the only way I can see of detecting that
it is a KM133 is by checking what device 01:00 is an S3 ProSavage.
Yuck.

Hopefully I'll here back from VIA with a definitive answer about when to
clear what bits, though.
-- 
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
			-- George Orwell
He's alive.  He's alive!  Oh, that fellow at RadioShack said I was mad!
Well, who's mad now?
			-- Montgomery C. Burns

Re: Screen corruption in 2.4.18

[Andre Pang]

On Sun, Mar 24, 2002 at 08:40:27PM -0600, Steven Walter wrote:

> I fear this as well.  In fact, I'm relatively certain that they /do/
> both use the same PCI ID.  Hence why lspci lists KT133/KM133.  But I
> hope to big mistaken.  If not, the only way I can see of detecting that
> it is a KM133 is by checking what device 01:00 is an S3 ProSavage.
> Yuck.

Is it possible to identify the KT133/KM133 by the vendor string,
rather than the PCI ID?  It's, erm, kinda ugly, but it might be
the cleanest way to do it if the PCI ID isn't unique.


-- 
#ozone/algorithm <ozone@algorithm.com.au>          - trust.in.love.to.save

Re: Screen corruption in 2.4.18

[Marc Wilson]

[-- Attachment #1: Type: text/plain, Size: 519 bytes --]

On Mon, Mar 25, 2002 at 12:43:18PM +1100, Andre Pang wrote:
> Can somebody with a KT133/KT133A do a "lspci -n" and grep for
> '8305'?  If it doesn't appear, I'll send off my patch.

Sorry to disappoint you:

$ sudo lspci -n | grep 8305
00:01.0 Class 0604: 1106:8305

It's an Abit KT7A-RAID, which is a KT133A.

Having said that, I've been seeing odd video artifacts in xawtv windows
since the patch was expanded from merely clearing bit 7. :)

-- 
Marc Wilson
msw@cox.net
http://members.cox.net/msw


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: Screen corruption in 2.4.18

[Daniel Gryniewicz]

On Mon, 25 Mar 2002 00:50:53 -0800
Marc Wilson <msw@cox.net> wrote:

> On Mon, Mar 25, 2002 at 12:43:18PM +1100, Andre Pang wrote:
> > Can somebody with a KT133/KT133A do a "lspci -n" and grep for
> > '8305'?  If it doesn't appear, I'll send off my patch.
> 
> Sorry to disappoint you:
> 
> $ sudo lspci -n | grep 8305
> 00:01.0 Class 0604: 1106:8305
> 
> It's an Abit KT7A-RAID, which is a KT133A.
> 
> Having said that, I've been seeing odd video artifacts in xawtv windows
> since the patch was expanded from merely clearing bit 7. :)
> 
> -- 
> Marc Wilson
> msw@cox.net
> http://members.cox.net/msw
> 
> 

00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 02)
(KT7-RAID, KT133)
00:01.0 Class 0604: 1106:8305

Daniel
--- 
Recursion n.:
        See Recursion.
                        -- Random Shack Data Processing Dictionary

Re: Screen corruption in 2.4.18

[Steven Walter]

On Mon, Mar 25, 2002 at 12:50:53AM -0800, Marc Wilson wrote:
> On Mon, Mar 25, 2002 at 12:43:18PM +1100, Andre Pang wrote:
> > Can somebody with a KT133/KT133A do a "lspci -n" and grep for
> > '8305'?  If it doesn't appear, I'll send off my patch.
> 
> Sorry to disappoint you:
> 
> $ sudo lspci -n | grep 8305
> 00:01.0 Class 0604: 1106:8305
> 
> It's an Abit KT7A-RAID, which is a KT133A.
> 
> Having said that, I've been seeing odd video artifacts in xawtv windows
> since the patch was expanded from merely clearing bit 7. :)

Is that to say, you suspect clearing bits 5 and 6 is causing you
trouble?  If so, by all means try the patch I posted to the list.  If
you can't find it in the archives or google groups or whatnot, I'll send
it to you directly.
-- 
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
			-- George Orwell
He's alive.  He's alive!  Oh, that fellow at RadioShack said I was mad!
Well, who's mad now?
			-- Montgomery C. Burns

Re: Screen corruption in 2.4.18

[Marc Wilson]

[-- Attachment #1: Type: text/plain, Size: 974 bytes --]

On Mon, Mar 25, 2002 at 03:02:44PM -0600, Steven Walter wrote:
> On Mon, Mar 25, 2002 at 12:50:53AM -0800, Marc Wilson wrote:
> > Having said that, I've been seeing odd video artifacts in xawtv windows
> > since the patch was expanded from merely clearing bit 7. :)
> 
> Is that to say, you suspect clearing bits 5 and 6 is causing you
> trouble?  If so, by all means try the patch I posted to the list.  If
> you can't find it in the archives or google groups or whatnot, I'll send
> it to you directly.

I don't seem to have the original message, so by all means, send it along
and I'll give it a shot.  What does it apply against?  The current kernel
on the box in question is:

Linux rei 2.4.19-pre2-ac2 #2 Sun Mar 3 22:07:50 PST 2002 i686 unknown

although I can put anything else on it, if it's necessary.  I've built
2.4.19-pre3-ac6 but haven't gotten around to rebooting to it yet. :)

-- 
Marc Wilson
msw@cox.net
http://members.cox.net/msw


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: Screen corruption in 2.4.18

[Andre Pang]

On Mon, Mar 25, 2002 at 12:50:53AM -0800, Marc Wilson wrote:

> On Mon, Mar 25, 2002 at 12:43:18PM +1100, Andre Pang wrote:
> > Can somebody with a KT133/KT133A do a "lspci -n" and grep for
> > '8305'?  If it doesn't appear, I'll send off my patch.
> 
> Sorry to disappoint you:
> 
> $ sudo lspci -n | grep 8305
> 00:01.0 Class 0604: 1106:8305
> 
> It's an Abit KT7A-RAID, which is a KT133A.
> 
> Having said that, I've been seeing odd video artifacts in xawtv windows
> since the patch was expanded from merely clearing bit 7. :)

What kind of video card do you have?


-- 
#ozone/algorithm <ozone@algorithm.com.au>          - trust.in.love.to.save

Re: Screen corruption in 2.4.18

[Marc Wilson]

On Fri, Mar 29, 2002 at 01:06:39PM +1100, Andre Pang wrote:
> On Mon, Mar 25, 2002 at 12:50:53AM -0800, Marc Wilson wrote:
> > It's an Abit KT7A-RAID, which is a KT133A.
> > 
> > Having said that, I've been seeing odd video artifacts in xawtv windows
> > since the patch was expanded from merely clearing bit 7. :)
> 
> What kind of video card do you have?

A Matrox G550 VGA/DVI in dual-head mode... why?

-- 
Marc Wilson
msw@cox.net
http://members.cox.net/msw

Re: Screen corruption in 2.4.18

[Andre Pang]

On Sun, Mar 24, 2002 at 04:07:31PM +0100, Danijel Schiavuzzi wrote:

> > same screen corruption.  Clearing only bit 7 of register 55 fixes
> 
> Well, we're not the only ones with this problem. BTW, which motherboard do 
> you have? Maybe it's a mainboard failure (mine is a MSI MS-6340M V1). I know 
> one more Linux user with this problem on the same M/B.

I have an Asus A7VC.  They're the motherboards that come with the
cute little Asus Terminator K7s[1]; I have no idea if you can
actually get this motherboard if you don't buy that kit.  So it's
not a motherboard-specific problem.

Relevant output from lspci for the A7VC:

    00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 81)
    00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP]
    01:00.0 VGA compatible controller: S3 Inc. ProSavage KM133 (rev 03)

    00:00.0 Class 0600: 1106:0305 (rev 81)
    00:01.0 Class 0604: 1106:8305
    01:00.0 Class 0300: 5333:8a26 (rev 03)

1. http://www.asus.com.tw/desktop/terminator/overview.htm


-- 
#ozone/algorithm <ozone@algorithm.com.au>          - trust.in.love.to.save

Re: Screen corruption in 2.4.18

[Danijel Schiavuzzi]

On Monday 25 March 2002 02:55, you wrote:
> On Sun, Mar 24, 2002 at 04:07:31PM +0100, Danijel Schiavuzzi wrote:
> > > same screen corruption.  Clearing only bit 7 of register 55 fixes
> >
> > Well, we're not the only ones with this problem. BTW, which motherboard
> > do you have? Maybe it's a mainboard failure (mine is a MSI MS-6340M V1).
> > I know one more Linux user with this problem on the same M/B.
>
> I have an Asus A7VC.  They're the motherboards that come with the
> cute little Asus Terminator K7s[1]; I have no idea if you can
> actually get this motherboard if you don't buy that kit.  So it's
> not a motherboard-specific problem.

OK.

> Relevant output from lspci for the A7VC:
>
>     00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133]
> (rev 81) 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365
> [KT133/KM133 AGP] 01:00.0 VGA compatible controller: S3 Inc. ProSavage
> KM133 (rev 03)
>
>     00:00.0 Class 0600: 1106:0305 (rev 81)
>     00:01.0 Class 0604: 1106:8305
>     01:00.0 Class 0300: 5333:8a26 (rev 03)

Yes, exactly the same as my...

Danijel