New Posts  All Forums:Forum Nav:

Gentoo on the 4780 - Page 3

post #41 of 69
2/11/04 at 3:35pm
Thread Starter 

New Error

The above settings are what they look like after changing to the internal agpgart. Now, when loading up X, as it's initializing DRI, I get this if I haven't pre-loaded the fglrx module by hand:

(II) fglrx(0): doing DRIScreenInit
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (No such device)
drmOpenDevice: open result is -1, (No such device)
drmOpenDevice: Open failed
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (No such device)
drmOpenDevice: open result is -1, (No such device)
drmOpenDevice: Open failed
[drm] failed to load kernel module "agpgart"
[drm] failed to load kernel module "fglrx"
(II) fglrx(0): [drm] drmOpen failed
(EE) fglrx(0): DRIScreenInit failed!


Here's what I get if I've done an "insmod /lib/modules/2.6.1-gentoo-r1/video/fglrx.ko" first:

(II) fglrx(0): [drm] loaded kernel module for "fglrx" driver
(II) fglrx(0): [drm] created "fglrx" driver at busid "PCI:1:0:0"
(II) fglrx(0): [drm] added 8192 byte SAREA at 0xf9a3e000
(II) fglrx(0): [drm] mapped SAREA 0xf9a3e000 to 0x401f2000
(II) fglrx(0): [drm] framebuffer handle = 0xf0000000
(II) fglrx(0): [drm] added 1 reserved context for kernel
(II) fglrx(0): DRIScreenInit done
(II) fglrx(0): Kernel Module Version Information:
(II) fglrx(0): Name: fglrx
(II) fglrx(0): Version: 3.2.8
(II) fglrx(0): Date: Sep 21 2003
(II) fglrx(0): Desc: ATI Fire GL DRM kernel module
(II) fglrx(0): Kernel Module version matches driver.
(II) fglrx(0): Kernel Module Build Time Information:
(II) fglrx(0): Build-Kernel UTS_RELEASE: 2.6.1-gentoo-r1
(II) fglrx(0): Build-Kernel MODVERSIONS: no
(II) fglrx(0): Build-Kernel __SMP__: no
(II) fglrx(0): Build-Kernel PAGE_SIZE: 0x1000
(II) fglrx(0): [drm] register handle = 0xec100000
(II) fglrx(0): [agp] Mode=0x1f004e1b bridge: 0x1039/0x0648
(II) fglrx(0): [agp] AGP disable mask 0x00000000
(II) fglrx(0): [agp] enabling AGP with mode=0x1f004f1a
(EE) fglrx(0): [agp] Failed to set AGP mode!
(EE) fglrx(0): cannot init AGP
(II) fglrx(0): [drm] removed 1 reserved context for kernel
(II) fglrx(0): [drm] unmapping 8192 bytes of SAREA 0xf9a3e000 at 0x401f2000
(WW) fglrx(0): ***********************************************
(WW) fglrx(0): * DRI initialization failed! *
(WW) fglrx(0): * (maybe driver kernel module missing or bad) *
(WW) fglrx(0): * 2D acceleraton available (MMIO) *
(WW) fglrx(0): * no 3D acceleration available *
(WW) fglrx(0): ********************************************* *
(II) fglrx(0): FBADPhys: 0xf0000000 FBMappedSize: 0x08000000

Then it locks up.
Reply
Reply
post #42 of 69
2/11/04 at 4:00pm
Thread Starter 
I find this part mildly interesting:

(II) fglrx(0): Build-Kernel __SMP__: no

That's definitely *not* correct, as I am running an SMP kernel:

Linux iolite 2.6.1-gentoo-r1 #4 SMP Fri Feb 6 23:10:36 PST 2004 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz GenuineIntel GNU/Linux

Whether that's enough to kill this or not, though, I couldn't say.
Reply
Reply
post #43 of 69
2/11/04 at 11:32pm
I don't know if they'll really help, but try setting "UseFastTLS" to "2", and adding

"EnablePrivateBackZ" "yes"

Actually, mine gives "no" for __SMP__ also. I think there's something wrong with the way the driver detects smp. (Maybe it only enables for real smp systems, and not hyperthreading ones)

I was going to suggest changing the agp aperture, but I remembered you already did that.

I'm not quite sure what to say anymore, but I'll try some suggestions:

"Failed to set AGP mode" seems to suggest that it has something to do with agpgart, though I can't really say for sure.
You might want to try changing back to the external agpgart, but compiling it directly into the kernel instead of as a module. (actually, I remember agpgart as a module gave me problems at some point way back in the day)

