Home Phoronix Phoronix Forums X.Org Videos From FOSDEM 2008

Radeon IRC Logs For 2009-12-01

Search This Log:

spstarr: watches gcc compile text flash across his console
MostAwesomeDude: eosie: Pong.
eosie: MostAwesomeDude: you can push my patches, if it breaks anything (which I seriously doubt), dave prefers fixing it after it gets merged
eosie: ... if anything shows up
MostAwesomeDude: eosie: Alrighty, sounds like a plan. Right now I'm just trying to get my card to behave.
Nightwulf|work: hi all
MostAwesomeDude: Whoo, kernel build.
spstarr: airlied: do i need to use drm-next or drm-next-testing + that patch for interrupts?
spstarr: er drm-radeon-testing
spstarr: built with all of the branches merged in
ossman: airlied, sorry about that. must have copied it out of "less"
ossman: airlied, any plans on doing a koji build with the r600 irq stuff?
spstarr: is about to test it
spstarr: firmware bits in place, check
spstarr: ramdisk rebuilt, to add in new .bin firmware bits, check
spstarr: Adding binary /lib/firmware/radeon/R600_rlc.bin
spstarr: Adding firmware radeon/R600_rlc.bin
spstarr: failed
spstarr: [ 0.655203] firmware radeon_cp.0: firmware_loading_store: unexpected value (0)
spstarr: [ 0.655297] platform radeon_cp.0: firmware: requesting radeon/R600_rlc.bin
spstarr: [ 0.656920] firmware radeon_cp.0: firmware_loading_store: unexpected value (0)
spstarr: [ 0.657001] r600_rlc: Bogus length 21504 in firmware "radeon/R600_rlc.bin"
spstarr: [ 0.657185] [drm:radeon_driver_load_kms] *ERROR* Fatal error while trying to initialize radeon.
spstarr: -rw-r--r-- 1 root root 3072 2009-12-01 00:27 R600_rlc.bin
spstarr: -rw-r--r-- 1 root root 4096 2009-12-01 00:27 R700_rlc.bin
spstarr: unless downloading them from attachment from http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg45004.html is bad somehow...
spstarr: it dont like
spstarr: if (rdev->rlc_fw->size != rlc_req_size)
spstarr: looks at RLC_UCODE_SIZE
spstarr: 768 * 4
spstarr: 3072 == -rw-r--r-- 1 root root 3072 2009-12-01 00:27 R600_rlc.bin
spstarr: !
spstarr: 21504 hmmmm
MostAwesomeDude: Mwahahaha! I are multicard!
spstarr: !
spstarr: interesting
spstarr: 21504 = 3072 * 7
spstarr: rlc_req_size = RLC_UCODE_SIZE * 4; <-- maybe you meant
spstarr: rlc_req_size = RLC_UCODE_SIZE * 7; ?
taiu: also 21504 = *_me.bin length
ossman: MostAwesomeDude, do you want us to call someone?
ossman: perhaps some fine gentlemen in white coats?
spstarr: ossman: need a patty wagon also ;)
spstarr: paddy
spstarr: hmm
spstarr: maybe NOT such a good word to use
spstarr: The most prevalent theory is based on the term "Paddy" (a common Irish shortening of Patrick), which was used (sometimes as derogatory slang) to refer to Irish people.
spstarr: but blame the Americans they invented 'paddywagon'
MostAwesomeDude: ossman: I'll be fine. This is win; I no longer have to switch between cards.
spstarr: MostAwesomeDude: bonus points if you can implement switchable GPUs ;)
MostAwesomeDude: Well, Gallium works on the r400 screen.
MostAwesomeDude: Unfortunately, I can't Alt-Tab between screens, but whatever.
spstarr: ugh
spstarr: second life too slow with ForceLowPower mode
spstarr: turns it off
spstarr: back to intel gpu ;/
airlied: ossman: will do it in the next couple of days for rawhide
airlied: not for f12 at this point
airlied: but I need to rebase a bunch of rawhide kernel
ossman: airlied, ok, great. rawhide kernels should still be usable on f12 though, right?
airlied: ossman: for a while at least
airlied: until someone screws us
airlied: I also have to find somewhere to stash the firmware
ossman: woodhouse's firmware project?
airlied: yeah Fedora doesn't ship it yet
ossman: ah
airlied: so I need to put it somewhere like a subpackage of -ati
ossman: airlied, too messy to include it in the kernel package?
ossman: that's seems like the reasonable place otherwise
MostAwesomeDude: airlied: system-config-display couldn't see my multicard, but Xorg -configure did. FYI.
MostAwesomeDude: Also, so far, no lockups. I think there might be a HW bug with this motherboard and disabling the onboard graphics.
ossman: MostAwesomeDude, are you running a single X server with multiple cards, or multiple X servers?
MostAwesomeDude: ossman: The former.
MostAwesomeDude: Multihead is so passe. :3
MostAwesomeDude: Multicard's where it's at, ooh yeah.
ossman: I guess this would be some form of multiseat then :)
ossman: seems to be all the rave in some countries though
MostAwesomeDude: It's two monitors, two cards, one Corbin.
ossman: I'm sure you and the voices can use one monitor each
MostAwesomeDude: Yeah, the main point of contention is the keyboard.
airlied: ossman: wrong license
ossman: airlied, aren't the existing firmware files covered by a myriad of licenses?
airlied: ossman: but adding a new one to the fedora kernel requires a license revie
airlied: since its not upsteram
ossman: mhm
ossman: but now it's time for work
ossman: &
spstarr: airlied: you saw my msgs above?
spstarr: airlied: doesnt load new firmware bits at all.
airlied: spstarr: works for me
spstarr: !
spstarr: airlied: er, what size is your firmware
spstarr: double checks the ramdisk
spstarr: ah
spstarr: the ramdisk doesn't even have it .. brb
spstarr: but the output showed it did
spstarr: hmm
spstarr: ahh
spstarr: its not in right dir
spstarr: ok now its there maybe it wasn't finding it in right dir
spstarr: airlied: what size is your firmware
spstarr: r6xx or r7xx
spstarr: -rw-r--r-- 1 root root 3072 2009-12-01 03:59 R600_rlc.bin
spstarr: -rw-r--r-- 1 root root 4096 2009-12-01 03:59 R700_rlc.bin
spstarr: ?
spstarr: trying agian
spstarr: [ 0.665178] firmware radeon_cp.0: firmware_loading_store: unexpected value (0)
spstarr: [ 0.665276] r600_rlc: Bogus length 21504 in firmware "radeon/R600_rlc.bin"
spstarr: airlied: failed
glisse: spstarr: ppc ?
spstarr: glisse: x86_64
spstarr: glisse: congratuations @ your redhat job :) (i noticed)
airlied: I tested on 64-bit today seemed fine
spstarr: airlied: took drm-next, drm-radeon-testing, drm-linus + that patch
spstarr: unless im only supposed to use one of those branches for this patch alone
airlied: no it should work anywhere it applies
spstarr: i get some hunk offsets
spstarr: but applies otherwise
airlied: have you built radeon in?
spstarr: yes
spstarr: it loads the other firmware bits fine, it used to before
spstarr: no radeon is module
airlied: granted I think I tested using the R700 rlc
airlied: I can't ssh in at the moment to see
spstarr: the only oddness with 21504 is it is 3072 * 7
spstarr: not * 4
airlied: can you pastebin the whole dmesg?
spstarr: yes
spstarr: airlied: http://www.sh0n.net/spstarr/dmesg.log
spstarr: im doing this from debian at the moment
spstarr: hmmmmm
spstarr: [ 0.490760] hotplug[291]: segfault at 7fffe32fe038 ip 00007f8486f94c26 sp 00007fffe32ac5f0 error 4 in ld-linux-x86-64.so.2[7f8486f92000+1d000]
spstarr: why doesn't this look good
spstarr: brb....
spstarr: something tells me something broke
airlied: blames debian and moves along
spstarr: indeed
spstarr: lemme sync for new libc stuff
spstarr: didn't even notice that one
spstarr: new libc6 updates
spstarr: gets
spstarr: gets a new udev also
spstarr: curses debian
spstarr: it loads manually
spstarr: the new dp stuff also seems to be detecting
spstarr: DVI-1, LVDS, DisplayPort and VGA connectors I have (if you have docking port then LVDS is available
spstarr: [ 464.166193] [drm] LCD1: INTERNAL_KLDSCP_LVTMA
spstarr: I did get a kernel warning
spstarr: airlied: http://www.sh0n.net/spstarr/radeon.log
spstarr: it loaded the interrupt bits right
spstarr: glxgears reports no more interrupt missing
spstarr: KMS + SecondLife == fast with interrupts
spstarr: if i can fix the stupid ramdisk
spstarr: good work on the interrupt handler addition
spstarr: barring that, i can just let X load radeon in KMS on X start
Terman: airlied: thanks for fixing the thinkpad x1400 kms resume problem! Will it be part or 2.6.32?
airlied: Terman: yes I think it already is
Terman: airlied: OK, it wasn't part of 2.6.32-rc8-git1 but it is part of -git2 (which came out earlier today ;-)
Terman: airlied: thanks again!!
Terman: bug on fdo closed
spstarr: airlied: it works, but there is a lot of stalls
spstarr: for a first pass, not bad
airlied: spstarr: I think if you reloaded radeon bad things can happen
spstarr: airlied: well i know if you let X load radeon, you get corrupt screen altogether (colour patterns) if you load it eariler in boot (init.d script) it works
spstarr: but with second life, i get alot of stalls during rendering primitives
spstarr: back in intel gpu now, but gonna sleep
spstarr: airlied: with KMS before,it was impossible to even load second life and move an avatar, now it moves, but there's stalls
spstarr: so, i'd say improvements :)
JohnDoe_71Rus: xserver-xorg-video-radeo 1:6.12.99+git20091127.a8 X.Org X server -- ATI Radeon display driver
JohnDoe_71Rus: 2.6.31-02063106-generic #02063106 SMP Tue Nov 10 10:06:12 UTC 2009 x86_64 GNU/Linux
JohnDoe_71Rus: 01:05.0 VGA compatible controller: ATI Technologies Inc RS482 [Radeon Xpress 200M]
JohnDoe_71Rus: what kind kernel command line to enable kms ?
soreau: radeon.modeset=1
JohnDoe_71Rus: not work. software
soreau: pastebin your x log
JohnDoe_71Rus: with radeon.modeset=1 or usual ?
JohnDoe_71Rus: http://pastebin.com/m57b753ee some day ago
Zombie: Hello?
Luzipher: "Zaphod", does that refer to multiseat (multiple X) or multihead (one X) or did I get something completely mixed up ?
adamk: Luzipher: Zaphod is multihead with separate screens.
Luzipher: adamk: thanks
Zombie: 02:00.0 VGA compatible controller: ATI Technologies Inc RV610 video device [Radeon HD 2400 PRO]
Zombie: Given this card.
Zombie: Which driver is better for this card?
adamk: Well the proprietary driver will definitely give you better 3D performance.
adamk: But if you compile a new enough kernel, libdrm, mesa, and DDX, 3D is available via the 'radeon' open source driver.
Ghworg: FWIW the irq firmware loads fine for me on debian, x86_64 kernel
Ghworg: r600
lordheavy: nice :-) with a RS880, i've got more fps with glxgears under galium than classic mesa (350 instead of 290)
lordheavy: error, it was softawre rasterizer :-p
hifi: are there any acceleration for R8xx family yet?
lordheavy: no
dottedmag: I've got a X server eating up 100% of CPU on radeon/kms (r600). Is that a known problem or something not yet observed in wild?
mroconnor: airlied: thanks for pointing out those fixes for DP, they worked well
dottedmag: Identical system with Intel (actually the same laptop with switched integrated/discrete card) does not exhibit this behaviour.
josmala: dottegmag: There are two opensource drivers and a closed source driver. And one of the opensource drivers gives that behaviour.
dottedmag: josmala: I meant radeon specifically, not radeonhd or fglrx
josmala: Ok. I'm just user like you but what I did I tried all of them and chose to use one that worked.
hifi: got a HD 4630 now
hifi: KMS works fine, but when I start X the screen is all garbled
hifi: *4650
BioTube: hifi: is fbcon loaded?
hifi: yes
kdekorte: hifi, is libdrm compiled with --enable-radeon-experimental-api and then xf86-driver-ati compiled against that drm?
hifi: OpenGL renderer string: Mesa DRI R600 (RV730 9498) 20090101 x86/MMX/SSE2 TCL DRI2
hifi: I had KMS working fine with my old RV570
soreau: eosie: Your patches no longer apply to latest mesa, did they get pushed?
hifi: KMS itself works, but xorg is corrupted
soreau: hifi: Which kernel?
hifi: ubuntu 2.6.32rcsomething
hifi: 2.6.32-5.6 which is.. *drum roll*
kdekorte: hifi if X is corrupted it is probably the DDX not being compiled for KMS
hifi: I had KMS working fine just yesterday with RV570
soreau: hifi: You need to make sure you have latest libdrm compiled with --enable-radeon-experiment like kdekorte said, and mesa, ddx and X compiled against that libdrm
kdekorte: X does not, just the DDX
soreau: Yes, X needs to be too
Ghworg: I've never compiled X and get a working KMS stack fine
kdekorte: The multi cp patches airlied made really improved the performance of gtkperf on my machine
soreau: If you use a binary distro, you may not have to
hifi: soreau: I'm using tormod's ppa
eosie: soreau: yes, they did
soreau: eosie: Great! thanks
kdekorte: On Fedora 11 and 12 I have never had to compile X when messing with libdrm, but there have been times where libdrm needed a newer X than what I had
hifi: it works but is corrupted
hifi: 2000fps with glxgears, yay for useless benchmarks
taiu: hifi: check you have not enabled colortiling in xorg conf
hifi: do I need to disable it, I have no xorg.conf at the moment
taiu: hifi: no, it's ok then
hifi: I'll post my Xorg log
kdekorte: hifi, is it minor corruption or major corruption?
kdekorte: Also are you using compiz?
hifi: major, I'll post moar
hifi: no compiz
hifi: oh, lol
soreau: hifi: Have you tried xorg-edgers repo instead?
hifi: soreau: I meant xorg-edgers, sorry
hifi: tormod was just the person who packages them
soreau: ah ok
hifi: theres no corruption when I take a screenshot with scrot
soreau: Pastebin the X log and a screenshot then
kdekorte: Do you have compositing enabled?
hifi: http://hifi.iki.fi/Xorg.0.log theres some log
hifi: kdekorte: for the last time, I have no xorg.conf, so I'm doing with the defaults now
kdekorte: compositing can be enabled without xorg.conf, like in metacity
hifi: I'm using plain openbox
kdekorte: X log looks fine
kdekorte: would like to see a screen shot? Do you happen to have a digital camera or cell phone picture?
soreau: Yea, it looks fine but it is suspicious the corruption does not show in a screenshot
hifi: I'll use a camera, one moment
soreau: hifi: Have you completely cold booted the machine?
hifi: sure, I just installed the card :p
soreau: And, have you tried compositing to see what happens?
hifi: no, I have not tried compositing
hifi: I launched xcompmgr, nothing changed, that enough?
hifi: the screen flickered but is still corrupted
kdekorte: should be
hifi: ooooh
hifi: I changed resolution with xrandr and the corruption is gone
hifi: I had a similiar problem in the past with RV570
soreau: If you change the resolution right back is it still gone?
hifi: also the full size resolution works, I just had to change it
kdekorte: did you happen to power off your monitor while you put in the new card
kdekorte: I've seen cases where I have to power off a display to get it to come up right
hifi: yes, everything was completely off
hifi: also the system console is fine
soreau: and if you reboot now, does the corruption come back or was it just a fluke?
kdekorte: interesting
hifi: with KMS
hifi: full resolution and everything
hifi: when I start X I get the corrupted screen, and if I kill X with ctrl-alt-backspace I get back to fully working KMS console
hifi: I restarted X and the corruption is back again, xrandring will fix
kdekorte: hifi, might try running "gnome-display-properties" and setting things there.. it should setup some things in HAL or device kit
kdekorte: And then restart X
hifi: uhh
hifi: I don't have gnome installed
hifi: it doesn't matter, I can put the xrandr hack in xinitrc, but the underlying problem is whats interesting
kdekorte: Might want to bugzilla it, attach the Xorg.log before the xrandr and after so the devs can see what changed
hifi: aww
hifi: worse performance with hl1 than my RV570 :)
dottedmag: Hmm... oprofile'd system: looks like X spends all the time in pixman_rasterize_edges. wtf?
soreau: dottedmag: compositing manager..?
dottedmag: soreau: nope, just Xmonad.
dottedmag: Just started oprofile and tried to switch between two fullscreen gtk apps (each takes couple of seconds to redraw).
hifi: duh, also my ALSA got confused and now only finds the HDMI audio, my PCI card is nowhere to be found :p
lordheavy: kdekorte: looklike the last cp patches enhance perfs under kde (for me) and fixes some corruptions (colors)
hifi: great, HD 4650 is just enough for my current needs regarding 3D acceleration
hifi: it runs openitg \o/
kdekorte: lordheavy, yes, that is a nice improvement
kdekorte: agd5f, what is the best way to test the r6xx interrupt patch?
rah: does the component-video dongle cable supplied with my HD4850 also output composite video?
agd5f: kdekorte: apply the patch and boot the kernel
agd5f: kdekorte: also make sure you have the new ucode installed
kdekorte: agd5f, which kernel do you recommend?
agd5f: rah: I think you need an s-video to composite cable
agd5f: kdekorte: radeon-dp or radeon-testing
kdekorte: agd5f, do you have the git address of either of those?
agd5f: kdekorte: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=summary
hifi: hm, HD 4650 freezes on another mobo with HDMI plugged in when xorg starts
rah: agd5f: but there's no s-video output
rah: agd5f: all I have is the component-video output
rah: which I guess is really my question
rah: how do I get composite-video output from my HD4850, given that all I have is a component-video dongle cable?
rah: can I buy an s-video dongle cable?
hifi: freezes also when I used DVI
hifi: back to the drawing board
agd5f: rah: same connector takes s-video or the dongle
rah: hmm
rah: really?
agd5f: rah: yes
agd5f: at least on most boards
rah: is it safe to plug the adaptor in while the machine is on?
agd5f: yeah
rah: of course it is
agd5f: hifi: if you recently updated the ddx make sure you have the latest libdrm, or you may be getting an unresolved symbol
hifi: I didn't have the latest git stuff, I had commented out them some days ago
rah: it fits
rah: looks promising..
kdekorte: agd5f, ok, I think I have things compiling now.. thanks for the tips so far
agd5f: kdekorte: np
hifi: xorg edgers failed to build latest DDX
Luzipher: Is there a way to put the new firmware (r600+ interrupts) into the kernel so I don't need a initramfs ?
hifi: agd5f: thats for the missing vbo symbols?
agd5f: hifi: I haven't looked at that yet, but the drm from fd one
wirry: wow...33s black screen at boot while waiting for kms to set the right resolution is a record, isnt it? :D
hifi: wirry: maybe the fbcon module was loaded later?
agd5f: wirry: you likely don't have fbcon loaded
Wizzup: Warsow 0.5 seems to work on r700, mesa 7-8
wirry: mom pls, emerging wgetpaste...
Terman: I want to build the current ...-ati driver, but the build process complains: xorg-macros version 1.3 or higher is required but 1.2.2 found
ajax: so install newer xorg macros.
Terman: which package do I need to upgrade (or which package contains the xorg-macros.m4 to be more precise)
ajax: % rpm -qf /usr/share/aclocal/xorg-macros.m4
ajax: xorg-x11-util-macros-1.3.0-1.fc12.noarch
Terman: I'm already at ftp://ftp.x.org/pub/individual/proto/, but my first two attempts were failures
ajax: if you're building from source, individual/util/xorg-macros-1.3.tar.bz2
rah: agd5f: is there anything I need to do to enable composite output?
rah: xrandr reports:
rah: DIN disconnected (normal left inverted right x axis y axis)
agd5f: rah: if load detection doesn't work, you'll have to force it on
rah: agd5f: Option "ForceTVOut"?
agd5f: rah: that or just use xrandr
agd5f: xrandr --addmode DIN 1024x768; xrandr --output DIN --mode 1024x768
agd5f: for example
rah: hmm
rah: rah@myrtle:~$ xrandr --output DIN --mode 1024x768
rah: xrandr: cannot find crtc for output DIN
wirry: http://pastebin.com/m4873553c <- dmesg
rah: agd5f: do I have to add a monitor definition to xorg.conf?
Terman: ajax: thanks, now compilation works again
agd5f: rah: no
wirry: i didnt touch anything with fbcon on it, and it was much faster 2 weeks ago
rah: agd5f: how do I enable to output?
agd5f: rah: if you already have two heads enabled, you'll have to disable one
rah: err.. eh?
rah: that's not practical
agd5f: rah: there are only two display controllers
agd5f: so you can only have two heads active
rah: urg
rah: that sucks
rah: it works but it's very green
hifi: wait what, can the motherboard affect graphics bugs
dottedmag: airlied: is fix for https://bugzilla.redhat.com/show_bug.cgi?id=528593 in Linus tree?
rah: hmm
rah: agd5f: I've switched the DIN off and now the monitor it replaced won't display
rah: agd5f: the mode is set but the monitor reports the input signal is out of range
agd5f: rah: try turning it off then on? what version of the driver are you using? kms?
rah: agd5f: yes, using kms
rah: (and of course I've turned it off and on again, give me *some* credit :)
tball: Hello
hifi: hmm, can there be 64bit bugs in radeon?
tball: Zajec, if you are here, do you have some PM to test? :P
agd5f: rah: what card?
rah: Asus EAH4850
agd5f: rah: file a bug
rah: meh
rah: ok
hifi: http://hifi.iki.fi/openitg-arrows.png (1080p shot, 1MB image)
wirry: agd5f: did you take a look on my log?
hifi: I just had the same card on a 32bit system and the arrows looked ok
hifi: but on the 64bit machine running a 32bit app they look like that
adamk: hifi, Do you have the 32-bit drivers installed?
hifi: I compiled them from source, so I believe not
adamk: Well then that's certainly a problem :-)
hifi: ooh
hifi: so I'd need like a 32bit mesa build?
adamk: If you want properly accelerated 32 bit apps, yes.
hifi: why the heck did it even work at all
hifi: but that would explain the broken arrows?
agd5f: wirry: I dunno. looks fine
adamk: It either fell back to the software rasterizer or, more likely, accelerated indirect rendering.
hifi: it did run at high fps
adamk: I'm happy for it :-)
hifi: I mean, really high
adamk: Alright.
adamk: I'm really happy for it.
hifi: hey, it should print the ogl info at boot
hifi: WARNING: Direct rendering is not enabled!
adamk: Hey look, I was right :-)
adamk: It's falling back to indirect rendering... Which is still accelerated via AIGLX.
hifi: would that explain the arrow bugs? :)
adamk: Well I imagine that AIGLX doesn't get as much bug testing with most applicaftions as direct rendering.
hifi: thats really perverted, accelerated indirect rendering
hifi: so my solutions would be to build a 32bit mesa and/or build the app as 64bit?
hifi: err, just or
dottedmag: or fix AIGLX :)
hifi: thats for the devs :p
adamk: hifi, Yes, those are your options.
hifi: I wonder if the app builds on 64bit
hifi: if I'd just copy the stuff from my 32bit machine, what files would I need, dri stuff?
adamk: libGL, libdrm, and the r300_dri.so (or r600_dri.so) driver
hifi: I'll test it out just for fun and breakage
kdekorte: agd5f, well I have r600 with interrupt support working...
kdekorte: not a real big change in speed or cpu usage, but nice to have
hifi: adamk: what was the env variable for libGL to look for another place for the DRI drivers?
hifi: thanks
Kurko: Does Vsync works with HD2600 and radeon driver?
hifi: adamk: thanks a lot, I made a special lib32 prefix where I dropped the new files from my other machine which has a git build and it works prefectly
agd5f: Kurko: with the recent interrupt patch, yes
kdekorte: agd5f, does anything else need to be rebuilt after the interrupt patch is applied?
agd5f: kdekorte: no. need to use kms though
kdekorte: I am on KMS
kdekorte: I ran second life and it crashed, but neverwinter worked fine
kdekorte: my clutter app, that was working fine before now is super slow... so I'll have to reboot into another kernel and retest
hifi: then back to another issue, vsync is doing something baaad
hifi: the app slows down a bit and then goes really fast for a moment
hifi: also keyboard input is slow and jumpy
kdekorte: I agree with Interrupt support the machine feels a little weird...
otaylor: hifi: that's usually a sign that you are getting synchronization at the output level without the app waiting for each frame to render
kdekorte: BRB... gonna try a kernel w/o interrupts
otaylor: so frames go out at a constant rate, but the app generates 15 frames then blocks when the buffers get full, then generates 15 more frames then blocks again (or whatever)
hifi: otaylor: yeah, that sounds right
hifi: do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
hifi: I'm getting that with glxgears
kdekorte: Ok, I swtiched back to a non-irq kernel and my clutter app runs much faster
hifi: I don't think .drirc is read at all
hifi: whatever I put in vblank_mode (force off) it still tried to wait
kdekorte: try vblank_mode=0 in front of the command
otaylor: hifi: you might get that behavior if you just didn't have vblank synchronization at all
hifi: ATTENTION: default value of option vblank_mode overridden by environment.
hifi: ATTENTION: option value of option vblank_mode ignored.
otaylor: hifi: it's also can be a symptom of just having a long pipeline without any synchronization
hifi: what? :D
hifi: I can't disable vsync with vsync_mode=0 and the app doesn't sync to vblank with any of those, I only get the drmWaitVBlank error
MostAwesomeDude: eosie: Ping. I'm seeing walls of failing glean tests; are you only testing a small subset of things?
Zajec: a
hifi: can I force the vblank off at source level from somewhere
agd5f: hifi: interrupts only work with kms on r6xx+
hifi: I have kms and r7xx :o
Zajec: what do I need to set to see DRM_DEBUG messages?
Zajec: drm.debug?
Zajec: what value?
hifi: how do I know if I have interrupts support in my kernel or is it a patch?
hifi: also how does it affect
jcristau: Zajec: 1
Zajec: hifi: start glxgears, check for lacking IRQ info
Zajec: hifi: (info about no IRQ and busy waits)
hifi: do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
olaf: i see on phoronix website , that irq support will only be pushed for kernel 2.6.33 , right ?
agd5f: hifi: you don't have the patch applied most likely
hifi: doesn't that mean that vsync should not work?
hifi: or what
agd5f: olaf: yes
hifi: openitg feels sluggish even at 100fps and keyboard response is slow
MrCooper: hifi: input lag can occur even at high framerates without frame trottling
hifi: oh, and the background video slows down and speeds up
hifi: and my RV570 also ignores all vblank_mode values
hifi: seems that whenever the stepmania engine is playing a movie trough ffmpeg it get laggish
spreeuw: hifi: gonna try it out
hifi: you mind if I pm you?
spreeuw: I'm no dev just a user
hifi: and this is only on R7xx for me
spreeuw: I can try it on a fatser card
hifi: well, try openitg intro
spreeuw: yeah I have one
hifi: just the intro video slows down and the sounds repeat
hifi: -just
spreeuw: beta2 doesnt run
spreeuw: complains about missing gtk so's
spreeuw: that should be loaded from the gamedatadir
spreeuw: I'll try an svn build
hifi: oh no
hifi: change your Static.ini
spreeuw: where is that?
hifi: Data/Static.ini
hifi: add this line: ShowLoadingWindow=0
hifi: the loading window is not supported with openitg at all I thini
hifi: think
rah: agd5f: the TVStandard option doesn't seem to work
rah: agd5f: I've got the following in my xorg.conf:
rah: Option "TVStandard" "pal"
agd5f: rah: doesn't work with kms
rah: urg
rah: agd5f: how do I make it work with kms?
agd5f: rah: with kms you need to use xrandr
rah: agd5f: how do I set the standard with xrandr?
spreeuw: hifi: ok it started
agd5f: xrandr --output DIN --set standard pal or something like that
rah: ok
agd5f: I forget what the attribute is called with kms
spreeuw: seems to run ok, but I have no sounds loaded
hifi: spreeuw: how does the intro video of roxor logo work for you?
agd5f: xrandr --verbose will show you all the attributes
hifi: is the flash from right to left smooth
spreeuw: it was blurry
spreeuw: but it worked
hifi: also the big X flames stutter a bit
hifi: and in the main menu if you scroll it with up and down arrows the background video should slow down
rah: agd5f: don't seem to see any appropriate attributes
hifi: though I do have a "non-standard" refresh rate on that screen, 50Hz
rah: agd5f: http://pastebin.com/m3130e0e7
hifi: maybe the driver goes haywires on that :)
agd5f: rah: probably a kms bug then
rah: argh
rah: !cool
hifi: though it might be the audio driver
rah: agd5f: what should properties look like?
agd5f: rah: should be a tv_standard property. I though kms had that
spreeuw: hifi: seems to run ok
hifi: must be ALSA then
rah: agd5f: I mean what does the xrandr command's output of properties look like?
spreeuw: hifi: the background video of dancing people is smooth too
spreeuw: how do you control this game
hifi: press enter
spreeuw: is it to dance on?
hifi: yes
hifi: you need a dance mat to play it
spreeuw: lol
hifi: (or a keyboard)
spreeuw: nice
agd5f: rah: like what you just pastebinned?
spreeuw: hifi: I miss 1280*960
hifi: what?
rah: agd5f: what would be the name of a property in what I pastebinned?
spreeuw: the game doesnt read out the xorg supplied values
hifi: spreeuw: did you select the correct aspect?
hifi: it's before you select resolution
spreeuw: yeah it isnt in 16/10 or 16/9
agd5f: rah: load detection is the only one listed
rah: I see
rah: the last update to the drm-2.6 kms branch was 13 days ago
spreeuw: hifi: it looks very snappy for the rest did you make it?
rah: is there a more recent tree?
rah: s/drm-2.6/drm-next/
agd5f: rah: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=summary
hifi: spreeuw: openitg? heavens no.
rah: agd5f: which head should I be using?
dottedmag: Gah: *ERROR* radeon: GPU lockup detected, fail to get a IB
agd5f: rah: drm-radeon-testing has the latest bits
dottedmag: agd5f: I believe you fixed something like this error recently, right?
rah: agd5f: ok, thanks
hifi: OpenITG is a fork of Stepmania (an open source dance game) and ITG is "In The Groove" from a game development company Roxor, which is now long dead
agd5f: dottedmag: not that I know of
hifi: OpenITG made the same changes to stepmania as roxor did but it's open source
Zajec: agd5f: i guess you're busy with new stuff, but could you spare a moment on my problem with IRQs, please?
Zajec: agd5f: i posted new mail in PATCH's thread
Zajec: agd5f: with logs this time
agd5f: Zajec: give me a few minutes
Zajec: agd5f: :)
Zajec: sure
dottedmag: agd5f: http://sourceforge.net/mailarchive/forum.php?thread_name=a728f9f90911021315q202633b3vd6453987d8162dfa@mail.gmail.com&forum_name=dri-devel -> https://bugs.freedesktop.org/show_bug.cgi?id=24218
dottedmag: (ugh, weird url)
agd5f: dottedmag: ah, ok
Zajec: dottedmag: ther thread you pointed fixed my bug with ring being incorrectly set
Zajec: agd5f: i guess driver is just busy with receiving CP int for some reason... and it does not receive VBLANKs anymore
dottedmag: Zajec: did it result in X stuck in ioctl loop?
agd5f: dottedmag: that means the gpu has hung
dottedmag: laughs: he has two cards in laptop, none usable: Intel does not have DVI output connected, radeon either getting stuck with KMS or completely broken with UMS
Zajec: dottedmag: not sure if that was ioctl loop, you can check https://bugs.freedesktop.org/show_bug.cgi?id=24535
agd5f: dottedmag: file a bug
dottedmag: agd5f: yep, researching
Zajec: still has some nasty bug to kill :|
dottedmag: agd5f: does it make any sense to report bugs about rendering artifacts in UMS configuration nowadays?
Zajec: every time I resume on KMS i get lockup
Zajec: dottedmag: i believe UMS will be still used for some time
agd5f: dottedmag: yes. also file a bug about kms if that has issues too
Zajec: dottedmag: just fill separated bugs please
dottedmag: okay. though I'm pretty sure KMS one is duplicate, and I did not have recent enough kernel.
agd5f: dottedmag: it'd be nice if you could verify that first
dottedmag: agd5f: doing it right now :)
dottedmag: Zajec: hey, I have triaged my share of tickets already :)
ossman: airlied, I can happily report that the kernel in koji properly solves the tv out hang
tmoertel_work: Can I use DRI w/o AIGLX?
agd5f: tmoertel_work: yes
tmoertel_work: agd5f: whoops, I meant regarding radeonhd (posted to wrong group).
tmoertel_work: agd5f: btw, got KMS working, thanks to airlied and new kernel: https://bugzilla.redhat.com/show_bug.cgi?id=540593
agd5f: tmoertel_work: cool
tmoertel_work: agd5f: do you know if there's an option to turn off AIGLX? I can't find one in either radeon or radeonhd man pages.
jcristau: twoerner: xorg.conf(5)?
agd5f: tmoertel_work: it's not driver specific
jcristau: err
jcristau: twoerner: sorry
jcristau: tmoertel_work: the above was for you, there's an aiglx serverflag
tmoertel_work: I'm so close to getting video working again. KMS now works. But if I use radeon, I get no video and no obvious errors; if I used radeonhd, I get no DRI, so rendering is slooooow.
tmoertel_work: jcristau: thanks.
agd5f: tmoertel_work: AIGLX probably isn't the problem
agd5f: tmoertel_work: radeonhd won't work with kms
Zajec: agd5f: patch v3... should it improve sth for me?
tmoertel_work: agd5f: if radeonhd won't work w/ KMS, it won
tmoertel_work: 't work for me at all because w/o KMS, VGA arb isn't available, and, again, DRI is disabled.
agd5f: Zajec: Don't know. maybe
tmoertel_work: So, I guess that means it's radeon for me. But when I try it, I get no video -- and no obvious errors in the Xorg.0.log.
agd5f: tmoertel_work: pastebin your xorg log and dmesg
tmoertel_work: agd5f: let me reboot w/ radeon to get them for you. (I'm running radeonhd now, just so I can get some kind of GUI.)
Zajec: agd5f: reading changes it probably won't :(
tmoertel_work: Be back in a moment.
tmoertel_work: agd5f: thanks, btw.
tmoertel_work: agd5f: my xorg.conf and Xorg.0.log: http://gist.github.com/246549
agd5f: tmoertel_work: dmesg?
tmoertel_work: agd5f: do you want me to reboot and get it or can I gather the output now, running under radeonhd?
agd5f: tmoertel_work: now should be fine
tmoertel_work: agd5f: here you go: http://gist.github.com/246560
agd5f: tmoertel_work: does the monitor work better on the other DVI port?
tmoertel_work: The card has only one DVI out; the other is VGA.
agd5f: tmoertel_work: does it work if you connect with vga?
tmoertel_work: agd5f: haven't tried it
agd5f: tmoertel_work: looks like your card needs a quirk then as it shows two DVI ports
tmoertel_work: agd5f: the mfg makes another version that has two DVI ports; probably same circuit board w/ different connector sets.
agd5f: tmoertel_work: send me your vbios and the output of lspci -vnn
tmoertel_work: How do I get the vbios?
tmoertel_work: agd5f: lspci -vnn: http://gist.github.com/246563
agd5f: tmoertel_work: cd /sys/bus/pci/devices/; echo 1 > rom; cat rom > /tmp/vbios.rom; echo 0 > rom
agd5f: as root
kdekorte: agd5f, any idea why clutter is super slow when interrupts are enabled on r6xx?
Curtman: I added the line "Virtual 2960 1050" to my Screen/Display section of xorg.conf. I am able to enable my second desktop now, but when I click maximize on a window from Metacity it spans the entire desktop, instead on one of the two displays. How can I fix this?
agd5f: kdekorte: not off hand
agd5f: kdekorte: maybe something with vblanks
tmoertel_work: agd5f: got it. where do you want me to send it?
agd5f: Curtman: rebuild your wm with xinerama support
agd5f: tmoertel_work: alexdeucher AT gmail DOT com
Curtman: agd5f, Ahh, right. never thought of that. Thanks very much.
ossman: agd5f, vblank not working here :/
ossman: agd5f, it is getting lots of interrupts though. and it isn't stopping when the last vblank client goes away
tmoertel_work: agd5f: sent.
agd5f: ossman: vblank interrupts or interrupts for other things?
ossman: how can I tell?
agd5f: ossman: enable drm debugging
ossman: will have to reboot. hang on
tmoertel_work: agd5f: if you're curious, here's the card in question: http://www.newegg.com/product/product.aspx?Item=N82E16814161017
tmoertel_work: agd5f: dual-link DVI, if it matters
ossman: damn this machine is slow...
ossman: agd5f, give me a few minutes :)
kdekorte: agd5f, etracer and glxgears worked great with interrupts enabled...
agd5f: tmoertel_work: sent you a patch
tmoertel_work: agd5f: got the patch
parabelboi_: hi all, is this the right channel for kernel bugs related to ttm/radeon ?
tmoertel_work: agd5f: funny thing is, I have the same card at home, and it works there under the same kernel and xorg versions from Fedora 12.
BioTube: parabelbio_: yes
parabelboi_: very good ;-)
agd5f: tmoertel_work: weird. that patch should at least fix the connectors
parabelboi_: I have a kernel bug, stacktrace is here: http://pastebin.com/m3844dee6
parabelboi_: the objdump looks like this: http://pastebin.com/m5ac94c85
ossman: agd5f, it keeps getting vblank interrupts
ossman: i.e. when it shouldn't be getting anything
ossman: and the rate is sane, so it just seems like something forgot to disable vblanks
agd5f: ossman: avivo cards probably need something like the pre-avivo cards have in the dpms hook
ossman: that's just to keep the counter somewhat updated
kdekorte: agd5f, clutter developers are saying that clutter uses WaitForVBlank and that could be why it is slow... there is a test that can be done by disabling vblank waits by using CLUTTER_VBLANK=none
tmoertel_work: agd5f: I'm comparing the Xorg.0.logs from home and work (here)... at home it's in PCI slot 4; here, 3. Not that it would likely matter.
agd5f: tmoertel_work: shouldn't matter. same monitors?
ossman: agd5f, IIRC the routine to disable vblank is scheduled after each vblank wait, so it should trigger as long as someone doesn't keep on waiting for vblanks
tmoertel_work: agd5f: different monitors: DELL 2001FP at home; DELL 2408FP here.
ossman: agd5f, it also gets obscene amounts of interrupts when xbmc is running
agd5f: tmoertel_work: see if you can try a different monitor
ossman: no idea what though as dmesg gets spammed with ioctl lines
tmoertel_work: agd5f: if you're interested, here's a diff between the Xorg.0.logs from home and here at work: http://gist.github.com/246592
kdekorte: agd5f, well I don't know what I did, but another reboot into an IRQ kernel and everything is now happy
agd5f: tmoertel_work: different chips: -(--) RADEON(0): Chipset: "ATI Radeon X1300/X1550" (ChipID = 0x7146)
agd5f: +(--) RADEON(0): Chipset: "ATI Radeon X1550" (ChipID = 0x7143)
tmoertel_work: agd5f: Hmm.. different chipsets, too ...
tmoertel_work: agd5f: (saw it at the same time ;-)
kdekorte: agd5f, ok this is really odd, right after reboot everything was working fine, now all of sudden all of my clutter apps are dead slow...
kdekorte: And setting CLUTTER_VBLANK=none and starting them again makes them fast
agd5f: kdekorte: sounds like the vblank problems others have been reporting
kdekorte: yeah, I agree
kdekorte: BIOS problem? or driver?
ossman: agd5f, [drm:r600_irq_process], r600_irq_process start: rptr 50784, wptr 50800
ossman: [drm:r600_irq_process], IH: CP int: 0x00000000
ossman: are lots of those expected?
agd5f: ossman: CP int are for command buffer fences
agd5f: kdekorte: driver
ossman: agd5f, and those existed previously and were just ignored?
agd5f: ossman: there were no interrupts until the patch
agd5f: ossman: previously the driver busy waited for fences
ossman: ah
ossman: agd5f, anyhoo, mesa doesn't do any proper vblank wait. there is still tearing and there is no frame rate limiter
ossman: how to debug?
agd5f: ossman: find out if you stop getting vblank interrupts or if it's a counter problems
ossman: I can see the vblank interrupts in dmesg
ossman: I get loads of these:
ossman: [drm:drm_ioctl], pid=1882, cmd=0xc0086464, nr=0x64, dev 0xe200, auth=1
tmoertel_work: Any advice on what I can do to optimize for getting working video sooner? (For context, this is day 2 I've been without usable video at work, since the F10->F12 upgrade, and my coworkers are waiting on me.) I'm willing to use radeon or radeonhd, kms or no kms, but, so far, have found no combination that works.
ossman: agd5f, can you tell anything useful from that?
tmoertel_work: (I'm willing to buy another PCIe x1 video card, even, if that will get me back to work sooner.)
agd5f: ossman: check if the irq handler is actually seeing interrupts for vblank
agd5f: tmoertel_work: try a different monitor or mode
agd5f: or try the vga intput on the monitor
ossman: agd5f, isn't it the interrupt handling that's printing those vblank lines in dmesg?
ossman: handler
tmoertel_work: agd5f: I can try the VGA, but I don't think it will drive the monitor at its native resolution, so it's good for diagnostics, but not work.
agd5f: ossman: not the ioctl lines
tmoertel_work: agd5f: I'll try it.
ossman: agd5f, I get other lines as well:
ossman: [root@hugin extra]# dmesg | grep vblank
ossman: [drm:r600_irq_process], IH: D1 vblank
kdekorte: ossman, are you seeing and IH: D1 blank messages?
agd5f: tmoertel_work: it will drive the monitor just fine
kdekorte: guess so
agd5f: tmoertel_work: I have the same monitor
kdekorte: but only 1?
tmoertel_work: agd5f: well, if it will give me crisp-as-DVI text, that's all I need. I'll try. thanks.
rah: tries UMS
ossman: kdekorte, they trigger at a reasonable rate
ossman: so I think the hardware and interrupt handler are working as expected
ossman: but something isn't hooking it up to userspace properly
tmoertel_work: disconnects DVI, reboots w/ VGA
tmoertel_work: ttl.
kdekorte: well in that code before the debug message it call drm_handle_vblank
ossman: kdekorte, agd5f, nm user error
ossman: goes and sits in the corner
ossman: agd5f, works beautifully now. many thanks for the hard work
kdekorte: ossman, so what did you changed
ossman: kdekorte, I though I had dri configured to always use vblank, but I seemed to have nuked that conf...
ossman: xbmc whined about missing vblank support with the previous kernel, so I figured the conf was still there
ossman: apparently not...
tmoertel_work: agd5f: back up, under VGA, and radeon seems to be working fine :-)
tmoertel_work: agd5f: radeon+kms, that is.
kdekorte: ossman, let me know if vblank seems to mess up over time, for me it seems to break after a few minutes
ossman: kdekorte, sure
ossman: in what way does it break?
kdekorte: agd5f, I see there is rs600_get_vblank_counter, is there anything that resets that counter?
tmoertel_work: agd5f: thanks for your help!
tmoertel_work: agd5f: I think I can get back to work for now.
agd5f: kdekorte: turning the crtc off
agd5f: tmoertel_work: cool
kdekorte: agd5f, is is possible that counter is overflowing.. it is only a u32...
tmoertel_work: agd5f: long term, I'd like to get DVI working again (the text suffers a bit under VGA, and I'd like to help debug the problem so other people don't hit it)
agd5f: kdekorte: it's a register so it just resets to 0
agd5f: tmoertel_work: try a different monitor or mode
dottedmag: tmoertel_work: is VGA picture of good quality? I'm getting kind-of-acceptable output with Dell 2407WFP, but not quite as good as from DVI.
kdekorte: ok, also it seems it would be pretty quick to overflow anyway.. about 5 mins of running mutter seemed to cause the slowdown
Zajec: agd5f: congratulations
tmoertel_work: dottedmag: it's better quality than I had expected. The text lacks a bit of crispness, but not much, and seems a little less dark.
Zajec: agd5f: v3 works great
airlied: dottedmag: yes
tmoertel_work: agd5f: by mode what do you mean? (video mode? kms?)
agd5f: Zajec: cool
agd5f: tmoertel_work: like a diffent modeline for 1920x1200 or a different mode (1024x768)
kdekorte: but even after killing mutter, clutter apps are still slow even after restart, but running them with CLUTTER_VBLANK=none makes them fast again
agd5f: kdekorte: try the latest version of my patch
kdekorte: ok I will
tball_: How far is PM, when we now have interrupt support?
tmoertel_work: needs coffee, bad
airlied: tmoertel_work: I think we have some issues on rv515 with lockups due to the crtcs disabling funny
tmoertel_work: has obtained the requisite coffee :-)
airlied: I'm going to do some testing today
tmoertel_work: airlied: I was seeing some glitching, if it makes any difference.
airlied: vblank has no effect on dri2 yet
kdekorte: agd5f, gonna reboot with your v3 patch applied
airlied: since al lthe throttling is done in the X server
Zajec: tball_: damn, slow down :P
Zajec: tball_: i have working IRQs for 1 hour maybe ;)
Zajec: tball_: I have to figure out something about two heads setups
tball_: Zajec, Well I don't think you got any code to test then :P
Zajec: should we disable PM for dual head configs? anyone?
airlied: glisse: don't cc lkml for radeon patches mostly
airlied: it'll mean less chance of me missing it
Ghworg: Zajec: What's the matter with you, have you been sleeping and eating and having a life again? Those things are just distractions from coding :-)
Zajec: Ghworg: :D
airlied: Zajec: dynamic PM on dual-head sounds not very doable
agd5f: Zajec: need to check bandwidth requirements
airlied: unless we somehow genlock the vblanks
agd5f: we can still clock down on dpms
airlied: yup
Zajec: airlied: actually I very rarely get single corrupted lines when reclokcing engine without syncing with VBLANK
airlied: Zajec: its sorta card dependent
Zajec: ah
Zajec: ok, will have to disable it for now
airlied: I know mjg59 on r500s bypassed atom to do it faster
airlied: it also depends on what modes are set
Zajec: airlied: ok, thanks
kdekorte: airlied, the multi cs patch you applied really made things fly.. thanks
kdekorte: gtkperf on my machine went from 58 sec to 30 (gtkperf -c 500 -a)
agd5f: airlied: did you ever get to try vbos with older chips?
airlied: agd5f: not yet I looked at the EXA code and decided it would be really ugly
airlied: I think we could merge a fair bit of radeon/r600 EXA code
kdekorte: agd5f, looks like the v3 patch is better... no problems yet
airlied: agd5f: there is one bug in the multi-op stuff still
agd5f: airlied: yeah, probably
agd5f: what's that?
airlied: if an IB flush occurs during an op we can't restart the op properly
airlied: since we don't have the information
airlied: non-r600 code does it properly
airlied: its a lot less likely to happen since the only time we write to the IB during an op is when we fill a VBO
airlied: and we'd have to fill 10 I think to hit the problem
spreeuw: rofl nexuiz is total carnage
spreeuw: very playable on 4670
spreeuw: with git
spreeuw: recommend it to devs for gfx testing
Zajec: airlied: could you try to grab all awaiting patches to some branch?
Zajec: airlied: i think we have fair amount on them already
ossman: kdekorte, no vblank issues yet
ossman: airlied, in case it scrolled out of view, I can confirm that the kernel in koji solves my tv out issue
kdekorte: agd5f, I think that the irq patch is looking good
agd5f: kdekorte: cool
tmoertel_work: airlied: btw, your changes in did resolve the oops in https://bugzilla.redhat.com/show_bug.cgi?id=540593
tmoertel_work: airlied: I tested the kernel on two machines, and both loved the new kernel.
ni1s: Is there any way to change the video res. on the console using KMS?
airlied: Zajec: not sure what is really outstanding, irq is the only one
airlied: hopefully the latest ones work
kdekorte: agd5f, I was able to run Neverwinter Nights with vblank enabled and clutter apps are still running well
ni1s: my radeon DRM set it to 1920x1440, but X only allows 1600x1200(which is what I want)
Zajec: airlied: yeah, that are not big patches generally
chithead: ni1s: you can pass resolution to the video= kernel parameter
ni1s: chithead, like one would using any other fb device?
chithead: ni1s: why not? did you try and it failed?
Zajec: airlied: maybe I don't get idea of commiting patches :)
ni1s: chithead, I havnt tried anything yet
rah: I have non-kms linux-2.6.32-rc8
rah: and radeon 6.12.3
rah: (and X server 1.6.5)
agd5f: rah: I posted a patch on dri-devel today to fix the tv standard with kms
rah: but I get no TV output
rah: agd5f: oh
rah: agd5f: shouldn't TV out work with UMS though?
rah: regardless?
agd5f: rah: yeah
agd5f: rah: with ums, you need Option "ATOMTvOut" "true"
rah: ah ok
rah: bbias
glisse: airlied: ok, i think there is other patches you missed
glisse: i need go throught git to check that
turmlos: Anyone seen corruption like this with KMS? http://sturmartillerie.org/linux/radeon-kms.png
dottedmag: turmlos: I've seen something similar today under UMS
Silas_: adamk are you always online ? :)
turmlos: dottedmag: UMS has treated me well so far, but I end up with screen corruption whenever I give KMS a try.
adamk: Well, I may always be here without actually being here.
glisse: turmlos: check for erro message in kernel log
glisse: like out of aperture
glisse: or can't validate buffer
amarks: agd5f: for the rv790 broken bug, can i just boot with nomodeset for non-kms?
agd5f: amarks: yes
amarks: agd5f: do you care whether is composite on or off?
parabelboi_: ping rnoland
amarks: maybe i'll type english next time
rnoland: pong
ossman: what's the status of KMS and suspend?
rnoland: parabelboi_: pong
parabelboi_: might commit 0a5c1e61 "A bit of cleanup work on radeon_freelist_get()" fixed the bug at http://pastebin.com/m3844dee6 ?
ossman: I'm not getting any output back on my R300
parabelboi_: rnoland, it's a null pointer dereference in ttm_tt_free_alloced_pages which is hard to reproduce
agd5f: amarks: if you mean gl/render composite manager, then yes, if you have issues
parabelboi_: I changed to drm-next now, and so far no bug
turmlos: glisse: Nothing of that nature, only strange messages I see are "Unpin not necessary"
airlied: glisse: I think I''m only missing that one, I generaly search in my lkml foilder for you
rnoland: parabelboi_: i doubt it...
airlied: but less often
parabelboi_: rnoland, i still have "[TTM] Erroneous page count. Leaking pages."
parabelboi_: rnoland, ok then, I'll try further
rnoland: parabelboi_: well, i don't do linux... but i would look to ttm....
parabelboi_: rnoland, thanks, I'll do so
ni1s: Is [drm:r100_cs_track_check] *ERROR* something one should report? Using git stuff here
airlied: depends on what you were doing
ni1s: playing a game
ni1s: freespace 2
airlied: glisse: oh I missed the TTM patches, I'm not sure TH saw them either
airlied: you definitely should cc him for review on those before I touch em
airlied: glisse: so in future no lkml cc is necessary
roy_hobbs: Does anyone know if the new pm-utils fixes issues with suspend/resume failures when KMS is enabled?
agd5f: roy_hobbs: make sure you are using latest radeon drm
roy_hobbs: Everything is up to date. I was having a problem with the radeon driver where when KMS was enabled, the computer wouldn't fully suspend. I've been looking forward to 2.6.32 because there are supposed to be a number of KMS fixes. Someone here told me they were having a similar problem and wasn't aware of a fix yet.
roy_hobbs: But then I just saw that pm-utils has made some KMS fixes. I thought I'd ask before I tried it though...
k\t: question: on a 64-bit arch compiling mesa. would it be ok to use --enable-32-bit when --enable-64-bit fails ?
rah: http://myrtle.6gnip.net/~rah/xorg-git.jpg
rah: this is what I get with radeon from git
rah: (both kms and non-kms)
rah: this is bad
roy_hobbs: rah, it kind of looks like you have a house on the beach and the blinds are closed
roy_hobbs: so it's not all bad
rah: err.. yeah..
DanaG: fatal: read error (Connection reset by peer)
DanaG: trying to git pull.
rah: man that peer is a bastard
rah: he gets my connection all the time
rah: I wish he'd get lost sometimes
DanaG: hmm, what's up with git.kernel.org?
MostAwesomeDude: It's not working?
DanaG: Not for me.
DanaG: git pull
DanaG: fatal: read error (Connection reset by peer)
DanaG: weird... cloning anew worked.
DanaG: hopes the new kms powersavings code will go into master soonish-ish.
airlied: DanaG: you can just apply it locally, its not ready for upstream yet
airlied: though I might merge it off by default if the basics make sense
DanaG: ah. Is it possible to build drm-next out-of-tree?
DanaG: Like was done with nouveau with the Makefile here: http://cgit.freedesktop.org/nouveau/linux-2.6/plain/nouveau/Makefile?h=master-compat
airlied: DanaG: you could copy that from nouveau
airlied: I'm not sure how well it worked
airlied: I think they abandoned it
DanaG: Hmm, it's worked fine for me, as recently as 2 days ago.
zhasha: airlied: I got a BIOS dump for you, but I'm not sure where I should file the bug
zhasha: also, I don't know if it's a kernel bug or a DDX bug given that I only see it when X starts (though the SVideo plug might be incorrectly detected on beforehand?)
airlied: zhasha: file it in the bugs.fd
airlied: smae palce as always
DanaG: hacked the Makefile
DanaG: now to reboot to a newer kernel, then build against that one.
zhasha: what do I file the bug under then?
zhasha: meh. I guess xf86-video-ati
airlied: zhasha: yes against the DDX
zhasha: airlied: filed as http://bugs.freedesktop.org/show_bug.cgi?id=25386
DanaG: http://pastebin.com/f3f49713e
DanaG: dmesg.
zhasha: and the attachment has been added
airlied: bugs.fd.o is being evil to me
DanaG: mmmyeah, null pointer dereference. Bummer.
airlied: DanaG: thats all fucked up what you posted
airlied: looks like old modules and new kernel or somethinfg
DanaG: ah, considering I'm booted on 2.6.32... yeah.
DanaG: hmm, so should I try .31 instead?
airlied: no idea you've done something that I'm not touching
DanaG: tries 2.6.31.
airlied: zhasha: add a dmesg in therer as well
zhasha: airlied: done
airlied: zhasha: now one with drm.debug=1 on the command line ;-)
airlied: and an lspci -vv as well for good luck
zhasha: aww but then I have to reboot :P (will be done boss)
zhasha: airlied: just to clarify, drm.debug=1 unrecognized, it's alright, right? :P
airlied: zhasha: yes
zhasha: airlied: okay, added
airlied: zhasha: I need you not to go into X
airlied: for the drm.debug=1 one
airlied: since its just full of X starting otherwise
zhasha: ah, I was wondering what was up with that
airlied: not sure how to make your distro not do X
zhasha: is there a fedora boot parameter for that or do I need to trick it somehow?
airlied: maybe single user
airlied: oh Fedora, just add 3 to the kernel command line
zhasha: kay
zhasha: airlied: all fixed and updated
zhasha: and I apologize for my retardation
DanaG: hmm, 2.6.31 doesn't have vga_arbiter, which radeon demands.
DanaG: So... looks like out-of-tree doesn't work. Bummer.
DanaG: oh wait... maybe I'm missing firmware?
zhasha: airlied: is there anything else you want me to put up there now that I'm at it?
DanaG: hmm, it doesn't even reach that stage.
DanaG: dang.
airlied: agd5f: should we merged displayport to master in DDX?
bnijk_: i just updated my whole system
bnijk_: on archlinux
bnijk_: and updated xf86-video-ati-git
bnijk_: and now X won't start
bnijk_: feh
bnijk_: it wipes the console
bnijk_: and gives me a _ at the top
bnijk_: and then stops accepting input
agd5f: airlied: yeah. I was thinking of adding a timer fr dp, but we can do that on master
agd5f: airlied: I've started on irq-based display detection for the drm
agd5f: I get interrupts, just gotta wire it up and deal with polarity swaps for connect vs. disconnect
airlied: agd5f: nice
airlied: I'll merge it over to master
airlied: agd5f: I've pushed irq + glisse object rework code + irq mitigation patches to drm-radeon-next
airlied: I'll probably pull DP into that branch
agd5f: airlied: cool. just checking it out. planning to merge drm dp?
agd5f: ah, cool
airlied: DP conflicts a bit on merge so I'll have to clean it up
airlied: mainly the i2c cleanups
airlied: I might also split the changes to core/non-radeon out to a separate patch
airlied: so Intel ppl can notice it
agd5f: airlied: yeah, half of atombios_dp.c could go into a common module
agd5f: I was thinking of two common modules, one for aux chan and one for common dp link trainign stuff
airlied: I'll just deal with the common i2c layer for now
airlied: we can cleanup more later
airlied: Ben also has some code for nouveau using it
airlied: okay drm-radeon-testing now has DP in it, I'll cleanup rebase it more tomorow
DanaG: hmm, drm-radeon-next... is that a separate branch from drm-next?
DanaG: er, s/next/testing/ would be, at least.
airlied: DanaG: I jsut sent a mail to dri-devl explaing branches
agd5f: airlied: did you push dp stuff yet to drm-radeon-testing or is it just local?
airlied: agd5f: pushed but korg mirroring takes a few mins
airlied: I rebased it on top of the other stuff
agd5f: cool
airlied: you might also need a git fetch --force since I force pushed it
agd5f: does drm-radeon-testing have r6xx irq patch?
airlied: yes
DanaG: check for dri-devel on gmane
DanaG: checks
DanaG: gmane.comp.video.dri.devel
airlied: oh maye I mis pushed gimme a sec
airlied: agd5f: okay pushed now drm-radeon-testing has DP rebased
DanaG: hmm, so when there's a new mainline kernel release, does the non-drm stuff in drm-next rebase off it? (or merge it, or whatever the term is)?
airlied: no
siimo: hi, any way to use xrandr to turn off laptop LCD? i just want to use it with external monitor only, i can turn off my laptop screen but is the graphics card still doing extra work to drive the two displays?
agd5f: siimo: xrandr --output LVDS --off
agd5f: will turn it off
siimo: agd5f: tried that but xrandr still says its connected?
agd5f: siimo: yes, it's connected, but not active
DanaG: hmm, how does drm-next stay up-to-date in non-drm stuff?
siimo: ok :S
agd5f: siimo: the hw isn't driving it when it's off
agd5f: but ther driver still tracks what monitors are connected, so you can turn them on
airlied: agd5f: https://bugzilla.redhat.com/attachment.cgi?id=375074
airlied: see the set_pll lines
airlied: https://bugzilla.redhat.com/show_bug.cgi?id=541562
siimo: agd5f: 1440x900 60.0*+ means connected right
airlied: has a real xorg log in it with proper pll s
siimo: i mean, on
siimo: if no * then not running
agd5f: siimo: * is currently running mode, + is preferred mode
siimo: if no * then?
agd5f: if you turn the output off, the * will go away
siimo: yeah cool
airlied: it might be a use_bios_dividers
airlied: but we don't set that with atom
agd5f: airlied: atom boards shouldn't use that option
airlied: yeah its wierd
agd5f: I see the problem
agd5f: airlied: patch on the way
airlied: agd5f: thanks I'm still staring blindly
amarks: agd5f: re rv790 broken rendering, i've tried nomodeset all today with and without opengl effects and i can't reproduce, looks like kms only
airlied: amarks: did you try with latest kms code as well? since I merged the multi-ops
airlied: ?
amarks: airlied: yes tried with updated multi-ops, feels snappier, but still occurs
airlied: finally spots what agd5f did 10 mins ago