AGP problem SiS 746FX Linux 2.6.5-rc3

AGP problem SiS 746FX Linux 2.6.5-rc3

[Hemmann, Volker Armin]

Hi,

in 2.6.5-rc3 was incorporated a fix for SiS648 chipsets that need a little 
time to get into a sane state again, after switching to AGP 8x.
The 746FX has the same timing problem and needs this 'pause', too.
Unfortunatly in sis-apg.c this fix is only checked against the 648, not the 
746, so the fix never gets invoked:

    		if(device->device == PCI_DEVICE_ID_SI_648) {
			// weird: on 648 and 648fx chipsets any rate change in the target command 
register
			// triggers a 5ms screwup during which the master cannot be configured
			printk(KERN_INFO PFX "sis 648 agp fix - giving bridge time to recover\n");
			set_current_state(TASK_UNINTERRUPTIBLE);
			schedule_timeout (1+(HZ*10)/1000);


Glück Auf,
Volker


-- 
Conclusions 
 In a straight-up fight, the Empire squashes the Federation like a bug. Even 
with its numerical advantage removed, the Empire would still squash the 
Federation like a bug. Accept it. -Michael Wong 

Re: AGP problem SiS 746FX Linux 2.6.5-rc3

[Dave Jones]

On Thu, Apr 01, 2004 at 07:00:47PM +0200, Hemmann, Volker Armin wrote:
 > Hi,
 > 
 > in 2.6.5-rc3 was incorporated a fix for SiS648 chipsets that need a little 
 > time to get into a sane state again, after switching to AGP 8x.
 > The 746FX has the same timing problem and needs this 'pause', too.
 > Unfortunatly in sis-apg.c this fix is only checked against the 648, not the 
 > 746, so the fix never gets invoked:

Ah, yes. I actually had that in mind when I merged this code, but it
must've got paged out 8-)

Can you send lspci -n output please?

		Dave

Re: AGP problem SiS 746FX Linux 2.6.5-rc3

[Hemmann, Volker Armin]

Hi,

On Thursday 01 April 2004 19:10, Dave Jones wrote:
> On Thu, Apr 01, 2004 at 07:00:47PM +0200, Hemmann, Volker Armin wrote:
>  > Hi,
>  >
>  > in 2.6.5-rc3 was incorporated a fix for SiS648 chipsets that need a
>  > little time to get into a sane state again, after switching to AGP 8x.
>  > The 746FX has the same timing problem and needs this 'pause', too.
>  > Unfortunatly in sis-apg.c this fix is only checked against the 648, not
>  > the 746, so the fix never gets invoked:
>
> Ah, yes. I actually had that in mind when I merged this code, but it
> must've got paged out 8-)
>
> Can you send lspci -n output please?
>
> 		Dave

here it is:
energy root # lspci -n
0000:00:00.0 Class 0600: 1039:0746 (rev 02)
0000:00:01.0 Class 0604: 1039:0002
0000:00:02.0 Class 0601: 1039:0963 (rev 25)
0000:00:02.1 Class 0c05: 1039:0016
0000:00:02.5 Class 0101: 1039:5513
0000:00:03.0 Class 0c03: 1039:7001 (rev 0f)
0000:00:03.1 Class 0c03: 1039:7001 (rev 0f)
0000:00:03.2 Class 0c03: 1039:7002
0000:00:04.0 Class 0200: 1039:0900 (rev 90)
0000:00:0b.0 Class 0400: 109e:0350 (rev 12)
0000:00:0d.0 Class 0401: 13f6:0111 (rev 10)
0000:01:00.0 Class 0300: 10de:0322 (rev a1)


Glück Auf,
Volker

-- 
Conclusions 
 In a straight-up fight, the Empire squashes the Federation like a bug. Even 
with its numerical advantage removed, the Empire would still squash the 
Federation like a bug. Accept it. -Michael Wong 

Re: AGP problem SiS 746FX Linux 2.6.5-rc3

[Bjoern Michaelsen]

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

On Thu, Apr 01, 2004 at 07:00:47PM +0200, Hemmann, Volker Armin
wrote:
[...]
Hi,

I wrote a patch against 2.6.5 to let the SiS 746 take advantage
of the SiS 648 patches too.
http://bugzilla.kernel.org/show_bug.cgi?id=2327

Your sincerly,

Björn
-- 
Björn Michaelsen
pub  1024D/C9E5A256 2003-01-21 Björn Michaelsen <bmichaelsen@gmx.de>
   Key fingerprint = D649 8C78 1CB1 23CF 5CCF  CA1A C1B5 BBEC C9E5 A256

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: AGP problem SiS 746FX Linux 2.6.5-rc3

[Dave Jones]

On Tue, Apr 06, 2004 at 05:19:49AM +0200, Bjoern Michaelsen wrote:

 > I wrote a patch against 2.6.5 to let the SiS 746 take advantage
 > of the SiS 648 patches too.
 > http://bugzilla.kernel.org/show_bug.cgi?id=2327

That and a few others are in the pending queue which I'll push
when Linus gets back. See http://www.codemonkey.org.uk/projects/bitkeeper/agpgart/
for the patch-of-the-day from bk://linux-dj.bkbits.net/agpgart

In particular theres an additional fix for SiS users, I broke
AGPv2 support in the previous fix that went into 2.6.5

		Dave

Re: AGP problem SiS 746FX Linux 2.6.5-rc3

[Hemmann, Volker Armin]

On Tuesday 06 April 2004 15:50, Dave Jones wrote:
> On Tue, Apr 06, 2004 at 05:19:49AM +0200, Bjoern Michaelsen wrote:
>  > I wrote a patch against 2.6.5 to let the SiS 746 take advantage
>  > of the SiS 648 patches too.
>  > http://bugzilla.kernel.org/show_bug.cgi?id=2327
>
> That and a few others are in the pending queue which I'll push
> when Linus gets back. See
> http://www.codemonkey.org.uk/projects/bitkeeper/agpgart/ for the
> patch-of-the-day from bk://linux-dj.bkbits.net/agpgart
>
> In particular theres an additional fix for SiS users, I broke
> AGPv2 support in the previous fix that went into 2.6.5
>
> 		Dave

I tried your diff from codemonkey.org against 2.6.5. witch patch -p1 < 
your.diff in /usr/src/linux. It applied and compiled, but after the reboot, 
testgart failed:
bash-2.05b$ testgart
open: No such file or directory

I reinstalled the nvidia drivers, started X, looked 
into /proc/drivers/nvidia/agp/status: disabled.

Now I did, what I should have done at the first place, dmesg:

Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected SiS 746 chipset
agpgart: Maximum main memory to use for agp memory: 439M
agpgart: unable to determine aperture size.
agpgart: agp_backend_initialize() failed.
agpgart-sis: probe of 0000:00:00.0 failed with error -22

I am rebooting after the mail back to 2.6.5-rc3 with the 'old' patches from 
last week, because even 2D is real slow now...

Glück Auf,
Volker 

-- 
Conclusions 
 In a straight-up fight, the Empire squashes the Federation like a bug. Even 
with its numerical advantage removed, the Empire would still squash the 
Federation like a bug. Accept it. -Michael Wong 

Re: AGP problem SiS 746FX Linux 2.6.5-rc3

[Dave Jones]

On Tue, Apr 06, 2004 at 08:04:34PM +0200, Hemmann, Volker Armin wrote:

 > Now I did, what I should have done at the first place, dmesg:
 > 
 > Linux agpgart interface v0.100 (c) Dave Jones
 > agpgart: Detected SiS 746 chipset
 > agpgart: Maximum main memory to use for agp memory: 439M
 > agpgart: unable to determine aperture size.
 > agpgart: agp_backend_initialize() failed.
 > agpgart-sis: probe of 0000:00:00.0 failed with error -22

something isn't right here. this takes us right back to where we
were before your first email about this problem.
Did the patch definitly apply to the tree you compiled ?
Not booted into the wrong kernel by mistake ?

 > I am rebooting after the mail back to 2.6.5-rc3 with the 'old' patches from 
 > last week, because even 2D is real slow now...

that's an nvidia problem, agpgart has no interaction with 2d whatsoever.

		Dave

Re: AGP problem SiS 746FX Linux 2.6.5-rc3

[Hemmann, Volker Armin]

On Tuesday 06 April 2004 20:11, Dave Jones wrote:
> On Tue, Apr 06, 2004 at 08:04:34PM +0200, Hemmann, Volker Armin wrote:
>  > Now I did, what I should have done at the first place, dmesg:
>  >
>  > Linux agpgart interface v0.100 (c) Dave Jones
>  > agpgart: Detected SiS 746 chipset
>  > agpgart: Maximum main memory to use for agp memory: 439M
>  > agpgart: unable to determine aperture size.
>  > agpgart: agp_backend_initialize() failed.
>  > agpgart-sis: probe of 0000:00:00.0 failed with error -22
>
> something isn't right here. this takes us right back to where we
> were before your first email about this problem.
> Did the patch definitly apply to the tree you compiled ?
> Not booted into the wrong kernel by mistake ?

I made sure, that I am booted 2.6.5, removed /usr/src/linux-2.6.5, 
and /lib/modules/2.6.5, unpacked the tarball by hand, in case the ebuild did 
some patching, made a symlink with ln -s linux-2.6.5 linux and cd'ed into 
linux.
There I copied agpgart-2004-04-06.diff into /usr/src/linux and applied it with 
patch -p1 < agpgart-2004-04-06.diff

It said, that it was applied against sis, intel, efficion and via (not this 
order..) and I found no *.rej files, while the supposed to be patched files 
had an actual timestamp.

After that I copied over my .config from 2.6.5-rc3, made make oldconfig, 
without any problems, and make all modules_install install after that.
Grub points to vmlinuz, so everything fine there.

I rebooted.
Same error, uname -r:
Linux energy.heim10.tu-clausthal.de 2.6.5 #1 Tue Apr 6 20:26:45 CEST 2004 i686 
AMD Athlon(tm) XP 2000+ AuthenticAMD GNU/Linux

So yes, I am pretty sure, that I am innocent ;o)

