airlied: MrCooper: I think mobile 9600 on 855 AGP is always bad
airlied: wrt earlier stuff, on other chipsets I think it might be okay
MrCooper: well, it's okay on my PowerBook :)
MrCooper: still it looks like 1x might be a better default for Mobility 9600 (all RV350?) in general
MrCooper: or maybe just with that bridge
rob-84x^: I have radeon 9550 and I'd like to setup dual-head configuration. yesterday I've been trying with propetiary driver with no success. neither open-source driver have worked out of the box..
rob-84x^: in general, is it possible to have radeon 9550 working with dual-head (vga & dvi outputs) configuration?
EruditeHermit: rob-84x^: what Xorg do you have?
EruditeHermit: what version
rob-84x^: EruditeHermit:
rob-84x^: X.Org X Server 1.5.3
rob-84x^: Release Date: 5 November 2008
EruditeHermit: ok
EruditeHermit: so it should work
EruditeHermit: what distribution are you using?
rob-84x^: archlinux
EruditeHermit: ok
EruditeHermit: well I don't know archlinux
EruditeHermit: but try using xrandr
EruditeHermit: with the radeon driver
rob-84x^: EruditeHermit: I had "dvi disconnected" all the time in `xrandr -q` output
rob-84x^: although the second monitor was connected to the dvi port
EruditeHermit: is it plugged in?
EruditeHermit: ok
EruditeHermit: there is a way to force it to turn on
EruditeHermit: I think
rob-84x^: I've been trying with xrandr --output dvi --set load_detection 1
rob-84x^: and Option "MonitorLayout" "CRT,CRT" in xorg.conf
EruditeHermit: hmm
EruditeHermit: try without that MonitorLayout in xorg.conf
rob-84x^: and I didn't even manage to have the dvi monitor running as the only monitor
rob-84x^: it didn't work
EruditeHermit: what else do you have in your config
EruditeHermit: you want dualhead?
EruditeHermit: or mirror
rob-84x^: yes
EruditeHermit: you will need a Virtual line in the modes section
rob-84x^: i know that
EruditeHermit: ok
EruditeHermit: hmm
EruditeHermit: perhaps you have a quirk that has to be worked around
EruditeHermit: anything interesting in Xorg.0.log?
rob-84x^: I think that for the beginning I would need to have both monitors working
EruditeHermit: it seems your DVI connector is not connected in the first place
EruditeHermit: err
EruditeHermit: its not being initialised by the driver
EruditeHermit: for whatever reason
rob-84x^: seems like something like that
EruditeHermit: you'll have to wait for someone who knows this stuff better I'm afraid if that is the case
rob-84x^: I can't make any tests at the moment
EruditeHermit: do you see anything in Xorg.0.log?
rob-84x^: I'll try it again in the evening
rob-84x^: for now I appreciate just the confirmation that it should work on my radeon 9550 ;)
EruditeHermit: well
rob-84x^: and that it's worth trying
EruditeHermit: I have a radeon 9600
EruditeHermit: and it works with that
EruditeHermit: is it AGP?
rob-84x^: yes
EruditeHermit: AGP boards are cantankerous
rob-84x^: EruditeHermit: do I have to load some kernel modules to have dvi output working?
EruditeHermit: worst case, file a bug on freedesktop.org
EruditeHermit: no
EruditeHermit: it should work
EruditeHermit: I think
rob-84x^: it's also strange that dvi output didn't work in X as the only display, isn't it?
EruditeHermit: yes
EruditeHermit: what is in your log?
EruditeHermit: it might give us a clue as to what is happening
rob-84x^: EruditeHermit: ok, I'll try it again now..
rob-84x^: (it's going to take 10 minutes or something like that)
EruditeHermit: ok
EruditeHermit: keep that log
EruditeHermit: and post it with a bug report
EruditeHermit: if you make one
EruditeHermit: describe all things that you have tried
EruditeHermit: and that the DVI connector doesn't show as connected in xrandr -q
rob-84x^: EruditeHermit: instead of trying dual-head for the beginning, I should start with trying with dvi monitor as the only output, right?
EruditeHermit: yes
EruditeHermit: well
EruditeHermit: i'd start with minimal xorg.conf config
EruditeHermit: start with the default config
EruditeHermit: and try to just use xrandr to get the output up
EruditeHermit: because some other option you have added may be conflicting with getting DVI output working
rob-84x^: so...
EruditeHermit: try to just get the same output from the primary screen to switch to the DVI output
rob-84x^: I'll connect monitor to the dvi port and reboot my machine
rob-84x^: how to generate the most simple working xorg.conf after that?
rob-84x^: hwd -x would be fine?
EruditeHermit: dunno about archlinux
EruditeHermit: but I can post one for you if you want
EruditeHermit: http://rafb.net/p/kuvbkb88.html
EruditeHermit: err
EruditeHermit: you can remove Option "Monitor-LVDS" "Configured Monitor"
EruditeHermit: replace that with Monitor-DVI
rob-84x^: thanks, I'll try with that
EruditeHermit: if that fails
EruditeHermit: just remove that line too
EruditeHermit: and remove the EXA line too
rob-84x^: ok, so I'll connect monitor to the dvi output, reboot my machine and I'll try that
rob-84x^: (withouth anything connected to the vga output)
EruditeHermit: ok
EruditeHermit: hmm
EruditeHermit: wait
EruditeHermit: the syntax is
EruditeHermit: Option "Monitor-DVI-0" "Configured Monitor"
EruditeHermit: instead of what I had "Monitor-LVDS"
EruditeHermit: if that fails
EruditeHermit: try this config
EruditeHermit: http://rafb.net/p/VB7pRd97.html
rob-84x^: it has already failed with: 1) your xorg.conf 2) without Option "Monitor-LVDS" 3) replaced with "Monitor-DVI"
rob-84x^: I have Xorg.0.log for all of these
rob-84x^: EruditeHermit: the fourth configuration, I should try, is this: http://rafb.net/p/VB7pRd97.html ?
EruditeHermit: yes
EruditeHermit: that forces the DVI output on
EruditeHermit: according to this document
EruditeHermit: http://wiki.debian.org/XStrikeForce/HowToRandR12
EruditeHermit: section III.4
EruditeHermit: if this config fails
EruditeHermit: you can try reading the document in detail
EruditeHermit: and looking at the example config and take elements that you need from it
EruditeHermit: like forcing outputs on
EruditeHermit: and naming conventions for outputs
rob-84x^: EruditeHermit: the fourth one failed
EruditeHermit: hmm
EruditeHermit: well
rob-84x^: I'll post the log file in a moment
EruditeHermit: ok
rob-84x^: EruditeHermit: Xorg.0.log for your xorg.conf: http://rafb.net/p/ivfDQ820.html
EruditeHermit: rob-84x^: what version of the radeon driver are you using?
rob-84x^: ati-dri 7.2-1
rob-84x^: from archlinux package repository
rob-84x^: Xorg.0.log for config with "Monitor-DVI" option: http://rafb.net/p/95Qiz488.html
EruditeHermit: errr
rob-84x^: sorry, it's xf86-video-ati 6.9.0-6
EruditeHermit: ok
EruditeHermit: can you try 6.10.0?
rob-84x^: i can give it a try...
EruditeHermit: I dunno if there are archlinux packages for that
EruditeHermit: or if you have to compile it yourself
EruditeHermit: other than that
EruditeHermit: I really don't know
rob-84x^: EruditeHermit: and that's the log for the fourth configuration, you have suggested: http://rafb.net/p/5GPRkr28.html
rob-84x^: (if that matters)
EruditeHermit: (II) RADEON(0): I2C device "DVI-0:ddc2" registered at address 0xA0.
EruditeHermit: (II) RADEON(0): I2C device "DVI-0:ddc2" removed.
EruditeHermit: it registers it and removes it immediately
EruditeHermit: don't know if that is supposed to happen
rob-84x^: (btw, I'm using vga -> dvi adapter. my monitor has vga cable only. so I'm using adapter to connect it to the dvi port in my radeon. that doesn't matter, does it?)
EruditeHermit: yes it does
EruditeHermit: that is probably the reason
EruditeHermit: well
EruditeHermit: it could be a reason
EruditeHermit: do you not have any DVI cables?
rob-84x^: no
rob-84x^: I don't have any
EruditeHermit: can you borrow one from someone?
EruditeHermit: or get hold of one
EruditeHermit: it would be worth trying
rob-84x^: I would have to borrow the monitor, right?
EruditeHermit: oh
EruditeHermit: the problem could be that it is not detecting the correct change in impedance that it is expecting from the cable/monitor
EruditeHermit: so it never turns the output on
EruditeHermit: i really dont know
EruditeHermit: oud be best to come back and ask someone else
EruditeHermit: i'm sorry
rob-84x^: EruditeHermit: thanks for your great support anyway!
rob-84x^: :(
EruditeHermit: i think its beyond me
rob-84x^: I've just tried 6.10.0 radeon driver from git repository -- still all the same result
rob-84x^: and I've also tried that the monitor on dvi port works on ms windows
rob-84x^: via that vga -> dvi adapter
soreau: Can you restate your problem?
rob-84x^: soreau: I have radeon 9550 on GNU/linux (archlinux distribution). I can't get a monitor working on the dvi port.
rob-84x^: soreau: my Xorg.0.log is here: http://rafb.net/p/ivfDQ820.html
soreau: So you have the primary vga monitor working and the second monitor is dvi which does only shows a black display?
rob-84x^: soreau: in general I'd like to setup a dual-head configuration, but the problem is that I can't get the dvi port working
rob-84x^: soreau: I'm trying to get dvi working as the only display for the beginning, to isolate the problem
soreau: What does xrandr say with both monitors connected?
rob-84x^: soreau: it allways shows that dvi is in disconnected state
rob-84x^: always*
soreau: Are you trying to use MergedFB by chance?
rob-84x^: soreau: no... nothing like that
rob-84x^: soreau: should I try that?
soreau: no..
soreau: I don't know what the problem might be though
stoned: hey guys, where can I find out which chipset a particular ATI card uses
stoned: like a list of em
apol: in a debian sid, what x.org driver should i use for an ati radeon 3450?
apol: the problem is that whenever i try another driver different than vesa i don't get a device found
adamk: stoned, Wikipedia has a pretty good list.
stoned: ok cool
yangman: stoned: http://wiki.x.org/wiki/Radeon%20ASICs has a listing extracted from fglrx's supported list
adamk: stoned, http://en.wikipedia.org/wiki/Comparison_of_ATI_Graphics_Processing_Units
stoned: thanks
MrCooper: apol: xserver-xorg-video-radeon(hd); no device found indicates the driver doesn't support the card (yet)
apol: MrCooper: yep, I've decided to install fglrx, it's working pretty well
apol: i'm looking forward to use radeonhd at some point, though
MrCooper: cool, but this channel happens to be about neither of those :)
apol: well, when i said radeonhd i meant any free driver
stoned: apol, as I mentioned, in order to use radeon driver for 3D on your gfx card you require xorg 7.4, mesa/dri from git as well as the radeon driver built from git
stoned: you can try the packages in debian experimental if you are on sid. add an repository for experimental and aptitude -t experimental install xserver-xorg
stoned: apol, I don't know the quality or the stability of those packages, but you an try them
apol: stoned: yep, recorded. i'll try it asap (exams soon :P)
mlankhorst: Just wondering, does gallium3d require anything from the kernel?
mlankhorst: A port of r7xx to gallium sounds kind of interesting
oga: mlankhorst: yes. the drm.
oga: same as "traditional" mesa does.
mlankhorst: Yeah, but is the drm different for gallium3d?
benh: agd5f: heya !
benh: agd5f: so this weird PCIe problem seems to be fixed by updating the FW on the embedded board
agd5f: benh: hey
agd5f: benh: nice!
benh: agd5f: some magic internal setting of the PCIe host bridge is wrong in the old FW or something
benh: agd5f: yeah, I'll see how 3d works later today or next week
agd5f: cool. glad it works :)
airlied: mlankhorst: gallium3d would prefer a real memory manager
airlied: benh: nice.
mlankhorst: Yeah, it sounds like an interesting project though
mlankhorst: too bad linux has a chronic amount of suck with regards to documentation
airlied: it always been questionable that documenting more would get more developers involved.
airlied: i.e. what the return on investment is.
mlankhorst: Yeah
airlied: really nobody starts working on X or DRI from the highlevel architecture and tries to understand it all.
airlied: most people pick a bug or small feature, fix that, then work their way outwards.
airlied: and maybe 20 years lateer one person understands how it all works.
mlankhorst: hehehe
mlankhorst: So I should start at a mesa r7xx driver?
mlankhorst: drawing triangles at light speed, instead of 1 at a time :X
rnoland: airlied: i resemble that remark....
rnoland: hell, all i ever intended to do was help anholt out some....
airlied: a gallium3d driver is probably a bit big as an initial project, like MostAwesomeDude is now looking at crazy llvm/gallivm stuff he probably would never have jumped straight inito
mlankhorst: hmm
airlied: but he started with the r500 frag shader and worked his way up.
mlankhorst: so what would be something more workable?
MostAwesomeDude: airlied: I'm still regretting biting off that much.
mlankhorst: r7xx frag shader?
mlankhorst: :P
MostAwesomeDude: So should I be emitting the same kind of state that we've got going right now in Mesa? Should I be using GEM only, or be making the dual-path thingy?
airlied: mlankhorst: it might be possible to do some r600/r700 mesa work, I think there might be a tree somewhere already, but I'm not sure.
mlankhorst: dunno
mlankhorst: not that hard to publish a git tree
airlied: mlankhorst: I think its probably the docs from AMD are needed first
mlankhorst: Yeah, I'm sort of waiting for that
soreau: So what's the status of dri2? What more needs to be done?
airlied: memory manager + fix bugs in glisse code.
soreau_: ugh wth
agd5f: mlankhorst: the sample code in r600_demo should be all you need to start on a 3D driver
agd5f: it has pretty much everything documented. that said, we should have a register guide to accompany it soon
mlankhorst: Hmm
mlankhorst: updates his xorg build again
soreau: So what's the status of dri2 and what more needs to be done to get there, on r350 for instance?
mlankhorst: Does KMS already work for r7xx?
airlied: mlankhorst: it probably needs some patches for the dce32 stuff
oga: r7xx is ATOM, right?
airlied: soreau: glisse had something that ran then crashed.
airlied: oga: yes
oga: unless they changed the format I presume that makes things mostly easier?
airlied: soreau: I've been trying to get it running again pre-xmas but won't get back to it until next week.
airlied: oga: they just add new interfaces to it
airlied: oga: I've already implemented them in the userspace driver
oga: so if you support the new interfaces, modesetting works/
airlied: I just haven't had time to make sure all the changes went back.
oga: handy. that's a good thing about ATOM.
soreau: airlied: What does it need though? Memory manager?
soreau: or it already is possible to get it working, it just needs to be done..
airlied: soreau: it should run on top of the kms tree.
MostAwesomeDude: airlied: Any opinion on how I should be holding state? Should I have the GEM-only interface, or do the dual-path setup?
oga: MostAwesomeDude: for gallium?
MostAwesomeDude: Yep.
oga: don't bother with the old interface.
oga: honestly, just don't.
MostAwesomeDude: No, for CS.
airlied: MostAwesomeDude: don't bother with that either
oga: IMHO memory management obsoletes what came before.
airlied: MostAwesomeDude: you can look at the glisse bo-cs
airlied: which does a legacy + gem path
soreau: airlied: Well I'm looking forward to it :)
MostAwesomeDude: airlied: That's what I've got pulled up. So I should go ahead and switch between the two... So glisse's winsys has the GEM path, should I just augment that with the non-GEM path?
MostAwesomeDude: And then from pipe, just submit BOs for winsys to handle?
mlankhorst: Just wondering, does gallium3d take the gem path?
airlied: I'd ignore the non-gem path
mlankhorst: or a new path altogether
airlied: mlankhorst: if you don't have legacy BO you can't have legacy CS
airlied: oops worng person
airlied: MostAwesomeDude: ^^
mlankhorst: ponders what a cs is
MostAwesomeDude: CS is command submission; BO is buffer object.
mlankhorst: ah
mlankhorst: bo I figured out
MostAwesomeDude: So do I put all state into BOs? When do I need to reloc stuff? Should I just stare at the bo-cs Mesa for a bit longer?
airlied: MostAwesomeDude: relocs happens in the kernel
MostAwesomeDude: Well, there's some EMIT_RELOC or whatever here. I'm guessing that I only have to indicate relocs for textures, yeah?
airlied: MostAwesomeDude: you emit relocs for any buffers
airlied: MostAwesomeDude: color/depth/texture/fbo/vbo
MostAwesomeDude: Ah. The more I think about it, the more it makes sense.
airlied: you emit a reloc for the bo of the buffer you are referencing
MostAwesomeDude: So should I do like nouveau and have a big bundle of state objs which "know" how to emit themselves, or should I break it down into derived, dynamic, immediate, like the i915?
spstarr_work: airlied: When do you anticipate DRI2 testing for me (reads /scroll above ->
airlied: spstarr_work: in theory rawhide has most of it I think, it doesn't work though.
spstarr_work: ok
airlied: I should get back to it in a week or two
spstarr_work: then i'll switch to rawhide, I had a successful install of it in VirtualBox using F10 anaconda
agd5f: MostAwesomeDude: anything that writes a base address needs a reloc
MostAwesomeDude: agd5f: Yeah, starting to get it. Didn't originally see what it had to do with DLL-style relocs, but I think I've got it now. Ish.
agd5f: you're dealing with handles in the driver rather than addresses now
MostAwesomeDude: Right. Instead of drawing to a statically allocated buffer, I'm drawing to DA FRAMEBUFFER, and it's the kernel's problem, not mine.
MostAwesomeDude: Hm. I suppose that I need to init every part of the 3D engine in order to do a trivial clear. :C
ndim: shows MostAwesomeDude the bus reset line.
ndim: :-D
mlankhorst: rePOSTs MostAwesomeDude
MostAwesomeDude: ndim, mlankhorst, talking about progs/trivial/clear.
MostAwesomeDude: Very first target.
agd5f: MostAwesomeDude: could use the 2d engine
ndim: MostAwesomeDude: Of course. I should stop making stupid jokes when I'm not actually contributing code.
MostAwesomeDude: agd5f: I could. I'm supposed to be able to blit; any pointers or should I stare at Mesa some more?
agd5f: MostAwesomeDude: a solid fill
MostAwesomeDude: agd5f: As in, the thingy at the beginning of the r5xx docs?
agd5f: MostAwesomeDude: like EXA solid()
MostAwesomeDude: Ooh. 'k.
MostAwesomeDude: has an inkling!
agd5f: just draws a solid rectangle
agd5f: dst, x/y, w/h, color
glisse: MostAwesomeDude: would be nice if you push your code somewhere, i want to spin gears with gallium tomorrow :)
glisse: well anyway it's already tomorrow i should get some sleep
spstarr: glisse: im excited to try your dri2 stuff :)
glisse: spstarr: i will get back to that next week too, i want to have a solid userspace the sooner
spstarr: airlied: It's been several weeks and I've remained in KMS
glisse: so we can test and change kernel API and be ready for 2.6.30 merge
spstarr: airlied: now once we optimize stuff, this will be super fast, but at least there's absolutely no corruption now
spstarr: glisse: .30 seems aways off
Terman: spstarr: probably 2-3 months until the merge window opens
glisse: spstarr: no way we do 2.6.29, we have not tested the API enough and beside the code is far from being what we can decently ask to merge
glisse: anyway zzzzZZZZzzzz
chithead: put it in linux-next so visibility of the kms patches is increased
Terman: spstarr: soa nice long time window where you can test bleeding edge code and find undiscovered bugs
spstarr: thats where us testers come in
MostAwesomeDude: glisse: Absolute minimum stuff is on gallium-0.2-radeon on my mesa repo. There's nothing there yet.
soreau: With xv video playback and compiz, the video does not move with the window when moving it. Does this mean I need to set TexturedVideo off?
revx: MostAwesomeDude: what chipset are you working with on that?
soreau: Or better yet, how do I get xv to use textured video?
airlied: MostAwesomeDude: just use the clear state from the driver.
airlied: chithead: -next is for stuff we know the API works.
spstarr: 2009 will be the year of the Radeon :)
revx: spstarr: don't jinx it like what happened with 2008 :P
spstarr: 2008 wasn't bad
spstarr: airlied pulled it out near the end :)
stoned: MostAwesomeDude, hi!
MostAwesomeDude: stoned: Hey.
stoned: how are you doing? long time no see
stoned: (cuz I haven't been here)
stoned: hehehe
MostAwesomeDude: I'm alright. Workin' on code that hurts my head.
soreau: Ok, figured that out. Now can anyone point me in the direction for /etc/drirc?
stoned: MostAwesomeDude, good luck and thank you
soreau: Sorry, I guide for options to be put in /etc/drirc I mean
soreau: s/I/a
stoned: MostAwesomeDude, I hope you to feel better soon
soreau: MostAwesomeDude: My head hurts too ;)
kdekorte: #radeonhd
stoned: owwwwwwwwwwwww
stoned: i cut my lip on my tooth
stoned: owww
stoned: ohhh it hurts
MostAwesomeDude: Oooh, okay. Just popped open the modesetting-gem libdrm, and now it kinda makes sense. So instead of a batchbuffer, I want to have a radeon_cs_manager, and then I create radeon_cs, stuff it full of goodies, and then submit it.
chithead: soreau: check with xvinfo whether textured video is supported by the driver, and then explicitly use mplayer -vo xv:port=
MostAwesomeDude: So how do I decide what a good size is for these? Obviously I can have as many cmdpackets as I want in a row... Should I just group them logically according to which state objects they track?
soreau: chithead: Yea, I got that part thanks
MostAwesomeDude: So one BEGIN, some WRITEs, and one END, for scissor, stencil, rs, sc, ga, gb, etc?
soreau: chithead: Now I'm trying to figure out what to put in /etc/drirc to get AA working
airlied: MostAwesomeDude: yup, 16k or 64k is probably big enough, depends on the total state siz
MostAwesomeDude: airlied: I assume that there's enough overhead per CS packet to form some sort of "sweet spot", yeah? That could come later.
airlied: MostAwesomeDude: ideally the state + drawing for a full scene in one packet.
MostAwesomeDude: airlied: If that's the case, maybe I should do like intel and allocate one cs packet, then attach it to the context and just append to it using BEGIN, WRITE, RELOC, END, etc.?
airlied: MostAwesomeDude: pretty much what you want to do I think
MostAwesomeDude: Which is, by no coincidence, a *lot* simpler.
airlied: MostAwesomeDude: I prefer the intel state handling to the radeon stuff
MostAwesomeDude: :)
MostAwesomeDude: airlied: Yeah, no more atoms.
airlied: the 965 driver in mesa is a lot nicer at state handling than the atom code
MostAwesomeDude: Indeed. This is our chance to "do it right," as it were.
MostAwesomeDude: But first, dinner.
ssieb: airlied: are you there?
ssieb: thinks he has an idea what airlied's time zone is and guesses he's most likely not here :-)
MostAwesomeDude: ssieb: He's in AU.
ssieb: really? why is his hostname in .ie?
MostAwesomeDude: I dunno. What's .ie?
ssieb: was pretty sure that was ireland...
ssieb: but I guess hostnames really don't necessarily correspond to what country they are in anymore
MostAwesomeDude: Hm. Well, I *thought* he was in Australia.
ssieb: heh, yay for the internet where you really don't care where someone lives :-P
ssieb: except when trying to arrange meetings across time zones...
MostAwesomeDude: That's what IRC is for. :3
ssieb: well, if he's in ireland, it will be many hours before he's back, if it's australia, he's probably around :-/
ssieb: is it just airlied that would be dealing with an X hang in the radeon driver or is there anyone else?
ssieb: MostAwesomeDude: any ideas?
enouf: well .. i guess you could install the xserver-xorg-core-dbg pkgs and one for radeon? (xserver-xorg-video-radeon-dbg ?)
MostAwesomeDude: ssieb: I am largely useless today.
enouf: i'm largely useless most of the time :-P
enouf: concerning video drivers, that is ;-)
ssieb: the hang goes into the kernel drm though
enouf: and install gdb too
enouf: then start gdb and launch X?
ssieb: has done all that and has stack traces, etc.
MostAwesomeDude: ssieb: Reproducible?
ssieb: 100%
enouf: oh. ok - good boy :-)
ssieb: :-P
MostAwesomeDude: Filed a bug?
ssieb: there are several
enouf: well, you're ready to post info - aye
MostAwesomeDude: Describe how to hang.
ssieb: I've tried tracking it into the kernel source, but got a little lost... too many macros :-)
ssieb: I also have some strace info that I should analyze
MostAwesomeDude: No, I mean, what do you do to cause the hang?
ssieb: oh, missed your question. take a gimp picture window and put it under another window. if you then move it so that more of the picture becomes visible, it will hang instantly
ssieb: this is using EXA, using XAA I can't get an exact method of reproducing it, but my wife keeps hitting it using facebook :-(
MostAwesomeDude: Hm. And which chipset?
ssieb: RS690 onboard
MostAwesomeDude: Ew, icky. Sounds like glisse territory.
ssieb: I just looking for someone who cares about it and can tell me what info they need to track it down...
airlied: ssieb: awake but on baby duty. in .au, irc client hides in .ie
ssieb: airlied: did you read back? any comments?
ssieb: airlied: I'm around for 2 more hours if you get a chance
spstarr: set_priority(airlied, BABY_DUTY, TASK_UNINTERRUPTIBLE);
ssieb: :-)
ssieb: has four kids and understands...