From: Gerassimo T. <g_t...@wo...> - 2003-03-30 12:53:01
|
Hi I have an HP EVO N1050v notebook with the IGP RADEON 340M graphics adapter running Mandrake 9.1 (Bamboo) with the 2.4.21-0.13mdk kernel and DRM radeon module compiled. I know the ATI bridge is not supported yet since I cannot load the agpgart module (even with agp_try_unsupported=1): [root@goku drm]# modprobe agpgart /lib/modules/2.4.21-0.13mdk/kernel/drivers/char/agp/agpgart.o.gz:init_module:No such device Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters. You may find more information in syslog or the output from dmesg modprobe: insmod /lib/modules/2.4.21-0.13mdk/kernel/drivers/char/agp/agpgart.o.gz failed modprobe: insmod agpgart failed and in syslog I get : Mar 30 14:31:01 goku kernel: Linux agpgart interface v0.99 (c) Jeff Hartmann Mar 30 14:31:01 goku kernel: agpgart: Maximum main memory to use for agp memory: 409M Mar 30 14:31:01 goku kernel: agpgart: unsupported bridge Mar 30 14:31:01 goku kernel: agpgart: no supported devices found. In Mandrake 9.1rc2, I could not load either the ATI or RADEON driver in X, but with this new MDK release it works (XFree86 version 4.3.0). However, when I do a xdpyinfo, I do not get a line that says XFree86-DRI. But I can load the DRM radeon kernel module just fine : modprobe radeon lsmod Module Size Used by ... radeon 107428 0 (unused) ... So, can I conclude that until support is provided for my specific ATI bridge, I will not be able to use any DRI features? And, although this probably isn't the list to ask this, but is there anyway I can help by providing info on this specific bridge? Additionally, if there is another list I should discuss this agp issue, could someone direct me to one? I've included relevant outputs from lspci, glxinfo and dmesg at the end of the email for those interested. Thanks Regards, G. Tselentis lspci: 00:00.0 Host bridge: ATI Technologies Inc: Unknown device cab2 (rev 02) 00:01.0 PCI bridge: ATI Technologies Inc: Unknown device 7010 ... 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon IGP 340M /var/log/dmesg: ... [drm] Initialized radeon 1.7.0 20020828 on minor 0 ... glxinfo: ... Xlib: extension "XFree86-DRI" missing on display ":0.0". ... OpenGL vendor string: Mesa project: www.mesa3d.org OpenGL renderer string: Mesa GLX Indirect OpenGL version string: 1.3 Mesa 4.0.4 ... |
From: <sm...@wa...> - 2003-04-03 18:59:38
|
> > (WW) RADEON(0): Direct rendering not yet supported on > > IGP320/330/340/350 integrated chips > > It's right there, in your server log. It has nothing to do with the > AGP bridge, it's just that your chip is not supported (yet). According > to > http://mirror.ati.com/technology/hardware/mobilityradeon7000IGP/index.html > it is similar to the Radeon 7000, at least the name ;-). But obviously > it's not close enough. Maybe someone on dri-devel or dri-users knows > more about the status of support for these mobile chipsets. IIRC the support is not there. Liam ---- it depends |
From: Roland S. <rsc...@sw...> - 2003-03-31 17:16:30
|
Gerassimo Tselentis wrote: > I have an HP EVO N1050v notebook with the IGP RADEON 340M graphics > adapter running Mandrake 9.1 (Bamboo) with the 2.4.21-0.13mdk kernel and > DRM radeon module compiled. I know the ATI bridge is not supported yet > since I cannot load the agpgart module (even with > agp_try_unsupported=1): <snip> you could try without agpgart, you can force pci gart (http://www.xfree86.org/4.3.0/radeon.4.html) . Not sure if this works reasonably, IIRC there were some other issues with that igp apart from the agp bridge. Roland |
From: Luis R. R. <mc...@ru...> - 2003-03-31 18:55:39
|
> you could try without agpgart, you can force pci gart > (http://www.xfree86.org/4.3.0/radeon.4.html) . Not sure if this works > reasonably, IIRC there were some other issues with that igp apart from > the agp bridge. I have the exact same AGP bridge as Gerassimo and I had tried this at no avail. I've also tried the 2.5.59 kernel but seems its still not supported. The only thing I haven't done yet is try the complete Xfree tree from CVS (I just use the drm modules). Suppose we'd want to hack the agp driver ourselves to support our bridge -- how involved would this be? Would we need to get access to some fun NDA-protected specs ? Luis R. Rodriguez |
From: Jens O. <je...@tu...> - 2003-03-31 19:32:42
|
Luis R. Rodriguez wrote: >>you could try without agpgart, you can force pci gart >>(http://www.xfree86.org/4.3.0/radeon.4.html) . Not sure if this works >>reasonably, IIRC there were some other issues with that igp apart from >>the agp bridge. > > > I have the exact same AGP bridge as Gerassimo and I had tried this at no > avail. I've also tried the 2.5.59 kernel but seems its still not > supported. The only thing I haven't done yet is try the complete Xfree > tree from CVS (I just use the drm modules). > > Suppose we'd want to hack the agp driver ourselves to support our bridge > -- how involved would this be? Would we need to get access to some fun > NDA-protected specs ? Yes, this documentation is only available directly from ATI. -- /\ Jens Owen / \/\ _ je...@tu... / \ \ \ Steamboat Springs, Colorado |
From: David M. <dm...@si...> - 2003-03-31 19:03:35
|
Running Debian Sid with XFree86 4.2.0 on an ATI All-In-Wonder Radeon (7200 core), I succesfully installed the DRI-trunk packages (including kernel module and openGL libraries). But, when I went to restart my xserver, kdm took a severe crap: it screwed up my tty sessions to the point where I had to reboot. I set my default runlevel to 3 and am able to do a startx with no problems, but everytime I go to start kdm the same thing happens. Thinking it might have been kdm, I tried xdm with the same results. Does anyone have a clue why this might be happening? I've also moved to XFree86 4.3.0 since this has all begun. Any help would be appreciated. Peace, DAVE |
From: Jens O. <je...@tu...> - 2003-03-31 14:28:24
|
Gerassimo Tselentis wrote: > So, can I conclude that until support is provided for my specific ATI > bridge, I will not be able to use any DRI features? Correct. > And, although this > probably isn't the list to ask this, but is there anyway I can help by > providing info on this specific bridge? Not at this time. You need someone with hardware specs to step forward and start supplying patches. > Additionally, if there is > another list I should discuss this agp issue, could someone direct me to > one? You've got the right list. -- /\ Jens Owen / \/\ _ je...@tu... / \ \ \ Steamboat Springs, Colorado |
From: Gerassimo T. <g_t...@wo...> - 2003-03-31 17:36:05
|
Hi Thanks for the reply. I'm gonna allow myself to ask you something, which does concern graphics (I think). My laptop's CPU runs very hot (up to 50C when the fan kicks in). I addressed this to the ACPI list already, but I wanted to ask whether the fact that my agp chipset isn't supported has something to do with this? I've got Gkrellm running and when I scroll a webpage or document using the scroll pad, the CPU is fine. But when I scroll with my mouse (click n' hold vertical scrollbar), my CPU is being drained. It shows up to 70% usage just for scrolling. My understanding is that when scrolling with a mouse wheel or scroll pad, it is done a page at a time, but with the mouse it is 'continuous' or finer which requires more graphics updating. So, repeating my question, does the fact that my agp chipset isn't detected anything to do with this? Thanks, G. Tselentis |
From: Jens O. <je...@tu...> - 2003-03-31 17:58:31
|
Gerassimo Tselentis wrote: > Hi > > Thanks for the reply. I'm gonna allow myself to ask you something, which > does concern graphics (I think). My laptop's CPU runs very hot (up to > 50C when the fan kicks in). I addressed this to the ACPI list already, > but I wanted to ask whether the fact that my agp chipset isn't supported > has something to do with this? I've got Gkrellm running and when I > scroll a webpage or document using the scroll pad, the CPU is fine. But > when I scroll with my mouse (click n' hold vertical scrollbar), my CPU > is being drained. It shows up to 70% usage just for scrolling. My > understanding is that when scrolling with a mouse wheel or scroll pad, > it is done a page at a time, but with the mouse it is 'continuous' or > finer which requires more graphics updating. So, repeating my question, > does the fact that my agp chipset isn't detected anything to do with > this? It's possible. You are probably running on the VESA driver which does software rendering. -- /\ Jens Owen / \/\ _ je...@tu... / \ \ \ Steamboat Springs, Colorado |
From: Gerassimo T. <g_t...@wo...> - 2003-03-31 20:41:35
|
> It's possible. You are probably running on the VESA driver which does > software rendering. I had it using the VESA driver when I had MDK 9.1rc2 because the radeon driver wouldn't work. But now after upgrading to MDK 9.1 (final) it accepts it, so I'm assuming it is not using the VESA driver? In the X logs, I get the following interesting lines amongst others: ... (--) RADEON(0): Chipset: "ATI Radeon IGP330M/340M/350M (U2) 4337" (ChipID = 0x4337) ... (II) RADEON(0): AGP Fast Write disabled by default (II) RADEON(0): Depth moves disabled by default ... (WW) RADEON(0): Direct rendering not yet supported on IGP320/330/340/350 integrated chips ... (II) RADEON(0): Using XFree86 Acceleration Architecture (XAA) ... Indirect CPU to Screen color expansion ... (II) RADEON(0): Acceleration enabled (==) RADEON(0): Backing store disabled (==) RADEON(0): Silken mouse enabled (II) RADEON(0): Using hardware cursor (scanline 770) (II) RADEON(0): Largest offscreen area available: 1024 x 7417 (**) Option "dpms" (**) RADEON(0): DPMS enabled (II) RADEON(0): Direct rendering disabled Please note that I don't mean interesting in a knowledgeable way but rather in an intuitive way (i.e. thumb suck). So well, the question I might ask now is whether there is any clue here as to whether it is the incompatibility in the agp that causes excessive heat/cpu utilization, and if not, where else should I dig? Thanks G. Tselentis |
From: Jens O. <je...@tu...> - 2003-03-31 20:55:18
|
Gerassimo Tselentis wrote: >>It's possible. You are probably running on the VESA driver which does >>software rendering. > > > I had it using the VESA driver when I had MDK 9.1rc2 because the radeon > driver wouldn't work. But now after upgrading to MDK 9.1 (final) it > accepts it, so I'm assuming it is not using the VESA driver? In the X > logs, I get the following interesting lines amongst others: > > ... > (--) RADEON(0): Chipset: "ATI Radeon IGP330M/340M/350M (U2) 4337" > (ChipID = 0x4337) > ... > (II) RADEON(0): AGP Fast Write disabled by default > (II) RADEON(0): Depth moves disabled by default > ... > (WW) RADEON(0): Direct rendering not yet supported on IGP320/330/340/350 > integrated chips > ... > (II) RADEON(0): Using XFree86 Acceleration Architecture (XAA) > ... > Indirect CPU to Screen color expansion > ... > (II) RADEON(0): Acceleration enabled > (==) RADEON(0): Backing store disabled > (==) RADEON(0): Silken mouse enabled > (II) RADEON(0): Using hardware cursor (scanline 770) > (II) RADEON(0): Largest offscreen area available: 1024 x 7417 > (**) Option "dpms" > (**) RADEON(0): DPMS enabled > (II) RADEON(0): Direct rendering disabled > > > Please note that I don't mean interesting in a knowledgeable way but > rather in an intuitive way (i.e. thumb suck). So well, the question I > might ask now is whether there is any clue here as to whether it is the > incompatibility in the agp that causes excessive heat/cpu utilization, > and if not, where else should I dig? Gerassimo, Looks like you've got hardware support for your 2D desktop...that's good. You don't have hardware support for 3D, but that probably isn't a problem unless you're running 3D apps. Even if you had 3D hardware support, I find that 3D applications (even screen savers) make my laptop run hot. I set my screen saver to blank instead, that helps. Any more advanced fix than that is probably related to hardware...either your individual piece of hardware is defective, or your chipset has some power feature that is not being used by the drivers. Probably your next step is to see if you can find other users with your laptop that are having similar problems. Sorry I can't be of more help. Regards, Jens -- /\ Jens Owen / \/\ _ je...@tu... / \ \ \ Steamboat Springs, Colorado |
From: Frank V. D. <fra...@st...> - 2003-03-31 20:23:17
|
On Monday 31 March 2003 19:18, Roland Scheidegger wrote: > you could try without agpgart, you can force pci gart > (http://www.xfree86.org/4.3.0/radeon.4.html) . Not sure if this works > reasonably, IIRC there were some other issues with that igp apart from > the agp bridge. Wait a minute. Are you saying that I might be able to use an agp card reliably in pci mode even if he agp driver for my motherboard sucks? Or doesn't it work for dri? -- Frank Van Damme | "Saying 8MB of RAM doesn't do as much anymore is http://www. | like saying a gallon of water holds more than it openstandaarden.be | did in 1988." --George Adkins |
From: Roland S. <rsc...@sw...> - 2003-04-01 02:23:01
|
Frank Van Damme wrote: > On Monday 31 March 2003 19:18, Roland Scheidegger wrote: > >>you could try without agpgart, you can force pci gart >>(http://www.xfree86.org/4.3.0/radeon.4.html) . Not sure if this works >>reasonably, IIRC there were some other issues with that igp apart from >>the agp bridge. > > > Wait a minute. Are you saying that I might be able to use an agp card reliably > in pci mode even if he agp driver for my motherboard sucks? Or doesn't it > work for dri? In prinicple, yes. As for "reliable" I'm not sure - there might be a reason it isn't enabled as default. I've just noticed pcigart is still #ifdefed out in radeon_cp.c, at least in the dri trunk (and if you use the new forcepcimode option XFree86 will just hang at startup filling its logfile rapidly...). But just out of curiousity, I've changed the #ifdef and enabled it. Seems to work but the performance hit is _HUGE_ (ut, quake3 are about a factor of 3 slower). That's with a via kt133a (insmoded radeon manually to be certain agpgart is not loaded), radeon 9000 pro. Looks like this isn't really an option for those poor nforce2 owners... And the driver needs to support this - the only ones I'm aware of which do are the radeon and r128. Nvidias binary driver also should work without agp support (at least you can disable it). But, as others have pointed out, it won't help the OP since the IGP still won't work, though I don't know what the differences to a standard radeon 7000 are (might need agp texturing?). Roland btw what board do you have which agp drivers sucks? I'm only aware of some boards which don't have an agp driver at all, or which don't run stable with all features (4x, sba, fw) enabled... |
From: Frank V. D. <fra...@st...> - 2003-04-01 10:43:34
|
On Tuesday 01 April 2003 04:25, Roland Scheidegger wrote: > In prinicple, yes. As for "reliable" I'm not sure - there might be a > reason it isn't enabled as default. I've just noticed pcigart is still > #ifdefed out in radeon_cp.c, at least in the dri trunk (and if you use > the new forcepcimode option XFree86 will just hang at startup filling > its logfile rapidly...). But just out of curiousity, I've changed the > #ifdef and enabled it. Seems to work but the performance hit is _HUGE_ > (ut, quake3 are about a factor of 3 slower). That's with a via kt133a > (insmoded radeon manually to be certain agpgart is not loaded), radeon > 9000 pro. > Looks like this isn't really an option for those poor nforce2 owners... > And the driver needs to support this - the only ones I'm aware of which > do are the radeon and r128. Nvidias binary driver also should work > without agp support (at least you can disable it). > But, as others have pointed out, it won't help the OP since the IGP > still won't work, though I don't know what the differences to a standard > radeon 7000 are (might need agp texturing?). > > Roland > btw what board do you have which agp drivers sucks? I'm only aware of > some boards which don't have an agp driver at all, or which don't run > stable with all features (4x, sba, fw) enabled... A Soltek sl-75fvr (kt400 northbridge, vt8235 southbridge). At least, I'm 99% sure is is due to the agp driver, since it only got supported recently (in kernel 2.4.21-pre1), since I used this graphics card in another mobo (epox 7kxa) and it ran pretty stably even with pre-release dri drivers. The sad thing is that I never get any useful messages of what went wrong, no panics/oopses or anything else that people fill bug reports with :-( -- Frank Van Damme | "Saying 8MB of RAM doesn't do as much anymore is http://www. | like saying a gallon of water holds more than it openstandaarden.be | did in 1988." --George Adkins |
From: Felix <fx...@gm...> - 2003-04-02 08:47:22
|
On 30 Mar 2003 14:52:42 +0200 Gerassimo Tselentis <g_t...@wo...> wrote: > Hi > > I have an HP EVO N1050v notebook with the IGP RADEON 340M graphics > adapter running Mandrake 9.1 (Bamboo) with the 2.4.21-0.13mdk kernel and > DRM radeon module compiled. I know the ATI bridge is not supported yet > since I cannot load the agpgart module (even with > agp_try_unsupported=1): > > [root@goku drm]# modprobe agpgart > > /lib/modules/2.4.21-0.13mdk/kernel/drivers/char/agp/agpgart.o.gz:init_module:No such device > Hint: insmod errors can be caused by incorrect module parameters, > including invalid IO or IRQ parameters. > You may find more information in syslog or the output from dmesg > modprobe: insmod > /lib/modules/2.4.21-0.13mdk/kernel/drivers/char/agp/agpgart.o.gz failed > modprobe: insmod agpgart failed > > and in syslog I get : > > Mar 30 14:31:01 goku kernel: Linux agpgart interface v0.99 (c) Jeff > Hartmann > Mar 30 14:31:01 goku kernel: agpgart: Maximum main memory to use for agp > memory: 409M > Mar 30 14:31:01 goku kernel: agpgart: unsupported bridge > Mar 30 14:31:01 goku kernel: agpgart: no supported devices found. > > In Mandrake 9.1rc2, I could not load either the ATI or RADEON driver in > X, but with this new MDK release it works (XFree86 version 4.3.0). > However, when I do a xdpyinfo, I do not get a line that says > XFree86-DRI. But I can load the DRM radeon kernel module just fine : > > modprobe radeon > lsmod > > Module Size Used by > ... > radeon 107428 0 (unused) > ... > > So, can I conclude that until support is provided for my specific ATI > bridge, I will not be able to use any DRI features? And, although this There are people who got PCI radeons working. The driver could just treat your AGP radeon like a PCI one. Try adding this line to the Device section of XF86Config-4. Option "ForcePCIMode" "true" > probably isn't the list to ask this, but is there anyway I can help by > providing info on this specific bridge? Additionally, if there is > another list I should discuss this agp issue, could someone direct me to > one? I've included relevant outputs from lspci, glxinfo and dmesg at the > end of the email for those interested. > > Thanks > Regards, > G. Tselentis > > lspci: > > 00:00.0 Host bridge: ATI Technologies Inc: Unknown device cab2 (rev 02) > 00:01.0 PCI bridge: ATI Technologies Inc: Unknown device 7010 > ... > 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon IGP 340M > > /var/log/dmesg: > ... > [drm] Initialized radeon 1.7.0 20020828 on minor 0 > ... > > glxinfo: > ... > Xlib: extension "XFree86-DRI" missing on display ":0.0". I'm not 100% sure, but I thought the DRI extension was hardware independent. So maybe you're just missing a few lines in XF86Config-4. The Module section should include these two lines: Load "dri" Load "glx" It would be helpful to see your full XF86Config-4 and /var/log/XFree86.0.log to know exactly what's going wrong. > ... > OpenGL vendor string: Mesa project: www.mesa3d.org > OpenGL renderer string: Mesa GLX Indirect > OpenGL version string: 1.3 Mesa 4.0.4 > ... > Regards, Felix ------------ __\|/__ ___ ___ ------------------------- Felix ___\_e -_/___/ __\___/ __\_____ You can do anything, Kühling (_____\Ä/____/ /_____/ /________) just not everything fx...@gm... \___/ \___/ U at the same time. |
From: Felix <fx...@gm...> - 2003-04-02 18:40:29
|
On 02 Apr 2003 20:26:06 +0200 Gerassimo Tselentis <g_t...@wo...> wrote: > (WW) RADEON(0): Direct rendering not yet supported on IGP320/330/340/350 > integrated chips It's right there, in your server log. It has nothing to do with the AGP bridge, it's just that your chip is not supported (yet). According to http://mirror.ati.com/technology/hardware/mobilityradeon7000IGP/index.html it is similar to the Radeon 7000, at least the name ;-). But obviously it's not close enough. Maybe someone on dri-devel or dri-users knows more about the status of support for these mobile chipsets. Regards, Felix ------------ __\|/__ ___ ___ ------------------------- Felix ___\_e -_/___/ __\___/ __\_____ You can do anything, Kühling (_____\Ä/____/ /_____/ /________) just not everything fx...@gm... \___/ \___/ U at the same time. |
From: Jens O. <je...@tu...> - 2003-04-04 03:56:16
|
Felix K=FChling wrote: > On 02 Apr 2003 20:26:06 +0200 > Gerassimo Tselentis <g_t...@wo...> wrote: >=20 >=20 >>(WW) RADEON(0): Direct rendering not yet supported on IGP320/330/340/35= 0 >>integrated chips >=20 >=20 > It's right there, in your server log. It has nothing to do with the AGP > bridge, it's just that your chip is not supported (yet). According to > http://mirror.ati.com/technology/hardware/mobilityradeon7000IGP/index.h= tml > it is similar to the Radeon 7000, at least the name ;-). But obviously > it's not close enough. Maybe someone on dri-devel or dri-users knows > more about the status of support for these mobile chipsets. Felix, AFAIK, it's an integrated part that resides in the north bridge...so=20 their are AGP issues just like other parts that use a similar integrated=20 design. The issues are certainly addressable by anyone with the knowledge of=20 graphics drivers, access to specs and time. I don't know of anybody in=20 that catagory right now. --=20 /\ Jens Owen / \/\ _ je...@tu... / \ \ \ Steamboat Springs, Colorado |