Nightwulf|work: hi all
mcgreg: hi
mcgreg: just tested alien-arena, highest settings and played 30seconds singleplayer .. it crashed with :
mcgreg: crx: r700_assembler.c:1088: next_ins: Assertion `pAsm->D.dst.reg >= pAsm->starting_export_register_number' failed.
mcgreg: google didnt tell me anything about that
Imperion: has R300 been fixed yet?
Imperion: *support
Imperion: has R300 support in Gallium been fixed yet?
glisse: fixed of what ?
chithead: Imperion: which bug # ?
Imperion: fixed of general not working
Imperion: as in, no discernable visuals
dileX: if you expect help, you should give more infos (for example show logs)
Imperion: nvm, I'll go readd xorg-edgers to my repos
Imperion: yay, everything's fixed
twnqx: am i actually still the only one who has issues when closing tabs that contain only an image in firefox? issues like, 100% cpu in X for multiple seconds, and only with KMS?
mentor: twnqx: I don't see it
twnqx: funny.
twnqx: i wonder which part (or combination of parts) of my system causes it
xming: twnqx: the user :p
twnqx: :(
xming: twnqx: maybe some FF add-ons
twnqx: but... why with KMS but not UMS?
twnqx: my bet rather goes in the direction of pango/cairo
glisse: twnqx: best is to use something like sysprof
glisse: run sysprof before closing the tab
glisse: stop it once you have the cpu back to normal
glisse: it should allow you to quickly point finger
twnqx: i can't even switch windows while that happens, X is completely loaded :P
glisse: twnqx: i told you to start sysprof before closing the window so before X is overloaded
glisse: and stop it after
twnqx: do i need kernel profiling support for that?
glisse: better with it
glisse: as then sysprof can also find out what the kernel is doing
TuomasT: Any ETA for working TV-out on R670? (well it works if only video cable in card when booting, but otherwise it is impossible to active both monitor and TV or only TV after boot)
glisse: TuomasT: it should work by forcing the output on with xrandr
agd5f: TuomasT: make sure the tv standard is set correctly
TuomasT: glisse: forcing?
TuomasT: glisse: I think you mean just this: http://www.x.org/wiki/radeonTV
TuomasT: The issue is that when I call "xrandr --output S-video --mode 800x600" then both the monitor and TV lose signal
TuomasT: (replace S-video with DIN)
agd5f: TuomasT: what other connector are you using?
agd5f: your monitor
TuomasT: agd5f: monitor with normal VGA connection and S-video TV
TuomasT: Monitor = Viewsonic VE500 15" LCD
agd5f: TuomasT: they might both be using the same DAC. Can you pastebin your dmesg?
TuomasT: agd5f: http://palvelin.dynalias.org/dmesg.txt
TuomasT: I might add that it has some EDID related errors :)
agd5f: TuomasT: the edid stuff should be fixed
agd5f: in a newer kernel
agd5f: TuomasT: the part I need has already scrolled past
agd5f: TuomasT: what connectors does your card have?
TuomasT: agd5f: dmesg link updated to fuller version. 2XDVI + S-video/composite/RGB TV out
agd5f: TuomasT: try the monitor on the other DVI port
agd5f: TuomasT: the DIN port and the VGA part of one of the DVI ports share the same DAC so they can't be used at the same time
TuomasT: agd5f: And works fine now..
TuomasT: Maybe xrandr should be able to tell user about a case like this
agd5f: TuomasT: randr doesn't really have a good mechanism for feedback of information like that
T_UNIX: hey there
T_UNIX: thanks for the GREAT work on the drivers :-)
T_UNIX: One question: Is the _constant_ flickering a known issue (radeon mobility x1400)?
glisse: T_UNIX: depends we got some user experiencing flickering but it's hard to know if it's the same issue causing the same effect
T_UNIX: glisse: is there some sort of reinitialization on lid close/open?
T_UNIX: cause sometimes it flickers _really_ hard and a workaround is to close and open the lid
T_UNIX: restart "fixes" it as well for some time
T_UNIX: how did you guys get to driver programming esp. graphic drivers?
glisse: try booting with radeon.new_pll=0 or radeon.new_pll=1 see if one helps
dileX: T_UNIX: 2.6.35-rc3?
T_UNIX: I'm really interested in that but have about 0 clue of it.. should be a course at university since it's a big field atm. :-/
T_UNIX: dileX: since an hour 2.6.35 daily
dileX: here I have x1300 - and sometimes flickering makes desktop unuseable. even setting low-profile as pm-method does not help. didnt test with lid close/open. but will try next time.
T_UNIX: I'll finish lunch and let you know about the new_pll later :-)
T_UNIX: glisse: thanks for now :-)
mcgreg: wow I just got the strangest crash ever. I updated ddx (mesa and drm is uptodate kernel is 2.6.35-rc2) .. just for fun I started wine Wow (world of warcraft) - I goit into the main screen - which was corrupted as usual.
mcgreg: I exited it...
mcgreg: the screen (kde screen) was corrupted
mcgreg: for a few second nothing happened...
mcgreg: then, Xorg crashed , back to the login screen - it was currupted too
mcgreg: for a few second nothing happened... and then my compuiter rebooted
mcgreg: like if I pressed the "reset" button - just I didnt do anything
dileX: wiki: I added new troubleshooting item "Troubleshooting flickering with radeon power-management (2.6.35-rcX)"
dileX: will add later new power-methods and explain diverse profiles (after soccer)
agd5f: dileX: if anything setting a low power state will make things worse
dileX: agd5f: so whats your recommended strategy to have less flickering - let things be "auto"?
agd5f: dileX: depends what the cause of the flickering is
dileX: thats hard to say
dileX: sometimes it happens when I compile software with parallel-make-jobs >=3..5
agd5f: dileX: constant flickering or momentary flickering when you change the power state or during certain accel ops
agd5f: dileX: IGP chip?
dileX: looks like the whole desktop screen is "partially not syncing" (sorry for my bad english)
dileX: x1300 pcie
dileX: rv515
agd5f: dileX: all the time or only in certain cases?
dileX: not all the time - but cpu-load is definitely one trouble-maker
TuomasT: Just for the record I have terrible 2D experience with HD 3850 with power management on, however I have downclocked the card in 2D from 300/722 to 200/678 so it is probably my own fault
dileX: after reboot - I start with nomodeset into init-3 - and when I load radeon-module with kms-enabled it sometimes start immediately flickering (seldom). in VT before starting X
agd5f: dileX: try forcing the CPU into a fixed power state instead of using ondemand, etc.
agd5f: TuomasT: lower clocks, lower performance
TuomasT: agd5f: exactly
dileX: yes, I have here cpu-freq (utils) running
TuomasT: As soon as I have Windows again I will put it to default
dileX: agd5f: counting to five before reloading with kms-enabled helps. like a ritual as soccer player do :-)
dileX: (nice, cbrill fixed automatic linkification in dri-log)
mcgreg: ok, I just repeated the wine Wow - test ... I got the same corruption - even after I restarted Xorg the screen was corrupted but I got no crashes this time. the corruptions look like that
mcgreg: http://i.imagehost.org/0109/screenshot1.jpg
mcgreg: dmesg didnt do any output since I did dmesg >dmesg-output.txt before I rebootet and after I restarted Xorg
mcgreg: ok now I even have curroptions after playing alien-arena fullscreen
mcgreg: now it#s just fonts being corrupted
mcgreg: hmm the corruptions slowly disappeared
T_UNIX: glisse: =0 option seems to work. But fps cut half (~2500 instead of ~5000)
glisse: glxgears is not a benchmark
T_UNIX: yeah, I see
glisse: and i would be surprised that pll have anything to do with fps
T_UNIX: it was just because of the composite manager running
T_UNIX: it's up to 5000 without it :-)
glisse: agd5f: we don't have force old pll infrastructure right ?
T_UNIX: what's pll? poll?
glisse: no, pll
glisse: it's the clock driving the display
glisse: laptop are very sensitive to pll
T_UNIX: aah...
glisse: thing is there is many way to compute pll and each algo might produce slightly different value which in the end might lead to issue such as flickering
glisse: but with display port pll are gone, thought there is other issue
T_UNIX: it usually wasn't really 'strong' but annoying. Just got 'strong' (screen was unreadable) here and then. Also sometimes a mix of artefacts and flickering appeared
agd5f: glisse: new_pll=0
mentor: Well, PLL is a phase lock loop, which generally multiplies a reference clock frequency
glisse: agd5f: i was think more like a list of hw on which we would automaticly use old pll algo
agd5f: glisse: we use the old algo on pre-avivo
glisse: it's an avivo laptop
glisse: which does work better with the old algo
glisse: T_UNIX: you should open a bug and attach dmesg when both booting with : drm.debug=15 radeon.new_pll=0
glisse: and drm.debug=15 radeon.new_pll=1
glisse: so we can compare pll values
T_UNIX: glisse: I will as soon as I've rebootet twice ;-)
agd5f: glisse: there used to be a quirk handler for LVDS to select different algos for specific laptops in radeon_atombios.c, but I removed it as the laptops I added it for ended up being a different issue
glisse: i will compare pll value and see how far they are from each other
glisse: if it's really small then i guess quirks are the best way to deal with this crap
agd5f: glisse: I don't think debug prints out the divider values
glisse: i thought it did
agd5f: only for new_pll
glisse: lucky me
agd5f: glisse: radeon_encoder_atom_dig struct still has the pll_algo member so it would be easy to resurrect the quirk
sling-shot: Hi. Does radeonhd support compositing in KDE/
Ke: radeonhd is obsolete
sling-shot: Then it is just radeon? Does it?
sling-shot: Right now my system is using 'ati' driver (not fglrx because X does not lauch with it - just locks up)
sling-shot: Is that 'ati' the same as 'radeon'?
MostAwesomeDude: More or less. ati is a small wrapper that loads radeon.
ajax: well, that loads whatever the right driver is, which could be radeon r128 or mach64, but if it's a radeon it'll load radeon.
MostAwesomeDude: And of course nobody has those old cards. I can't even find my Rage. :C
sling-shot: I have HD4670. I am actually trying to see if there is a way to get the proprietary driver work or if it fails open driver with support for KDE compositing.
agd5f: sling-shot: compositing works fine.
dileX: agd5f: googled a bit for the cpu-on-demand thing you mentionned. found http://lwn.net/Articles/384132/
dileX: "This problem can also affect 3D apps, where the CPU may alternate between heavy calculations and waiting for the GPU. Will these patches help for that case, or are they strictly for disk I/O?" unfortunately, this is not answered there.
sling-shot: For me compositing is disabled! :-(
agd5f: dileX: sounds like it. IIRC there was an fdo bug with similar issues to what you described and the fix was to turn off the ondemand governor
agd5f: sling-shot: make sure you have 3D enabled. if you want to use the open driver you need to uninstall fglrx
sling-shot: agd5f: Right now Synaptic (my package manager) says fglrx is installed. Using XFdrake (the xorg.conf editing tool) I have set it to use the free driver.
mwc: sling-shot: fglrx includes a kernel module, you'll need to prevent that from loading. Easiest thing to do is uninstall fglrx
mwc: lsmod | grep fglrx to see if there's anything installed
agd5f: sling-shot: you need to uninstall it. fglrx also replaces several X-related libs
sling-shot: agd5f: "lsmod | grep fglrx" gives no output. I guess it is not installed then?!
sling-shot: mwc: "lsmod | grep fglrx" gives no output. I guess it is not installed then?!
mwc: at least the kernel module isn't loaded, but there can be x libs as well
sling-shot: agd5f: I will uninstall fglrx now.
sling-shot: Synaptic shows the following as installed: [1] dkms-fglrx [2] fglrx-control-centre [3]x11-driver-video-fglrx
sling-shot: Shall I remove all?
mwc: yep, those are respectively the kernel module, the GUI control stuff, and the X libs
sling-shot: Marking x11-xxx for removal also removes the other 2. So going ahead...
sling-shot: Should I reboot after this or just restarting X will be sufficient?
sling-shot: Hmmm. Synaptic has hung "Applying Changes" thinking will it be wise to kill Synaptic
sling-shot: Going down for reboot.
sling-shot: Will be back to tell you what happened
sling-shot: Something looks odd. I have uninstalled fglrx and rebooted. Compiz is installed as per Synaptic. Why am I still not able to use compositing/
agd5f: sling-shot: make sure 3D is enabled. see what the renderer line in glxinfo says
sling-shot: agd5f: This here is my glxinfo : http://pastebin.com/52Kcqnen
sling-shot: agd5f: Is that SGI the one you refer to as renderer?
BioTube: OpenGL renderer string: Software Rasterizer
sling-shot: BioTube: That means my video card is not being used?
BioTube: correct
sling-shot: Hmmm... what might be the next step?
BioTube: check your Xorg log and dmesg for causes
sling-shot: Any clue as to what should I look for? (I am like "your eyes will not see what your mind does not know")
BioTube: things related to 'dri', 'drm' and 'radeon'
Droste: sling-shot: pastebin Xorg.log and dmesg | grep -E "drm|radeon"
sling-shot: xorg.0.log http://pastebin.com/yBxgHEnZ
sling-shot: Some DRI2 fail seems to be there. AIGLX is reporting some fail.
BioTube: (EE) AIGLX error: dlopen of /usr/lib/dri/r600_dri.so failed
BioTube: looks like you don't have the 3d driver installed
sling-shot: dmesg | grep -E "drm|radeon" http://pastebin.com/u3n8KXwJ
sling-shot: This was the final screen generated by XFdrake after configuring display http://pastebin.com/dw1Ld94c
sling-shot: Droste: dmesg | grep -E "drm|radeon" i suppose deals with some kernel thingy
Droste: right
sling-shot: Wow! This Linux is sure a great teacher :-)
Droste: you're missing the 3d (mesa) driver
Droste: and I would suggest to update xserver to at least 1.7.x and kernel to 2.6.33
Droste: and to delete xorg.conf after updating to >=1.7.x
sling-shot: Droste: I will search Synaptic for that
sling-shot: Droste: Installing new kernel. xorg-x11 exact version is not know but installing something called 7.3.something
Droste: oh stop
Droste: 7.3 is too old
sling-shot: Droste: Ok. Aborted installation midway.
Droste: reinstall 7.4
sling-shot: Droste: You mean I had 7.4 and was going to install 7.3? Weird.
sling-shot: Which command will tell me which version of X i am using?
Droste: Xorg -version
sling-shot: The first line is X.Org X Server 1.6.5
Droste: it's also in your xorg.log
Droste: yes
Droste: it's the version of the xserver
sling-shot: But that does not correspond with the Synaptic versioning (=7.3-1pclos2010)
Droste: that package has many programs with different versions in it. http://www.x.org/wiki/Releases/7.3 and http://www.x.org/wiki/Releases/7.4 shows what programs are included and the versions of them
Droste: 7.5 has xserver with 1.7.1
sling-shot: Droste: That means I am running Xorg version 7.3 with X11 version 1.6.5 and considering x.org says X11R7.5 was released on October 26, 2009, I am ancient ;-)
Droste: yes :-)
Daekdroom: Xserver version != xorg version
sling-shot: I do not know which disto(s) you run, but I am on PCLinuxOS. Here the importance is on stability more than features/latest/greatest. PCLinuxOS is also a rolling release distro so installing from outside repos breaks warranty.
sling-shot: Yes Daekdroom. As I said earlier Linux is a great teacher. I have learnt a lot just now :-)
Droste: the problem your facing right now is, that there is no old/stable KMS radeon driver. if you want to use your graphics card with opensource drivers, you need to update to get stable drivers.
Daekdroom: A rolling release aimed at stability? O.o
sling-shot: Daekdroom: Yes. And generally it has been well received. I am one prime example. Except for this one problem I have never faced any other hiccups in my last 3 and more years with it.
sling-shot: Droste: I will request in the forum's package request section for a newer X11. Also can I just install the new kernel and see if it makes any difference with the same X11? Or will it break things?
Droste: no it shouldn't break anything
Droste: to get 3d you need a recent kernel, libdrm, xf86-video-ati and mesa
sling-shot: For the time being I will do that. Then wait for newer X11 to appear in PCLinuxOS repos. Then once again I will try the binary driver too. Who knows, may be it will work then!
sling-shot: Droste: Out of the 4 mentioned, only recent kernel is missing in the repos. rest 3 are installed as per Synaptic.
Droste: but I doubt there up-to-date
Droste: sling-shot: http://wiki.x.org/wiki/radeonBuildHowTo#Prereq.3AKMSforr100-r500.2Cr600.2BAC8-r700andr800
sling-shot: Droste: May be like X11, they are going one release back to ensure there are no unknown bugs.
sling-shot: Droste: Thanks for the link. Very informative and bookmarked right away.
sling-shot: Thanks a lot to all particularly Droste , Daekdroom and BioTube. GoodNight.
DanaG: wishes there were a nice Athlon Neo version of that Mini 5102. Bonus points if they'd put an Evergreen in it.
ConnorBehan: can someone explain why the KMS radeon driver has been getting worse and worse on an RV515 over the past year?
ConnorBehan: on 2.6.31 it works fine, on 2.6.32 my distro disabled it "for being buggy", on 2.6.33 it's really slow on my card and on 2.6.34 it appears to have dropped support for my card
MostAwesomeDude: Your distro is...Arch?
ConnorBehan: yes
ConnorBehan: I've tried several git builds in between those though
ConnorBehan: and they are always bad... the further I get from 2.6.31.6
ConnorBehan: that seems to be the magic number
MostAwesomeDude: I no longer have an RV515, but it has worked fine on my R580 for a while.
MostAwesomeDude: Are you applying Arch patches, or using vanilla?
ConnorBehan: on the kernel I just tried... I actually got "Invalid ROM contents"
MostAwesomeDude: Do you have any other cards in there? Any onboard video?
ConnorBehan: there are patches that Arch applies but I don't think they touch drm / radeon... I'll have to double check
ConnorBehan: and the other card I have is r128 based
ConnorBehan: this works fine of course
mattst88: "explain why it's getting worse" is awfully vague. What's the actual problem?
ConnorBehan: the actual problem is glxgears went from 300fps to 20fps
ConnorBehan: and X is basically unusable
ConnorBehan: even though direct rendering is on
ConnorBehan: according to glxinfo
ConnorBehan: and the problem on 2.6.34 is pretty self-explanatory
ConnorBehan: radeon_get_bios fails and the system hangs
ConnorBehan: modprobe radeon modeset=1 does that
ConnorBehan: modprobe radeon modeset=0 works though
MostAwesomeDude: radeon_get_bios failing is *bad*. File a bug for that sucker.
MostAwesomeDude: But as for performance... Could you boot into a KMS setup, and pastebin "LIBGL_DEBUG=verbose glxinfo", as well as /var/log/Xorg.0.log?
tstellar: ConnorBehan: I have a RV515 with 2.6.34-rc6 it seems to work fine glxgears gets 1261 fps.
ConnorBehan: tstellar: your RV515 is PCI express right?
tstellar: ConnorBehan: Yeah
ConnorBehan: mine is PCI
ConnorBehan: so some slowness is expected
MostAwesomeDude: Not exactly.
MostAwesomeDude: But yeah. Pastebins, please. :3
ConnorBehan: MostAwesomeDude: do I have to reinstall kernel 2.6.33, reboot and run those commands?
ConnorBehan: I'm running 2.6.31 now and it works fine
MostAwesomeDude: ConnorBehan: You don't have any of these kernels sitting around?
mattst88: Hard to tell what's wrong if it's all working fine.
ConnorBehan: what's wrong is I'm stuck at 2.6.31 and if a new kernel feature ever comes out I'll have to choose between that and KMS
ConnorBehan: MostAwesomeDude: I have the old kernels lying around but the ramdisk takes a few minutes to generate
ConnorBehan: and when I start X to open up irc and paste it here...
ConnorBehan: I will be minutes getting my mouse to move across the screen and such
ConnorBehan: I checked those commands yesterday though and AFAICT they look exactly the same as they do now
ConnorBehan: only the dmesg changed significantly
MostAwesomeDude: I'd like to see the dmesg too, then.
ConnorBehan: should I do a comparison for all three files?
ConnorBehan: what they look like on .31 and what they look like on .33?
mattst88: yeah, can't hurt.
tstellar: ConnorBehan: You could boot into a "non-working" kernel, save the logs, and then boot into your "working kernel" and paste the logs.
tstellar: That way you don't have to deal with trying to use IRC with a slow X server.
ConnorBehan: ok so tell me everything I need to do in the "non-working" kernel now
ConnorBehan: so I have to go back to it as few times as possible
tstellar: dmesg > demsg.bad
ConnorBehan: ok I will take the time to do that
ConnorBehan: but honestly... this is the millionth time I've noticed that radeon is broken in the new kernel and pasted logs to no avail
ConnorBehan: and I think it's because I use PCI
airlied: I'm guessing its not a radeon problem if it can't find the PCI ROM
airlied: something else probaly changed
tstellar: ConnorBehan: LIBGL_DEBUG=verbose glxinfo &>glxinfo.bad
ConnorBehan: the PCI ROM issue is 2.6.34 and I can't paste anything related to that
ConnorBehan: the system won't get far enough to even give me a shell
ConnorBehan: yeah so please don't drop support for regular PCI!
ConnorBehan: I will be back with the pastes
ConnorBehan: cya
mattst88: and I thought I was a bit nuts for using PCI radeons. I've at least kinda got an excuse.
MostAwesomeDude: I've got a few of them, but I didn't know they made any r500 PCI cards.
MostAwesomeDude: guesses that he's actually got an AGP
airlied: no a PCI one is out there
MostAwesomeDude: Really? Fascinating.
airlied: PCIE->PCI bridges
MostAwesomeDude: My roommate's got an rv630 glued onto an AGP-to-PCIe bridge, so I guess it's not *that* weird.
mattst88: MostAwesomeDude, yeah, x1300, x1550, hd2400, and hd4350 are available as PCI cards
MostAwesomeDude: mattst88: Sorry, I must have heard you wrong. Who would put an r700 on a PCI card?
mattst88: haha :)
ConnorBehan: I got the pastes but I must've not tried 2.6.33 before
ConnorBehan: that's what I'm using now and it's a bit slower than 2.6.31 but not by much
ConnorBehan: err
ConnorBehan: 2.6.33.4
ConnorBehan: I retract my "worse and worse" statement
agd5f: good. complain and then leave without providing any info.