On Thu, Apr 04, 2002 at 02:23:31PM -0500, Nilmoni Deb wrote:
> I just now discovered from http://www.viaarena.com/?PageID=70
> that:
>
> KM133 => VT8365 northbridge _always_
> KL133 => VT8361 northbridge _OR_ VT8364 northbridge
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.
> 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 ?
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.
> 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.
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