taiu: airlied: weems so, was it related to the 'leaking dma' problem some have encountered?
airlied: taiu: in theory it was a step to making it easier to track down
airlied: the problem is if we have a VBO we are using and we fill an IB, there can be vertices in the previous VBO we still want
airlied: splitting mapping out made it easier to track
cxo: Hey airlied , i have a problem with -rc6, get a "failed to parse resolution" error and X becomes very unstable
cxo: -rc5 seems fine
cxo: Are you aware of this problem?
airlied: doesn't ring any bells
airlied: what gpu?
cxo: hd4870
cxo: just before that error i see something about a gem object and failed something
airlied: agp or pci?
cxo: pci
cxo: -e
cxo: everything is out of git, linux, drm, mesa, xf86-video-ati, just that -rc6 has the problem, -rc5 doesnt
cxo: (linux-2.6.33-rc6)
airlied: shouldn't be too hard to track down
airlied: cxo: don't suppose you are building from git?
airlied: a bisect would save a lot of guessing
airlied: cxo: what is the parse resoltion error?
airlied: parse relocation I assiume
cxo: i am building from git
cxo: looks in logs
airlied: cxo: so -rc5 boot with same userspace, -rc6 messes up?
airlied: is it -rc6 plain or latest Linus?
cxo: yup, same userspace
cxo: latest
airlied: try reverting ff82f052d2a187dd0fa0e431ba70eb457c71a40e
airlied: or if not that try plain -rc6
cxo: it was an error about failed to parse resolution - whatever that means
spstarr: airlied: reverting drm-linus stops the glyph corruption
spstarr: i dont know which commit though exactly
cxo: how do you just revert 1 commit?
Ghworg: git revert $commit_id
cxo: thanks
cxo: i got to go now, but i'll try tomorrow
cxo: i also found this in the logs, http://pastebin.com/m5499dd5b
airlied: spstarr: reverting it to what?
spstarr: airlied: plain -rc6
airlied: spstarr: okay try ditching the same commit
airlied: that I jus tsuggested
spstarr: reverting 2 patches seemed to stop GPU locking up also
spstarr: pick db78e27 drm/ttm: Avoid conflicting reserve_memtype during ttm_tt_set_page_caching.
spstarr: pick dd5fde6 drm/ttm: remove padding from ttm_ref_object on 64bit builds
spstarr: but im not sure why
spstarr: building kernel now w/o ff82f...
airlied: spstarr: okay it could only be the first one of those
spstarr: so i should revert the top one and the one you mentioned
airlied: try just the one I mentioned
spstarr: ok
spstarr: building
spstarr: done
spstarr: airlied: yes that fixed the glyph corruption
jesse_wk: hi airlied, i extracted my initrd with cpio and found all firmware in lib/firmware/radeon/, so i think that shouldn't be a problem of the initrd?
jesse_wk: and the firmware loads well with 'nomodeset'
spstarr: i only noticed one odd corruption when kde started up one of the icons had corruption when it was loading the animation the others were ok
spstarr: it had like
spstarr: ___
spstarr: ___
spstarr: ___
spstarr: ___
spstarr: airlied: i can video record that if you want later
spstarr: i dont see any other corruption however right now
spstarr: ouch
spstarr: second life fails to run
spstarr: ERROR: createGLTexture: LLImageGL::createGLTexture failed to make texture
spstarr: gets the mesa error
spstarr: 2010-02-04T06:48:42Z INFO: LLViewerImageList::updateMaxResidentTexMem: Total Video Memory set to: 256 MB
spstarr: 2010-02-04T06:48:42Z INFO: LLViewerImageList::updateMaxResidentTexMem: Available Texture Memory set to: 192 MB
spstarr: error mapping 0x508a9d0 0x40000000 (error = -22)
spstarr: -22 ..
spstarr: EINVAL
spstarr: that was valid in UMS though
spstarr: we are right now limited to 256MB VRAM, maybe I should try 128
spstarr: no difference
spstarr: 2010-02-04T06:52:06Z INFO: LLViewerImageList::updateMaxResidentTexMem: Total Video Memory set to: 128 MB
spstarr: 2010-02-04T06:52:06Z INFO: LLViewerImageList::updateMaxResidentTexMem: Available Texture Memory set to: 96 MB
spstarr: error mapping 0x7fd05c35ba20 0x40000000 (error = -22)
jesse_wk: eh, of course in ums the firmware is loaded very late...
spstarr: im assuming that error mapping is coming from mesa
spstarr: yes
spstarr: i have a stack trace from gdb..
spstarr: gets debug symbols installed
spstarr: i might as well build new mesa trunk
spstarr: will be best to see what gdb is showing so we have an idea
spstarr: airlied: ok i have some corruption appearing now...
spstarr: inverted colours
spstarr: airlied: http://www.sh0n.net/spstarr/wrong-colour.jpg
spstarr: it just started to happen all of a sudden
spstarr: there should be no yellow like that just the grey
spstarr: and now it corrected itself?
airlied: spstarr: okay try reverting that TTM one then
spstarr: ok
spstarr: which one of those
spstarr: padding one?
airlied: no the other one
airlied: padding shouldn't affect anything
spstarr: pick db78e27 drm/ttm: Avoid conflicting reserve_memtype during ttm_tt_set_page_caching.
spstarr: this one
spstarr: reverting
spstarr: db78e27de7e29a6db6be7caf607cf803d84094aa
spstarr: building
spstarr: i'll get to the error mapping issue, next
spstarr: will provide pastebin of the stack dump assuming the two are related
spstarr: gets out his video camera, i will record if i see the startup corruption still
spstarr: airlied: GPU locks up
spstarr: i have the video of that initial corruption of icon (ignore the first second or so as the buffers are not cleared when kdm logs in)
spstarr: airlied: http://www.sh0n.net/spstarr/radeon/corrupt-icon.avi
spstarr: airlied: after that video the screen went blank and GPU was wedged
spstarr: in UMS dont see that corruption on the splash screen startup
airlied: ums isn't useful since its a different kernel stack
spstarr: yea
airlied: it would be nice to know what was stable and what wasn't in KMS
spstarr: but that video was with KMS
airlied: but videos don't tell me much
spstarr: im only in ums now because the gpu wedges a moment after it logs in
spstarr: what more info do you want me to give?
airlied: if it works stable at all on any vrsion
airlied: and when it broke if possible
spstarr: it used to work prior to any of the latest drm-linus commits
spstarr: removing this: pick db78e27 drm/ttm: Avoid conflicting reserve_memtype during ttm_tt_set_page_caching. <-- causes GPU wedge
airlied: git bisect the patches in drm that it introduces
airlied: if the guess I made don't help
spstarr: Revert "drm/radeon/kms: Bailout of blit if error happen & protect with mutex V3" <-- stops my text glyph corruption
spstarr: looks at the commit list
airlied: okay so we need to track down what is wrong with that
spstarr: the blit patch i can confirm is indeed causing: http://www.sh0n.net/spstarr/radeon/glyph-corruption.jpg
airlied: spstarr: thats on the W500?
spstarr: yes
airlied: glisse: any ideas?
spstarr: asks Red Hat to buy airlied a W500 :-)
airlied: the one I have is in the office
airlied: I'm not
spstarr: oh
airlied: but its glisse's commit
spstarr: i can stay up all night to help debug, it's 2:43am, and im not doing anything today, my interview was yesterday (phone) and they want to meet me in person when they schedule it
taiu: hm, drm-radeon-testing dowsn't ave that commit
taiu: drm-linus looked very corrupt on first boot, second was ok, third is again messed up
glisse: airlied: no, it's strange that this commit lead to glyph corruption
glisse: will look closer
glisse: it should fail on gpu lockup case only
airlied: glisse: should have left the WARN_ON's in there as well ;-)
glisse: yeah that's what i was just saying to myself
spstarr: glisse: hi
spstarr: gimme patches :)
spstarr: will test
airlied: add back the warnings see if he hits them
airlied: I'm not sure failing is the right answer if we can't get an IB
spstarr: they just commented out but still in code?
glisse: airlied: only case when it fails is gpu lockup really
glisse: so failing is the only option then
spstarr: glisse: the other patch locks up:
spstarr: removing this: pick db78e27 drm/ttm: Avoid conflicting reserve_memtype during ttm_tt_set_page_caching. <-- causes GPU wedge
airlied: glisse: the radeon_move_blit layer has a FIXME to han dle failing
glisse: yeah i know
glisse: idea is to fallback to memcpy
airlied: spstarr: so taking drm-linus and reverting just the patch causes problems?
spstarr: taking drm-linus and reverting drm/radeon/kms: Bailout of blit if error happen & protect with mutex V3 alone stops corruption of text glyphs.
taiu: spstarr: maybe you can retest, I got 2 corrupt and 1 correct 1 sessions on head - now testing with reverted
spstarr: taking drm-linus and reverting drm/ttm: Avoid conflicting reserve_memtype during ttm_tt_set_page_caching causes GPU wedge, this is ALSO with drm/radeon/kms: Bailout of blit if error happen & protect with mutex V3 removed as well.
spstarr: I do not suspect having both of them reverted is causing the gpu to lockup, but i could recommit the blit patch only.
airlied: lets ignore the TTM one for now
airlied: if the blit/muitex ones causes problems
airlied: though taiu could be right and it could be some wierd reproducing issue
spstarr: ok ignoring the TTM one (i'll put it back in)
spstarr: ok so i've reset my git tree to just revert ff82f052d2a187dd0fa0e431ba70eb457c71a40e (drm/radeon/kms: Bailout of blit if error happen & protect with mutex V3)
spstarr: waiting...
spstarr: so any patch you give me glisse, i can apply
glisse: spstarr: add a DRM_INFO("COPY FAIL\n"); after if (r) { in r600_copy_blit
glisse: and report if the message appear in log when glyph corruption happen
airlied: we still have that wierd 30 sec hang ppl reported don't we
glisse: which hang, the boot hang on macbook pro ?
airlied: yeah its pauses for like 30secs
airlied: and then keeps going, blamed the SS code
spstarr: glisse: so put back the other commit also?
glisse: spstarr: yeah
spstarr: ok resetting
glisse: i don't see how kms can lead to such pause
airlied: glisse: atom tables
airlied: I should probably push my atom table bailout code
glisse: we loop over and over in one atombios func ?
airlied: on my rv515 at least we can sometimes
airlied: stupid wait for vblank
airlied: and hw never reports it
airlied: I actually think the turn off crtc then turn off outputs ordering screws us a bit
spstarr: glisse: where is that code?
spstarr: the function has
spstarr: r = r600_blit_prepare_copy(rdev, num_pages * RADEON_GPU_PAGE_SIZE);
spstarr: if (r) {
libv: you still haven't noticed this bug in the atombios code?
libv: heh.
glisse: spstarr: yeah just after the if (r) { you pasted
libv: it was only fixed in rv620+
spstarr: glisse: done
airlied: libv: oh we have, its actually one gpu that we've seen it on
airlied: only the rv515 seems to ever show it up here
airlied: the exact same atomtable on my other r5xx hw is fine
libv: i would have to find a backup of my old suse homedir to get the dumps
airlied: when I saw it last I dumped all my roms to compare the atom tables
libv: but all the r5xx, r600, rv610/rv630 all had it
airlied: and it was the same table
airlied: but only the rv515 would hang
glisse: macbook pro is x1600 iirc so r520
spstarr: building
airlied: though the spread spectrum table might have another issue on the macbook
airlied: its probably a BIOS from a r200 or something knowing apple
airlied: my laptop is an rv530 and never hangs
airlied: don't think I have a real r520 though
spstarr: linux-image-2.6.33-rc6-custom-00154-ge9e70bc-dirty coming up...
airlied: glisse: btw if you have no RLC firmware, X in rawhide fails to start
glisse: oh weird
glisse: will look at that too
spstarr: glisse:
spstarr: [ 63.388953] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0x40000000
spstarr: [ 63.388956] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation !
spstarr: [ 63.399597] CPUFREQ: Per core ondemand sysfs interface is deprecated - up_threshold
spstarr: [ 65.280343] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0x40000000
spstarr: [ 65.280353] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation !
spstarr: I am not seeing your debug however
spstarr: text glyphs are corrupted
spstarr: drm.debug=1 ?
spstarr: if so, will reboot
glisse: airlied: weird it works here, do i need to upgrade to all lastest ?
glisse: spstarr: did you reported that you did have those messages before ?
Nille02: its a bug on kms that DVI-0 is DVI-1. Or is it intentional?
spstarr: lemme put logs up
spstarr: glisse: htp://www.sh0n.net/spstarr/radeon/dump-radeon-initial.txt <-- right now its in drm.debug=3 right now so this is as soon as I logged in
spstarr: glisse: http://www.sh0n.net/spstarr/radeon/dump-radeon-initial.txt <-- right now its in drm.debug=3 right now so this is as soon as I logged in
spstarr: glisse: http://www.sh0n.net/spstarr/radeon/dump-drm-error.txt <-- just before, im not sure how i triggered this, but i haven't seen it in this session
spstarr: glisse: I am *not* seeing that debug added to r600.c for DRM_INFO() msg
taiu: got about 5 correct boots with blit reverted,
spstarr: [ 387.588259] [drm:r600_kms_blit_copy], emitting copy 10226000 e1b85000 8192 0
spstarr: but no errors
glisse: spstarr: my question was, did you saw this gem lookup error message before when experiencing glyph corruption ?
spstarr: glisse: no with it
spstarr: lemme look at that log..
spstarr: yes that is with KMS on and with the offending patches still in
glisse: so any time there was glyph corruption, this message was in the log ?
spstarr: i will reboot with drm.debug off...
spstarr: then i can tell you
spstarr: brb
glisse: yeah debug=0 is fine enough to debug this issue
spstarr: yes
spstarr: [ 42.747940] [drm:drm_ioctl], pid=2270, cmd=0xc0206466, nr=0x66, dev 0xe200, auth=1
spstarr: [ 42.748046] [drm:drm_ioctl], pid=2270, cmd=0xc008646a, nr=0x6a, dev 0xe200, auth=1
spstarr: root@segfault:~# [ 44.809040] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0x40000000
spstarr: [ 44.809779] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation !
spstarr: [ 46.852977] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0x40000000
spstarr: [ 46.854956] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation !
spstarr: [ 49.746216] r600_irq_process start: rptr 5632, wptr 5648
spstarr: [ 57.889643] r600_irq_process start: rptr 7504, wptr 7520
spstarr: [ 57.960234] r600_irq_set: hpd 1
spstarr: [ 61.010062] r600_irq_process start: rptr 8544, wptr 8560
spstarr: glisse: I did see it, as soon as I logged into KDE after kdm then it spit this out while i was switched to console as KDE started up.
glisse: so glyph corruption trigger this message in the log
taiu: glisse: btw, i dont get any lookup failed errors
glisse: so it means this is an userspace bug
spstarr: glisse: i see corruption prior to seeing this
glisse: taiu: you have corruption too ?
spstarr: this just happened after i logged in
taiu: yes,
glisse: which gpu ?
taiu: rv740
glisse: which xserver version ? how much vram/gtt?
glisse: kde ?
spstarr: X server: 1.7.4
spstarr: [ 20.920135] ATOM BIOS: M86M
spstarr: [ 20.920291] [drm:atom_allocate_fb_scratch], atom firmware requested 1fffb000 20kb
spstarr: [ 20.920306] [drm] Clocks initialized !
spstarr: [ 20.922386] [drm] Detected VRAM RAM=256M, BAR=256M
spstarr: [ 20.922551] [drm] RAM width 128bits DDR
taiu: gnome, 256M
spstarr: [ 20.922775] [TTM] Zone kernel: Available graphics memory: 2027710 kiB.
spstarr: [ 20.922965] [drm] radeon: 256M of VRAM memory ready
glisse: spstarr: i know for you
spstarr: [ 20.923127] [drm] radeon: 512M of GTT memory ready.
spstarr: glisse: ^^
spstarr: ok
chithead: spstarr: use a pastebin next time
spstarr: chithead: im not able to
chithead: install wgetpaste or whatever
spstarr: im in BitchX in a screen and corruption in X
spstarr: developers here want as much info as I can give them
chithead: you can paste from command line with wgetpaste, no need to flood irc channels
spstarr: wgetpaste?
spstarr: looks for it
spstarr: what distro
spstarr: Fedora 12 dont got it
spstarr: lemme check my debian
chithead: maybe fedora has pastebinit
spstarr: looking
spstarr: no
spstarr: checking debian
taiu: glisse: maybe try moving r600_blit_init back to where it was, now it's too early, maybe smth overwriting parts of it?
spstarr: debian has pastebinit
spstarr: pastebinit is fine..
taiu: blit's working in principle, but it seems like it's not clearing 3d state or smth, if i resize my imageviewer window each time i see a different image consisting of misplaced blocks
spstarr: it does however make the developers have to load a webpage
glisse: taiu: no i think it would lead to gpu lockup
glisse: what puzzle me is that i am unable to reproduce this bug
glisse: no matter how hard i try
glisse: do you have any special font ?
spstarr: glisse: you have a RV635?
glisse: i do
spstarr: glisse: all text is getting corrupt, even the kdm default theme in debian in this case.
glisse: i have a lot of r6xx/r7xx gpu and none exhibit rendering corruption
spstarr: !
spstarr: im even using fedora's kernel config excluding some of the debug enabled
taiu: spstarr: does rmmod radeon;modprobe radeon help?
spstarr: you cannot rmmod radeon when in KMS..
glisse: you can, need to unbind fb first
spstarr: ew
glisse: taiu: does corruption happen quickly for you ?
taiu: echo 0 > /sys/class/vtconsole/vtcon1/bind ; rmmod radeon
spstarr: I can try that sec..
taiu: glisse: straight away when starting X fonts are bad
spstarr: taiu: same
glisse: taiu: f12 ?
taiu: glisse: yes
Nille02: i get the saame with
Nille02: gdm on kms
Nille02: some time
glisse: taiu: you are using kdm and not gdm ?
taiu: glisse: startx with gnome
taiu: glisse: currently no compiz even
taiu: spstarr: same what?
taiu: glisse: sofar only can reproduce with smth like 50% probability after boot, after rmmod radeon;modprobe radeon cannot reproduce
unimatrix: hi, does radeon support blur yet?
airlied: oh gem object lookups isn't a drm bugf
airlied: revert top of lib/idr.c
airlied: just hit it myself
spstarr: bad idea
spstarr: do not remove radeon.. i get that pretty screen going into a very bright white fade effect
airlied: the revert patch just went on the list
spstarr: taiu: if i try to remove radeon, the machine locks up, the screen goes from black console to whiter and whiter in a gradient getting brighter and brighter..
spstarr: (almost looks like a screensaver effect :-)
spstarr: looks at dri-devel ML
spstarr: i'd have to make a video to explain
airlied: idr patch is on lkml since its not a dri bug
airlied: spstarr: that just panel fade
spstarr: airlied: but a crash still
airlied: unloading kms drivers isn't really supported, though we could probably turn off all the hw before doing it
taiu: radeon_vram_mm map looks the same with or without the patch
spstarr: airlied: thats what I thought, so i never attempt to :)
spstarr: [PATCH 2.6.33-rc6] idr: revert misallocation bug fix
spstarr: reverting....
taiu: although in one case blit bo is created before gart bo
spstarr: 859ddf09743a8cc680af33f7259ccd0fd36bfe9d
taiu: it's the bo_pin which places objects?
airlied: taiu: yes
taiu: hmm, how does it copy if no blit yet, memcpy?
spstarr: building
spstarr: airlied: ive now left all kms patches in and just reverted 859ddf09743a8cc680af33f7259ccd0fd36bfe9d
spstarr: testing
taiu: glisse: afaik now filling shaders is before vga render disable
airlied: that could be bad
taiu: glisse: the commit message in http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=698443d9
taiu: dows not look too good
spstarr: airlied: interesting
spstarr: airlied: removing the idr commit fixes that icon corruption i recorded before
spstarr: airlied: it does not fix the text glyph corruption however
glisse: yeah maybe its somethings with vga
spstarr: so now we know where that comes from, yuck
spstarr: i wouldn't even want to know how you'd debug that
glisse: it's a theory
spstarr: glisse: anything you want me to debug now?
spstarr: any info in debugfs?
spstarr: looks at idr.c
glisse: yeah i will do a quick patch which move the blit init back after mc
spstarr: glisse: i will test it as soon as ready
airlied: damn ordering issues, such a pain
spstarr: what amazes me is how that idr change caused very, very specific corruption for me in the first place
glisse: taiu, spstarr :
glisse: http://people.freedesktop.org/~glisse/0001-drm-radeon-kms-move-blit-initialization-after-we-dis.patch
spstarr: danke
spstarr: doesn't apply
spstarr: does it manually
spstarr: buildin
spstarr: if this works, then i can get back to finding ou why DRI is failing to alloc texture memory
spstarr: w/ KMS
spstarr: although...it might be due to idr commit
spstarr: brb...testing
spstarr: text glyph corruption fixed
spstarr: glisse: yes ordering issue
Nille02: its now a bug that on KMS DVI-0 is DVI-1 and DVI-1 is DVI-0? Is it intentional?
spstarr: now let's try SL
spstarr: airlied: Second Life works also now...
spstarr: it was idr issue
Nille02: because then i can ignore ist at my but report
taiu: glisse: 5 correct boots sofar, i guess fixed thx, spstarr thanks for bisecting this also!
spstarr: :)
spstarr: im looking for other corruption now
airlied: Nille02: not really just different hw detection logic
airlied: glisse: can you also review suokko patch for flushing
spstarr: now let's see maybe latencytop will give me reason why im seeing stalls
Nille02: ok also i can ignore that
airlied: if you have time ;-)
taiu: although looked pretty improbable commit initially
Nille02: thank you
nunatak: hello. I think about a new system. There is a Dell offer with the new radeon hd 5450. At ATI.com this card is not in the list yet. Will there be ubuntu-linux drivers for this card?
soreau: The open radeon driver will have support for it eventually
airlied: zzz &
nunatak: eventually?
suokko: Nice. Suspend to ram works with KMS now :)
suokko: One bug: OGL renders 2 small strides at top of screen after resume to gnome-screensaver
Nille02: suokko: like this? http://img205.imageshack.us/img205/359/bildschirmfoto1o.png
dileX: hmm, something wrong between 2.6.33-rc6-git3 and 2.6.33-rc6-git2. my e17 does not come up. downgraded to -git2 and everythings OK.
dileX: anyone has same problem? here rv515
spstarr: ah
spstarr: idr broke intel also
Nille02: suokko: if yes i have the same if i restart gdm
suokko: Nille02: no. My problem is tat ogl is rendering to outside of the window to gnome-sreensaver context
dileX: spstarr: which idr?
spstarr: the idr patch
spstarr: ;)
spstarr: not the irc idr :)
dileX: spstarr: you have also troubles?
spstarr: not anymore
suokko: and only after suspend/resume
spstarr: revert the idr patch and get glisse's fix for text glyph corruption
spstarr: im now in KMS with 2.6.33-rc6 just fine
dileX: 2010-02-02 13:43 Tejun Heo idr: fix a critical misallocation bug
soreau: MrCooper: Can you test if compiz alpha blur works for you? Here it crashes and I'm trying to bisect it though I haven't found a reliable good commit yet. So far it seems it wasn't the mrt addition that broke it
soreau: (crashes compiz)
Nille02: where on the freedesktop bugzilla can i open an bug for radeon?
Nille02: unter new ther is nothing relatet to radeon
suokko: Nille02: mesa->DRI/rX00 where X is for your model (r300 or r600)
spstarr: boo
Nille02: thank you
spstarr: glisse: crash
dileX: spstarr: what has the idr-revert-patch to do with glisse's fix for text glyph corruption?
spstarr: glisse: the LCD screen just went black, i cannot ssh into the laptop
spstarr: it is.. dead
spstarr: can't even ping it
Nille02: mh but this is for 3D i have only an bug with kms and xserver
spstarr: dileX: the idr patch breaks Xorg in different ways
dileX: http://patchwork.kernel.org/patch/76931/
Nille02: nvm i find it
dileX: [2.6.33-rc6] idr: revert misallocation bug fix
suokko: Nille02: From your screenshot it looke like problem with 3D context when you have KMS enabled
spstarr: glisse: so now finding out why the screen went blank is another issue :/
spstarr: tries to ssh in again
suokko: spstarr: Always run netconsole+remote sysloger to save it ;)
Nille02: this is an other bug first i have problems if i use my display at DVI-0 ( kms say its DVI-1 )
spstarr: dead
spstarr: suokko: redirect syslog to another box? hmm sure
spstarr: but netconsole doesn't work if you cant ping the machine? :-)
suokko: spstarr: It works until machine freees so you get the last error message out from it (hopefully)
spstarr: lemme set that up...
spstarr: fedora kernel config has netconsole enabled i think
suokko: I don't think fedora is disabling any near zero cost debugging feature
MrCooper: soreau: seems to work here with 4x bilinear, which filter are you using?
soreau: MrCooper: Gaussian (sorry, should have specified)
Nille02: mh its not posible to add more as one file in an bug report?
jcristau: not directly when you file it. you can add more files later though
Nille02: thank you
okias: still same problem [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0x1f71, twice with damaged first icon in KDE splash... I suspect this commit, seems to only related: drm/radeon/kms: Fix oops after radeon_cs_parser_init() failure.
okias: bug is somewhere between rc5 and lastest git
glisse: okias: idr bug
glisse: patch is in the queue
glisse: spstarr: likely gpu lockup somethings different than the others thingy
okias: glisse: thanks, that save me lot of compiling/bisecting time :-D
glisse: suokko: strange that you need those flush
glisse: i would expect that mesa driver already put them in
glisse: thought it won't hurt if kernel add them
spstarr: ok i have rsyslogd forwarding everything to another box
spstarr: cannot use netconsole over wifi (wlan0)
spstarr: but if it crashes it should dump it over network now
dileX: looks good with idr-patch reverted. thx
spstarr: rsyslog is so nice
spstarr: :FROMHOST, isequal, "segfault" /var/log/segfault-messages.log
spstarr: :FROMHOST, isequal, "segfault" ~
spstarr: and now all messages go to that file and not mess up the local messages file
okias: MostAwesomeDude: Hi, by the way - any news about r300g on RS690?
spstarr: ugh
spstarr: these stalls really, REALLY suck when im trying to move my damin avatar ;)
Nille02: where can i view the current power state if i use dynclks
MrCooper: dynclks is just clock gating, no power states
Nille02: thank you
MrCooper: np
spstarr: [radeon_cs_ioctl] 251.4 msec 1.0 %
spstarr: that is kinda high?
suokko: glisse: mesa doesn't een know about those registers
soreau: MrCooper: Did you get a chance to test with gaussian?
soreau: I can't for the life of me find a good commit :P
suokko: glisse: It was in dri1 driver in kernel side adition in drm idle ioctl
MrCooper: soreau: no sorry, I'm happy the way it is :)
glisse: suokko: then it's definitly ok to add them in kernel will ack your patch
spstarr: [radeon_fence_wait] 6.2 msec 17.3 %
soreau: MrCooper: No, I mean does gaussian crash compiz on rv350 there?
suokko: Sorry for later reply but I ended up playing some warzone. That patch also fixes rendering bugs in warzone for r200 ;)
Nille02: its posibile that the output order for an si
Nille02: signal is DVi-0, TV-out, DVI-1 ?
MrCooper: soreau: as I said, the 'how much do I care divided by time' coefficient is too low for me right now
soreau: You didn't say that before
suokko: spstarr: that radeon_cs_ioctl should happen thousands of times per second when you render some complex 3D so anything over 10ms is very high
soreau: but I see you don't care so, nevermind
spstarr: suokko: yeah im in a very busy 3D scene
spstarr: but the stalls only seem to happen with DRI2 not DRI1
spstarr: its hard for me to capture thes
spstarr: latencytop says:
suokko: It would be nice to get some lock info which locks have too much contettion and why
spstarr: Userspace lock contention 4.9 msec 1.3 %
spstarr: Receiving TCP/IP data 4.9 msec 0.4 %
spstarr: [radeon_fence_wait] 4.4 msec 14.1 %
spstarr: [radeon_cs_ioctl] 3.0 msec 0.1 %
spstarr: im having alot of poll/select events
suokko: So maybe some kernel tracepoints to radeon?
spstarr: Page fault 9.5 msec 0.1 %
spstarr: [radeon_cs_ioctl] 8.4 msec 0.2 %
spstarr: [radeon_fence_wait] 6.2 msec 11.7 %
spstarr: im not sure..
spstarr: something smells
spstarr: why is my system doing alot of polls?
spstarr: Waiting for event (poll) 5.0 msec 38.9 %
suokko: glisse: Do you know any easy wy to collect kernel locking waits?
suokko: spstarr: xserver->mesa mesa->xserver
spstarr: overhea?
spstarr: overhead?
glisse: suokko: hhhhmm i think there is somethings in kernel hacking which expose it through some debugfs file
glisse: or sys or proc file
suokko: glisse: just looking that 250ms latency for radeon_cs_ioctl. It looks a lot like some mutex is held way too long for unknown reason
glisse: yeah 250ms is a lot
spstarr: that may have been one of those stallouts
spstarr: that i managed to capture at the right time
suokko: It would be nice if latencytop had better inteface for recording data
spstarr: yeah
spstarr: [radeon_cs_ioctl] 5.1 msec 0.2 %
mcgregor: to get sound over hdmi working, do I need any special configuration?
spstarr: i'd like to know the path being taken
spstarr: sysprof can tell me
spstarr: maybe?
suokko: maybe if it works
spstarr: i got it to compile
spstarr: lemme build it
spstarr: i have a patch if you like
suokko: For me it crashes the rc kernel
spstarr: !
spstarr: it hasn't crashed me yet
spstarr: [ 6492.057090] sysprof: loaded (1.1.5)
spstarr: captured
spstarr: suokko: i have lots of info
spstarr: r600_dri.so is 35.13% self total: 35.64%
spstarr: broken down it is quite interesting
spstarr: r600_cs_parse = 1.04% self, total, 2.61%
spstarr: suokko: you know how to read the data if i give you an XML output?
MrCooper: profiling probably doesn't help in this case as only some of the calls take a long time, which will drown in the other data
spstarr: what other mechanisms do we have? kprobes?
MrCooper: FWIW though sysprof 1.1.x (which uses the kernel performance events framework instead of its own kernel module) should give better results for the kernel
spstarr: there's another sysprof?
spstarr: not the gnome one?
suokko: spstarr: yes
soreau: MostAwesomeDude: I tried to figure this out but I had little success. I did find out that alpha blur has been crashing with gallium commits as far back as two weeks and for classic, alpha blur worked a commit before the MRT addition
suokko: and there is sysprof-cli
MrCooper: the above looks like you loaded the sysprof kernel module, which wouldn't be built / used by sysprof built to use the kernel performance events
soreau: MostAwesomeDude: Now with classic, it doesn'r crash compiz but it makes transparent terminals opaque and Alt+Scroll opacity does not work right either. It makes the window darker and darker until at about the last ten% it goes quickly to fully transparent
spstarr: MrCooper: looking...
spstarr: maybe my change turned that off
spstarr: ya they fixed the code
spstarr: MrCooper: how do I know if it's using kernel performance events?
spstarr: Could not open performance counter: Function not implemented
spstarr: hmm
spstarr: this is what i had until I fixed it
suokko: spstarr: maybe CONFIG_HAVE_PERF_EVENTS=y
spstarr: i should have that on
suokko: CONFIG_PERF_EVENTS=y? CONFIG_PERF_COUNTERS=y?
mcgregor: hmm I couldnt get a sound through hdmi here. should I get a error if it doesnt work?
spstarr: both are on
suokko: I got the latest git sysprof to run with performance events
spstarr: suokko: my patch was this:
spstarr: which git repo
spstarr: git://git.gnome.org/sysprof ?
suokko: yes
spstarr: I had to change:
spstarr: - return syscall (__NR_perf_counter_open, attr, pid, cpu, group_fd, flags);
spstarr: + return syscall (__NR_perf_event_open, attr, pid, cpu, group_fd, flags);
spstarr: and comment out #define __NR_perf_counter_open 336
spstarr: then it worked
spstarr: ?
suokko: For me it worked without changes
spstarr: anything else besides CONFIG_PERF_EVENTS/COUNTERS?
spstarr: pulls it from scratch
spstarr: now it builds..
spstarr: odd
spstarr: it builds but it doesn't work
suokko: Does it requrie some user space wapper library performance counters?
spstarr: wouldn't it not compile if if it did require something?
spstarr: checks google
suokko: C=lots of hacks to let anything compile even if it doesn't run
spstarr: i have performance counters on
MrCooper: it doesn't need a library
spstarr: -*- Kernel performance events and counters [*] Tracepoint profiling sources [*] Kernel performance counters (old config option)
spstarr: so im not sure
spstarr: i thought i have it all
spstarr: im gonna get som erest
spstarr: MrCooper: if you have any ideas for me to try lemme know, i'll do that after
spstarr: glisse: if you have any patches for me to try, i'll do that also after...
spstarr: is sleep &
agd5f: spstarr: does SL use OML_sync_control? that's been broken on ati cards since the dri2 swap stuff landed. http://bugs.freedesktop.org/show_bug.cgi?id=26240
maleadt: I'm seeing frequent corruption with Freeciv on a R600 (2.6.32.7, mesa 7.7, -ati 6.12.4, UMS): http://i.imgur.com/07oua.png http://i.imgur.com/6yrT3.png . Anything I can do about it, bugreport | update to GIT | try some other stuff?
okias: maleadt: try KMS and/or update to git
agd5f: maleadt: does freeciv use opengl? also is this an agp card?
maleadt: agd5f: not sure, having a look. It's a PCI card
suokko: That looks like freeciv gtk backend
[Enrico]: agd5f: since freeciv doesn't depends on mesa here (i'm looking at the gentoo ebuild) it should not USE opengl
agd5f: ok
okias: zhasha: Hi, do you still work on d3d9 tracker?
maleadt: I'll have a go at KMS and report back
zhasha: okias: I do
okias: zhasha: good to hear :-)
zhasha: working on it right now actually, cleaning up the latest mega commit
zhasha: okias: want to help? 'cause I could really use some. Psychological help too
okias: zhasha: I'm really fan of your project, but I have to say, that gallium work only on experimental nouveau, no luck with radeong(RS690) and i915g(X4500)... so I can't offer much :-D
Dr_Jakob: okias: i965g...
zhasha: my state tracker only has a softpipe winsys right now, courtesy of Dr_Jakob
okias: Dr_Jakob: sorry, typo :-)
zhasha: I'm not using hardware acceleration at all right now
twnqx: hm, i should try to finally migrate to 2.6.32 this weekend
twnqx: maybe it stopped hard crashing my laptop
okias: zhasha: if you need something what I can provide (probably only testing), I like help :-)
Black_Mage: zhasha, thanks for starting the direct3d st, im actually reading your code right now, trying to understand what you did and hopefully join in on the effort
zhasha: Black_Mage: I'm undoing a lot of the things I did
Black_Mage: zhasha, thats ok, i still breally understand anything anyway
Black_Mage: are you still working on this alone?
zhasha: it would seem so
okias: zhasha: few stupid question: do d3d9 (generally) include backwards compatibility?
zhasha: specifically I'm adding helper functions for internal state and changing internal calls to avoid the glue
zhasha: okias: with D3D8 etc? I have this tingling feeling it would be simple to layer older versions onto D3D9
zhasha: 10 is where it really changed
okias: zhasha: thanks for info :-)
mokoloko: I built radeon ddx driver like in that guide but when I try to restart x only blank screen shows up http://pastebin.com/m49d5c4ff
cxo: Anyone know why i get this error when trying to run Warsow on my hd4870? http://pastebin.com/m31ddbb47
mokoloko: I made xorg.conf file and added those lines from the guide but nothing happens :( fedora 12 here
mokoloko: *made xorg.conf file with the help of "system-config-display --reconfig"
mokoloko: well installed straight to system folders and now it works :P
maleadt: the freeciv corruption issue is gone!
maleadt: I upgraded everything to git, which helped squat, but enabling KMS seems to have done the trick
suokko: glisse: What about moving the locking comment outside of the function?
glisse: suokko: yeah would be fine too
Ivanovic: agd5f: uhm, was your last mesa commit really complete?
Ivanovic: this one changed line in r600_blit.c sounds strange
Ivanovic: (just adding a comment without anything else)
agd5f: Ivanovic: yes
Ivanovic: okay, just wanted to be sure
agd5f: Ivanovic: we can't remove those idle calls until the drm bits are upstream
Ivanovic: ah, okay, this explains everything
wswartz: Does anyone have HDMI audio working on a 4350?
wswartz: All I see in alsamixer is an S/PDIF device for the HDMI card. I'm using KMS right now.
agd5f: wswartz: it's not supported on r7xx at the moment with kms
wswartz: Okay, then what about xf86-video-radeonhd?
wswartz: I never got it to work with that, either. All I see is the single S/PDIF device, and I get no sound, even though MPlayer says it's playing fine. I've tried AC3 passthrough, as well, and enabling the "Audio" option in xorg.conf didn't do anything, either.
MrCooper: agd5f: the X/Mesa drivers will still need to emit cache flushes between rendering to a buffer and sampling from it?
suokko: MrCooper: No if kernel always adds it to end of command buffer
MrCooper: suokko: it can happen within a command buffer
suokko: GPU only?
MrCooper: yes
suokko: I would think that it can read from cache
MrCooper: that would be too easy :}
suokko: OF course there has to be some erratas ;)
MrCooper: actually newer cards might be coherent, but R300 and older certainly aren't
suokko: yes. Flush is must if trying to read 3D engine rendering with 2D engine or vice-versa
suokko: MrCooper: btw, dma->2D is coherent while 2d->dma is not in r200
agd5f: MrCooper: hmmm... yeah, probably
agd5f: MrCooper: probably have to check if the bo is referenced and add a flush
MrCooper: right, something like that
mcgregor: agd5f, do you by chance know i I have to configure anything to make sound over hdmi working? any options within xorg.conf? or should it just work? I am using .33 kernel+latest libdrm/ddx.
agd5f: mcgregor: what chip
mcgregor: rv730 (4650 mobility)
agd5f: mcgregor: r7xx doesn't support hdmi audio yet with kms
mcgregor: agd5f, ok, thank you
marvin24: regarding https://bugs.freedesktop.org/show_bug.cgi?id=26347
marvin24: is the default "mode" always the high performace mode?
marvin24: wonder if my mobo is some kind of "special"
suokko: marvin24: A silent product?
AndrewR: agd5f, is this possible your hw_i2c_on_r1xx-5xx patches not work yet on rv280? (1 VGA, 1 DVI, 1 S-video outputs). Applying whole diff between drm-radeon-next and drm-radeon-testing on top of 2.6.33-rc6 resulted in same invalid edid error as with plain d-r-t
marvin24: suokko: yeah - something like this
marvin24: but there is no fan on the southbridge
marvin24: maybe it will just melt if clocked higher
AndrewR: agd5f, sorry, too long line ... trying to apply only two i2c-related patches (not power stuff) over 2.6.33-rc6 ... it compiles ...
agd5f: AndrewR: they worked ok on my rv280 last time I tried, but I haven't had a chance to get back to it in a while
AndrewR: agd5f, for me it fails (?) on DVI-I-1 ... (none was connected to it)
agd5f: AndrewR: might need to adjust the prescale
AndrewR: agd5f, and funny side-effect - X uses 1280x99, not 1024x768 resolution .. so bug was visible right after X start, not only in logs ... Not really big bug compared to strange instability i gained somewhere between 2.6.33-rc6 and current -tip
wswartz: Is there some KMS/RV710/HDMI audio code I can test in GIT?
agd5f: wswartz: not at the moment
AndrewR: agd5f, *1280x900 (usable, but not very optimal resolution for my CRT, only 60 hz)
kdekorte: wswartz: you just want to be able to run one cable? or you have another reason
agd5f: AndrewR: must be some default xserver mode
agd5f: since there's no edid
AndrewR: agd5f, tnx, reboot for testing ...
wswartz: I'm going into a HDTV.
kdekorte: wswartz: you should be able to configure your TV to get audio from another source right? Just have it use the rca jacks if possible
AndrewR: agd5f, Bug 26430 - but not sure for now long i'll be online
kdekorte: What components are required for tear free video? KMS (kernel 2.6.33?) and XServer 1.8?
BioTube: AFAIK, just KMS and an IRQ-supporting kernel
kdekorte: BioTube: I have that and I think something else is required
suokko: kdekorte: textured video in ddx
kdekorte: suokko: nope I get tearing when dragging windows around (compiz is the window manager)
virtuald: /Wi KDEkorte
soreau: kdekorte: Did you check sync settings in ccsm>general options and ccsm>workarounds?
agd5f: kdekorte: if you are not using a compositer, then it will just work as long as you are using Xv
agd5f: kdekorte: if you are using a compositor, you need a compositer that supports some sort of vsync with g;
agd5f: *gl
agd5f: which is currently broken in mesa head: http://bugs.freedesktop.org/show_bug.cgi?id=26240
soreau: heh
agd5f: due to the intel dri2 swap buffer merge
kdekorte: agd5f: I had vsync enabled, but since I am using mesa git that is probably why it is broken
agd5f: kdekorte: you can reset to the commit prior to that merge
kdekorte: nah, I'll just wait for it to get fixed in mesa.. no biggy... just curious as to the requirements
Eythan: hello, does anyone know when the next release will be out ?
BioTube: ddx: sometime around 2.6.33
BioTube: libdrm: probably the same thing
BioTube: mesa has an actually schedule, IIUC
BioTube: s/actually/actual/
xming: has a whiny GPU fan :(
spstarr: wakes up
spstarr: agd5f: http://bugs.freedesktop.org/show_bug.cgi?id=26240 ? looking now
spstarr: agd5f: let me check code for you.
spstarr: agd5f: libraries/x86_64-linux/include/GL/glxext.h:#define GLX_OML_sync_control 1
spstarr: agd5f: looking more... if this header is being used directly.
spstarr: llrender/llglheaders.h:# include "GL/glxext.h"
spstarr: agd5f: I think it *does* use that GL extension
spstarr: agd5f: just had a crash and a corresponding corruption caught before it crashed
spstarr: agd5f: http://www.sh0n.net/spstarr/radeon/wrong-colour.jpg
spstarr: agd5f: after i made a screencapture of this, the screen went blank, box is dead
spstarr: you see on the panel left side the yellow colour over one of the items on panel
spstarr: tries to sync the machine's local logs
spstarr: nothing in syslog
suokko: Is PolygonStiple (aka glean -t paths) working with r300?
suokko: At least for r200 glPolygonStipple hander is never called
AndrewR: what about this branch: http://cgit.freedesktop.org/~osiris/mesa/log/?h=radeon_tiled_textures ? Will it be merged into master soon? (it has some changes in common radeon texturing code ... may have new bugs or bug-fixes )
evil_core: I want vsync :/
evil_core: can i upgrade some small xorg extension or something?
suokko: downgrade mesa?
hexa-: hi again
hexa-: adamk, are you around by any chance?
adamk: Yo.
hexa-: I switched my ubuntu installation to 32-bit, but wine still gives me software rendering stuff. pretty annoying :/
evil_core: suokko: cannot I patch it or something?
hexa-: compiz works out of the box
adamk: hexa-: I thought we had gotten you hardware acceleration in 64-bit Ubuntu already?
adamk: In wine apps.
hexa-: hmm
hexa-: not really
hexa-: there were 32 bit mesa libs missing
hexa-: so wine used software rendering as fallback
adamk: iirc, libdrm_radeon was missing and you used a version I had.
adamk: Or maybe I'm thinking of someone else.
hexa-: yes
hexa-: but it crashed wow
adamk: In any case...
suokko: evil_core: vsync should be working unless you are running the latest git version
hexa-: anyway, I thought i could get around the issue if i switched to 32 bit, but it didnt really help
adamk: How do you know you're not getting 3D acceleration in wine apps now?
hexa-: again WINEDEBUG=wgl wine WoW.exe
hexa-: gives me trace:wgl:X11DRV_WineGL_InitOpenglInfo GL renderer : Software Rasterizer.
adamk: Huh.
hexa-: trace:wgl:X11DRV_WineGL_InitOpenglInfo GL version : 2.1 Mesa 7.6.
adamk: OK, that's enough.
adamk: Run it with LIBGL_DEBUG=verbose too.
hexa-: no clue really who's fault this is
adamk: And then pastebin the full output.
kdekorte: hexa-: does setting "LIBGL_DEBUG=verbose " before WINEDEBUG give an additional information
adamk: Didn't I just suggest that? :-)
hexa-: kdekorte, working on it :P
kdekorte: adamk: ha, see how multitasking distracts people... like me
MichaelLong: I'm always wondering, why people testing such a fragile software like this driver with an even more error-prone software like wine...
adamk: This driver is fragile?
hexa-: oh crap, that is a long debug
MichaelLong: of course it is.
adamk: hexa-: http://pastebin.com/ please (or another similar service).
kdekorte: hexa-: it should have only added one line or two
hexa-: adamk, errh now, I'm stuck at copying :)
hexa-: libGL: XF86DRIGetClientDriverName: 5.3.0 r300 (screen 0)
hexa-: libGL: OpenDriver: trying /usr/lib/dri/tls/r300_dri.so
hexa-: libGL: OpenDriver: trying /usr/lib/dri/r300_dri.so
hexa-: those i suppose (hope 3 lines are ok)
hexa-: ah wait, there's more
kdekorte: should be a little more
evil_core: I can share 32+64 synchronized Mesa/libdrm and ati driver
hexa-: http://pastebin.com/m2ba51449
hexa-: with an error :)
evil_core: prebuilt
hexa-: #
hexa-: libGL error: drmMap of framebuffer failed (Cannot allocate memory)libGL error: reverting to software direct rendering
evil_core: or builting scripts
evil_core: building*
adamk: hexa-: Huh... I must admit that I've never seen that one before.
hexa-: :)
evil_core: or is in /opt/xorg,, so I am not messing with distro libs :D
hexa-: adamk, would this be an issue with the graphis driver or wine?
kdekorte: hexa-: mesa
kdekorte: maybe even kernel and libdrm
hexa-: hmm
kdekorte: I haven't seen that one either
hexa-: xD
hexa-: so who would I ask next? :)
adamk: hexa-: Do you get that after a fresh boot?
hexa-: dunno, brb :P
evil_core: !stbr th upgrade cmatrix
evil_core: !stbr th noupgrade tss
evil_core: ouch, sorry
hexa-: http://pastebin.com/m4eccccf3
hexa-: not really any change
hexa-: (full paste this time, maybe you'll find s.th. else?)
spstarr: agd5f: I should turn off that GL extension ?
spstarr: agd5f: built new mesa with your r600 change on flushes
spstarr: GLX_OML_sync_control
adamk: hexa-: I did some googling and have come across others with the same message from a few years ago, but they were all using fglrx.
adamk: hexa-: As a test, can you try running another application via wine with LIBGL_DEBUG=verbose ?
spstarr: agd5f: I am running Xorg 1.7.4 though?
spstarr: isn't that new enough for OML_sync_control ?
hexa-: adamk, hm i suppose I can
hexa-: any other? or any other using opengl
adamk: Well, even D3D games will use opengl via wine. So just as long as it's something that uses 3D acceleration.
agd5f: spstarr: that extension is broken on radeon right now due to the dri2 swap merge
hexa-: as usually no game comes to my mind :)
adamk: Heh.
adamk: hexa-: It's very likely that this is just some bug in the driver.
hexa-: which we will be able to track down?
hexa-: (will get steam btw)
adamk: Hmmm... Are you using KMS?
evil_core: spstarr: so can I get vsync with new Mesa?
hexa-: adamk, i wasn't the last time you checked
hexa-: (II) [KMS] drm report modesetting isn't supported.
adamk: You could try enabling it and seeing if it makes a difference, though I have my doubts.
adamk: That's certainly an easy check. When grub loads, edit the default selection and add radeon.modeset=1 to the kernel line.
spstarr: glisse: http://bugzilla.kernel.org/attachment.cgi?id=24909 <-- will try this also
hexa-: i knew how to do that in grub1 :) in grub2 i don't really see a possibility to select things
hexa-: i suppose i'll hack this into grub.cfg then
adamk: Sorry, I'm not really familiar with grub2.
hexa-: np
adamk: I even went back to grub1 on my lone Ubuntu installation.
hexa-: I'll be testing some steam game first
hexa-: :D
hexa-: (taking time...)
glisse: spstarr: which bug are you chasing ?
spstarr: glisse: the corruption i see randomly
spstarr: glisse: http://www.sh0n.net/spstarr/radeon/wrong-colour.jpg
hexa-: boy, this is taking time :/
spstarr: glisse: http://www.sh0n.net/spstarr/radeon/wrong-colour2.jpg
spstarr: glisse: notice the yellow on bottom? it comes up randomly sometimes.
glisse: where should i look ?
spstarr: glisse: bottom of those images, notice the yellow
glisse: ok seen the yellow
spstarr: in each you see the yellow in a different place, im not sure how i trigger this though, it just happens
spstarr: yeah
spstarr: glisse: im testing your fix http://bugzilla.kernel.org/attachment.cgi?id=24909 <- which may resolve it
spstarr: i dont know yet
spstarr: just built new libdrm, mesa master, ddx master
spstarr: brb ...
Ivanovic: spstarr: for me a good way to trigger it is/was a workspace with thunderbird in fullscreen and a rather long folder active
spstarr: Ivanovic: you've seen that sort of corruption also?
Ivanovic: so that with some transparancy kicking in the taskname as well as the workspace switcher got black
Ivanovic: yes, the patches in that report seem to have fixed it
spstarr: hmm
Ivanovic: since i tried them yesterday i had no more issues
spstarr: so THIS corruption is fixed by that url above you say
spstarr: testing now..
Ivanovic: that is: i just installed the "real" patch some hours ago, lets see if it will continue to work
Ivanovic: for me it is
Ivanovic: had no more of those "border around window" and "wrong colored rects in taskbar" anymore since i use the patch
stikonas: me also has this bug, it it is not occuring so often to become annoying
spstarr: ok graphics stack updated now to reboot laptop and detach screen :)
spstarr: now to see if i can trigger that, im in the new kernel now
Ivanovic: good luck
spstarr: :)
spstarr: runs on VBOs
spstarr: i know SL will crash if I do
spstarr: but maybe i can get a stack dump now for why
spstarr: whoa
spstarr: so far VBOs enabled has not crashed SL
spstarr: hehe
agd5f: suokko: r100 might need to add stp to the state list as well
spstarr: loading GLSL blew up
spstarr: #2 0x00007fffddc9349f in r600NewTextureObject (ctx=
spstarr: #3 0x00007fffddd1c9bd in _mesa_GenTextures (n=1, textures=0x7ffffffccfec) at main/texobj.c:810
spstarr: #4 0x0000000001edd61a in LLImageGL::generateTextures(int, unsigned int*) ()
spstarr: I guess VBO + GLSL == nono right now
spstarr: Fedora rawhide crashes my r1xx .. but i dont know why yet
spstarr: this hard disk is dying, and I did an emergency dd to another drive
spstarr: agd5f: lemme turn on latencytop im getting alot of delays now
spstarr: [radeon_fence_wait] 7.6 msec 20.0 %
spstarr: [radeon_cs_ioctl] 6.8 msec 1.1 %
spstarr: I just hit some corruption
spstarr: some part of my desktop tooltip panel just got displayed overtop konsole
spstarr: tries to reproduce and snapshot it
spstarr: [radeon_fence_wait] 19.7 msec 19.4 %
spstarr: ouch
spstarr: agd5f: if i turn off that GL extension what will happen?
spstarr: if im able to
agd5f: spstarr: that extension is for vsync
spstarr: so i can't turn it off if i recompile second life w/ it set to 0?
agd5f: spstarr: ?
suokko: agd5f: I will have to check that tomottow -> time to sleep
spstarr: agd5f: well if that is what might be implicated in the stalls, if the program doesn't see that extension available it will not use it right?
agd5f: spstarr: most likely
spstarr: lemme try that
suokko: spstarr: Try my patch from dri-devel that adds cache flush to fence emit
suokko: If you have the corruption with r100 or r200 card
hexa-: adamk, tested another opengl powered game via wine and it uses software renderer too
spstarr: agd5f: ugh rebooted.. it went blank the screen again
hexa-: adamk, same error msg from libgl debug
spstarr: agd5f: i was about to type something to you then the GPU wedged
spstarr: suokko: you use SL? or some other GL games?
suokko: hexa-: you probably should ask debugging tips from #wine if their d3d devs are around
spstarr: suokko: im in UMS now
spstarr: looks at your patch
suokko: spstarr: saurbraten and warzone
spstarr: suokko: so you also noticed stalls when playing them
spstarr: ?
hexa-: suokko, okay, thanks
spstarr: http://marc.info/?l=dri-devel&m=126529960602396&w=2
spstarr: agd5f's patch right?
suokko: No. I don't have them. Except when there is incorrect rendering causing some wild incorrect operations in GPU
spstarr: i see
spstarr: so i can apply this patch even with latest git mesa/ddx?
spstarr: since i saw a comment that he has a drm comment to move flushes to drm from ddx/messa
agd5f: spstarr: the patch doesn't affect r6xx+
spstarr: oh
hexa-: suokko, doesn't the libGL error point to an error in the driver?
suokko: I tough that you were using the machine with r100 for change
suokko: hexa-: ussualy yes
suokko: But what is the error?
hexa-: wow crashes after the intro video. http://pastebin.com/m4eccccf3
spstarr: agd5f: hmm, so no point in applying if it doesn't affect the RV635
agd5f: spstarr: no
suokko: hexa-: Do you have any errors in dmesg?
hexa-: unhandled page fault on read...but couldnt that be caused by the software rasterizer?
spstarr: ok
hexa-: no, not really
spstarr: tries VBO w/ UMS
suokko: It looks like mmap is somehow broken with wine
suokko: But I realy have to go to sleep- gn
mcencora: suokko: hi. are you the author of CS size prediction code?
hexa-: xD
spstarr: VBO crashed
spstarr: let's see if gdb will show me why
hexa-: will be back, cu guys. thanks for help so far
spstarr: 2010-02-04T22:40:27Z INFO: mapBuffer: GL_ARRAY_BUFFER_ARB size is 304520
spstarr: 2010-02-04T22:40:27Z llrender/llvertexbuffer.cpp(821) : error
spstarr: 2010-02-04T22:40:27Z ERROR: mapBuffer: glMapBuffer returned NULL (no vertex data)
spstarr: hmm
spstarr: i do not see any mesa calls
spstarr: or maybe I can only use VBO in KMS now (which seemed to work) and not UMS
spstarr: heh
spstarr: drm says nothing
Nille02: hexa is yout grub2 problem fixed?
Nille02: your*
Ivanovic: spstarr: so are the glitched in kwin gone or have you seen more of those after the patch?
spstarr: i see something else differently.. but im now im UMS
spstarr: Ivanovic: screen goes blank/GPU wedges cant ssh in
Ivanovic: bree
Ivanovic: okay, ums is problematic
spstarr: ums is ok for me
Ivanovic: are you using qt 4.6.x?
spstarr: ya
spstarr: trunk 4.6.x
Ivanovic: that is the problem
Ivanovic: if you run qt 4.6.x you will get some crashes/freezes
spstarr: there is a confirmed corruption on the panel though.. half of it goes inverted colour, but this isn't a video issue.
Ivanovic: that was at least the case for me
Ivanovic: no issues with 4.5.x and UMS though
Ivanovic: and no issues with 4.6.x and KMS
spstarr: odd
Ivanovic: jupp
Ivanovic: somehow the freeze with qt occurs once some load (not sure if just cpu or cpu+io or only io) happens on the system
Ivanovic: really not a nice thing at all...
spstarr: interestingly
spstarr: with UMS Second Life if 'slower' overall, in KMS it is much smoother until i get stalls
spstarr: so we already know KMS is BETTER than UMS in somethings
Ivanovic: it is better when you run windowed apps
Ivanovic: you can then still switch workplaces and move the window around without problems
Ivanovic: (as in "other windows can be in front of the opengl app thanks to DRI2")
spstarr: yes
Ivanovic: time to head off to bed, got to drive over to brussels in some ten hours... (fosdem here i come (again))
justinkb: i just googled for "[drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0x40000000" and found a chatlog for this chatroom, wanted to add i have this error too, can i help debug?
justinkb: i have glyph corruption on kde login during the splash screen, the second icon in it is always corrupted
justinkb: also, this may be unrelated (but i dont think so) i have been dropped to console twice without any other option than magic sysrq reboot
justinkb: glisse: pm me if you need syslogs or whatever
justinkb: i have read the chatlog a bit further and i'm trying the suggested patch now
spstarr: justinkb: revert idr patch
justinkb: hmm, ok, so not just apply the 'fix'? from http://people.freedesktop.org/~glisse/0001-drm-radeon-kms-move-blit-initialization-after-we-dis.patch
virtuald: dis.patch <3
spstarr: yhats another patch needed
justinkb: which commit do you mean exactly spstarr, first few chars?
spstarr: justinkb: which GPU do you have?
spstarr: pretty interesting that you have exact same corruption
justinkb: hd4870
spstarr: justinkb: reverting the idr patch in the chat log stops that corruption
spstarr: the 001-drm-radeon one fixes text glyph corruption
justinkb: ah i c
spstarr: the idr one also fixes Xorg crashes
justinkb: could either of those problems have caused kernel oopses and dropped me to console?
spstarr: when reverted
justinkb: oki cheers
justinkb: and which commit is it exactly?
spstarr: getting
justinkb: 859ddf09743a8cc680af33f7259ccd0fd36bfe9d?
spstarr: http://marc.info/?l=linux-kernel&m=126527394728303&w=2
spstarr: 859ddf09743a8cc680af33f7259ccd0fd36bfe9d
spstarr: yes
justinkb: ok cheers
spstarr: justinkb: you had this: http://www.sh0n.net/spstarr/radeon/corrupt-icon.avi ?
spstarr: ignore the initial corruption thats just buffers not cleared
justinkb: yes exactly that
spstarr: hehe
spstarr: neat
justinkb: indeed :P
spstarr: its rare when corruption is identical to someone else :)
spstarr: you can thank google for indexing the irc chat log :-)
spstarr: chithead: thats also why i paste stuff in here, google logs it, pastebins dont last forever
spstarr: people can find keywords and come here for debugging/helping out
justinkb: hehe for sure... X crashing every few mins is not something i can use :)
justinkb: kernel compiling now :)
BioTube: what would be to blame for the machine freezing during VT switch?
BioTube: it only happens rarely
wswartz: I don't know kernel programming, but is there something else I could to help bring KMS HDMI audio to the RV710? I've got git installed.
fIReun: switches to sid, git pull's, and rebuilds drm, ddx, mesa
fIReun: you're late
mike-burns: I'll start with the actual question I have: do I need KMS in order to get DisplayPort working? Radeon HD 3650 on a Thinkpad T500.
fIReun: doesnt know that answer
BioTube: looking at cgit, it looks like UMS should support it
WhiteRabbit56: airlied: any idea why the latest r600.dri is causing a segfault in fedora 12
spstarr: WhiteRabbit56: ldr patch in your kernel?
mike-burns: I was in #radeonhd last night, asking about DP, and someone there suggested that I use the latest xf86-video-ati from git. Tried it today, kernel 2.6.30, plugged in at bootup, and xrandr didn't find it. However it did work from non-X (the console).
mike-burns: Any guidance?
WhiteRabbit56: no idea... ive been running the distro supplied kernel
BioTube: i've never used anything but VGA
mike-burns: Nor have I.
mike-burns: At this rate, I never may.
fIReun: hmm, anyone know if the drm/radeon packages in debian sid are all kms enabled or not? 2.4.17
jcristau: yes
fIReun: yes you know? (:
Jonimus: well I know HDMI and DVI work well on my HD4670 mobile on my laptop
fIReun: so I dont need to build anything from git then.
jcristau: you need xserver-xorg-video-radeon from experimental though.
Jonimus: I wish I had a DP monitor for testing but alas I do not
jcristau: (and mesa)
fIReun: jcristau: can I just build git instead?
WhiteRabbit56: spstarr: how can i check?
jcristau: fIReun: sure.
fIReun: jcristau: that seems easier from console
jcristau: if you say so :)
fIReun: or I guess I could switch sources, install the two, then switch back to sid
mike-burns: Well at this point a poll is worthwhile: has anyone had DisplayPort work? If so, did it "just work"? Did you do anything? Any advice whatsoever?
spstarr: drm-linus has all fixes now in it
spstarr: is now setting his attention towards the GPU wedging with KMS now
spstarr: and no debug being spewed.. I may have to enable drm.debug=3 to catch this?
mike-burns: OK, so, no DisplayPort. OK.
fIReun: try again later?
mike-burns: Will do, for sure.
fisxoj: I've been trying to get KMS working on my mobility hd 3650 for the last two days, it seems like other people with the same chip on debian with the same packages are getting it to work, so I'm confused. When I set things up to load KMS at boot time, I get a screen of black and white stripes and can't do anything, and when I turn it on after xorg has started once, I get a black screen and can't do anything
fIReun: jcristau: there is no xserver-xorg-video-radeon in "experimental"
BioTube: flReun: are you going by packages.debian.org?
fIReun: or is experiemental not on ftp.debian.org?
fIReun: I will try that
BioTube: p.d.o is outdated
BioTube: apt-cache for me shows ddx in experimental
fIReun: suffers a momentary bout of confusion
jcristau: not built yet on amd64 apparently
fIReun: that clears it up
fIReun: builds the source
airlied: mike-burns: no
airlied: latest -ati from git should work
airlied: unless it regressed with evergreen
mike-burns: It didn't work. Not sure how to figure out why.
airlied: pastebin the lgofile
airlied: is it DP or DP->something convertor?
mike-burns: DP->DVI
airlied: okay thats not so much DP as DVI
airlied: though it should also work
mike-burns: Well I'm plugging it into the DP port on my laptop.
airlied: I don't have my DP->DVI convertor to test here
airlied: it worked a couple of weeks ago when I fixed it, but I haven't tested it in the Lenovo yet
mike-burns: http://pastebin.org/86496 - Xorg.log
mike-burns: I do not have the DP monitor with me right now; it's back at the office. I do have the laptop, though.
mike-burns: xrandr says DisplayPort-0 disconnected (normal left inverted right x axis y axis)
mike-burns: Even though the monitor is plugged in.
airlied: yeah its not detecting it in any way at all
mike-burns: Yeah.
Hackus: xrandr
airlied: wierd the DP sink command is return DP as the type
airlied: not DVI
agd5f: mike-burns: does the DP port with with the adapter in windows? I wonder if that port is wired up to support DVI on the DP port
agd5f: might be DP only
mike-burns: I have no access to a Windows machine.
mike-burns: The monitor is an Apple 30" with DVI and some Apple nonsense.
airlied: the convertor is active? got USB power cable?
airlied: agd5f: I tihnk it works in the BIOS
agd5f: mike-burns: does the bios light up the monitor with the adapter if you boot with it attached and the lid closed?
mike-burns: Yup and yup.
mike-burns: The monitor works from non-X.
agd5f: ok
mike-burns: So, kernel boot etc.
airlied: mike-burns: feel like editing atombios_output.c:RADEON_DP_GetSinkType
airlied: and making it always return CONNECTOR_OBJECT_ID_DUAL_LINK_DVI_I
airlied: to see if its a detectiojn problem
mike-burns: xf86-video-ati?
airlied: yes
mike-burns: Sadly I won't be able to try this until tomorrow EST, but I'll give it a whirl. I'll probably also be in here while trying it.
airlied: mike-burns: if oyu have a real DP monitor it'll break
airlied: but it should be worth a try for the DP->DVI convertor
airlied: unless Apple is doing something strange in their convetor
airlied: I only had a single link one to test
Jonimus: hmm I should find a DP to DVI adapter so I can test on my laptop
mike-burns: It's always possible that Apple is doing something odd. It's not possible to directly plug the monitor into an Apple laptop; my coworkers use an Apple-made converter for DVI->Apple DVI.
agd5f: the port is likely only wired with one link
agd5f: so duallink won't work
agd5f: the second like is wired to the DVI port
Jonimus: though I only have a HDMI to DVI Cable, so it would have to go DP>DVI>HDMI which I doubt would work
agd5f: *link
spstarr: hmm
spstarr: agd5f: any patches or things for me to test, airlied same?
agd5f: *link
fIReun: heads for a reboot
fIReun: neat, X booted
fIReun: wonders if everthing is working properly, but doesnt have time to check right now
fIReun: damn, glxinfo says software raster
fisxoj: so, apparently, KMS is loading properly and everything, in all my logs, but I get a screen with black and white stripes
BioTube: fisxoj: when X loads or also at terminal?
airlied: fisxoj: got CONFIG_FRAMEBUFFER_CONSOLE
airlied: ?
fisxoj: airlied, I don't think so, console goes black, it doesn't seem to be in sid's kernel
fisxoj: I can't modprobe it
airlied: any mention in dmesg of console switcinh
airlied: Console: switching to colour frame buffer device
fisxoj: [ 0.507794] Console: switching to colour frame buffer device 80x30
airlied: okay so probably not that
fisxoj: and my Xorg.0.log.old has a line that says "[DRI2] Setup complete" in it
fisxoj: the last message before the forced reboot in my old dmesg logs is "Feb 5 07:59:15 --- kernel: [ 2663.402749] Unpin not necessary for eb230f00 !"
fisxoj: do I need fbcon, because I don't seem to have it?
Jonimus: fisxoj: if its not built in I do believe you need it
airlied: need to check if its built-in
fisxoj: how do I check that?
airlied: get the config file from the kernel
airlied: might be in /boot
fisxoj: k
fisxoj: ok, it's built in
fisxoj: CONFIG_FRAMEBUFFER_CONSOLE=y
fisxoj: my console is supposed to look different that before KMS, right? because it doesn't
Jonimus: heh I can turn off the power light on my monitor thanks to dcccontrol making it even easier to make it seem off even when its on
Jonimus: fisxoj: yeah you should get a hires console with KMS
fisxoj: ok, I'm not gettin that...
Jonimus: is kms enabled by default, you may need to pass radeon.modeset=1 to the kernel
hagabaka: when I use video=1024x768 for 2.6.33 kernel, I don't get video between the grub screen and X (monitor says "no signal"), but this works in 2.6.32. anyone have an idea?
Jonimus: hagabaka: IIRC video= breaks KMS
hagabaka: hmm
Jonimus: and should be unneeded with it anyway
BioTube: Jonimus: you're thinking of vga=
airlied: no video= should work
fisxoj: I guess I'll try the radeon.modeset=1 flag
fisxoj: anything else to keep in mind trying that?
hagabaka: it works after X starts, but not before that
Jonimus: ahh my bad
Droste: hagabaka: pastebin the output of: dmesg | grep -E "(radeon|drm)"
hagabaka: http://pastebin.com/f2c7236f3
Droste: hm it's not setting the mode. what happens if you don't pass a video mode?
hagabaka: hmm I haven't tried actually...
hagabaka: let me see
spstarr: goes to intel GPU for a bit
spstarr: laptop is getting way too hot for comfort
hagabaka: Droste: I get the same thing
hagabaka: this time the output is http://pastebin.com/f5632a55e , but it looks about the same too
hagabaka: after X started, I can switch to a TTY and see the display
airlied: [drm:edid_is_valid] *ERROR* EDID checksum is invalid, remainder is 199
airlied: thats not so good
Droste: and it changes
airlied: got a log from a non-kms run? Xorg log
hagabaka: Xorg log from now or non-kms?
Droste: non kms
hagabaka: I don't know how to disable kms...
Droste: boot with nomodeset in kernel boot line
hagabaka: ok
Droste: airlied: shouldn't it use a fallback if edid is missing/wrong?
spstarr: does dynclks work?
spstarr: i have to enabled right now.. I can't use intel GPU with new kernel locks up
airlied: Droste: it should pick 1024x768 in that case
hagabaka: airlied: with nomodeset, I get no display at all. so I restarted and this is Xorg.1.log: http://pastebin.com/f44ae8370
DanaG: oh yeah, I thought of a way to do the serial-over-lan thing over wireless: a wireless ethernet bridge.
DanaG: I've found I can't use the wireless-management stuff; it locks up.
airlied: it at least seems to find the viewsonic monitor
spstarr: airlied: the biggest issue left im seeing is, the GPU randomly just wedging without dumping any log anywhere, I will have to turn on drm.debug=3 to see if I can catch it
DanaG: I've gotten similar stuff on my samsung netbook. gpu wedging.
DanaG: s/wedg/wedgie-/
DanaG: er.
spstarr: DanaG: when in use right?
airlied: spstarr: doing anything in particulaR?
hagabaka: btw I commented out "options radeon modeset=1" in a file in /etc/modprobe.d before starting these two times, and now the output doesn't mention an error in EDID: http://pastebin.com/f7198381f
spstarr: airlied: I have second life running, but it has crashed w/o it running too
spstarr: airlied: dynamic clocks seem to work!
spstarr: laptop feels cooler
spstarr: 63C vs 73C
spstarr: although sluggish using GL
spstarr: let's see what latencytop says
airlied: hagabaka: yes without modeset the kernel doesn't do any driver work
DanaG: spstarr: yup, I use compiz, so it's never "not" in use.
spstarr: [radeon_fence_wait] 10.3 msec 6.0 %
spstarr: no compiz here
DanaG: hmm, is dynclks still glitchy?
DanaG: And what are your power states like?
DanaG: Last time I tried the PM patches, it didn't downclock very far at all.
spstarr: cant tell
spstarr: feels cooler
airlied: they do now they follow the bios tables
airlied: but only engine clock
airlied: still not the memory or pcie stuf
DanaG: how recent was that change?
DanaG: Last time I tried, I got this:
DanaG: http://pastebin.com/f7160f518
hagabaka: airlied: is KMS off now then? but it still says "radeon kernel modesetting enabled", and in the console the text is in 1024x768, which only happened since I enabled KMS
DanaG: Engine clock has low, medium, and high... and it downclocked only to medium.
airlied: DanaG: ah yes it still doesn't pick great
spstarr: EXT4 is showing a lot of latency
spstarr: :/
airlied: hagabaka: maybe its on by deafult
DanaG: My states are also a bit funky.
spstarr: dynpm locks up GPU for me
DanaG: Two battery states.
spstarr: hmm
spstarr: mine is not showing dynamic clock info in dmesg
spstarr: huh
spstarr: [ 754.923227] DRHD: handling fault status reg 2
spstarr: [ 754.923231] DMAR:[DMA Read] Request device [01:00.0] fault addr 0
spstarr: [ 754.923232] DMAR:[fault reason 07] Next page table ptr is invalid
spstarr: what is that
airlied: spstarr: thats badness
airlied: the iommu caught something badf
spstarr: radeon related?
fisxoj: hello again! I can't get my computer to have the framebuffer it's supposed to. And mesa is falling back on software. It doesn't seem to like my libdrm, but, I've been led to believe I have a good version.
spstarr: device 01:00.0 is
spstarr: 01:00.0 VGA compatible controller: ATI Technologies Inc Mobility Radeon HD 3650
spstarr: airlied: that is with
spstarr: root=UUID=d7dd8c66-cb1b-44fb-92c9-a39b586ea3d0 ro nmi_watchdog=0 radeon.modeset=1 printk.time=1 slub_debug=- cgroup_disable=memory i915.modeset=1 radeon.dynclks=1 single
spstarr: /sbin/modprobe radeon modeset=1 audio=0 dynclks=1
airlied: spstarr: doing anything when it happens?
soreau: fisxoj: Can you pastebin your X log?
airlied: or is it in the logs?
spstarr: airlied: its in log
spstarr: other than SL running and me switching console.. nothing else.
spstarr: this is with the kernel we've been using since yesterday, I should build a new one against drm-linus - idr patch
fisxoj: soreau, http://pastebin.com/d78c225
Jonimus: how hard would it be to overload the i2c port, I was running a script to check of reg changes on my monitor and I all the sudden got lost of errors...
spstarr: there is something enabled because the laptop is 10C cooler now
Jonimus: s/of/for
spstarr: airlied: i did have latencytop running....
soreau: fisxoj: What about dmesg? Does it have any interesting messages? perhaps maybe about firmware issues?
soreau: The first bad message seems to be (II) RADEON(0): GPU accel disabled or not working, using shadowfb for KMS
soreau: but not sure what that means exactly
fisxoj: hmm
fisxoj: r600_cp: Failed to load firmware "radeon/R600_rlc.bin"
soreau: heh
soreau: I was right :)
fisxoj: that could be something :)
soreau: fisxoj: Look at the wiki in the topic here, I believe it has a section about firmware
soreau: fisxoj: Without it, you wont get 3D
fisxoj: huh, I'd already handled the other firmware, so, I thought I had it all
spstarr: airlied: cant trigger now
spstarr: very odd...
fisxoj: soreau, alright, hopefully, the final reboot
fisxoj: thanks
spstarr: airlied: those sorts of errors usually indicate what?
airlied: spstarr: its the GPU sending a DMA request outside the area it should
spstarr: not good
spstarr: should I log that an an issue?
spstarr: not much to go on though :/
spstarr: other than me enabling dynclks=1 with linus-drm code
fisxoj: soreau, so... it got to the gdm screen that time before it froze, with the right half of gdm on the left of the screen, and the left of gdm on the right
fisxoj: also, this followed by three other lines from dmesg "Feb 5 13:59:04 clam kernel: [ 25.800187] radeon 0000:01:00.0: GPU softreset "
fisxoj: and I still don't get the nice terminal
fisxoj: do I need to modprobe fbcon before radeon?
soreau: Well yes...
fisxoj: hmm
fisxoj: so, sticking it before radeon in /etc/modules? just to be exceedingly clear?
WhiteRabbit56: airlied: you helped me the other day... why is glxinfo and glxgears segfaulting on fedora 12 when i rebuild r600 dri after running git pull on mesa
airlied: WhiteRabbit56: make distclean ?
WhiteRabbit56: alright ill try that
fisxoj: well, no DRI2 for me, apparently... now no firmware error and things still don't work..
WhiteRabbit56: hey that worked thanks airlied!
WhiteRabbit56: what does this mean though? do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
WhiteRabbit56: Try adjusting the vblank_mode configuration parameter.
airlied: WhiteRabbit56: it means the kernel doesn't have irq support
WhiteRabbit56: alright
spstarr: mm
spstarr: airlied: GPU wedge with UMS + ForceLowPowerMode on RV635
spstarr: DynamicPM is not locking up though with UMS
agd5f: spstarr: probably the pcie lane stuff
spstarr: agd5f: did you see the DMA thing i posted above?
agd5f: spstarr: yes
spstarr: im not sure if i'll be able to reproduce that
agd5f: spstarr: you can disable the pcie lane stuff by returning at the top of RADEONSetPCIELanes()
spstarr: not supported yet
agd5f: spstarr: in UMS
airlied: okay I've pushed out a new drm-radeon-testing, I think its everything except suokko's buffer patches
spstarr: i should build that