Glück Auf
Volker

-- 
Conclusions 
 In a straight-up fight, the Empire squashes the Federation like a bug. Even 
with its numerical advantage removed, the Empire would still squash the 
Federation like a bug. Accept it. -Michael Wong 

Re: AGP problem SiS 746FX Linux 2.6.5-rc3

[Dave Jones]

On Tue, Apr 06, 2004 at 08:44:06PM +0200, Hemmann, Volker Armin wrote:

 > I rebooted.
 > Same error, uname -r:
 > Linux energy.heim10.tu-clausthal.de 2.6.5 #1 Tue Apr 6 20:26:45 CEST 2004 i686 
 > AMD Athlon(tm) XP 2000+ AuthenticAMD GNU/Linux
 > 
 > So yes, I am pretty sure, that I am innocent ;o)

Ok, what happens if you nuke the ..

	} else {
		sis_driver.agp_enable=sis_648_enable;
	}

in sis_get_driver() ?
That should put things back to 2.6.4 style "working" order for you.

		Dave

Re: AGP problem SiS 746FX Linux 2.6.5-rc3

[Hemmann, Volker Armin]

Hi,

On Tuesday 06 April 2004 21:24, Dave Jones wrote:
> On Tue, Apr 06, 2004 at 08:44:06PM +0200, Hemmann, Volker Armin wrote:
>  > I rebooted.
>  > Same error, uname -r:
>  > Linux energy.heim10.tu-clausthal.de 2.6.5 #1 Tue Apr 6 20:26:45 CEST
>  > 2004 i686 AMD Athlon(tm) XP 2000+ AuthenticAMD GNU/Linux
>  >
>  > So yes, I am pretty sure, that I am innocent ;o)
>
> Ok, what happens if you nuke the ..
>
> 	} else {
> 		sis_driver.agp_enable=sis_648_enable;
> 	}
>
> in sis_get_driver() ?
> That should put things back to 2.6.4 style "working" order for you.
>
> 		Dave

