Re: Summary of KL133/KM133 problems w/2.4.18

Re: Summary of KL133/KM133 problems w/2.4.18

[Nilmoni Deb]

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


On Thu, 4 Apr 2002, Andre Pang wrote:

> On Thu, Apr 04, 2002 at 03:24:58AM -0500, Nilmoni Deb wrote:
> 
> > But the naming could have been more accurate and the following may be
> > good suggestions:
> > 
> > #define VIA_8364_KL133_REVISION_ID 0x84
> > #define VIA_8365_KM133_REVISION_ID 0x81
> 
> Thanks Nil!  I'll send off another patch to Alan/Marcelo/Dave
> when I get some time :).  (Feel free to do that if you like, of
> course.)
> 
> 
> -- 
> #ozone/algorithm <ozone@algorithm.com.au>          - trust.in.love.to.save
> 

Re: Summary of KL133/KM133 problems w/2.4.18

[Andre Pang]

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 <ozone@algorithm.com.au>          - trust.in.love.to.save

COMPILE error with 2.4.18: need help

[Nilmoni Deb]

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 (quintela@bi.mandrakesoft.com) (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

Re: Summary of KL133/KM133 problems w/2.4.18

[Nilmoni Deb]

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