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 ------------------------------
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
> > 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
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
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
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
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 <[email protected]> - trust.in.love.to.save
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);
}
}
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
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);
}
}
> 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.
> > 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
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 <[email protected]>
Tom Brehm <[email protected]>
Andre Pang <[email protected]>
Steven Walter <[email protected]>
Tom Eastep <[email protected]>
Regards,
Danijel
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
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 <[email protected]> - trust.in.love.to.save
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 <[email protected]> - trust.in.love.to.save
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 <[email protected]> - trust.in.love.to.save
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
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 <[email protected]> - trust.in.love.to.save
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
[email protected]
http://members.cox.net/msw
On Mon, 25 Mar 2002 00:50:53 -0800
Marc Wilson <[email protected]> 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
> [email protected]
> 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
On 25 Mar 02 at 12:07, Daniel Gryniewicz 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
>
> 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133]
> (rev 02) (KT7-RAID, KT133)
> 00:01.0 Class 0604: 1106:8305
You can try revisions. All KMxxx I saw had revision 8x, while (this) KT133
has 0x.
Best regards,
Petr Vandrovec
[email protected]
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
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
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
[email protected]
http://members.cox.net/msw
>Does everyone who sees this problem have the 8363/5 combination with the
>onboard Pro-Savage
>
>
>Alan
I have this chipset with a built-in S3 Savage and am experiencing the
problem. Up till now I just removed the line from pci-pc.c, safe or
unsafe it fixed the video garble.
I have the Asus Terminator "bare bones" system. The small cute all-in-one
box.
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]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40)
00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06)
00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 1a)
00:07.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 1a)
00:07.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
00:07.5 Multimedia audio controller: VIA Technologies, Inc. AC97 Audio Controller (rev 50)
00:0e.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone]
00:12.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 10)
01:00.0 VGA compatible controller: S3 Inc. ProSavage KM133 (rev 03)
Please CC,
BH
On Thursday 28 March 2002 23:46, Bill Hammock wrote:
> I have this chipset with a built-in S3 Savage and am experiencing the
> problem. Up till now I just removed the line from pci-pc.c, safe or
> unsafe it fixed the video garble.
One more with the problem...
> I have the Asus Terminator "bare bones" system. The small cute all-in-one
> box.
>
>
> 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev
> 81) 00:01.0
It's interesting that everyone who is experiencing these problems has the
*revision 81* of the VT8365 chipset! This should be the key...
Danijel
On Fri, Mar 29, 2002 at 01:14:47AM +0100, Danijel Schiavuzzi wrote:
> > 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev
> > 81) 00:01.0
>
> It's interesting that everyone who is experiencing these problems has the
> *revision 81* of the VT8365 chipset! This should be the key...
You know, we might be barking down the wrong tree. (Arf.)
So far, everybody who has reported video corruption seems to have
a Savage or ProSavage video card. Maybe it'd be a better idea to
look at the ProSavage data sheets and see if we should be
tweaking something there? That would be much safer than playing
around with the northbridges.
--
#ozone/algorithm <[email protected]> - trust.in.love.to.save
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 <[email protected]> - trust.in.love.to.save
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
[email protected]
http://members.cox.net/msw
On 29 Mar 02 at 13:05, Andre Pang wrote:
> On Fri, Mar 29, 2002 at 01:14:47AM +0100, Danijel Schiavuzzi wrote:
>
> > > 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev
> > > 81) 00:01.0
> >
> > It's interesting that everyone who is experiencing these problems has the
> > *revision 81* of the VT8365 chipset! This should be the key...
>
> You know, we might be barking down the wrong tree. (Arf.)
>From my findings revision 81 is KL133/KL133A (and only KL133 is affected
by clearing bit 5 in 0x55, KL133A works fine in both configs). KM133/KM133A
have revision 84, and KM133 is affected (I have no idea about KM133A).
> So far, everybody who has reported video corruption seems to have
> a Savage or ProSavage video card. Maybe it'd be a better idea to
Because of they are integrated with K[LM]133...
> look at the ProSavage data sheets and see if we should be
> tweaking something there? That would be much safer than playing
> around with the northbridges.
As now we have also report (from G550 user) that PCI -> AGP transfers
are broken when bit 5 is cleared, I think that playing dangerous games
with northbridge is only way to go.
Petr Vandrovec
[email protected]
Hi,
I have an i840 motherboard with dual 733 MHz PIIIs and a Matrox G400
MAX, and I am also seeing console corruption with 2.4.18. The difference
with me is that I *only* see it when I am using xine (CVS) and the
SyncFB video plugin, possibly the Xv video plugin sometimes too. When I
kill xine, the regular multicoloured rectangle disappears from the console.
Obviously, this isn't something that I would normally notice - I
wouldn't have noticed at all if the CVS xine hadn't locked up on me in
full-screen mode, forcing me to turn to a console to kill it.
A few other things:
- since I have about 1.25 GB of RAM, I have enabled a 256 MB AGP aperture.
- I am using XFree86 4.2, but with the mga.o module that is native to
Linux 2.4.18. I have not installed the Matrox HAL X module.
Whatever is causing this console corruption, it doesn't seem to be a VIA
bug (in my case, anyway).
Chris
On 2 Apr 02 at 22:43, Chris Rankin wrote:
>
> I have an i840 motherboard with dual 733 MHz PIIIs and a Matrox G400
> MAX, and I am also seeing console corruption with 2.4.18. The difference
> with me is that I *only* see it when I am using xine (CVS) and the
> SyncFB video plugin, possibly the Xv video plugin sometimes too. When I
> kill xine, the regular multicoloured rectangle disappears from the console.
>
> Whatever is causing this console corruption, it doesn't seem to be a VIA
> bug (in my case, anyway).
It is something completely different - your color rectangle is xine (or Xv)
still painting to framebuffer although X are no longer visible. If
you are using matroxfb, you should see either single color rectangle
(in overlay mode) or picture from xine (in direct paint mode). With
vgacon you'll see single color areas of strange stable characters in overlay
mode, and multicolored areas of strange changing characters in non-overlay
mode.
VIA corruption exists without X, and appears just immediately, during
kernel boot sequence.
Petr Vandrovec
[email protected]
--- Petr Vandrovec <[email protected]> wrote:
> On 2 Apr 02 at 22:43, Chris Rankin wrote:
> It is something completely different - your color
> rectangle is xine (or Xv)
> still painting to framebuffer although X are no
> longer visible. If
> you are using matroxfb, you should see either single
> color rectangle
> (in overlay mode) or picture from xine (in direct
> paint mode). With
> vgacon you'll see single color areas of strange
> stable characters in overlay
> mode, and multicolored areas of strange changing
> characters in non-overlay
> mode.
OK, but for the record, I'm not using a framebuffer.
My console is text-mode.
Chris
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
On Tue, 2 Apr 2002, Chris Rankin wrote:
[SNIPPED...]
>
> A few other things:
> - since I have about 1.25 GB of RAM, I have enabled a 256 MB AGP aperture.
What? 'since amount of RAM' has nothing to do with AGP aperature. The
aperature should be the same as the amount of AGP shared RAM used for
the screen-card on-board graphics. This is normally set by the BIOS but
can be reset if the BIOS doesn't 'understand' your screen card.
So, unless you have 256 MB on your screen board, typically 32 MB for
high-resolution true-color boards, you will be disabling PCI hardware
hand-shaking for a lot of addresses above your screen board. This
can make DRAM-controler, controlled RAM accesses interfere.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Windows-2000/Professional isn't.
--- "Richard B. Johnson" <[email protected]>
wrote: > On Tue, 2 Apr 2002, Chris Rankin wrote:
> [SNIPPED...]
>
> >
> > A few other things:
> > - since I have about 1.25 GB of RAM, I have
> enabled a 256 MB AGP aperture.
>
> What? 'since amount of RAM' has nothing to do with
> AGP aperature. The
> aperature should be the same as the amount of AGP
> shared RAM used for
> the screen-card on-board graphics. This is normally
> set by the BIOS but
> can be reset if the BIOS doesn't 'understand' your
> screen card.
>
> So, unless you have 256 MB on your screen board,
> typically 32 MB for
> high-resolution true-color boards, you will be
> disabling PCI hardware
> hand-shaking for a lot of addresses above your
> screen board. This
> can make DRAM-controler, controlled RAM accesses
> interfere.
I set the AGP aperture based upon the following
information:
"The AGP aperture is an area of system RAM reserved
for use by the AGP card for storing textures if it
needs to. The RAM is available for use by the system
as normal if not used by the graphics card."
...
"It is generally advised to set the AGP aperture to
half the system RAM ."
Therefore, it seemed reasonable to maximise my AGP
aperture size for all and any conceivable textures (I
have system RAM to spare), with no harm done.
Admittedly, 256 MB does seem excessive, but anyway ...
;-).
Chris
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
On Tue, 02 Apr 2002 22:43:03 +0100
Chris Rankin <[email protected]> wrote:
> Hi,
>
> I have an i840 motherboard with dual 733 MHz PIIIs and a Matrox G400
> MAX, and I am also seeing console corruption with 2.4.18. The difference
> with me is that I *only* see it when I am using xine (CVS) and the
> SyncFB video plugin, possibly the Xv video plugin sometimes too. When I
> kill xine, the regular multicoloured rectangle disappears from the console.
>
> Obviously, this isn't something that I would normally notice - I
> wouldn't have noticed at all if the CVS xine hadn't locked up on me in
> full-screen mode, forcing me to turn to a console to kill it.
>
> A few other things:
> - since I have about 1.25 GB of RAM, I have enabled a 256 MB AGP aperture.
> - I am using XFree86 4.2, but with the mga.o module that is native to
> Linux 2.4.18. I have not installed the Matrox HAL X module.
>
> Whatever is causing this console corruption, it doesn't seem to be a VIA
> bug (in my case, anyway).
>
> Chris
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
I'm having the same problem, just that this happens when I've been using mplayer with the -vo vesa parameters. I also have this problem with the 2.4.17 kernel.
--
--
Best regards, Erik
On Tue, 2 Apr 2002, [iso-8859-1] Chris Rankin wrote:
> --- "Richard B. Johnson" <[email protected]>
> wrote: > On Tue, 2 Apr 2002, Chris Rankin wrote:
> > [SNIPPED...]
> >
> > >
> > > A few other things:
> > > - since I have about 1.25 GB of RAM, I have
> > enabled a 256 MB AGP aperture.
> >
> > What? 'since amount of RAM' has nothing to do with
> > AGP aperature. The
> > aperature should be the same as the amount of AGP
> > shared RAM used for
> > the screen-card on-board graphics. This is normally
> > set by the BIOS but
> > can be reset if the BIOS doesn't 'understand' your
> > screen card.
> >
> > So, unless you have 256 MB on your screen board,
> > typically 32 MB for
> > high-resolution true-color boards, you will be
> > disabling PCI hardware
> > hand-shaking for a lot of addresses above your
> > screen board. This
> > can make DRAM-controler, controlled RAM accesses
> > interfere.
>
> I set the AGP aperture based upon the following
> information:
>
> "The AGP aperture is an area of system RAM reserved
> for use by the AGP card for storing textures if it
> needs to. The RAM is available for use by the system
> as normal if not used by the graphics card."
> ...
> "It is generally advised to set the AGP aperture to
> half the system RAM ."
>
> Therefore, it seemed reasonable to maximise my AGP
> aperture size for all and any conceivable textures (I
> have system RAM to spare), with no harm done.
> Admittedly, 256 MB does seem excessive, but anyway ...
> ;-).
>
> Chris
>
>From Page 153, "The BIOS COMPANION" ISBN 188967120-7
"The AGP Aperture Size is the amount of system memory for the
AGP card, so host cycles hitting that area are forwarded to that
card without translation..."
This may be causing confusion because it really should read
"amount of system address space". Too many writers interchange
the word "memory" for "address space".
No graphics cards, on their own, or with their own BIOS, use any
"system memory". They can't. They don't "own" any. Of course, when
you run X, X will own some system memory that it allocated via mmap(),
and it uses it in conjunction with your AGP card. The internal RAM
within the AGP card is the only RAM in "owns". This is accessible
to the CPU as well as the card electronics. The address range through
which the CPU can access this high-speed RAM is called the Graphics
Aperture and/or the AGP Aperture.
This is the same thing as (page 139), "VGA Frame Buffer Size"
for the older PCI/VGA boards.
So, if you set your AGP aperture size to overlap address-space where
memory exists, you will probably see streaking and flashing (snow) on
the screen. The bus-contention will also slow your machine during
RAM access and may even cause data corruption in RAM. In other words,
if you have 32 MB of RAM in your screen-card, set the aperture size
to 32 MB, not (!) 256 MB.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Windows-2000/Professional isn't.
--- "Richard B. Johnson" <[email protected]>
wrote:
> if you have 32 MB of RAM in your screen-card, set
> the aperture size
> to 32 MB, not (!) 256 MB.
OK, I've reset the aperture to 32MB and I no longer
get screen corruption with xine. However, it appears
that there are a lot of different opinions on how to
best set the AGP aperture:
http://www.lostcircuits.com/advice/bios2/12.shtml
Chris
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com