Summary of KL133/KM133 problems w/2.4.18

Andre,
I just now discovered from http://www.viaarena.com/?PageID=70
that:

KM133 => VT8365 northbridge _always_
KL133 => VT8361 northbridge _OR_ VT8364 northbridge

Now (from kernel 2.4.18) linux-2.4.18/arch/i386/kernel/pci-pc.c has these comment lines:

* VIA 8363,8622,8361 Northbridges:
* - bits 5, 6, 7 at offset 0x55 need to be turned off

It appears that ur patch doesnot affect chipsets with VT8361 northbridge.

Basically, ur patch is applicable for all KM133 (VT8365) chipsets. But should it apply only to those KL133 chipsets with VT8364 northbridge or to KL133 chipsets with VT8361 northbridge too ?

So, besides the issue of renaming two macros, this patch needs to decide which (or all) of the two types of KL133 chipsets is to be targeted.

thanks
- Nil

Ah! Thanks for that ... viaarena.com should be definitive (since it's an official site), and might solve the whole "my motherboard has a VT836[1234567890xdeadbeef]" game for those K?133 chipsets.

The patch should apply to all KL133 chipsets; from what you've said, that appears to be the VT8361 and VT8364.

The KM133 (VT8365) is a less clear. From what I understand, it has an integrated video card (ProSavage), but it also has an AGP slot so that you can use your own video card if you like. We _may_ want to clear bit 5 if we're not using the integrated ProSavage. The only way to confirm this is to find somebody who has a KM133 who is using an external video card, and see what the Windows VIA drivers do. Any volunteers?

In general though, I think we should apply the same behaviour to the KM133 that we're using for the KL133 -- leave bit 5 alone, and don't clear it. All the VT836?s seem to have issues with touching bit 5, anyway, with or without the integrated ProSavage.

The northbridge chipsets are already correctly detected (revision IDs 0x81/0x84). I'm taking a guess that the VT8365 is revision ID 0x84, and either the VT8361 or VT8364 is revision ID 0x81, but I don't know which one. I'm not sure if finding out what's what is that important (other than being a pedant with the macro names), since we haven't hit anybody yet who has a KL133 with a northbridge that is not a revision of 0x81.

In a nutshell, it's just the macro names and comments which need to be clarified. (Not that they're any less important.) Thanks for pointing out the disparity :).

#ozone/algorithm <[email protected]>          - trust.in.love.to.save

Hi all,
I need to fix the severe video corruption problem on my KM133
chipset by the patch described in
the post http://www.uwsg.iu.edu/hypermail/linux/kernel/0204.0/0002.html .

I am using the stock gcc-2.96-0.76mdk of mandrake-8.2 to compile kernel 2.4.18-6mdk. But before applying the patch in the above post I ran a test to see if I could compile the default kernel source tree from /usr/src/linux with the mandrake supplied default .config file.

I ran these commands:

make dep
make clean
make bzImage
make modules

The first 3 commands worked fine. But in "make modules" I got the error:

make -C affs modules
make[2]: Entering directory `/home/ndeb/usr/src/linux-2.4.18-6mdk/fs/affs' gcc -D__KERNEL__ -I/home/ndeb/usr/src/linux-2.4.18-6mdk/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i586 -DMODULE -DMODVERSIONS -include /home/ndeb/usr/src/linux-2.4.18-6mdk/include/linux/modversions.h -DKBUILD_BASENAME=super -c -o super.o super.c
gcc -D__KERNEL__ -I/home/ndeb/usr/src/linux-2.4.18-6mdk/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i586 -DMODULE -DMODVERSIONS -include /home/ndeb/usr/src/linux-2.4.18-6mdk/include/linux/modversions.h -DKBUILD_BASENAME=namei -c -o namei.o namei.c
In file included from namei.c:11:
/home/ndeb/usr/src/linux-2.4.18-6mdk/include/linux/sched.h:6: nondigits in number and not hexadecimal /home/ndeb/usr/src/linux-2.4.18-6mdk/include/linux/sched.h:6: nondigits in number and not hexadecimal /home/ndeb/usr/src/linux-2.4.18-6mdk/include/linux/sched.h:6: parse error before `7b16c344' /home/ndeb/usr/src/linux-2.4.18-6mdk/include/linux/sched.h:6: warning:
function declaration isn't a prototype
make[2]: *** [namei.o] Error 1
make[2]: Leaving directory `/home/ndeb/usr/src/linux-2.4.18-6mdk/fs/affs' make[1]: *** [_modsubdir_affs] Error 2
make[1]: Leaving directory `/home/ndeb/usr/src/linux-2.4.18-6mdk/fs'
make: *** [_mod_fs] Error 2

Line 6 of linux-2.4.18-6mdk/include/linux/sched.h is ->

extern unsigned long event;

I have even tried egcs to compile and got the same error.

If I comment out line 6 of linux-2.4.18-6mdk/include/linux/sched.h then the compilation continues beyond this point but fails later.

The irony is that dmesg shows this ->

Linux version 2.4.18-6mdk ([email protected]) (gcc version 2.96 20000731 (Mandrake Linux 8.2 2.96-0.76mdk)) #1 Fri Mar 15 02:59:08 CET 2002

which means that the same kernel was compiled by the same compiler version which I am working with and is currently running on my machine!! I don't get it. How was this kernel compiled in the first place if it doesn't compile now ?

Any help is welcome.

thanks
- Nil

Hi Andre,
Consider this as one more positive feedback, though slightly
unorthodox. The graphics corruption problem on my KM133 chipset (revision 81) is gone, thanks to ur solution.

Since I had problems compiling the 2.4.18 kernel, I took the easy way out.

% lspci -s 00:00.0 -xxx
00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev
81)
00: 06 11 05 03 06 00 10 22 81 00 00 06 00 08 00 00
10: 08 00 00 d8 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 19 10 90 09
30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 16 f4 6b b4 47 08 10 10 80 00 08 10 10 10 10 10
60: 03 2a 00 20 d6 d4 d4 c4 50 5c 86 0f 08 21 00 00
70: de 88 4c 0c 0e 81 92 00 01 05 11 02 00 00 00 00
80: 0f 40 00 00 c0 00 00 00 02 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 02 c0 20 00 07 02 00 1f 00 00 00 00 2f 02 04 00
b0: ff ec 1a 48 f7 a1 40 00 07 00 00 00 00 00 00 00
c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 22 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 81 00 32 42 00 b0 00 00 00 00

The byte at location 0x55 has the hex value 08 which means bit 5 is 0. Bit 5 will be 1 if the value is hex 08 | 20 = 28.

% setpci -v -s 00:00.0 55.b=28
00:00.0:55 08

The setpci command does the job.

In fact, now I can turn this bit on and off whenever I want to and see the graphics corruption appearing/disappearing within seconds. I suggest that folks try this out _first_ before going thru the process of compiling, installing and running a patched kernel. This way any special cases for the various target chipsets will be identified beforehand. Also, this is convenient and the only way out when kernel compilation fails.

thanks
- Nil