airlied: agd5f: can you find out why fglrx emits things to the ring in 16 dwords blocks with packet2 fillers?
roh: mmmh.. nah.. still freezes on this t60p
roh: ah.. patches in drm git
wcpl: hello all, sorry me for my poor english, but i very need in your help (:
wcpl: i have radeon xpress 1100 card, freebsd 7 default kernel, loaded radeon and drm modules, but radeon "(WW) RADEON(0): Direct rendering disabled"
wcpl: I have installed: dri-7.0.3_1,2 , Mesa 7.2
airlied: wcpl: ask rnoland on #dri-devel, he deals with the BSD stuff
airlied: wcpl: you may need to add Option "DRI" "true" to xorg.conf driver section
wcpl: ok thanx, I'll try
airlied: agd5f: also the tcore mentions "Any DMA from CP to system memory while 2D engine is busy can cause a hang" for rv410
airlied: that sounds pretty serious.
rx__: did i miss something ...
airlied: rx__: no its just on my machine :)
rx__: oh.. well as long as it's in good hands
MrCooper: airlied: sounds like we should disable writeback on RV410?
airlied: MrCooper: yeah I'm hoping there is a nicer workaround :)
MrCooper: is it a big deal?
MrCooper: assuming it's only about DMA by the CP itself, not the 2D engine, so it shouldn't affect data transfers
airlied: the CP_RESYNC stuff appears to require DMA to work, and we want to use that for CS.
glisse: airlied: we don't necessarily need dma for CP_RESYNC iirc
glisse: airlied: is their an arg to drm module to desactivate modesetting ?
airlied: glisse: modeset=0
agd5f: airlied: I think you just have to make sure the 2d engine is idle before using CP DMA
agd5f: as tot he 16 DWORD padding, I know r6xx has a 16 dword alignment, some older asics may as well
glisse: agd5f: the problem here is that CP_RESYNC don't happen at same time of ring
glisse: cp delay dma of resync things until it get a pulse from backend and this can happen while 2d start doing stuff
glisse: for alignment i saw that writting wptr with aligned ptr help to solve some lockup
glisse: agd5f: it seems there is a workaround for this like doing flush then emitting the pulse
spstarr_work: glisse: the RV410 is similar to the RV350?
glisse: spstarr_work: workaround are often asic specific
spstarr_work: glisse: not nice
glisse: so in this case RV410!=RV50
glisse: so in this case RV410!=RV350
spstarr_work: it's no wonder airlied has so many little problems on all these gpus :(
spstarr_work: if we had 10 developers that would be nice :)
kriko_root: Hi! I'm trying to setup radeon 9250se for compositing, but I'm getting:
kriko_root: direct rendering: No
kriko_root: dri is loaded
kriko_root: what could be wrong?
glisse: kriko_root: LIB_GL_DEBUG=verbose glxinfo
glisse: topof output should tell you what's wrong
glisse: or see troubleshooting on dri wikie dri.freedesktop.org
kriko_root: server glx vendor string: SGI
kriko_root: this is ok?
glisse: well no
glisse: look at your Xorg.log there should be some informations on why dri is disabled
kriko_root: can you take a look also? I already looked many times: http://pastebin.com/d4316bb51
glisse: kriko_root: tell me nothings
glisse: is what i am refering too
glisse: (EE) RADEON(0): [agp] AGP failed to initialize. Disabling the DRI.
glisse: is this with kms ?
kriko_root: I forgot -had nvidia before
kriko_root: and I added "blacklist amd64_agp"
kriko_root: will reboot now...
etnoy: there seems to be problems with 16 bit color depth and Radeon Mobility M7 LW
etnoy: more info at: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/290359
etnoy: it worked fine in older versions of xorg
etnoy: any ideas? I have been talking to the compiz devs, and they are pretty sure it's a problem with the radeon driver
otaylor: etnoy: I've never had any luck with compiz + 16bpp
otaylor: etnoy: it looked like a relatively simple problem in terms of what fbconfigs were exported, but I didn't investigate in detali
etnoy: it used to work on ubuntu hardy, but the new xorg version in intrepid isn't working :)
etnoy: my card doesn't have the vram to run 24bit depth w/ compiz
otaylor: etnoy: IMO, your card doens't really have the vram to run 16 bit depth either ... guessing from the fact that at 32bpp I don't have enough vram to really run compiz with 64mb vram
etnoy: well yeah, my box seems to use indirect rendering in any case
etnoy: maybe the diagnosis is wrong, but compiz runs as described in the bug report when running the latest version
otaylor: etnoy: "regression between hardy and intrepid" is something for the Ubuntu X maintainers, err, maintainer to figure out
etnoy: otaylor: okay :)
otaylor: etnoy: I don't know why it would have worked on hardy offhand. It didn't work for me this spring, but that may have been with newer code than in hardy
otaylor: etnoy: it isn't rocket science to fix, I think ... probably an hour or two for someone who understands the GLX setup code paths
otaylor: (that is, not me :-)
etnoy: well, this seemed like quite a serious bug for intrepid, since all thinkpad t30:s are affected
etnoy: that's why I wanted to find out all I could about this
otaylor: etnoy: t30 is basically off the back end of what peopel care about, I'm afraid
otaylor: is getting nervous about the "people care about" status of his T42...
etnoy: too bad thinkpads never break ;)
MrCooper: FWIW, the amount of video RAM shouldn't be as critical anymore once we have a mature memory manager
MrCooper: compiz should work fine with everything in GART memory
otaylor: MrCooper: Yeah.
spstarr_work: otaylor: i think it hit your texture bug?
spstarr_work: otaylor: were you getting this with 2D or 3D
otaylor: spstarr_work: It's a 3D bug
spstarr_work: i was getting a gpu wedge with 2D + kms
otaylor: spstarr_work: that would be a different issue
otaylor: (I saw a 2d lockup yesterday as well)
spstarr_work: otaylor: was it like this:
spstarr_work: i also get
spstarr_work: hangs all over
spstarr_work: checks for any updates
otaylor: spstarr_work: the second doesn't look like a hang
spstarr_work: oh airlied was busy
spstarr_work: modesetting add some debugging in /proc and pad ring writes
otaylor: spstarr_work: as for the first, something for an expert, could be a normal "gpu hung, things screw up subsequently", but it might also be a more obvious locking problem in the drm or something
spstarr_work: i should have attached to X with gdb to get a userspace dump
spstarr_work: otaylor: tried new kernel?
spstarr_work: he has some more changes in drm
otaylor: spstarr_work: not today. I'm only for rebooting every couple of days since my laptop is my primary work machine
spstarr_work: I'll try out this new stuff today
spstarr_work: ah, he took some ideas from fglrx
spstarr_work: hence his question to agd5f today
spstarr_work: he added a /proc interface
rmh3093: airlied, ping
spstarr_work: rmh3093: he might not be up yet, his day starts 'soonish' :)
rmh3093: well you play with the kms compat xorg driver right?
rmh3093: s/play/work on
spstarr_work: im a KDE developer not driver :)
rmh3093: thats why you were stressing kwin ;)
rmh3093: i just noticed with wierd glitch
rmh3093: when typing an e-mail on gmail
rmh3093: some of the character turn all messed up for a second
rmh3093: but if i keep typing it gets fixed
rmh3093: only noticed it so far in ff
rmh3093: i might be able to get a screen shot of it
spstarr_work: thats known
spstarr_work: it was fixed i think
spstarr_work: text glyph corruption
rmh3093: fixed where, i though i was using latest everything i could
spstarr_work: hullo MAD
agd5f: rmh3093: airlied's git kernel tree has the latest drm bits, be brings them back to modesetting-gem periodically
spstarr_work: and each one is a gem in itself ;-)
rmh3093: agd5f, so u are saying the gliph issue is in the kernel driver not the X driver
agd5f: rmh3093: not sure, I haven't looked at it
rmh3093: cause my ebuild pull from his repos for libdrm and mesa, but for the kernel i pulled from modesetting-dem
rmh3093: so if its fixed there is only one place it could be ;)
otaylor: spstarr_work: Text glyph corruption is not (AFAIK) fixed
rmh3093: otaylor, thanks
spstarr_work: otaylor: :(
otaylor: (there are actually several separate text glyph corruption problem,s shouldn't lump them all together...)
rmh3093: as long as its known about thats all that I cared about
Boxfire: has anyone had success with experimental rendering on xpress 200M? Currently I only get a black screen (it once worked in the past, regression?)
Boxfire: I am using latest git sources, and am starting to get a headache... I have no idea how to trace what is going wrong
agd5f: Boxfire: there was a problem with enabling busmastering I fixed int the drm yesterday
Boxfire: agd5f: hmm thanks a lot. I will rebuild now and see if it works
Boxfire: I am curious, is it possible to toggle the driver option DynamicClocks while X is running (say toggle it on/off depending on if I am on AC power or battery power)?
agd5f: Boxfire: not at the moment, and that option will cause problems on XPRESS chips
tlp: ah, didn't even know there was experimental support for that. It's too bad the screen fell off on the laptop I have with that chipset.
tlp: tempted to plug it into a CRT to play with it.
Boxfire: alright, I will be back later... if drm still doesnt work I am going to kill myself
oga: well if that happens you don't have to fix his bugs ;)
spstarr_desk: airlied: any changes to test? i see direct changes for r3xx in drm code update
airlied: spstarr_desk: you can try runnning -61 it isn't in rawhide just koji
airlied: it might save the world or eat your cat. I'm not sure.
spstarr_desk: what's one less kitten ;)
spstarr_desk: ya, i saw your changes
spstarr_desk: a new /proc interface
spstarr_desk: any useful debug that i can get for you from that?
airlied: if it hangs and you can ssh both radeon_gem_* files might of interest
spstarr_desk: can do.. trying now...
airlied: tries a bridgman summons :)
spstarr_desk: airlied: good news
spstarr_desk: airlied: rebooting with kms works
spstarr_desk: your release of the agp worked ;)
spstarr_desk: i tried again and it locked on reboot
spstarr_desk: i dont know how that worked the first time
spstarr_desk: exa crash..
spstarr_desk: X crashed with it
spstarr_desk: getting debug
spstarr_desk: ooh kernel oopps
spstarr_desk: airlied: http://www.sh0n.net/spstarr/drm-oops.txt
spstarr_desk: not an oops but maybe it is
spstarr_desk: (it doesnt say oops)
spstarr_desk: some memory stuff
airlied: spstarr_desk: gpu died there by the look of it.
airlied: ib_get failed is very bad.
spstarr_desk: anything in proc you need>
airlied: can you look in those proc/dri/0/radeon*
spstarr_desk: Interrupt enable: 02000001
spstarr_desk: Interrupts received: 23947
spstarr_desk: Current sequence: 8635 8635
spstarr_desk: Counter sequence: 8657
spstarr_desk: CS: 6647
spstarr_desk: RADEON_CP_RB_WPTR 0003e666
spstarr_desk: RADEON_CP_RB_RPTR 0003e666
spstarr_desk: X restarted however
spstarr_desk: or not
spstarr_desk: its dead
spstarr_desk: switches back to non kms + xaa ;/
EruditeHermit: spstarr_desk: debugging r300 AGP?
spstarr_desk: uh huh
airlied: spstarr_desk: so thats just starting kdm and logging in? composite on?
spstarr_desk: no comp
spstarr_desk: thats after logged in
spstarr_desk: i had a konsole full screen and resized it
spstarr_desk: then wham
spstarr_desk: the only X ricer option on is AccelDFS for exa
airlied: spstarr_desk: btw does booting with radeon.agpmode=-1
airlied: make it any more stable or long lasting?
spstarr_desk: trying now.
spstarr_desk: crashed X
z3ro: damn, there is a lot more involved in sending something via DHL than I thought...
spstarr_desk: looks different
z3ro: still have to email the consulate too.
spstarr_desk: getting ...
spstarr_desk: airlied: http://www.sh0n.net/spstarr/drm-oops2.txt
airlied: spstarr_desk: when is that happening?
spstarr_desk: same test
spstarr_desk: i used a gnome-terminal maximized it
spstarr_desk: then max/full over and over
spstarr_desk: until it killed X
spstarr_desk: when you un-maximize it it still remains maximized but repeating that over a few times will blow up
spstarr_desk: Interrupt enable: 02000001
spstarr_desk: Interrupts received: 30569
spstarr_desk: Current sequence: 14801 14801
spstarr_desk: Counter sequence: 14801
spstarr_desk: CS: 12133
spstarr_desk: RADEON_CP_RB_WPTR 0002c6da
spstarr_desk: RADEON_CP_RB_RPTR 0002c6da
spstarr_desk: ro root=/dev/VolGroup00/LogVol00 slub_debug=- printk.time=1 quiet 5 rhgb radeon.agpmode=-1
airlied: spstarr_desk: no compiz?
spstarr_desk: no compiz no kwin composite
spstarr_desk: no composite
spstarr_desk: X restarted
spstarr_desk: airlied: EXA composite is still left on
airlied: yup thats fine.
spstarr_desk: i still see irq 9 being shut off with no kms on reboot same as before ;/
spstarr_desk: if its not radeon, then i will reopen kernel.org bug
airlied: spstarr_desk: I should add debugging in /proc for that.
spstarr_desk: that would be bonus
spstarr_desk: airlied: anything else you need me to test?
spstarr_desk: i'll go back to my old mode of use ;/
airlied: spstarr_desk: nothing more thanks.
spstarr_desk: ok, if you have new stuff i'll try later this evening
spstarr_desk: airlied: interesting when X crashed and restarted, I switched VT and did a reboot *with* kms it rebooted
spstarr_desk: it did spit out some irq dump but rebooted
terracon: how goes things spstarr
spstarr: terracon: there is a big flux right now, expect things to be wild
terracon: f10 development freeze :)
spstarr: the kernel doesn't freeze
spstarr: and airlied isn't doing 'development' but finishing implementing kms really.
airlied: I think I'll have to make AGP lose :(
airlied: I'm having no luck crashing things here...
terracon: yes true true
spstarr: i will remain in rawhide in anycase and f11-dev
airlied: I've got 3 machines in front of me and two in my remote rack.
spstarr: but selective f11 updates will become the norm
spstarr: airlied: r3xx?
airlied: spstarr: two rv370s, one mobile one desktop
airlied: both PCIE
terracon: beginning f11 rawhide, scary!
spstarr: yes, AGP really sucks bad
airlied: but I'm triyng to get my rv280 AGP to die also to no avail
airlied: how much VRAM you guys got on those cards btw?
spstarr: this thing has 64MB vram
spstarr: bios does not allow setting aperture
airlied: no just VRAM I care about.
spstarr: just 64
spstarr: airlied: what worries me is the alignment errors from mtrr
spstarr: mtrr: base(0xe1144000) is not aligned on a size(0x5a4000) boundary
spstarr: assuming the DDX or drm is using mtrr
airlied: they shouldn't cause any problem.
spstarr: I believe mtrr is no longer used for PCIE?
airlied: oh they are used, I think I just need to tweak their setup in the kms driver.
spstarr: is it possible if things aren't aligned we might be hitting boundaries elsewhere where the mtrr is being used
airlied: not likely to cause any problems.
spstarr: airlied: just trying to see if there's any weird corolations, terracon: did you see mtrr alignment error in your dmesg/kernel?
airlied: spstarr: we get them in all machines
airlied: hmm one silly agp bug squashed on module unload it might make reboot better
spstarr: different code path where agp not released?
airlied: wrong ordering on agp cleanup
terracon: spstarr: I have ksm off right now. Next time I turn it on I'll check dmesg for mtrr errors
spstarr: terracon: ignore
airlied: and one silly rs690 outputs bugs fixed.
spstarr: i hope this won't come down to 'specific' gpus or even worse, workarounds due to bugs in hw
airlied: its all specific gpus and workaround due to bugs in hw now.
spstarr: i would have thought all the r3xx were similar enough, even with less shaders etc to still be programmed the same excluding agp/pcie models
spstarr: doesn't AMD have those documented somewhere for us?
airlied: not really.. its been years since they fixed them in fglrx
terracon: an errata perhaps?
agd5f: spstarr: they are programmed the same (for the most part), but there are family and asic specific errata. welcome to silicon
spstarr: you can't make 'error free'
agd5f: you could keep respinning, but you are usually on to new asics at that point
spstarr: agd5f: but those erratas would be enormously helpful for airlied given the pain we're causing :)
spstarr: agd5f: different rev #s
spstarr: agd5f: or microcode patch fixes if possible
terracon: I've been suffering since mach32!
spstarr: and i think you have microcode the r3xx has microcode loaded i noticed
agd5f: spstarr: the problem is it's a bit hard to dig up 5 year old errata
spstarr: isn't it coded in fgrlx (or commented in that code)?)
agd5f: sure, some stuff, but 28 million lines of code that I don't have access to
spstarr: you do have people who might be able to help though from that group?
airlied: spstarr: they probably don't remember how it works, I barely remember 5 years ago
spstarr: agd5f: I would think ATI kept those errata docs incase they needed those chips for embedded etc
airlied: spstarr: they only make certain chips long term used
spstarr: (instead of spinning new revs just workaround the bugs)
airlied: surprisinly the 9600 was never one of them.
airlied: though I think the M10 was.
spstarr: the mobiles maybe, yeah
agd5f: if there is a very specific issue I can sometimes get info on it, but if we just have some generic lock up issue, it's hard to say what might cause it
spstarr: would using mmio kernel module on fgrlx get us any better if i get some dumped register info?
airlied: spstarr: probably not...
spstarr: like nouveau has done with the nvidia binary blob
spstarr: hmm ok
airlied: I suspect its just something minor we are doing different since the driver works without kms.
airlied: and kms doesn't really do things that differently in theory.
spstarr: is kms actually a 'special' mode in terms of the gpu/chipset?
airlied: spstarr: no.
agd5f: spstarr: no
airlied: it just sets things up in the kernel instead of in Xorfg
spstarr: so wouldn't then the DDX hold some keys to the setup ?
airlied: spstarr: is EXA without kms bad for you?
spstarr: airlied: it will lockup yes
spstarr: i get some busy wait problem
airlied: so I think we just have the same problem under kms just happens easier.
agd5f: spstarr: most of the kms code was stright copied to the kernel for kms
agd5f: from the ddx
spstarr: im in xaa right now just because ive only gotten it to crash when using composite
spstarr: this is my 'safe mode' :/