Mach64 GX driver problems in post 2.4.22 kernels

Mach64 GX driver problems in post 2.4.22 kernels

[Thomas Jahns]

Hi,

I have the following problem when I try to build a new kernel for my  
PowerMac 7500 (604e CPU, PCI adapters: Adaptec 2940UW SCSI, Apple  
Mach64 GX card):

Kernel versions newer than my last build (of 2.4.22 plus preempt, benh,  
lowlatency, ea+acl+nfsacl, cryptoloop patches, all from debian sid  
source packages of that time) show a blank screen when switching to the  
Mach64 framebuffer (BootX pre-boot messages are fine). The kernel  
continues to boot and even activates the atyfb driver so I can login  
blind on the console or remotely via ssh.

I have so far built the following kernels: 2.4.25 from debian package  
kernel-source-2.4.25_2.4.25-3, with and without the debian kernel- 
patch-2.4.25-powerpc patch derived from Benjamin Herrenschmidt's source  
tree, a kernel from each of www.kernel.org 2.4.26 and 2.4.25 archives  
(without any patches) and a downloaded kernel from Benjamin's site  
directly (rsync'ed on 2004/06/01, ca. 16:30). All of these builds show  
the behaviour outlined above: kernel boots fine but screen blanks  
immediatly.

As Mach64 is obviously quite important to a number of PowerMacs I hope  
someone already stumbled across the same problem, although I couldn't  
find anything truely specific by googling.

Please tell if you need any more specific logs or info, I'll include  
the dmesg lines and lspci -v output relevant to the card for a start:

> dmesg | grep -i \(aty\|console\)
Kernel command line: root=/dev/sda7 video=atyfb:vmode:18:cmode:8  
panic=60
Console: colour dummy device 80x25
atyfb: mach64GX (ATI888GX00) [0x00d7 rev 0x03] 4M VRAM, 14.31818 MHz  
XTAL, 135
MHz PLL, 50 Mhz MCLK
Console: switching to colour frame buffer device 144x54
fb0: ATY Mach64 frame buffer device on PCI
MacOS display is /bandit/ATY,mach64

I noticed one of these lines reads differently on my 2.4.22 kernel:

atyfb: mach64GX (ATI888GX00) [0x00d7 rev 0x03] 4M VRAM, 14.31818 MHz
XTAL, 135 MHz PLL, 50 Mhz MCLK
                   ^^^^^^^^^^^
Would that be a sign of the culprit?

> lspci -v -s 00:0f.0
0000:00:0f.0 VGA compatible controller: ATI Technologies Inc 210888GX  
[Mach64
GX] (rev 03) (prog-if 00 [VGA])
       Flags: stepping, medium devsel, IRQ 25
       Memory at 81000000 (32-bit, non-prefetchable) [size=16M]
       Expansion ROM at <unassigned> [disabled] [size=64K]



Thanks for any input you can provide with respect to my problem.

Ciao, Thomas Jahns
-- 
"Computers are good at following instructions,
 but not at reading your mind."
D. E. Knuth, The TeXbook, Addison-Wesley 1984, 1986, 1996, p. 9


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504

Re: Mach64 GX driver problems in post 2.4.22 kernels

[Thomas Jahns]

Hi again,

On 06/05/04 20:56:47, Thomas Jahns wrote:
>> dmesg | grep -i \(aty\|console\)
> Kernel command line: root=/dev/sda7 video=atyfb:vmode:18:cmode:8  
> panic=60
> Console: colour dummy device 80x25
> atyfb: mach64GX (ATI888GX00) [0x00d7 rev 0x03] 4M VRAM, 14.31818 MHz  
> XTAL, 135
> MHz PLL, 50 Mhz MCLK
> Console: switching to colour frame buffer device 144x54
> fb0: ATY Mach64 frame buffer device on PCI
> MacOS display is /bandit/ATY,mach64

classic error, the above line reads the same as that below because copy  
and paste swallowed exactly the part of the line which is different, so  
here it comes again (now hopefully complete):

atyfb: mach64GX (ATI888GX00) [0x00d7 rev 0x03] 4M VRAM, 14.31818 MHz  
XTAL, 135 MHz PLL, 50 Mhz MCLK, 50 Mhz XCLK

> I noticed one of these lines reads differently on my 2.4.22 kernel:
> 
> atyfb: mach64GX (ATI888GX00) [0x00d7 rev 0x03] 4M VRAM, 14.31818 MHz
> XTAL, 135 MHz PLL, 50 Mhz MCLK
                                 ^^^^^^^^^^^

Ciao, Thomas Jahns
-- 
"Computers are good at following instructions,
 but not at reading your mind."
D. E. Knuth, The TeXbook, Addison-Wesley 1984, 1986, 1996, p. 9


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504

Re: Mach64 GX driver problems in post 2.4.22 kernels

[Thomas Jahns]

Hi,

my problem of non-working display with atyfb and a Mach64 GX card in a  
Powermac 7500 is still unsolved and my posting here got no replies.

So I wanted to ask:

- Did I perhaps post to the wrong list?
- If yes, where else should I ask for help?
- Does anyone have a similar enough configuration to verify the bug?

Thomas Jahns
-- 
"Computers are good at following instructions,
 but not at reading your mind."
D. E. Knuth, The TeXbook, Addison-Wesley 1984, 1986, 1996, p. 9


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

Re: Mach64 GX driver problems in post 2.4.22 kernels

[David Eger]

Could you send your .config?  (This could only help with the most 
trivial of problems, but worth a shot.)

You're posting to the right list; you're probably not getting responses
because none of the active framebuffer developers have a setup similar 
enough to yours :-/

At least, that's why I'd not responded... still trying to debug radeon
and cirrus...

-dte


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

Re: Mach64 GX driver problems in post 2.4.22 kernels

[Geert Uytterhoeven]

On Mon, 21 Jun 2004, David Eger wrote:
> You're posting to the right list; you're probably not getting responses
> because none of the active framebuffer developers have a setup similar
> enough to yours :-/

Indeed. Mach64 GX are old and rare. And since they didn't have an integrated
clock generator and RAMDAC, they used (many different) external parts, leading
to lots of possible combinations to support...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

Re: Mach64 GX driver problems in post 2.4.22 kernels

[David Eger]

Dear Thomas,

> my problem of non-working display with atyfb and a Mach64 GX card in a  
> Powermac 7500 is still unsolved and my posting here got no replies.
> 

James just posted a framebuffer update against 2.6.7 that he says
includes Mach64 updates. It looks like he did a lot of cleanup, and
possibly some logical changes -- you might try his patch and let him/us
know if it's any help.

his patch: http://www.infradead.org/~jsimmons/changes.diff

-dte



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Mach64 GX driver problems in post 2.4.22 kernels

[Thomas Jahns]

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

On 06/21/04 10:08:58, David Eger wrote:
> 
> Could you send your .config?  (This could only help with the most
> trivial of problems, but worth a shot.)

Okay, I'll bzip the .configs and also include a diff I created from  
both files with the following sequence of commands (tungsten is the  
hostname of the Pmac in question):

 > grep -v '^#' ../boot/config-2.4.22-tungsten >config-2.4.22-tungsten. 
cleanup
 > grep -v '^#' ../boot/config-2.4.25-tungsten >config-2.4.25-tungsten. 
cleanup
 > diff -u config-2.4.2*cleanup >dot.config.diff-u

see below for the diff. PREEMPT is no longer selected because this diff  
is already for a kernel configuration that I did not patch as much as  
the working 2.4.22 kernel to limit the potential error sources.

> You're posting to the right list; you're probably not getting
> responses because none of the active framebuffer developers have a  
> setup similar enough to yours :-/

That's unfortunate, I think quite a number of Macs in the 9500 and 9600  
lines came preinstalled with such cards and ATI cards were also a  
popular upgrade for Mac graphics at that time.

> At least, that's why I'd not responded... still trying to debug  
> radeon and cirrus...

I'm also a user of the radeon driver so keep up the good work.

Ciao, Thomas

--- config-2.4.22-tungsten.cleanup	2004-06-24 22:30:01.000000000  
+0200
+++ config-2.4.25-tungsten.cleanup	2004-06-24 22:30:07.000000000  
+0200
@@ -11,9 +11,12 @@
 CONFIG_6xx=y
 CONFIG_PPC_STD_MMU=y
 CONFIG_ALL_PPC=y
-CONFIG_PREEMPT=y
 CONFIG_PPC_ISATIMER=y

+CONFIG_HIGHMEM_START=0xfe000000
+CONFIG_LOWMEM_SIZE=0x30000000
+CONFIG_KERNEL_START=0xc0000000
+CONFIG_TASK_SIZE=0x80000000
 CONFIG_PCI=y
 CONFIG_NET=y
 CONFIG_SYSCTL=y
@@ -93,6 +96,10 @@
 CONFIG_IP_NF_TARGET_LOG=m
 CONFIG_IP_NF_TARGET_ULOG=m
 CONFIG_IP_NF_TARGET_TCPMSS=m
+
+
+CONFIG_IPV6_SCTP__=y
+
 CONFIG_ATALK=m


@@ -100,6 +107,7 @@


 CONFIG_SCSI=y
+
 CONFIG_BLK_DEV_SD=y
 CONFIG_SD_EXTRA_DEVS=40
 CONFIG_CHR_DEV_ST=y
@@ -107,6 +115,7 @@
 CONFIG_BLK_DEV_SR_VENDOR=y
 CONFIG_SR_EXTRA_DEVS=2
 CONFIG_CHR_DEV_SG=m
+
 CONFIG_SCSI_CONSTANTS=y

 CONFIG_SCSI_AIC7XXX_OLD=y
@@ -178,9 +187,12 @@



+
 CONFIG_NVRAM=y

+
 CONFIG_DRM=y
+
 CONFIG_DRM_NEW=y
 CONFIG_DRM_R128=m

@@ -218,11 +230,9 @@

 CONFIG_NFS_FS=m
 CONFIG_NFS_V3=y
-CONFIG_NFS_ACL=y
 CONFIG_NFS_DIRECTIO=y
 CONFIG_NFSD=m
 CONFIG_NFSD_V3=y
-CONFIG_NFSD_ACL=y
 CONFIG_NFSD_TCP=y
 CONFIG_SUNRPC=m
 CONFIG_LOCKD=m
@@ -251,6 +261,9 @@
 CONFIG_SOUND=y
 CONFIG_DMASOUND_PMAC=m
 CONFIG_DMASOUND=m
+CONFIG_I2C=m
+CONFIG_I2C_KEYWEST=m
+



@@ -273,6 +286,6 @@
 CONFIG_CRC32=m
 CONFIG_ZLIB_INFLATE=m
 CONFIG_ZLIB_DEFLATE=m
-CONFIG_QSORT=y

 CONFIG_BOOTX_TEXT=y
+CONFIG_LOG_BUF_SHIFT=0


[-- Attachment #2: config-2.4.22-tungsten.bz2 --]
[-- Type: application/x-bzip, Size: 4186 bytes --]

[-- Attachment #3: config-2.4.25-tungsten.bz2 --]
[-- Type: application/x-bzip, Size: 4035 bytes --]

Re: Mach64 GX driver problems in post 2.4.22 kernels

[Thomas Jahns]

On 06/23/04 20:31:33, David Eger wrote:
> James just posted a framebuffer update against 2.6.7 that he says
> includes Mach64 updates. It looks like he did a lot of cleanup, and
> possibly some logical changes -- you might try his patch and let
> him/us
> know if it's any help.
> 
> his patch: http://www.infradead.org/~jsimmons/changes.diff

Thanks I'll try that as soon as I find the time to download 2.6.7 (will  
the kernel source ever get smaller?;-)).

Nice weekend everyone, Thomas
-- 
"Computers are good at following instructions,
 but not at reading your mind."
D. E. Knuth, The TeXbook, Addison-Wesley 1984, 1986, 1996, p. 9


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com