more bad news, it did not.
It compiled and the module loaded, but with the error again.
I copied over tht sis-agp.c from 2.6.5-rc3 that was modified with your patches 
last week and AGP is now working again.
I did a diff between the modified sis-agp.c from 2.6.5 (sis-agp.bak, without 
the else) and the working sis-agp.c from 2.6.5-rc3 (now in 2.6.5):


bash-2.05b$ diff 
-u /usr/src/linux/drivers/char/agp/sis-agp.bak /usr/src/linux-2.6.5-rc3/drivers/char/agp/sis-agp.c
--- /usr/src/linux/drivers/char/agp/sis-agp.bak 2004-04-06 21:43:53.000000000 
+0200
+++ /usr/src/linux-2.6.5-rc3/drivers/char/agp/sis-agp.c 2004-04-02 
03:21:43.000000000 +0200
@@ -92,17 +92,17 @@
<snap only whitespace difference> 

@@ -225,9 +225,11 @@

 static void __devinit sis_get_driver(struct agp_bridge_data *bridge)
 {
-       if (bridge->dev->device == PCI_DEVICE_ID_SI_648 ||
-           bridge->dev->device == PCI_DEVICE_ID_SI_746) {
-               if (agp_bridge->major_version == 3) {
+        if (bridge->dev->device == PCI_DEVICE_ID_SI_648 ||
+           bridge->dev->device == PCI_DEVICE_ID_SI_746) {
+               if (agp_bridge->major_version == 3 && 
agp_bridge->minor_version < 5) {
+                       sis_driver.agp_enable=sis_648_enable;
+               } else {
                        sis_driver.agp_enable                   = 
sis_648_enable;
                        sis_driver.aperture_sizes               = 
agp3_generic_sizes;
                        sis_driver.size_type                    = 
U16_APER_SIZE;


Glück Auf
Volker

-- 
Conclusions 
 In a straight-up fight, the Empire squashes the Federation like a bug. Even 
with its numerical advantage removed, the Empire would still squash the 
Federation like a bug. Accept it. -Michael Wong 

Re: AGP problem SiS 746FX Linux 2.6.5-rc3

[Dave Jones]

On Tue, Apr 06, 2004 at 10:06:38PM +0200, Hemmann, Volker Armin wrote:
 >  static void __devinit sis_get_driver(struct agp_bridge_data *bridge)
 >  {
 > -       if (bridge->dev->device == PCI_DEVICE_ID_SI_648 ||
 > -           bridge->dev->device == PCI_DEVICE_ID_SI_746) {
 > -               if (agp_bridge->major_version == 3) {
 > +        if (bridge->dev->device == PCI_DEVICE_ID_SI_648 ||
 > +           bridge->dev->device == PCI_DEVICE_ID_SI_746) {
 > +               if (agp_bridge->major_version == 3 && 
 > agp_bridge->minor_version < 5) {
 > +                       sis_driver.agp_enable=sis_648_enable;
 > +               } else {

Ah, a clue. lspci -vvv output please ?

		Dave

Re: AGP problem SiS 746FX Linux 2.6.5-rc3

[Hemmann, Volker Armin]

Hi,

On Tuesday 06 April 2004 22:31, Dave Jones wrote:
> On Tue, Apr 06, 2004 at 10:06:38PM +0200, Hemmann, Volker Armin wrote:
>  >  static void __devinit sis_get_driver(struct agp_bridge_data *bridge)
>  >  {
>  > -       if (bridge->dev->device == PCI_DEVICE_ID_SI_648 ||
>  > -           bridge->dev->device == PCI_DEVICE_ID_SI_746) {
>  > -               if (agp_bridge->major_version == 3) {
>  > +        if (bridge->dev->device == PCI_DEVICE_ID_SI_648 ||
>  > +           bridge->dev->device == PCI_DEVICE_ID_SI_746) {
>  > +               if (agp_bridge->major_version == 3 &&
>  > agp_bridge->minor_version < 5) {
>  > +                       sis_driver.agp_enable=sis_648_enable;
>  > +               } else {
>
> Ah, a clue. lspci -vvv output please ?
>
> 		Dave


energy root # lspci -vvv
0000:00:00.0 Host bridge: Silicon Integrated Systems [SiS] 746 Host (rev 02)
        Subsystem: Unknown device 1849:0746
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort+ >SERR- <PERR-
        Latency: 0
        Region 0: Memory at d0000000 (32-bit, non-prefetchable)
        Capabilities: [c0] AGP version 3.0
                Status: RQ=32 Iso- ArqSz=2 Cal=3 SBA+ ITACoh- GART64- HTrans- 
64bit- FW+ AGP3+ Rate=x4,x8
                Command: RQ=1 ArqSz=0 Cal=3 SBA+ AGP+ GART64- 64bit- FW- 
Rate=x8

0000:00:01.0 PCI bridge: Silicon Integrated Systems [SiS] SG86C202 (prog-if 00 
[Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 128
        Bus: primary=00, secondary=01, subordinate=02, sec-latency=128
        I/O behind bridge: 0000f000-00000fff
        Memory behind bridge: cdd00000-cfefffff
        Prefetchable memory behind bridge: bda00000-cdbfffff
        BridgeCtl: Parity- SERR+ NoISA- VGA+ MAbort- >Reset- FastB2B-

0000:00:02.0 ISA bridge: Silicon Integrated Systems [SiS]: Unknown device 0963 
(rev 25)
        Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0

0000:00:02.1 SMBus: Silicon Integrated Systems [SiS]: Unknown device 0016
        Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
        Interrupt: pin B routed to IRQ 17
        Region 4: I/O ports at 0c00 [size=32]

0000:00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] 
(prog-if 80 [Master])
        Subsystem: Unknown device 1849:5513
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 128
        Region 4: I/O ports at ff00 [size=16]

0000:00:03.0 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 
Controller (rev 0f) (prog-if 10 [OHCI])
        Subsystem: Unknown device 1849:7001
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 128 (20000ns max), cache line size 08
        Interrupt: pin A routed to IRQ 20
        Region 0: Memory at cfffd000 (32-bit, non-prefetchable)

0000:00:03.1 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 
Controller (rev 0f) (prog-if 10 [OHCI])
        Subsystem: Unknown device 1849:7001
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 128 (20000ns max), cache line size 08
        Interrupt: pin B routed to IRQ 21
        Region 0: Memory at cfffe000 (32-bit, non-prefetchable)

0000:00:03.2 USB Controller: Silicon Integrated Systems [SiS] USB 2.0 
Controller (prog-if 20 [EHCI])
        Subsystem: Unknown device 1849:7001
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 128 (20000ns max)
        Interrupt: pin D routed to IRQ 23
        Region 0: Memory at cffff000 (32-bit, non-prefetchable)
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA 
PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:04.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 
10/100 Ethernet (rev 90)
        Subsystem: Unknown device 1849:8201
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 128 (13000ns min, 2750ns max)
        Interrupt: pin A routed to IRQ 19
        Region 0: I/O ports at dc00 [size=fffe0000]
        Region 1: Memory at cfffc000 (32-bit, non-prefetchable) [size=4K]
        Expansion ROM at 00020000 [disabled]
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:0b.0 Multimedia video controller: Brooktree Corporation Bt848 Video 
Capture (rev 12)
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 128 (4000ns min, 10000ns max)
        Interrupt: pin A routed to IRQ 19
        Region 0: Memory at cdcff000 (32-bit, prefetchable)

0000:00:0d.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 
10)
        Subsystem: C-Media Electronics Inc CMI8738/C3DX PCI Audio Device
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 128 (500ns min, 6000ns max)
        Interrupt: pin A routed to IRQ 17
        Region 0: I/O ports at d800
        Capabilities: [c0] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:01:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 
5200] (rev a1) (prog-if 00 [VGA])
        Subsystem: LeadTek Research Inc.: Unknown device 2967
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 248 (1250ns min, 250ns max)
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at ce000000 (32-bit, non-prefetchable) 
[size=cfee0000]
        Region 1: Memory at c0000000 (32-bit, prefetchable) [size=128M]
        Expansion ROM at 00020000 [disabled]
        Capabilities: [60] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [44] AGP version 3.0
                Status: RQ=32 Iso- ArqSz=0 Cal=3 SBA+ ITACoh- GART64- HTrans- 
64bit- FW+ AGP3+ Rate=x4,x8
                Command: RQ=32 ArqSz=2 Cal=0 SBA+ AGP+ GART64- 64bit- FW- 
Rate=x8

Glück Auf
Volker

-- 
Conclusions 
 In a straight-up fight, the Empire squashes the Federation like a bug. Even 
with its numerical advantage removed, the Empire would still squash the 
Federation like a bug. Accept it. -Michael Wong 

Re: AGP problem SiS 746FX Linux 2.6.5-rc3

[Dave Jones]

On Tue, Apr 06, 2004 at 10:37:02PM +0200, Hemmann, Volker Armin wrote:

 >         Capabilities: [c0] AGP version 3.0

Ok, so your system is fully AGP v3 compliant, (both host and gfx card).
The missing check highlighted in your diff means that we only do
AGPv3 stuff if we have an AGP 3.5 host bridge. You have a 3.0 bridge,
so it was falling back to AGP v2.  My suspicion now is that the 648 and
746 chipsets vary too much for them to both use the generic routines,
so I'll reinstate the check.  It'll still report that it finds an
AGP v3.0 device, but until someone comes forward with chipset docs,
it looks like it'll be limited to AGP v2. (I'm amazed that it works
at all, really).

It survives a testgart run too ?

		Dave

Re: AGP problem SiS 746FX Linux 2.6.5-rc3

[Hemmann, Volker Armin]

On Tuesday 06 April 2004 22:48, Dave Jones wrote:
> On Tue, Apr 06, 2004 at 10:37:02PM +0200, Hemmann, Volker Armin wrote:
>  >         Capabilities: [c0] AGP version 3.0
>
> Ok, so your system is fully AGP v3 compliant, (both host and gfx card).
> The missing check highlighted in your diff means that we only do
> AGPv3 stuff if we have an AGP 3.5 host bridge. You have a 3.0 bridge,
> so it was falling back to AGP v2.  My suspicion now is that the 648 and
> 746 chipsets vary too much for them to both use the generic routines,
> so I'll reinstate the check.  It'll still report that it finds an
> AGP v3.0 device, but until someone comes forward with chipset docs,
> it looks like it'll be limited to AGP v2. (I'm amazed that it works
> at all, really).
>
> It survives a testgart run too ?
>
> 		Dave

I am amazed, too, that may box is running... ;o)

testgart works,  I did a fresh reboot, to be sure:

version: 0.100
bridge id: 0x7461039
agp_mode: 0x1f004e1b
aper_base: 0xd0000000
aper_size: 128
pg_total: 112384
pg_system: 112384
pg_used: 0
entry.key : 0
entry.key : 1
Allocated 8 megs of GART memory
MemoryBenchmark: 1444 mb/s
MemoryBenchmark: 1474 mb/s
MemoryBenchmark: 1477 mb/s
Average speed: 1465 mb/s
Testing data integrity (1st pass): passed on first pass.
Testing data integrity (2nd pass): passed on second pass.

and dmesg:

Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected SiS 746 chipset
agpgart: Maximum main memory to use for agp memory: 439M
agpgart: AGP aperture is 128M @ 0xd0000000
<snip>
agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V3 device at 0000:00:00.0 into 8x mode
agpgart: sis 648 agp fix - giving bridge time to recover
agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x mode

Glück Auf
Volker

-- 
Conclusions 
 In a straight-up fight, the Empire squashes the Federation like a bug. Even 
with its numerical advantage removed, the Empire would still squash the 
Federation like a bug. Accept it. -Michael Wong 

Re: AGP problem SiS 746FX Linux 2.6.5-rc3

[Dave Jones]

On Tue, Apr 06, 2004 at 11:04:11PM +0200, Hemmann, Volker Armin wrote:

 > > It survives a testgart run too ?
 > I am amazed, too, that may box is running... ;o)
 > testgart works,  I did a fresh reboot, to be sure:

Ok, too strange for words.
I'm inclined to make things more explicit, and make
sis_get_driver look like this..

static void __devinit sis_get_driver(struct agp_bridge_data *bridge)
{
    if (bridge->dev->device == PCI_DEVICE_ID_SI_648) {
        sis_driver.agp_enable=sis_648_enable;
        if (agp_bridge->major_version == 3) {
            sis_driver.aperture_sizes       = agp3_generic_sizes;
            sis_driver.size_type            = U16_APER_SIZE;
            sis_driver.num_aperture_sizes   = AGP_GENERIC_SIZES_ENTRIES;
            sis_driver.configure            = agp3_generic_configure;
            sis_driver.fetch_size           = agp3_generic_fetch_size;
            sis_driver.cleanup              = agp3_generic_cleanup;
            sis_driver.tlb_flush            = agp3_generic_tlbflush;
        }
    }
                                                                                                                            
    if (bridge->dev->device == PCI_DEVICE_ID_SI_746) {
        /*
         * We don't know enough about the 746 to enable it properly.
         * Though we do know that it needs the 'delay' hack to settle
         * after changing modes.
         */
        sis_driver.agp_enable=sis_648_enable;
    }
}


 > agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
 > agpgart: Putting AGP V3 device at 0000:00:00.0 into 8x mode
 > agpgart: sis 648 agp fix - giving bridge time to recover
 > agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x mode

It's pretty convinced it's in AGPv3 mode too.
Oh well. 8-)

		Dave

Re: AGP problem SiS 746FX Linux 2.6.5-rc3

[Hemmann, Volker Armin]

Hi,

On Tuesday 06 April 2004 23:08, Dave Jones wrote:

> Ok, too strange for words.
> I'm inclined to make things more explicit, and make
> sis_get_driver look like this..
>
> static void __devinit sis_get_driver(struct agp_bridge_data *bridge)
> {
>     if (bridge->dev->device == PCI_DEVICE_ID_SI_648) {
>         sis_driver.agp_enable=sis_648_enable;
>         if (agp_bridge->major_version == 3) {
>             sis_driver.aperture_sizes       = agp3_generic_sizes;
>             sis_driver.size_type            = U16_APER_SIZE;
>             sis_driver.num_aperture_sizes   = AGP_GENERIC_SIZES_ENTRIES;
>             sis_driver.configure            = agp3_generic_configure;
>             sis_driver.fetch_size           = agp3_generic_fetch_size;
>             sis_driver.cleanup              = agp3_generic_cleanup;
>             sis_driver.tlb_flush            = agp3_generic_tlbflush;
>         }
>     }
>
>     if (bridge->dev->device == PCI_DEVICE_ID_SI_746) {
>         /*
>          * We don't know enough about the 746 to enable it properly.
>          * Though we do know that it needs the 'delay' hack to settle
>          * after changing modes.
>          */
>         sis_driver.agp_enable=sis_648_enable;
>     }
> }

ok, I was a little confused so:
vanilla 2.6.5+this patch: old testgart garbeling problem again
patched 2.6.5-rc3+this patch: everything fine
vanilla 2.6.5+agpgart-2004-04-06.diff+ this patch: everything fine, too

In each cases, I removed all .o and .ko files from drivers/char/agp 
and /lib/modules/2.6.5 to be sure.

Well, I dont care, if its believes to be at AGPv3 mode or not, as long X is 
working fine ;o)

Glück Auf
Volker

-- 
Conclusions 
 In a straight-up fight, the Empire squashes the Federation like a bug. Even 
with its numerical advantage removed, the Empire would still squash the 
Federation like a bug. Accept it. -Michael Wong 

Re: AGP problem SiS 746FX Linux 2.6.5-rc3

[Dave Jones]

On Wed, Apr 07, 2004 at 12:01:35AM +0200, Hemmann, Volker Armin wrote:

 > ok, I was a little confused so:
 > vanilla 2.6.5+this patch: old testgart garbeling problem again
 > patched 2.6.5-rc3+this patch: everything fine
 > vanilla 2.6.5+agpgart-2004-04-06.diff+ this patch: everything fine, too

Ah yes, sorry I should've mentioned you need the other parts.
This is as expected. I'll push this out. Thanks for your
testing, and your patience 8-)

		Dave

Re: AGP problem SiS 746FX Linux 2.6.5-rc3

[Hemmann, Volker Armin]

On Wednesday 07 April 2004 00:14, Dave Jones wrote:
> On Wed, Apr 07, 2004 at 12:01:35AM +0200, Hemmann, Volker Armin wrote:
>  > ok, I was a little confused so:
>  > vanilla 2.6.5+this patch: old testgart garbeling problem again
>  > patched 2.6.5-rc3+this patch: everything fine
>  > vanilla 2.6.5+agpgart-2004-04-06.diff+ this patch: everything fine, too
>
> Ah yes, sorry I should've mentioned you need the other parts.
> This is as expected. I'll push this out. Thanks for your
> testing, and your patience 8-)
>
> 		Dave

no problem, I am the one who needs the support and is to dumb to do it 
himself ;o)

If you have more patches you want to get tested, just send them.. with fs or 
ide-patches I would be a lot more reluctant ;o)

Glück Auf
Volker

-- 
Conclusions 
 In a straight-up fight, the Empire squashes the Federation like a bug. Even 
with its numerical advantage removed, the Empire would still squash the 
Federation like a bug. Accept it. -Michael Wong 

Re: AGP problem SiS 746FX Linux 2.6.5-rc3

[Bjoern Michaelsen]

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

On Wed, Apr 07, 2004 at 12:26:00AM +0200, Hemmann, Volker Armin wrote:
> If you have more patches you want to get tested, just send them.. with fs or 
> ide-patches I would be a lot more reluctant ;o)
Just to make confusion perfect: my patch lets me work in AGP V3.0
on SiS 746. Just in case here is the relevant part of my lspci:

00:00.0 Host bridge: Silicon Integrated Systems [SiS]: Unknown device 0746 (rev 02)
	Subsystem: Elitegroup Computer Systems: Unknown device 1808
	Flags: bus master, medium devsel, latency 0
	Memory at d0000000 (32-bit, non-prefetchable) [size=128M]
	Capabilities: [c0] AGP version 3.0

01:00.0 VGA compatible controller: nVidia Corporation: Unknown device 0312 (rev a1) (prog-if 00 [VGA])
	Flags: bus master, 66Mhz, medium devsel, latency 248, IRQ 11
	Memory at ce000000 (32-bit, non-prefetchable) [size=16M]
	Memory at b0000000 (32-bit, prefetchable) [size=256M]
	Expansion ROM at cfee0000 [disabled] [size=128K]
	Capabilities: [60] Power Management version 2
	Capabilities: [44] AGP version 3.0

this is a ECS L7S7A2 mainboard and a NoName (Manli) GeForce
FX5600TD 256MB.
Yours,
-- 
Björn Michaelsen
pub  1024D/C9E5A256 2003-01-21 Björn Michaelsen <bmichaelsen@gmx.de>
   Key fingerprint = D649 8C78 1CB1 23CF 5CCF  CA1A C1B5 BBEC C9E5 A256

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: AGP problem SiS 746FX Linux 2.6.5-rc3

[Oliver Schoett]

Dave Jones <davej@redhat.com> writes:

 > Ok, so your system is fully AGP v3 compliant, (both host and gfx card).
 > The missing check highlighted in your diff means that we only do
 > AGPv3 stuff if we have an AGP 3.5 host bridge. You have a 3.0 bridge,
 > so it was falling back to AGP v2.  My suspicion now is that the 648 and
 > 746 chipsets vary too much for them to both use the generic routines,
 > so I'll reinstate the check.  It'll still report that it finds an
 > AGP v3.0 device, but until someone comes forward with chipset docs,
 > it looks like it'll be limited to AGP v2. (I'm amazed that it works
 > at all, really).

Here is some information about the AGP mode checks I learned from
Oliver Heilmann: The two chipsets SiS 648 and SiS 648FX both have the
chipset ID 0x0648, but need different initalisation code.  The way to
distinguish them is that the 648FX reports itself as AGP v3.5 capable,
while the 648 reports itself as AGP v3.0 capable.  This is handled
correctly in Heilmann's patch in his Article
<1obEA-82t-11@gated-at.bofh.it> Date: Thu, 12 Feb 2004 00:10:08 +0100:

+static void __devinit sis_get_driver(struct agp_bridge_data *bridge)
+{
+	if(bridge->dev->device==PCI_DEVICE_ID_SI_648)
+	{
+		if(agp_bridge->major_version==3 && agp_bridge->minor_version < 5)
+		{
+			sis_driver.agp_enable=sis_648_enable;
+		}
+		else
+		{
+			sis_driver.agp_enable         = sis_648_enable;
+			sis_driver.aperture_sizes     = agp3_generic_sizes;
+			sis_driver.size_type	      = U16_APER_SIZE;
+			sis_driver.num_aperture_sizes = AGP_GENERIC_SIZES_ENTRIES;
+			sis_driver.configure	      = agp3_generic_configure;
+			sis_driver.fetch_size	      = agp3_generic_fetch_size;
+			sis_driver.cleanup	      = agp3_generic_cleanup;
+			sis_driver.tlb_flush	      = agp3_generic_tlbflush;
+		}
+	}
+	bridge->driver=&sis_driver;
+}
+

Please preserve this distinction in your patch and don't degrade the
SiS 648 chipset to AGP 2.0 (currently, 2.6.5 runs fine with AGP 3.0 on
my SiS 648 chipset).

By the way, I noticed an oddity in the changeset
http://linux.bkbits.net:8080/linux-2.5/patch@1.1643.35.7: the line

-		set_current_state(TASK_INTERRUPTIBLE);

becomes

+			set_current_state(TASK_UNINTERRUPTIBLE);

Which of the two settings is correct?

Regards,

Oliver Schoett