From: Felix <fx...@gm...> - 2006-04-25 22:26:47
|
Am Dienstag, den 25.04.2006, 18:18 -0500 schrieb ki...@ba...: >=20 > On Tue, 25 Apr 2006, Felix Khling wrote: >=20 > > Am Montag, den 24.04.2006, 21:18 -0500 schrieb > > ki...@ba...: >=20 > > Oh, that's an easy one. You could have got the answer I'm giving you = on > > the dri-users mailing list. The problem is also mentioned in > > http://dri.freedesktop.org/wiki/DriTroubleshooting. <hint/> > > > > You also need a chipset specific agp module, for example intel-agp. > > Which module you need depends on your main board, not your graphics > > card. Note that this is nothing Savage-specific. >=20 > I tried the mailing list, and indeed it says I need to be subscribed. I= =20 > can understand why it is set up this way, as I am a developer. But as a= =20 > user and a developer at the same time, it is unpleasant. I am already=20 > subscribed to several mailing lists where I have actually been active: >=20 > gphoto-devel=20 > gphoto-users > usb-storage > sane-devel >=20 > and now yet another one... >=20 > But I guess I will do it. The problem is unfortunately not as easy to=20 > solve as you wish it to be. I checked my kernel config, and: >=20 > 1. The support for via-agp is enabled. >=20 > 2. The file /lib/modules/2.6.16.8/kernel/char/via-agp.ko does exist. >=20 > 3. The via-agp module does not get loaded automatically on any occasion= ,=20 > even though the agpgart module does get loaded automatically, on bootup= . >=20 > And then >=20 > 4. To load via-agp manually before starting X does not help at all to m= ake=20 > the problem to go away. All it does is to cause via-agp to be listed wh= en=20 > one does lsmod. One only achieves >=20 > root@khayyam:/etc/X11# lsmod|grep agp > via_agp 7808 0 > agpgart 28976 2 via_agp,drm > root@khayyam:/etc/X11# >=20 > but Xorg.0.conf _still_ says when I restart X after manually installing= =20 > the via_agp module, that AGP is not available and it is falling back to= =20 > PCI mode. (Also noticing that modules.dep requires agpgart before via_a= gp=20 > instead of the other way round, which seems strange) It makes sense to me. The hardware-specific module requires the generic one. OTOH the generic one wouldn't know which hardware-specific one to depend on. Does dmesg say anything about via-agp? Does it find the AGP bridge? Also make sure that savage and drm are loaded after via-agp and agpgart. >=20 > So, tried the troubleshooting routine and it does not seem to give any=20 > positive results; I sent now a subscription request to the xorg mailing= =20 > list and am waiting for it to be "approved". This is a DRI-specific issue, so dri-users should be the right mailing list. It does not require subscription. I'm CCing that list. Regards, Felix >=20 > Theodore Kilgore --=20 | Felix K=C3=BChling <fx...@gm...> http://fxk.de.v= u | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | |
From: Felix <fx...@gm...> - 2006-04-25 23:42:28
|
Am Dienstag, den 25.04.2006, 19:21 -0500 schrieb ki...@ba...: [snip] > Could be that the problem is an "unknown" chipset on the board? OK,=20 > I'll bite. Which one of these creatures is supposed to be the "AGP=20 > bridge"? I don't see it mentioned. (lspci output follows) >=20 > root@khayyam:/lib/modules/2.6.16.8# lspci > 00:00.0 Host bridge: VIA Technologies, Inc. K8M800 Host Bridge > 00:00.1 Host bridge: VIA Technologies, Inc. K8M800 Host Bridge > 00:00.2 Host bridge: VIA Technologies, Inc. K8M800 Host Bridge > 00:00.3 Host bridge: VIA Technologies, Inc. K8M800 Host Bridge > 00:00.4 Host bridge: VIA Technologies, Inc. K8M800 Host Bridge > 00:00.7 Host bridge: VIA Technologies, Inc. K8M800 Host Bridge > 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge=20 > [K8T800/K8T890 South] > 00:0f.0 IDE interface: VIA Technologies, Inc.=20 > VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) > 00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1=20 > Controller (rev 81) > 00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1=20 > Controller (rev 81) > 00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1=20 > Controller (rev 81) > 00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1=20 > Controller (rev 81) > 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) > 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge=20 > [KT600/K8T800/K8T890 South] > 00:11.5 Multimedia audio controller: VIA Technologies, Inc.=20 > VT8233/A/8235/8237 AC97 Audio Controller (rev 60) > 00:11.6 Communication controller: VIA Technologies, Inc. AC'97 Modem=20 > Controller > (rev 80) > 00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (= rev=20 > 78) > 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]= =20 > HyperTransport Technology Configuration > 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]= =20 > Address > Map > 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]= =20 > DRAM Controller > 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]= =20 > Miscellaneous Control > 01:00.0 VGA compatible controller: S3 Inc. Savage 4 (rev 03) > root@khayyam:/lib/modules/2.6.16.8# On an opteron system I believe you should use amd64-agp. Regards, Felix >=20 >=20 > > > > This is a DRI-specific issue, so dri-users should be the right mailin= g > > list. It does not require subscription. I'm CCing that list. >=20 > Thanks. >=20 > Theodore Kilgore --=20 | Felix K=C3=BChling <fx...@gm...> http://fxk.de.v= u | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | |
From: <ki...@ba...> - 2006-04-26 00:50:05
|
On Tue, 25 Apr 2006, Felix K=FChling wrote: > Am Dienstag, den 25.04.2006, 19:21 -0500 schrieb > ki...@ba...: (...) > > On an opteron system I believe you should use amd64-agp. > > Regards, > Felix This may have cured the problem: We have now directly after reboot the following: root@khayyam:~# lsmod|grep agp amd64_agp 10372 1 agpgart 28976 1 amd64_agp root@khayyam:~# dmesg|grep agp Linux agpgart interface v0.101 (c) Dave Jones agpgart: Detected AGP bridge 0 agpgart: AGP aperture is 32M @ 0xd0000000 root@khayyam:~# so things are looking better. And after starting X we get root@khayyam:~# dmesg|grep agp Linux agpgart interface v0.101 (c) Dave Jones agpgart: Detected AGP bridge 0 agpgart: AGP aperture is 32M @ 0xd0000000 agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0. agpgart: Device is in legacy mode, falling back to 2.x agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode agpgart: Putting AGP V2 device at 0000:01:00.0 into 4x mode root@khayyam:~# and root@khayyam:~# lsmod|grep savage savage 32704 1 drm 64340 2 savage root@khayyam:~# and in the Xorg.0.log we now have =2E.. (II) SAVAGE(0): [drm] framebuffer handle =3D 0xf0000000 (II) SAVAGE(0): [drm] added 1 reserved context for kernel (II) SAVAGE(0): [agp] Mode 0x1f000207 [AGP 0x1106/0x0204; Card=20 0x5333/0x8a22] (II) SAVAGE(0): [agp] 16384 kB allocated with handle 0x00000001 (II) SAVAGE(0): [agp] command DMA handle =3D 0xd0000000 (II) SAVAGE(0): [agp] agpTextures handle =3D 0xd0100000 (II) SAVAGE(0): [drm] aperture handle =3D 0xf2000000 =2E.. which looks much better. Thanks. Now, do you have a USB digital still camera with proprietary=20 interface that you want to make to=20 work? Perhaps I could help you with that. Unless of course it is using one= =20 of those cursed proprietary compression algorithms ... Theodore Kilgore |
From: Felix <fx...@gm...> - 2006-04-26 00:57:53
|
Am Dienstag, den 25.04.2006, 20:55 -0500 schrieb ki...@ba...: >=20 > On Tue, 25 Apr 2006, Felix Khling wrote: >=20 > > Am Dienstag, den 25.04.2006, 19:21 -0500 schrieb > > ki...@ba...: > (...) > > > > On an opteron system I believe you should use amd64-agp. > > > > Regards, > > Felix > This may have cured the problem: >=20 > We have now directly after reboot the following: >=20 > root@khayyam:~# lsmod|grep agp > amd64_agp 10372 1 > agpgart 28976 1 amd64_agp > root@khayyam:~# dmesg|grep agp > Linux agpgart interface v0.101 (c) Dave Jones > agpgart: Detected AGP bridge 0 > agpgart: AGP aperture is 32M @ 0xd0000000 > root@khayyam:~# >=20 > so things are looking better. And after starting X we get >=20 > root@khayyam:~# dmesg|grep agp > Linux agpgart interface v0.101 (c) Dave Jones > agpgart: Detected AGP bridge 0 > agpgart: AGP aperture is 32M @ 0xd0000000 > agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0. > agpgart: Device is in legacy mode, falling back to 2.x > agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode > agpgart: Putting AGP V2 device at 0000:01:00.0 into 4x mode > root@khayyam:~# >=20 > and >=20 > root@khayyam:~# lsmod|grep savage > savage 32704 1 > drm 64340 2 savage > root@khayyam:~# >=20 > and in the Xorg.0.log we now have >=20 > ... >=20 > (II) SAVAGE(0): [drm] framebuffer handle =3D 0xf0000000 > (II) SAVAGE(0): [drm] added 1 reserved context for kernel > (II) SAVAGE(0): [agp] Mode 0x1f000207 [AGP 0x1106/0x0204; Card=20 > 0x5333/0x8a22] > (II) SAVAGE(0): [agp] 16384 kB allocated with handle 0x00000001 > (II) SAVAGE(0): [agp] command DMA handle =3D 0xd0000000 > (II) SAVAGE(0): [agp] agpTextures handle =3D 0xd0100000 > (II) SAVAGE(0): [drm] aperture handle =3D 0xf2000000 > ... >=20 > which looks much better. Yes. Does it work too? I mean do you get reasonable acceleration, preferably without lockups? >=20 > Thanks. Now, do you have a USB digital still camera with proprietary=20 > interface that you want to make to=20 > work? Perhaps I could help you with that. Unless of course it is using = one=20 > of those cursed proprietary compression algorithms ... Thanks. But my Canon PowerShot S70 is working just fine under Linux. :) Regards, Felix >=20 > Theodore Kilgore >=20 --=20 | Felix K=C3=BChling <fx...@gm...> http://fxk.de.v= u | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | |
From: <ki...@ba...> - 2006-04-26 03:07:30
|
On Tue, 25 Apr 2006, Felix K=FChling wrote: > Am Dienstag, den 25.04.2006, 20:55 -0500 schrieb > ki...@ba...: >> >> On Tue, 25 Apr 2006, Felix Khling wrote: >> >>> Am Dienstag, den 25.04.2006, 19:21 -0500 schrieb >>> ki...@ba...: >>> >>> On an opteron system I believe you should use amd64-agp. You know, it would be nice if this were more prominently stated in the=20 kernel documentation. For starters, the kernel choices about the CPU do=20 not even mention the AMD Sempron, not even in the help screen. Similar WRT= =20 the help for config AGP_AMD64. AFAIK the only place where Sempron gets=20 mentioned at all is in Documentation/cpu-freq/amd-powernow.txt, which one= =20 will probably not seek out unless terribly concerned about frequency=20 scaling. (...) >> We have now directly after reboot the following: >> >> root@khayyam:~# lsmod|grep agp >> amd64_agp 10372 1 >> agpgart 28976 1 amd64_agp >> root@khayyam:~# dmesg|grep agp >> Linux agpgart interface v0.101 (c) Dave Jones >> agpgart: Detected AGP bridge 0 >> agpgart: AGP aperture is 32M @ 0xd0000000 >> root@khayyam:~# >> >> so things are looking better. And after starting X we get >> >> root@khayyam:~# dmesg|grep agp >> Linux agpgart interface v0.101 (c) Dave Jones >> agpgart: Detected AGP bridge 0 >> agpgart: AGP aperture is 32M @ 0xd0000000 >> agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0. >> agpgart: Device is in legacy mode, falling back to 2.x (why this sequence? does the card need to be _put_ into 4x mode?) >> agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode >> agpgart: Putting AGP V2 device at 0000:01:00.0 into 4x mode >> root@khayyam:~# >> (...) >> >> and in the Xorg.0.log we now have >> >> ... >> >> (II) SAVAGE(0): [drm] framebuffer handle =3D 0xf0000000 >> (II) SAVAGE(0): [drm] added 1 reserved context for kernel >> (II) SAVAGE(0): [agp] Mode 0x1f000207 [AGP 0x1106/0x0204; Card >> 0x5333/0x8a22] >> (II) SAVAGE(0): [agp] 16384 kB allocated with handle 0x00000001 >> (II) SAVAGE(0): [agp] command DMA handle =3D 0xd0000000 >> (II) SAVAGE(0): [agp] agpTextures handle =3D 0xd0100000 >> (II) SAVAGE(0): [drm] aperture handle =3D 0xf2000000 >> ... >> >> which looks much better. > > Yes. Does it work too? I mean do you get reasonable acceleration, > preferably without lockups? > Seems so, yes. But I looked at so much stuff today that I forget exactly=20 what is the significance of (II) SAVAGE(0): [agp] 16384 kB allocated with handle 0x00000001 This does not refer to memory on the card, or does it? As the memory on=20 the card is 32mb is it better to adjust this, somehow? I saw something=20 about this somewhere today, but right now I cannot recall where. Also there is still the pesky log message which fills up syslog, saying Apr 25 19:31:58 khayyam kernel: mtrr: 0xf0000000,0x8000000 overlaps=20 existing 0xf0000000,0x2000000 Apr 25 19:31:58 khayyam kernel: mtrr: base(0xf2000000) is not aligned on a= =20 size(0x5000000) boundary Somehow, it ought to be possible to get rid of this error message, which I= =20 understand is not exactly an error but it still looks bad. >> >> Thanks. Now, do you have a USB digital still camera with proprietary >> interface that you want to make to >> work? Perhaps I could help you with that. Unless of course it is using o= ne >> of those cursed proprietary compression algorithms ... > > Thanks. But my Canon PowerShot S70 is working just fine under Linux. :) > According to libgphoto2/camlibs/canon/ChangeLog, Marcus Meissner did that= =20 one and he does great work, too. But if you have a Jenoptik JDC350 or a=20 Soundstar TDC-35 lying around, it's one of mine. Thanks again, Theodore Kilgore |
From: Felix <fx...@gm...> - 2006-04-26 13:52:28
|
Am Dienstag, den 25.04.2006, 23:12 -0500 schrieb ki...@ba...: >=20 > On Tue, 25 Apr 2006, Felix Khling wrote: >=20 > > Am Dienstag, den 25.04.2006, 20:55 -0500 schrieb > > ki...@ba...: > >> > >> On Tue, 25 Apr 2006, Felix Khling wrote: > >> > >>> Am Dienstag, den 25.04.2006, 19:21 -0500 schrieb > >>> ki...@ba...: > >>> > >>> On an opteron system I believe you should use amd64-agp. >=20 > You know, it would be nice if this were more prominently stated in the=20 > kernel documentation. For starters, the kernel choices about the CPU do= =20 > not even mention the AMD Sempron, not even in the help screen. Similar = WRT=20 > the help for config AGP_AMD64. AFAIK the only place where Sempron gets=20 > mentioned at all is in Documentation/cpu-freq/amd-powernow.txt, which o= ne=20 > will probably not seek out unless terribly concerned about frequency=20 > scaling. There were two different Sempron generations. The older ones were based on the K7, the newer ones are based on K8. So you can't simply state that Sempron is either one. I suppose the general assumption is, if you're savvy enough to build your own kernels you know what your hardware is. ;-) The average user should never be confronted with this as the hardware is auto-detected and the correct modules loaded on default installations. >=20 > (...) >=20 > >> We have now directly after reboot the following: > >> > >> root@khayyam:~# lsmod|grep agp > >> amd64_agp 10372 1 > >> agpgart 28976 1 amd64_agp > >> root@khayyam:~# dmesg|grep agp > >> Linux agpgart interface v0.101 (c) Dave Jones > >> agpgart: Detected AGP bridge 0 > >> agpgart: AGP aperture is 32M @ 0xd0000000 > >> root@khayyam:~# > >> > >> so things are looking better. And after starting X we get > >> > >> root@khayyam:~# dmesg|grep agp > >> Linux agpgart interface v0.101 (c) Dave Jones > >> agpgart: Detected AGP bridge 0 > >> agpgart: AGP aperture is 32M @ 0xd0000000 > >> agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0. > >> agpgart: Device is in legacy mode, falling back to 2.x >=20 > (why this sequence? does the card need to be _put_ into 4x mode?) 2.x here means AGP version 2.x, so speeds up to 4x. AFAIK the Savage4 can only support AGP version 2 (speed 4x). >=20 > >> agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode > >> agpgart: Putting AGP V2 device at 0000:01:00.0 into 4x mode Here you go. AGP version 2 device. > >> root@khayyam:~# > >> > (...) > >> > >> and in the Xorg.0.log we now have > >> > >> ... > >> > >> (II) SAVAGE(0): [drm] framebuffer handle =3D 0xf0000000 > >> (II) SAVAGE(0): [drm] added 1 reserved context for kernel > >> (II) SAVAGE(0): [agp] Mode 0x1f000207 [AGP 0x1106/0x0204; Card > >> 0x5333/0x8a22] > >> (II) SAVAGE(0): [agp] 16384 kB allocated with handle 0x00000001 > >> (II) SAVAGE(0): [agp] command DMA handle =3D 0xd0000000 > >> (II) SAVAGE(0): [agp] agpTextures handle =3D 0xd0100000 > >> (II) SAVAGE(0): [drm] aperture handle =3D 0xf2000000 > >> ... > >> > >> which looks much better. > > > > Yes. Does it work too? I mean do you get reasonable acceleration, > > preferably without lockups? > > > Seems so, yes. But I looked at so much stuff today that I forget exactl= y=20 > what is the significance of >=20 > (II) SAVAGE(0): [agp] 16384 kB allocated with handle 0x00000001 >=20 > This does not refer to memory on the card, or does it? As the memory on= =20 > the card is 32mb is it better to adjust this, somehow? I saw something=20 > about this somewhere today, but right now I cannot recall where. This is the amount of system memory that is reserved for graphics (mostly textures). You can change it using the AgpSize option in xorg.conf. See the savage manpage for more options. That said, I never heard of Savage4 cards with 32MB memory. I had one with 16MB memory. The theoretical maximum the chip can handle is 32MB but I've only seen that with on-board graphics and 32MB shared graphics memory configured in the BIOS. Your Xorg.0.log should state the amount of graphics memory somewhere. >=20 > Also there is still the pesky log message which fills up syslog, saying >=20 > Apr 25 19:31:58 khayyam kernel: mtrr: 0xf0000000,0x8000000 overlaps=20 > existing 0xf0000000,0x2000000 > Apr 25 19:31:58 khayyam kernel: mtrr: base(0xf2000000) is not aligned o= n a=20 > size(0x5000000) boundary >=20 > Somehow, it ought to be possible to get rid of this error message, whic= h I=20 > understand is not exactly an error but it still looks bad. If you're using vesafb, disable it. It has the bad habit of setting an MTRR for only part of the video memory and makes it impossible for X to set up an MTRR for the whole video memory later on. I think there is also a kernel option to disable mtrr setting in the vesafb driver. Regards, Felix >=20 > >> > >> Thanks. Now, do you have a USB digital still camera with proprietary > >> interface that you want to make to > >> work? Perhaps I could help you with that. Unless of course it is usi= ng one > >> of those cursed proprietary compression algorithms ... > > > > Thanks. But my Canon PowerShot S70 is working just fine under Linux. = :) > > >=20 > According to libgphoto2/camlibs/canon/ChangeLog, Marcus Meissner did th= at=20 > one and he does great work, too. But if you have a Jenoptik JDC350 or a= =20 > Soundstar TDC-35 lying around, it's one of mine. >=20 > Thanks again, >=20 > Theodore Kilgore --=20 | Felix K=C3=BChling <fx...@gm...> http://fxk.de.v= u | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | |
From: <ki...@ba...> - 2006-04-26 16:36:43
|
On Wed, 26 Apr 2006, Felix K=FChling wrote: > Am Dienstag, den 25.04.2006, 23:12 -0500 schrieb > ki...@ba...: >> >> On Tue, 25 Apr 2006, Felix Khling wrote: >> >>> Am Dienstag, den 25.04.2006, 20:55 -0500 schrieb >>> ki...@ba...: >>>> >>>> On Tue, 25 Apr 2006, Felix Khling wrote: >>>> >>>>> Am Dienstag, den 25.04.2006, 19:21 -0500 schrieb >>>>> ki...@ba...: >>>>> >>>>> On an opteron system I believe you should use amd64-agp. >> >> You know, it would be nice if this were more prominently stated in the >> kernel documentation. For starters, the kernel choices about the CPU do >> not even mention the AMD Sempron, not even in the help screen. Similar W= RT >> the help for config AGP_AMD64. AFAIK the only place where Sempron gets >> mentioned at all is in Documentation/cpu-freq/amd-powernow.txt, which on= e >> will probably not seek out unless terribly concerned about frequency >> scaling. > > There were two different Sempron generations. The older ones were based > on the K7, the newer ones are based on K8. So you can't simply state > that Sempron is either one. So _that_ is the problem. That is what made me to wonder, too, what=20 choices to use when compiling the kernel. I suppose the general assumption is, if > you're savvy enough to build your own kernels Been doing that since 1996, you know what your > hardware is. ;-) But this one slipped past me. One of the things one must rely on when=20 compiling ones own kernel is documentation, obviously, and it is lacking=20 here, but the reason they did not provide very much is that they did not=20 know what to say. I understand, now. It's another version of Catch 22. The average user should never be confronted with this > as the hardware is auto-detected and the correct modules loaded on > default installations. >> (why this sequence? does the card need to be _put_ into 4x mode?) > > 2.x here means AGP version 2.x, so speeds up to 4x. AFAIK the Savage4 > can only support AGP version 2 (speed 4x). Thus saith lsusb -vv, so no surprise there. >>>> agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode >>>> agpgart: Putting AGP V2 device at 0000:01:00.0 into 4x mode > > Here you go. AGP version 2 device. OK. (...) >> Seems so, yes. But I looked at so much stuff today that I forget exactly >> what is the significance of >> >> (II) SAVAGE(0): [agp] 16384 kB allocated with handle 0x00000001 >> >> This does not refer to memory on the card, or does it? As the memory on >> the card is 32mb is it better to adjust this, somehow? I saw something >> about this somewhere today, but right now I cannot recall where. > > This is the amount of system memory that is reserved for graphics > (mostly textures). To be more clear about this, what does "system memory" signify? Does that= =20 include any memory on the card? Or is this memory which is robbed from=20 your on-board memory? Just how does that work out in practice? You can change it using the AgpSize option in > xorg.conf. See the savage manpage for more options. > > That said, I never heard of Savage4 cards with 32MB memory. I had one > with 16MB memory. The theoretical maximum the chip can handle is 32MB > but I've only seen that with on-board graphics and 32MB shared graphics > memory configured in the BIOS. Your Xorg.0.log should state the amount > of graphics memory somewhere. It says there are 32 megs. I am not at home now to be able to give you the= =20 line from the log file which says so, but it is there. For that matter, a= =20 flash screen at bootup gives the name of the video card and the amount of= =20 RAM on it, too. So I could put such a line as you say into the config file, but it would=20 be better to know exactly what this line is doing. After all, X already=20 correctly detects the amount of memory which is supposed to be on the=20 card, so what is this doing, exactly? Along the same lines, I have never understood what the BIOS thinks is the= =20 "AGP aperture" and how to set that. Right now it is set at 32mb (same as=20 what is on the card) but I am uncertain about what function this BIOS "AGP= =20 aperture" setting is serving. And, again, does it relate to some=20 set-aside of on-board RAM, for use to prepare things to be sent to the=20 card, or does it relate to the RAM which is on the card? I never did=20 understand the answer to these questions, as what is in all of the BIOS=20 documentation which I have ever chased down is rather cryptic and seems to= =20 assume that I already know what I am trying to find out. > >> >> Also there is still the pesky log message which fills up syslog, saying >> >> Apr 25 19:31:58 khayyam kernel: mtrr: 0xf0000000,0x8000000 overlaps >> existing 0xf0000000,0x2000000 >> Apr 25 19:31:58 khayyam kernel: mtrr: base(0xf2000000) is not aligned on= a >> size(0x5000000) boundary >> >> Somehow, it ought to be possible to get rid of this error message, which= I >> understand is not exactly an error but it still looks bad. > > If you're using vesafb, disable it. It has the bad habit of setting an > MTRR for only part of the video memory and makes it impossible for X to > set up an MTRR for the whole video memory later on. I think there is > also a kernel option to disable mtrr setting in the vesafb driver. I will check this. I assume you mean here that all of the framebuffer=20 stuff in the kernel should be turned off? I did make modules for that,=20 thinking they might get used for something, but they do not get called=20 and loaded. Thanks, Theodore Kilgore |
From: Felix <fx...@gm...> - 2006-04-26 20:14:18
|
Am Mittwoch, den 26.04.2006, 12:42 -0500 schrieb ki...@ba...: [snip] > >> (II) SAVAGE(0): [agp] 16384 kB allocated with handle 0x00000001 > >> > >> This does not refer to memory on the card, or does it? As the memory= on > >> the card is 32mb is it better to adjust this, somehow? I saw somethi= ng > >> about this somewhere today, but right now I cannot recall where. > > > > This is the amount of system memory that is reserved for graphics > > (mostly textures). >=20 > To be more clear about this, what does "system memory" signify? Does th= at=20 > include any memory on the card? Or is this memory which is robbed from=20 > your on-board memory? Just how does that work out in practice? Short explanation of AGP memory: This is memory on your main board. When the X server is started it reserves the amount of memory specified in the AgpSize option or some sensible default and makes that available for use directly by the graphics card. So 3D applications can put textures into that part of the main memory and the card will automatically pick it up from there for rendering. This basically allows extending the size of the graphics memory. The disadvantage is that access to that memory from the graphics engine is slower, so rendering performance may suffer slightly if this memory gets used. For a more technical explanation see http://dri.freedesktop.org/wiki/AGP. >=20 > You can change it using the AgpSize option in > > xorg.conf. See the savage manpage for more options. > > > > That said, I never heard of Savage4 cards with 32MB memory. I had one > > with 16MB memory. The theoretical maximum the chip can handle is 32MB > > but I've only seen that with on-board graphics and 32MB shared graphi= cs > > memory configured in the BIOS. Your Xorg.0.log should state the amoun= t > > of graphics memory somewhere. >=20 > It says there are 32 megs. I am not at home now to be able to give you = the=20 > line from the log file which says so, but it is there. For that matter,= a=20 > flash screen at bootup gives the name of the video card and the amount = of=20 > RAM on it, too. >=20 > So I could put such a line as you say into the config file, but it woul= d=20 > be better to know exactly what this line is doing. After all, X already= =20 > correctly detects the amount of memory which is supposed to be on the=20 > card, so what is this doing, exactly? It does not change the amount of graphics memory on your graphics card. It affects by how much you extend that memory using system memory on your main board. If you don't use any applications that need lots of textures, you can reduce the amount of memory here. But don't reduce it to 0, because part of the AGP memory is needed for command or vertex DMA (sending stuff to the card without making the CPU wait). >=20 > Along the same lines, I have never understood what the BIOS thinks is t= he=20 > "AGP aperture" and how to set that. Right now it is set at 32mb (same a= s=20 > what is on the card) but I am uncertain about what function this BIOS "= AGP=20 > aperture" setting is serving. It has nothing to do with the amount of video RAM on your card. It's the maximum amount of system memory that you can use for AGP. If you set it to something bigger, you can reserve more system memory for AGP use. Increasing this setting alone does not consume any memory. It only sets the upper limit. Regards, Felix > And, again, does it relate to some=20 > set-aside of on-board RAM, for use to prepare things to be sent to the=20 > card, or does it relate to the RAM which is on the card? I never did=20 > understand the answer to these questions, as what is in all of the BIOS= =20 > documentation which I have ever chased down is rather cryptic and seems= to=20 > assume that I already know what I am trying to find out. >=20 >=20 [snip] --=20 | Felix K=C3=BChling <fx...@gm...> http://fxk.de.v= u | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | |
From: <ki...@ba...> - 2006-04-26 22:35:07
|
On Wed, 26 Apr 2006, Felix K=FChling wrote: > Short explanation of AGP memory: This is memory on your main board. When > the X server is started it reserves the amount of memory specified in > the AgpSize option or some sensible default and makes that available for > use directly by the graphics card. So 3D applications can put textures > into that part of the main memory and the card will automatically pick > it up from there for rendering. This basically allows extending the size > of the graphics memory. The disadvantage is that access to that memory > from the graphics engine is slower, so rendering performance may suffer > slightly if this memory gets used. > > For a more technical explanation see > http://dri.freedesktop.org/wiki/AGP. Thanks, also I found a fairly good explanation, finally, of AGP aperture.= =20 I get the impression that, most probably, this designated memory has to be= =20 within the memory designated by the BIOS as "AGP aperture"? > >> >> You can change it using the AgpSize option in >>> xorg.conf. See the savage manpage for more options. >>> After these explanations, there seems to be little point in changing the=20 default, actually. >>> That said, I never heard of Savage4 cards with 32MB memory. I had one >>> with 16MB memory. The theoretical maximum the chip can handle is 32MB >>> but I've only seen that with on-board graphics and 32MB shared graphics >>> memory configured in the BIOS. Your Xorg.0.log should state the amount >>> of graphics memory somewhere. Here (also some extra lines to ID the card): (II) SAVAGE(0): VESA BIOS detected (II) SAVAGE(0): VESA VBE Version 2.0 (II) SAVAGE(0): VESA VBE Total Mem: 32768 kB (II) SAVAGE(0): VESA VBE OEM: Diamond Mutlimedia. Savage4 (II) SAVAGE(0): VESA VBE OEM Software Rev: 1.1 (II) SAVAGE(0): VESA VBE OEM Vendor: Diamond Multimedia Inc. (II) SAVAGE(0): VESA VBE OEM Product: Stealth III Savage4 (II) SAVAGE(0): VESA VBE OEM Product Rev: Rev C (--) SAVAGE(0): Chip: id 8a22, "Savage4" (--) SAVAGE(0): Engine: "Savage4" (--) SAVAGE(0): AGP card detected >> >> So I could put such a line as you say into the config file, but it would >> be better to know exactly what this line is doing. After all, X already >> correctly detects the amount of memory which is supposed to be on the >> card, so what is this doing, exactly? > > It does not change the amount of graphics memory on your graphics card. > It affects by how much you extend that memory using system memory on > your main board. If you don't use any applications that need lots of > textures, you can reduce the amount of memory here. But don't reduce it > to 0, because part of the AGP memory is needed for command or vertex DMA > (sending stuff to the card without making the CPU wait). Probably is good to leave it at 16MB, then.=20 > >> >> Along the same lines, I have never understood what the BIOS thinks is th= e >> "AGP aperture" and how to set that. Right now it is set at 32mb (same as >> what is on the card) but I am uncertain about what function this BIOS "A= GP >> aperture" setting is serving. > > It has nothing to do with the amount of video RAM on your card. It's the > maximum amount of system memory that you can use for AGP. If you set it > to something bigger, you can reserve more system memory for AGP use. > Increasing this setting alone does not consume any memory. It only sets > the upper limit. > More seriously, I am still trying to get my mind around the MTRR errors or= =20 warnings in syslog. According to your previous message, this might=20 possibly have something to do with having framebuffer support. Well, I=20 compiled a new kernel and turned off the framebuffer support completely.=20 After starting X now I still get the syslog complaint that Apr 26 16:07:54 khayyam kernel: mtrr: 0xf0000000,0x8000000 overlaps=20 existing 0xf0000000,0x2000000 Apr 26 16:07:54 khayyam kernel: mtrr: base(0xf2000000) is not aligned on a= =20 size(0x5000000) boundary At the same time: root@khayyam:/var/log# cat /proc/mtrr reg00: base=3D0x00000000 ( 0MB), size=3D1024MB: write-back, count=3D1 reg01: base=3D0xf0000000 (3840MB), size=3D 32MB: write-combining, count=3D= 2 reg02: base=3D0xf6000000 (3936MB), size=3D 16MB: write-combining, count=3D= 1 reg03: base=3D0xf4000000 (3904MB), size=3D 32MB: write-combining, count=3D= 1 reg04: base=3D0xf2000000 (3872MB), size=3D 32MB: write-combining, count=3D= 1 reg05: base=3D0xd0000000 (3328MB), size=3D 32MB: write-combining, count=3D= 1 root@khayyam:/var/log# which AFAICT looks good (and also looks pretty much the same as before the= =20 re-compile). Apparent conclusions: 1. Nothing to do with framebuffer support per se, as that is not even=20 enabled now. 2. ?????? Any comments are welcome. I get the impression that nothing really fatal=20 is occurring here, but if that is the case then why these log messages,=20 and if OTOH there really is a problem, then what to do about it? Thanks, Theodore Kilgore |
From: <ki...@ba...> - 2006-04-25 23:16:26
|
On Tue, 25 Apr 2006, Felix K=FChling wrote: > Am Dienstag, den 25.04.2006, 18:18 -0500 schrieb > ki...@ba...: >> I tried the mailing list, and indeed it says I need to be subscribed. Oops, from what you say below, wrong mailing list. (...) >> 4. To load via-agp manually before starting X does not help at all to ma= ke >> the problem to go away. All it does is to cause via-agp to be listed whe= n >> one does lsmod. One only achieves >> >> root@khayyam:/etc/X11# lsmod|grep agp >> via_agp 7808 0 >> agpgart 28976 2 via_agp,drm >> root@khayyam:/etc/X11# >> >> but Xorg.0.conf _still_ says when I restart X after manually installing >> the via_agp module, that AGP is not available and it is falling back to >> PCI mode. (Also noticing that modules.dep requires agpgart before via_ag= p >> instead of the other way round, which seems strange) > > It makes sense to me. The hardware-specific module requires the generic > one. OTOH the generic one wouldn't know which hardware-specific one to > depend on. > OK. Sortof makes sense, though OTOH it would also seem to make sense for=20 the hardware to be found first, or else neither via-agp nor agpgart gets=20 loaded. But after having looked into that part of the kernel code and=20 seen who wrote it, I will take your word for it. :) > Does dmesg say anything about via-agp? Does it find the AGP bridge? > No, it says nothing at all about these things. root@khayyam:/lib/modules/2.6.16.8# dmesg|grep agp Linux agpgart interface v0.101 (c) Dave Jones Linux agpgart interface v0.101 (c) Dave Jones root@khayyam:/lib/modules/2.6.16.8# and moreover in the following no memory location or allocation is=20 mentioned: root@khayyam:/lib/modules/2.6.16.8# dmesg|grep drm [drm] Initialized drm 1.0.1 20051102 [drm] Initialized savage 2.4.1 20050313 on minor 0 [drm] Module unloaded [drm] Initialized drm 1.0.1 20051102 [drm] Initialized savage 2.4.1 20050313 on minor 0 root@khayyam:/lib/modules/2.6.16.8# (note: the unloading and reloading was done by hand, to try to make things= =20 work in the proper order -- see below). > Also make sure that savage and drm are loaded after via-agp and agpgart. Saw that in the troubleshooting guide. But how? In modules.dep both savage= =20 and drm list a dependency upon agpgart, but neither lists a dependency=20 upon via-agp. I have, of course, also tried doing this by hand in the=20 prescribed order. But that was of no help (probably because the AGP bridge= =20 is not found?). The via-agp is ignored, it seems. Could be that the problem is an "unknown" chipset on the board? OK,=20 I'll bite. Which one of these creatures is supposed to be the "AGP=20 bridge"? I don't see it mentioned. (lspci output follows) root@khayyam:/lib/modules/2.6.16.8# lspci 00:00.0 Host bridge: VIA Technologies, Inc. K8M800 Host Bridge 00:00.1 Host bridge: VIA Technologies, Inc. K8M800 Host Bridge 00:00.2 Host bridge: VIA Technologies, Inc. K8M800 Host Bridge 00:00.3 Host bridge: VIA Technologies, Inc. K8M800 Host Bridge 00:00.4 Host bridge: VIA Technologies, Inc. K8M800 Host Bridge 00:00.7 Host bridge: VIA Technologies, Inc. K8M800 Host Bridge 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge=20 [K8T800/K8T890 South] 00:0f.0 IDE interface: VIA Technologies, Inc.=20 VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1=20 Controller (rev 81) 00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1=20 Controller (rev 81) 00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1=20 Controller (rev 81) 00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1=20 Controller (rev 81) 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge=20 [KT600/K8T800/K8T890 South] 00:11.5 Multimedia audio controller: VIA Technologies, Inc.=20 VT8233/A/8235/8237 AC97 Audio Controller (rev 60) 00:11.6 Communication controller: VIA Technologies, Inc. AC'97 Modem=20 Controller (rev 80) 00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev= =20 78) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]=20 HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]=20 Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]=20 DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]=20 Miscellaneous Control 01:00.0 VGA compatible controller: S3 Inc. Savage 4 (rev 03) root@khayyam:/lib/modules/2.6.16.8# > > This is a DRI-specific issue, so dri-users should be the right mailing > list. It does not require subscription. I'm CCing that list. Thanks. Theodore Kilgore |