Also, in the X logs, if you go to the drmOpenDevice section (the same part where you're getting "No such device" errors when you don't preload the module), what does it say?

And on a related note, after modprobing the fglrx module, check and see if you really do have a /dev/dri/cardX node (or several).
Reply
Reply
post #44 of 69
2/12/04 at 11:54am
You are compiling agp into the kernel right. Is the agpgart module loaded when you try and manually load the module by hand? Remember lsmod is your friend
Reply
Reply
post #45 of 69
2/12/04 at 7:10pm
Thread Starter 
I've tried compiling agpgart into the kernel, as a module, and leaving it out completely. It doesn't seem to make a whole lot of difference how I do it. I suspect the reason it's working for other people and not for me is the SiS chipset on the 4780, but that's just a wild guess at this point.

The /dev/dri/cardX nodes do exist, as long as agpgart is loaded... At this point, I'm not sure what else I can try. I'm going to play with the AGP BIOS settings next, I think, since I know they've caused me grief (and very similar system lockups) in other parts of this installation.

I'm also currently playing with a 2.4.22 kernel, though it's doing the same thing as the 2.6.1 kernel. The Gentoo drivers for the modem currently will only compile under a 2.4 kernel (there are newer versions of the driver in the unstable portage tree, but they didn't want to compile for me).

I may never use the modem, but my goal here is to get as much working as I can, whether I need it or not.
Reply
Reply
post #46 of 69
2/15/04 at 2:02pm
Thread Starter 

Giving Up (for now) on DRI

I've been banging my head against this DRI thing for a while now, and really threw some time into trying to get it to work this weekend. After quite a bit of research, I've figured out that the problem isn't that I'm doing something wrong, it's that the support for the SiS AGP chipset is incomplete, and I'm just not going to be able to get it working without some fixes to either the kernel AGP drivers or the ATI code. If I get time at some point I may try doing the fixes myself, but I'm not feeling too optimistic due to relatively little documentation available from SiS.

It's a bit of a bummer, but I figure I'm not losing DRI; I'm gaining a project.
Reply
Reply
post #47 of 69
2/15/04 at 5:33pm
Yeah, since you've put in enough time I guess its a good idea to let it be for a while. Plus, you're not really losing anything as long as you dont intend to game in Linux (I have only tried Q3 Arena on Linux - but that was just to see if it works).

Mikhail
Reply
Reply
post #48 of 69
2/17/04 at 4:51pm
Thread Starter 
Well, looks like I've gotten about as far as I'm going to get, so here are my final results, with any pertinent gotchas I can think of:

Version: I used Gentoo 1.4, with a 2.6.1 kernel built from gentoo-dev-sources.

Installation: I got my best results disabling all internal hardware (sound, modem, etc, and firewire) through the system BIOS before starting installation, and booting from the LiveCD with the "acpi" kernel. Once initial installation was done, I was able to re-enable all hardware in the BIOS and get a clean boot. I still have the AGP aperture set to 64M -- setting it to 128M caused some booting issues.

Video: Works fine at native resolution, but no DRI. Currently I've got it using the ATI drivers, and told it to use external agpgart. The agpgart and fglrx modules load at system startup. As long as I do *not* load the kernel sis-agp module, all works well. Loading sis-agp will cause a system lockup when X starts. glxgears reports frame rates of 300-500 FPS. Console appears to be running at native resolution via VESA framebuffer using "vga=791" parameter passed to kernel at boot. Rumor has it the new XFree 4.4 *may* have better Radeon/SiS support, and I'm hoping that'll resolve the DRI issues.

Audio: Works, using Alsa with the intel8x0 driver.

Ethernet: Works, using r8196 driver.

DVD/CD-RW: Works.

Fax Modem: Currently available slmodem drivers to not build under 2.6.x kernels, only 2.4.x. I rarely (if ever) use the modem, so didn't take the time (yet) to find out if these drivers actually work under older kernels.

Wireless: Not installed on my 4780.

TV Tuner: I had earlier thought the tuner card was recognized by the V4L drivers, but was mistaken. It appears the USB version of the AverMedia TV Studio card is not yet supported under Linux.

CMOS Video Camera: No Linux drivers available.

Hyperthreading: Works, with SMP kernel.

The system's been very stable since it was set up... and I've never had a machine that handled compiling all this Gentoo stuff as well as my 4780 with hyperthreading enabled. It *flies* through compiles now, even with its 4800 RPM drive.

Now I'm playing with development sources (using ACCEPT="~x86" in make.conf) and everything seems to work fine with those, too. No real differences to speak of.
Reply
Reply
post #49 of 69
3/4/04 at 11:10pm

New here, but figured I'd post an update

For those users of the 4780 who have been unable to get their laptops working with DRI, I have found a working solution(after a bit of research...). Mind you, I'm running slackware and not gentoo, and I'm running the 2.6.3 kernel. Theres a patch thats been released to fix the sis-agp module thats been causing us to be unable to use the dri under X. The patch is posted here for those of you who are willing to try it out. *Mind you, I do not take any responsibility in the case of a problem, and you are applying the patch at your own risk.* That said, it works great for me and I'm getting 191 FPS running glxgears fullscreen at 1440x900 resolution. This is with the 3.7.0 ATI drivers, I have yet to test out the 3.7.1 one.
Hope this info helps! =)

