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
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
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
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 <[email protected]>
Key fingerprint = D649 8C78 1CB1 23CF 5CCF CA1A C1B5 BBEC C9E5 A256
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 <[email protected]>
Key fingerprint = D649 8C78 1CB1 23CF 5CCF CA1A C1B5 BBEC C9E5 A256
Dave Jones <[email protected]> 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
<[email protected]> 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/[email protected]: the line
- set_current_state(TASK_INTERRUPTIBLE);
becomes
+ set_current_state(TASK_UNINTERRUPTIBLE);
Which of the two settings is correct?
Regards,
Oliver Schoett