-Xaxeon
Reply
Reply
post #50 of 69
3/5/04 at 7:30pm
Thread Starter 
Xaxeon, you are my new favorite person.

I applied the kernel patches, and I'm happy to report DRI now works under Gentoo as well. A windowed glxgears is now getting around 2400-2500, using the 3.2.8 ATI drivers.


Even better, I know know it wasn't me screwing up, and that it really was buggy drivers for the SiS chipset.
Reply
Reply
post #51 of 69
3/5/04 at 7:51pm
Awesome news, TrickM. Yeah, those SIS drivers have always given people trouble.

Mikhail
Reply
Reply
post #52 of 69
3/5/04 at 11:40pm
BTW, have any of you had a problem with the NIC(r8169) locking up under high load? If I try and transfer a file on my local network, it gets up to about 8k/sec and then the netcard locks up and won't work anymore unless the laptop is rebooted.
-Xaxeon
Reply
Reply
post #53 of 69
3/6/04 at 12:58am
Although I have an 5680, I have never experienced the problem.
Reply
Reply
post #54 of 69
3/6/04 at 2:55pm
Quote:
Originally Posted by xaxeon
BTW, have any of you had a problem with the NIC(r8169) locking up under high load? If I try and transfer a file on my local network, it gets up to about 8k/sec and then the netcard locks up and won't work anymore unless the laptop is rebooted.
-Xaxeon
Just a question about your issue. Is the 8k a speed that is always locks at or does it run for a while on a big file at around 8k then freeze. If it locks as soon as it hits the 8k speed than I am unsure as to the problem. I run mine on an internal network at much higher speeds than that, but a large file seems to give me problems on my home network. Around 1 gig for a unfixed amount of time will give a NIC freeze. I figured it was the CRC erroring out on the return. The file sends okay but the NIC errors in the end and I have to reboot. May be my network config.
Reply
Reply
post #55 of 69
3/6/04 at 9:19pm
Thread Starter 
I've had no problems whatsoever with the network card. I've seen similar lockups on other machines, though, if the card's duplex setting didn't match the hub or switch it was plugged into.
Reply
Reply
post #56 of 69
3/7/04 at 12:40am
Its not a set speed that it happens at, its just after a very short period of transmitting at high speed(using a 10/100 hub) over my lan it locks up. bringing the eth0 down and back up via ifconfig, and even unloading/reloading the module doesn't do it. I know I saw someone mention it might have something to do with SMP/PREEMPT settings in the kernel. So thats where I am right now. Though I do have a pcmcia nic card I can use while in linux so its not a major issue, more of an annoyance. =) If I can figure anything else out about it, I'll post it here.
-Xaxeon
Reply
Reply
post #57 of 69
3/8/04 at 4:47pm
Thread Starter 
Deleted my last message -- forgot which OS we're talking about here. Gimme a minute for one that makes sense.
Reply
Reply
post #58 of 69
3/8/04 at 4:51pm
Thread Starter 
[Still feeling stupid for posting instructions on checking duplex settings under Windows]

You're on a hub? Definitely check your duplex settings, since it may be autonegotiating incorrectly.

If you don't have the ethtool package installed, install it. Then run "ethtool -s eth0 speed 100 duplex half" and see if the problem persists (or just take a look at the output of an ifconfig or dmesg to verify you're at half duplex).

If it's autonegotiating to full duplex with your hub, it'll cause problems like you're describing, since hubs don't support full duplex.
Reply
Reply
post #59 of 69
3/8/04 at 5:12pm
Just wondering but why use the kernel agpgart module and not the internal ATI dirvers one. Switching to the internal ATI agp increased my FPS and lowered my artifacts in ET RTCW - not the same systems I admit - jsut curious.
Reply
Reply
post #60 of 69
3/8/04 at 5:25pm
Thread Starter 
The internal one cannot initialize AGP -- if you dig back further in this thread you'll see the error messages it spits out. As a result, DRI won't work at all with the internal module.
Reply
Reply
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Linux & Other OS's