airlied: finding out why EXA dies without kms is probably something to investigate first.
spstarr: i can get you some debug now if you like, easy to reproduce
airlied: I'm not sure what to debug.
airlied: it sounds like a lockup that looks like every other lockup
spstarr: the gpu dying :)
spstarr: its basically, a stalemate, without knowing what is triggering the crash one can't know which errata fix to use
spstarr: :/
spstarr: airlied: basically, write off r3xx,r4xx and start anew with r5xx+ as being done now :)
airlied: spstarr: I think I'll just write-off AGP :)
spstarr: heh
airlied: my rv370s are working great.
spstarr: sorry 'AGP r3xx,r4xx'
airlied: I'm running compiz on my X600 and everything.
spstarr: i donno if r5xx comes in AGP flavours i think they do
airlied: you can get AGP r500 and 600s
spstarr: even the r6xx has some AGP boards?
spstarr: oh fun
spstarr: yeah if you try to use an amd agp card, X starts up and you get a sad frown smiley, and nothing happens further ;)
tlp: just ordered an AGP r5xx
spstarr: tlp ;)
terracon: I thought they made agp versions of most of the newer ones
tlp: No systems with PCIe yet :p
terracon: Saphire Radeon HD 3850 512 agp
spstarr: AGP won't die yet..as much as it should
terracon: Saphire HD 2600 pro 512 agp
terracon: Saphire X1650pro 512 agp
spstarr: terracon: i don't think you're making airlied happy by showing those ;) (even if he knows)
terracon: asus AH3650 silent 512 ddr2 agp
tlp: I bought an X1650 Pro 512 AGP, dunno if it's Saphire.
terracon: Just looking at http://www.infonec.com/site/main.php?module=catalog&catID=1160
terracon: I usually buy my stuff from there
spstarr: has a PCIE HD 3650 which will be tested when kms is enabled
spstarr: PCIe
terracon: what R** is 3850
agd5f: terracon: r6xx
agd5f: 4xxx are r7xx
terracon: spstarr's dream of agp dying a quick death isn't going to plan
agd5f: I think we'd all like it to die...
airlied: agd5f: we should look at the Ubuntu quirk patch at some point.
tlp: it is mostly gone from new systems, no?
airlied: it might be worth just quirking and running at this stage
agd5f: airlied: yeah
airlied: granted I still think we have bugs with EXA we'll need to chase down.
agd5f: yeah
spstarr: ubuntu made fixes?
agd5f: spstarr: a table of problematic agp card/bridge combos and the preferred agp mode
agd5f: it's attached to one of the agp bugs. I really should try and get it merged
airlied: http://patches.ubuntu.com/x/xserver-xorg-video-ati/extracted/100_quirk_system.patch
spstarr: i can certainly give it a try
spstarr: looks at code
spstarr: airlied: but we tried AGP 0x with radeon.agpmode=-1 (I assume just sets to no accel agp mode?)
spstarr: + /* Intel 82852/82855 host bridge / Mobility 9600 M10 RV350 Needs AGPMode 1 (deb #467460) */
spstarr: + { PCI_VENDOR_INTEL,0x3580, PCI_VENDOR_ATI,0x4e50, 0x1025,0x0061, 1 },
spstarr: that one is against me
spstarr: though not intel
spstarr: somehow I am very skeptical of that patch
agd5f: spstarr: -1 means PCI mode
spstarr: yeah and we have it lock up in PCI mode
spstarr: when using kms, i didnt try that in non-kms with exa
agd5f: non-kms it's Option "BusType" "PCI"
spstarr: i can give that a try to fallback to PCI and see if i wedge this
spstarr: easy to try now
spstarr: (**) RADEON(0): Forced into PCI mode
spstarr: and now we try to get it to crash...
spstarr: there is some text glyph corruption
spstarr: no crash yet.. trying things that would usually trip it
agd5f: spstarr: you can probably fix the corruption by disabling DFS
spstarr: can turn that off after sure
spstarr: is it possible this *all* could be with .. AGP? :P
spstarr: i wonder if i try to enable composite after...
spstarr: first try to get EXA to crash
spstarr: so far, nothing
agd5f: AGP is made of fail
spstarr: perhaps just force PCI mode for all r3xx, r4xx AGP chipsets
spstarr: ;)
spstarr: tries composite and VT switch for fun
spstarr: in composite
spstarr: vt switch....
spstarr_desk: *zap*
spstarr_desk: X is in a loop
spstarr_desk: [19745.409012] [
spstarr_desk: [19745.409012] [
spstarr_desk: [19745.409012] [
spstarr_desk: top call is do_IRQ
spstarr_desk: gdb says
spstarr_desk: assuming i can attach
spstarr_desk: wedged
spstarr_desk: although i can kill X
spstarr_desk: on disabling composite
spstarr_desk: the usual
spstarr_desk: #0 0x0806c029 in dixLookupPrivate (privates=0xa080b18, key=0x65b570)
spstarr_desk: at privates.c:135
spstarr_desk: rec = (PrivateRec *) 0xa35bea8
spstarr_desk: ptr =
spstarr_desk: #1 0x00654e0e in DRIGetDrawableInfo (pScreen=0xa0809c8, pDrawable=0xa080a68,
spstarr_desk: :/
airlied: wierd it gets stuck doing getparams...
spstarr_desk: I don't know what the drm routines each do
spstarr_desk: now that its trashed my other virtual terms, reboot..
MostAwesomeDude: My laptop's got to go into the shop. This is an ideal opportunity to tell my teachers, "Hey, my laptop's in the shop."
MostAwesomeDude: And then stay home and work on r3xx fogcoords. :3
spstarr: back to PCI + exa - no accel DF - no composite
spstarr: need to try to get this to crash
MostAwesomeDude: spstarr: It just occurred to me that you get lots of crashes and locks, but I only ever have problems when I mess up RS writes.
MostAwesomeDude: Is there something quirky about your card?
spstarr: its a M10 9600 mobile
MostAwesomeDude: "mobile" explains all. :3
spstarr: unless IBM futzes with something
spstarr: RS ?
airlied: MostAwesomeDude: he uses KDE :)
spstarr: airlied: gnome crashes it too enough :p
spstarr: you can't blame a DE
spstarr: MostAwesomeDude: which chip do you have in the r3xx series
airlied: if everyone would just use GNOME then I'd have fixed the problem before they get to them :)
spstarr: thats just masking bugs ;)
spstarr: I do that enough @ work :(
spstarr: lack of resources
MostAwesomeDude: airlied: I've got KDE!
spstarr: MostAwesomeDude: WHAT
spstarr: MostAwesomeDude: 4.x? with composite eyecandy?
MostAwesomeDude: spstarr: No, I don't hate myself that much.
spstarr: AGP or PCIe
MostAwesomeDude: spstarr: An X700 and an X1950.
spstarr: ok, modern ;p
MostAwesomeDude: (Neither of which are technically R3xx...
spstarr: airlied: suppose I cannot get exa to lockup with PCI mode...
MostAwesomeDude: Hm. Anybody know what's missing under "mostly" with r5xx tex and shader core?
airlied: MostAwesomeDude: mostly where?
MostAwesomeDude: airlied: In the RadeonStatus page.
MostAwesomeDude: http://wiki.x.org/wiki/RadeonFeature
MostAwesomeDude: Or RadeonFeature, whatever.
MostAwesomeDude: I'm pretty sure we're using every HW inst in the shader core, since I pushed the DDX/DDY code.
airlied: I think its just bugs fixin.
MostAwesomeDude: Hm.
MostAwesomeDude: I think the only outstanding FP bug is...
MostAwesomeDude: *drumroll*
MostAwesomeDude: ...FOG COORDS!
airlied: someone needs to fix that :)
MostAwesomeDude: Hm.
MostAwesomeDude: 'k, so my current knowledge.
MostAwesomeDude: Setting up the FF pipeline appears to work with the Mesa default shader.
MostAwesomeDude: Setting up the VPS pipeline and splitting a color works with the fog HW.
MostAwesomeDude: fragment.fogcoord, however, *never* works. :3
MostAwesomeDude: Oh, and no attempt has successfully rendered progs/tests/fogcoord AND progs/demos/fogcoord.
MostAwesomeDude: What about textures? What texture features are we missing?
spstarr: fog
spstarr: I see snow, you look at fog :)
airlied: MostAwesomeDude: tiling
MostAwesomeDude: airlied: Oooh, yeah. Forgot about that.
MostAwesomeDude: Isn't it just a register we set, and then we have to make sure we tile all our textures when we upload them?
airlied: pretty much... the second bit is the hard part.
MostAwesomeDude: Hm. Can't Mesa tile stuff for us?
MostAwesomeDude: Seems to me like that kind of thing should be a utility function, rather than per-driver.
MostAwesomeDude: Hm, do *any* Mesa drivers tile?
MrCooper: define 'tile'
airlied: MostAwesomeDude: don't think we have tiled teextures anywhere else.
MostAwesomeDude: Hm.
airlied: we have tiled buffers
MostAwesomeDude: Hm.
MostAwesomeDude: Okay, so the hard part is zero-copy tiling, right? Making sure that stuff gets tiled as it gets copied to the card.
airlied: there is an open bug on it, the patches got messy :)
MostAwesomeDude: But single-copy tiling should be easy.
airlied: it'll all change with bufmgr also.
MostAwesomeDude: Oh.
MostAwesomeDude: should get a GEM kernel so he can get occlusion queries figured out
MostAwesomeDude: I just wish I knew why FF vertices work and VPS vertices --
MostAwesomeDude: Wait.
MostAwesomeDude: Fragment programs read inputs from RS. RS reads them from VPS output memory, which is formatted for RS.
MostAwesomeDude: But if everything comes in FF-style, RS is re-programmed according to FF.
MostAwesomeDude: So what if fog coords are already sitting in fragment memory, at the same damn FF position...
MostAwesomeDude: XD, BRB.
MostAwesomeDude: Okay.
MostAwesomeDude: So. Why are there 16 texture slots in RS?
MostAwesomeDude: I guess I'm not quite understanding how RS reads stuff from vertex output memory and writes the fragment stack.
spstarr: rubs eyes... RS, XD, FF, VPS, FP, DDY, NSN :)
spstarr: NSN = Need Sleep NOW!
MostAwesomeDude: Rasterizer, smiley, fixed-function, vertex programmable shader, fragment program, derivative with respect to y.
MostAwesomeDude: Okay, here's what I've figured out.
MostAwesomeDude: Setting the vertprog and swtcl code to always use the (correct)
MostAwesomeDude: FF slot for fog coords seems to yield correct results when fog is done in HW; that is, when Mesa's not generating internal stuff with fragment.fogcoord.
MostAwesomeDude: Which leads me to believe that we need to tell RS to do something with fog, and we're simply not doing it.
MostAwesomeDude: I'm going back over the entire r3xx 3D register set right now, but I think that it's something non-obvious. I find it really hard to believe that we're required to do something as ugly as SW TCL color splitting.
MostAwesomeDude: Much more likely that we need to tell RS in a special way to take fog coord and rasterize and make available to FP.
MostAwesomeDude: ...Wait. FOG_DEPTH_SRC (4bd8) says that depth can "come from shader as four discrete values."
MostAwesomeDude: Which shader is that? We've just kind of assumed that it's been fragment shader...is it vertex shader?
airlied: yup vertex
airlied: I would expect color splitting in swtcl
airlied: it what we do in other drivers I think.
MostAwesomeDude: Hm.
MostAwesomeDude: Found something. :3
MostAwesomeDude: W can be enabled in RS.
MostAwesomeDude: W_EN if we need to generate W (faked fog coords for fragment.fogcoord), W_ADDR is where the fog coord comes from in FF memory?
airlied: from the VP
MostAwesomeDude: Right, but for now, I'm kinda forcing that to 14 (the FF fog slot).
MostAwesomeDude: It's just that we're not setting any of these at all, and we probably should.
airlied: revenge traces from a swtcl machine might help :)
MostAwesomeDude: I've already upgraded all my boxes and lack the patience (and chicken bones) required to downgrade them and get fglrx working. :3
MostAwesomeDude: 'Sides, it's more fun this way.
airlied: hhehe me too..
MostAwesomeDude: Hm. I'm sure those regs have some kind of usage.
MostAwesomeDude: Sleep time.
glisse: hates zbuffer
matlec: can anyone give me a hint how monitor hot plugging is implemented?
matlec: don't find much on this topic in google
glisse: matlec: on dvi connector we can get an irq
glisse: otherwise we have to probe the output
matlec: glisse: you mean polling?
matlec: or do you get any event?
glisse: matlec: well it's up to who is in charge to decide to poll or not but better not poll as this is a costly operation
glisse: we don't get any event
glisse: os like osx probe output every sec i think
matlec: what about the radeon impl?
glisse: linux is about policy, policy is in userspace :)
matlec: :) so where to control the probing mechanism? :-)
glisse: well gnome probe way too often i think there are some randr new feature slatted to make probing more consistant in X world
matlec: hm, ok.. can you give any hint where probing is implemented in radeon?
glisse: in ddx it's a pretty straightforward name like prob* somethings
matlec: thanks, glisse
MrCooper: glisse: GTK+, not GNOME, and this was disabled again in the current stable release
glisse: MrCooper: thanks to remind me, i am definitly ignorant in userspace world :)
agd5f: MostAwesomeDude: you can swizzle the RS inputs and the PVS outputs however you want for tcl hw
agd5f: also there are 16 texture addressers, however you can only use 8 at a time
glisse: agd5f: did you ever tested r300-bufmgr ?
glisse: if so were no tcl path broken regarding color ?
agd5f: glisse: I haven't played with that yet
MostAwesomeDude: XD, looks like it's safe to dynamically allocate RS instructions.
MostAwesomeDude: Can't figure out how to get fog into W and get it routed, so just going to use a rasterizer inst.
MostAwesomeDude: So, unfortunately, can't use all 8 textures && 4 colors && fog on < r5xx, but OTOH only 8 RS insts means that we've always gotta make choices.
agd5f: MostAwesomeDude: you actually get 16 RS instructions on r5xx
agd5f: 8 on r3xx and r4xx
spstarr_work: looks around
spstarr_work: agd5f: at this point i might have to concede defeat and use fglrx for r3xx :/
MostAwesomeDude: agd5f: Yes, but I'm doing the r4xx one first since that's what happens to be in the workstation ATM.
MostAwesomeDude: I was playing StarCraft a few nights ago, needed HW accel. :3
agd5f: MostAwesomeDude: are you settin W_ADDR in RS_COUNT?
agd5f: W_COUNT too for that matter
MostAwesomeDude: agd5f: That's what I was playing around with, yeah, but it does nothing.
MostAwesomeDude: Unless I'm not reading it from the right place. The docs have *no* hint as to where W gets written by RS.
agd5f: I don't think it gets written anywhere. it's just used for coordinate transforms I think
MostAwesomeDude: Well, and perhaps for HW fog, but that's not useful for fragment fog, which is what Mesa desires.
agd5f: MostAwesomeDude: so the per-vertex fog coordinate transforms the resulting color that gets written to the render buffer right?
agd5f: so pass the fog coord as a color to the FS and then do the math in the FS
spstarr_work: jcarlos_: which DDX, Xorg and kernel
glisse: agd5f: i think it's better to let the fog stage do the math as this is likely faster :)
spstarr_work: jcarlos_: assuming Fedora patches have broken r3xx :)
jcarlos_: spstarr_work: One moment
spstarr_work: jcarlos_: and which Mesa
jcarlos_: spstarr_work: All from debian unstable
spstarr_work: versions plz
jcarlos_: spstarr_work: OK
jcarlos_: spstarr_work: Shit ... I cannot tell you now ... My laptop is turn off ... :-(
agd5f: glisse: but it doesn't seem like the fog hw handles per vertex fog
jcarlos_: jcarlos_: Wait a moment ... searching in the web ...
jcarlos_: spstarr_work: xserver->1.4.2
spstarr_work: 1.5.2 here
jcarlos_: spstarr_work: mesa->7.3
jcarlos_: 7.0.3
jcarlos_: spstarr_work: Kernel->2.6.26
spstarr_work: hmmm
glisse: agd5f: you have to route fogcoord to z unit
spstarr_work: jcarlos_: vt switch works?
spstarr_work: jcarlos_: EXA or XAA mode
jcarlos_: spstarr_work: Absolutely
spstarr_work: jcarlos_: which DDX
glisse: agd5f: if fragprog doesn't write z
jcarlos_: spstarr_work: How can I get that ddx info ?
glisse: otherwise you have to do fog in fragprog
spstarr_work: jcarlos_: your xorg radeon driver deb package
jcarlos_: spstarr_work: 6.9.0
MostAwesomeDude: glisse, agd5f: I'm currently trying to pass fog in through to fragment shader. The recent Mesa changes mean that Mesa tries to do fog in FP whenever possible.
spstarr_work: jcarlos_: hmmmm
jcarlos_: spstarr_work: I have XAA mode now, but I think I also tried EXA mode ...
glisse: MostAwesomeDude: well i guess it's easier to always do fog in fp
MostAwesomeDude: glisse: IIRC that's how it'll be done in Gallium.
glisse: just slower
spstarr_work: jcarlos_: XAA works with composite ish... but please try EXA
spstarr_work: I used XAA last year with eyecandy and it was 'ok' even suspending/resuming
spstarr_work: with some corruption here and there in the composite image
jcarlos_: spstarr_work: I cannot try now ... I have no access to my laptop ... in two hours I can try
spstarr_work: thanks
spstarr_work: airlied: more AGP r3xx/r4xx are coming out to tell me lockups with kms random freezes.. with/without compiz enabled
spstarr_work: such badness
agd5f: glisse: is there a way to route fragment shader to Z unit?
spstarr_work: i donno how much the AGP quirk patch will do for me if anything given i wont have any matching IDs in that list
agd5f: spstarr_work: yes there still appears to be issues with the kms drm and agp at a lower level than that patch
spstarr_work: agd5f: indeed
spstarr_work: agd5f: i assume the gpu will wedge if you don't complete a command in a certain sequence expected?
spstarr_work: i see airlied added some COMMIT_RING()
spstarr_work: so you have to send the command sequence to the gpu as a 'packet' ?
spstarr_work: then commit the written instructions to registers
agd5f: that just flushes the ring
spstarr_work: ring == buffer?
spstarr_work: or a queue
agd5f: a ring buffer
spstarr_work: ok
agd5f: spstarr_work: read chapter 4 of the r5xx accel guide
agd5f: same model applies to all radeons
spstarr_work: is that on xorg that guide?
spstarr_work: in /amd dir?
agd5f: yeah
spstarr_work: will look during lunch break
Alpo\: how do i enable exa with radeon driver?
oga: AccelMethod "EXA"
oga: in xorg.conf
Alpo\: didn't help me with my problem
Alpo\: i have no mouse cursor
spstarr_work: ive seen that one before :)
spstarr_work: get a new Xorg build?
jcarlos_: spstarr_work: Switching to VTs with the radeon driver and compositing activated (EXA mode) ...
jcarlos_: spstarr_work: Working fine
spstarr_work: ...
spstarr_work: !
spstarr_work: no lockups :(
jcarlos_: Nop
spstarr_work: airlied: i really wonder if Xorg 1.5 has done some serious damage, or some 'new' patches in Fedora have broken things badly
spstarr_work: jcarlos_: in kde or gnome?
jcarlos_: KDE 4.1
spstarr_work: !
spstarr_work: jcarlos_: can you enable/disable composite?
jcarlos_: OK
spstarr_work: does it crash ? (try it a few times)
jcarlos_: Composite off
jcarlos_: Working fine
jcarlos_: Switching VTs fine
spstarr_work: you're running sid?
jcarlos_: Compositing on again
jcarlos_: Working fine
spstarr_work: i wonder if i have enough swap partition space to install Debian on it
spstarr_work: to try
jcarlos_: Debian sid
jcarlos_: And KDE 4.1 from experimental
spstarr_work: or opensuse even just to see wtf is going on
jcarlos_: Only KDE from experimental
jcarlos_: No xserver 1.5 from experimental
jcarlos_: xserver 1.4.2
spstarr_work: unless 1.4.2 -> 1.5 broke X's GLX bits a lot...
spstarr_work: i have to suspect there is badness in Xorg 1.5 GLX
jcarlos_: I don't know ... all fine here ...
MrCooper: spstarr_work: even if most people are lucky enough not to lose the race, it's still there...
spstarr_work: MrCooper: we're assuming the race isn't introduced *in* Xorg 1.5...
spstarr_work: and not 1.4.2
spstarr_work: jcarlos_: which libdrm
MrCooper: pretty sure it was always there
spstarr_work: MrCooper: hmm
MrCooper: and I was never able to reproduce your problem even with xserver Git
spstarr_work: MrCooper: using Fedora?
MrCooper: nope, I'm a Debian guy
spstarr_work: i did not have problems with Debian composite either.. but i switched to Fedora (since Debian falls behind in technology or moves slow enough)
glisse: agd5f: yoou can write to Z from the fragshader but this involves a bit of different states
spstarr_work: MrCooper: my hope is the move to kms + Gallium will allow us to throw out the current muck, excluding the gpu specific bugs we may be encountering (errata problems)
jcarlos_: spstarr_work: One moment
spstarr_work: MrCooper: im very close to switching to fgrlx
spstarr_work: maybe just abandon r3xx, r4xx support DDX/DRI for AGP altogether
jcarlos_: spstarr_work: 2.3.1
spstarr_work: I wish AMD could give us code bits from fgrlx that program the GPU specifically, i don't understand the problem
spstarr_work: there's no IP in that, there's only one way you can program the GPUs (I think)
spstarr_work: barring someone reverse engineering the darn thing altogether to get it
glisse: MrCooper: is the screen resolution reported somewhere through dri1 ?
MrCooper: glisse: not sure offhand
glisse: wish i hadn't a dying hd
spstarr_work: glisse: time to dump disk data off it asap if not already
spstarr_work: is reminded his thinkpad HD is soon 4.5 years old
glisse: spstarr_work: it's dev machine i pushed bit to fdo, sadly i am use to dying hd
spstarr_work: heh
glisse: sights, dma are handled so badly....
airlied: spstarr_work: it might be newer kernels breaking stuff.
spstarr_work: airlied: it seems to be
spstarr_work: airlied: i will try new kernel + DDX tonight
airlied: try and old kernel :)
airlied: I wonder if 2.6.26 works better than .27
airlied: for composite or something like that.
spstarr_work: if this is all kernel related then i can continue to help you debug, since then it wouldn't be a GPU issue
spstarr_work: .26 had same problems
spstarr_work: .25 also
spstarr_work: im not sure on .25 now...
airlied: I'm just hearing rumours that .27 is worse than .26 for certain r300s.
spstarr_work: airlied: hmm
spstarr_work: i know for sure .26 i had the same locking problems
spstarr_work: i logged that bug back in may when we had .26 still
spstarr_work: lemme check
spstarr_work: worse
spstarr_work: kernel-2.6.25-14
spstarr_work: that might have had .26 patches though (from -mm if they got merged into .26)
spstarr_work: the same bug i can reproduce today
spstarr_work: https://bugzilla.redhat.com/show_bug.cgi?id=445331
spstarr_work: but the drm isn't showing me those locking errors anymore
spstarr_work: (so far)
spstarr_work: i think i was using XAA back then, but in EXA i can reproduce the same crash from X however
spstarr_work: airlied: with Nouveau reverse engineering the nvidia binary blob, why couldn't we with fgrlx in the same mannor they are doing?
spstarr_work: how are they dealing with any errata issues?
spstarr_work: aka Mmiotrace
airlied: spstarr_work: because you need a lot more than mmiotrace
airlied: we would need to get valgrind-mmt working again most likely.
airlied: and really fglrx isn't always much more stable :)
spstarr_work: heh
spstarr_work: but if it gets us any extra help
spstarr_work: airlied: its interesting because im on Nouveau now and for 31 days i had a stable DDX, only X is leaking somewhere (i'll update rawhide to replace Xorg bits)
spstarr_work: http://www.phoronix.com/scan.php?page=article&item=nouveau_40&num=2
spstarr_work: "instead valgrind-mmt can be used to trace user-space FIFOs."
spstarr_work: im guessing they use it
airlied: nvidia chips are a lot stabler.
spstarr_work: except the mobile ones that are melting? ;)
spstarr_work: hmm
glisse: balancing pin/unpin is horrible
airlied: glisse: in theory we could do them all in-kernel with kms.
airlied: I'm just not having much time to make it happen.
glisse: airlied: i am in mesa and glxgears fails after few secs when gart memory is ehausted because no previous dma is freed :)
glisse: got a log of pin/unpin of 41993 lines :)
airlied: glisse: oh lovely, sounds like missing reclaim stuff.
airlied: whats pinning/unpinnin?
glisse: mesa vertex array basicly AllocDmaRegion pin while release array unpin
glisse: add that cs pin relocated buffer and unpin once cs is executed
glisse: and you get a nice pin/unpin logs
glisse: i think i will shrink my gart size so i get a smaller log
glisse: others than that my bo/cs mesa seems to work with old style memory :)
airlied: mesa can't pin memory.
airlied: that ioctl needs restricting.
glisse: well it's not exactly pining i badly picked the work
glisse: word*
glisse: it's about making sure the memory is not reuse before the cs is executed or before any consummer
glisse: is done with it
glisse: i should pick ref/unref
airlied: ah cool.. so in userspace.
glisse: yup userspace
spstarr_work: airlied: will try new kernel and test
agd5f: spstarr_work: you do realize that most of the r3xx 3D work came from reverse engineering. it's not some pancea. lots of stuff has been fixed since we got docs
spstarr: airlied: in new DDX + kernel
spstarr: airlied: I think the irq issue is an upstream issue...
spstarr: i get it the moment eth0 is activated then reboot
spstarr: i will reopen the upstream bug
spstarr: trying to get exa to crash with kms no composite
spstarr: text glyph corruption
spstarr: here goes...
spstarr: didnt crash
spstarr: severe corruption
legis: radeon and radeonhd man pages both say they support my card, which one should I use?
spstarr: text glupth and some corruption from video
spstarr: glyph
spstarr: corruption is better than lockup
spstarr: vt switch
spstarr: back
spstarr_desk: wedged
spstarr_desk: [ 468.934012] [
spstarr_desk: [ 468.934012] [
spstarr_desk: [ 468.934012] [
MostAwesomeDude: legis: Whichever works best. Obviously, most of us recommend radeon. :3
spstarr_desk: same mess
airlied: spstarr: can you cat those /porc files
spstarr_desk: sure
spstarr_desk: Interrupt enable: 02000001
spstarr_desk: Interrupts received: 116167
spstarr_desk: Current sequence: 95121 95121
spstarr_desk: Counter sequence: 95139
spstarr_desk: CS: 67397
spstarr_desk: RADEON_CP_RB_WPTR 000186c6
legis: MostAwesomeDude: ah ok, though they were the same project
spstarr_desk: RADEON_CP_RB_RPTR 000184bf
MostAwesomeDude: legis: Nope.
spstarr_desk: airlied: any other from there or just the radeon files
legis: MostAwesomeDude: Ok thanks, you are really awesome :D
MostAwesomeDude: legis: I get that a lot. :3
legis: heh
airlied: spstarr_desk: so gpu is wedged...
airlied: thats an old fashioned GPU wedge :)
spstarr_desk: airlied: a good thing or bad?
airlied: it managed to process 97k of ring commands before dying.
spstarr_desk: or a good wedge or bad one
airlied: spstarr_desk: well its bad in that it happens.
airlied: its good in that I think its AGP only.
spstarr_desk: 97k of commands doesnt that get flushed?
spstarr_desk: or it can hold a lot the ring buffer
airlied: no it gets through that much ring buffer which is quite a lot.
spstarr_desk: airlied: if the buffer got too full would it wedge or would the gpu drop the Last packets
spstarr_desk: ah
airlied: its a ring, there is no too full.
spstarr_desk: never dealt with a ring buffer
airlied: I wonder if I made all commit rings pad to 16-dwords boundaries would it hlep.
spstarr_desk: X isn't dead
spstarr_desk: 1 0x0070ad38 in RADEONCopySwap (dst=0xa6a7320 "",
spstarr_desk: src=0xb4a75000 , size=2400,
spstarr_desk: swap=
spstarr_desk: No locals.
spstarr_desk: #2 0x00766281 in RADEON_DFS_CS () at radeon_exa_funcs.c:611
spstarr_desk: \
spstarr_desk: i can get you the full dump if needed
airlied: the gpu is dead though.
spstarr_desk: but the last stack from userspace might give clues to why?
airlied: nope its long past that point, maybe I should see what defaulting DFS to off does.
airlied: spstarr_desk: can you build xorg-x11-drv-ati locally?
spstarr_desk: ya
spstarr_desk: git or spec + patch?
airlied: I'll post a patch in a sec.
airlied: spec + patch
spstarr_desk: easy enough yea
spstarr_desk: #Option "AccelDFS" "true" if its not commented is it on by default?
spstarr_desk: i had it commented
airlied: I'm ignoring that with kms at the moment.
spstarr_desk: ok
airlied: http://people.freedesktop.org/~airlied/kms-dfs-option.patch
airlied: spstarr_desk: try that with no AccelDFS option
spstarr_desk: ok building
spstarr_desk: lemme grab srpm and jam that in
airlied: you have fedora CVS you shoudl be able to just checkout the reop
spstarr_desk: it will pull tarball automagically?
legis: does radeon supports opengl?
airlied: spstarr_desk: when you do make local it does.
spstarr_desk: ah ok pulling
airlied: legis: on what card? r500 and below yes, above no.
spstarr_desk: so just modify your spec and put the patch line in (cvs doesnt show that pulled yet)
legis: airlied: (--) RADEON(0): Chipset: "ATI Radeon X1650" (ChipID = 0x71c1)
legis: (WW) RADEON(0): R500 support is under development. Please report any issues to xorg-driver-ati@lists.x.org
legis: airlied: does that mean it does?
spstarr_desk: building
spstarr_desk: neat, didnt use make local before.. saves me much time
airlied: legis: yes.
airlied: spstarr_desk: yup just modify the spec and add that patch in.
spstarr_desk: done
spstarr_desk: building
legis: airlied: Ok, thanks.
spstarr_desk: missing some deps...
spstarr_desk: now building
tlp: legis: Are you familiar with the 'glxinfo' command? Should answer that question for you in the future.
tlp: direct rendering: Yes
tlp: (and I think it lets you know if it's software rendering or not, too)
legis: tlp: no didn't know, don't have that command either.
spstarr_desk: grr
spstarr_desk: multilib
spstarr_desk: ok i will build this in my 32bit chroot
airlied: spstarr_desk: you want a 64-bit driver.
airlied: I would assume if you havea 64-bit X
spstarr_desk: the laptop is 32bit
airlied: ah.
spstarr_desk: building 32bit packges on x86_64 is.. not pretty
spstarr_desk: has to be done in mock or chroot
spstarr_desk: no biggie i have compile32 for that chroot
tlp: legis: On Debian/Ubuntu, it's provided by the 'mesa-utils' package.
spstarr_desk: ok there we go
spstarr_desk: done
spstarr_desk: booting
legis: tlp: ah ok, thx.
spstarr_home: ok, we're in
spstarr_home: some text glyph corruption
legis: tlp: direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose)
spstarr_desk: ouch
spstarr_desk: airlied: now it killed display
spstarr_desk: i crashed it...
spstarr_desk: sshing in
tlp: legis: what distribution are you using?
legis: tlp: debian sid
spstarr_desk: airlied: i cant ssh in ;)
spstarr_desk: woo
tlp: hmm. I haven't tried the radeon driver yet. Still waiting for my card.
spstarr_desk: *zap*
spstarr_desk: hooks up console
tlp: wonders just how many spstarrs are in here :p
legis: weird, 'man radeon' says it supports card
tlp: yeah, it should. Other things can break direct rendering.
spstarr_desk: minicom..
legis: spstarr_desk: cu!
legis: any ideas on how to find what is the problem?
spstarr_desk: legis: one for each crash or PC ;)
tlp: You might try doing an 'export LIBGL_DEBUG=verbose' and running the command again. Might provide some useful info, dunno.
chithead: legis: does Xorg.0.log report errors?
spstarr_desk: now, assuming kernel has something to spit out ...
tlp: oh, maybe you need to enable dri in xorg.conf. Forgot about that.
legis: chithead: just checked it, didn't see any
spstarr_desk: X startup
spstarr_desk: [ 70.533026] [drm] LVDS-10: set mode b
spstarr_desk: [ 70.533037] [drm] bios LVDS_GEN_CNTL: 0x30ff24
chithead: legis: often Xorg.0.log gives a reason why direct rendering is disabled
legis: chithead: let me paste it
spstarr_: airlied: oh very nice
spstarr_: rofl
spstarr_: airlied: my Xroot is the system boot up :D
spstarr_: pretty
spstarr_: massive corruption.. now it reset
airlied: ah well not DFS then :)
spstarr_: try to lock up .. now..
airlied: stupid memory leak fixed.
spstarr_: i can make a screencapture of the corruption
airlied: may as well..
tlp: are you testing kms?
spstarr_desk: oh i locked it
spstarr_desk: but i have console
spstarr_desk: gettting info
spstarr_desk: waits for 9600 baud
spstarr_desk: airlied: trying to screen capture locked it :)
spstarr_desk: it was too ashamed to show itself
spstarr_desk: is it possible there's overflow in the drawing at 1400x1050? this seems to happen on 'big' window operations
spstarr_desk: still waiting for dmesg X ..
spstarr_desk: [ 411.340663] [
spstarr_desk: [ 411.340663] [
spstarr_desk: [ 411.340663] [
airlied: spstarr_desk: it might be just large amounts of data transfer screwing the AGP
spstarr_desk: yes
airlied: I run most machinse at 1680x1050
spstarr_desk: then perhaps agd5f can ask the fgrlx people for any erratas on large amounts of data for AGP
spstarr_desk: getting X trace ...
spstarr_desk: the machine is still busy... no ssh but serial is still good
spstarr_desk: fglrx even
legis: chithead: http://rafb.net/p/MNhgwV19.html
agd5f: spstarr_desk: most AGP problems are related to the bridge, not the GPU, and unfortunately, that's not our IP
spstarr_desk: so IBM's board is bad
spstarr_desk: attached to X finally
chithead: legis: the log says that direct rendering is enabled. you may want to use exa instead of xaa. is your user in the video group?
spstarr_desk: EXA
spstarr_desk: #20 0x0079c27f in fbBlt (srcLine=0xb4971000, srcStride=256, srcX=0,
spstarr_desk: dstLine=0xa354f40, dstStride=241
spstarr_desk: stuff above is Xorg whining about mi
legis: chithead: yeah
legis: chithead: video:x:44:legis
spstarr_desk: the strade looks wrong
spstarr_desk: 256?
spstarr_desk: if my video is 1400x1050 the stride is much bigger than that
chithead: legis: also line 978 in the pastebin looks suspect
spstarr_desk: stack is:
spstarr_desk: ProcGetImage -> DoGetImage -> miSpriteGetImage -> exaGetImage -> fbGetImage -> fbBltStip -> fbBlt
spstarr_desk: agd5f: we could blacklist AGP on certain IBM laptops
legis: chithead: where do I set EXA?
chithead: legis: AccelMethod in the Device section of xorg.conf, also see the radeon manpage
spstarr_desk: airlied: I will try booting with no agp but PCI mode + no DFS
spstarr_desk: let's see what happens
legis: chithead: that should fix right?
spstarr_desk: [ 749.887019] irq 9: nobody cared (try booting with the "irqpoll" option)
spstarr_desk: beh
spstarr_desk: rebooting
spstarr_desk: [ 749.887019] handlers:
spstarr_desk: [ 749.887019] [
spstarr_desk: [ 749.887019] [
spstarr_desk: [ 749.887019] [
spstarr_desk: [ 749.887019] Disabling IRQ #9
spstarr_desk: surely there's a bug in kernel.org upstream
airlied: spstarr_desk: I would still guess that might be radeon's fault but I'm not sure how.
spstarr_desk: hmm
airlied: so unless you can repro with an upstream clean kernel don't go bothering them
chithead: legis: that should fix the problem in line 933 but probably not the one in line 978
spstarr_desk: using upstream kernel in rawhide thats going to be painful to do
airlied: should work fine.
airlied: I boot upstream + kms a lot.
spstarr_desk: you build an rpm from kernel.org's Makefile? or manual + custom .config
airlied: just manual.
spstarr_desk: ok, then i just need to find my old .config i used
airlied: I use the fedora config if I have lots of build power :)
spstarr: ok PCI mode no DFS.. let's go....
spstarr: no corruption
spstarr: stressing
spstarr: no corruption still
spstarr: vt switch, ok
spstarr: tries a big operation
spstarr: passed
legis: chithead: yeah, http://rafb.net/p/lcMfUR77.html
spstarr: airlied: unless we have two problems
spstarr: DFS is broken in EXA and AGP is broken on r3xx/r4xx :)
airlied: spstarr: DFS works fine for me here...
spstarr: does DFS do anything different per GPU?
airlied: nope not under kms.
spstarr: ok
spstarr: no lockups, no corruption so far
spstarr: the only poor speed is Xchat and windows overlapping it when moving them around and large.
spstarr: lock
spstarr: ooh
spstarr: it stalled quite long
spstarr: i just had X stall but nothing in log or dmesg
spstarr: and it was for 3 seconds
spstarr: no corruption
legis: chithead: tried 'Option "RenderAccel" "1"' but same error
spstarr: i can certainly trigger X to slow down when doing funny things to gnome-terminal
spstarr: only thing in dmesg is mtrr msg
spstarr: airlied: i think we have a 'winner'
chithead: legis: could be some b0rked library
spstarr: no agp and no dfs == workaround for rv350
spstarr: tries composite for fun
spstarr: composite enabled, but its damin slow
legis: chithead: darn
spstarr: vt switch...
spstarr: yes
spstarr: OH MY
spstarr: airlied
spstarr: it didnt wedge
spstarr: it fscking didnt wedge!
spstarr: toggles on/off
spstarr_desk: ok...
spstarr_desk: dont turn it off ;)
spstarr_desk: oh nice
spstarr_desk: 3: /usr/bin/X(dixLookupPrivate+0x18) [0x806c018]
spstarr_desk: 4: /usr/lib/xorg/modules/extensions//libdri.so(DRIGetDrawableInfo+0x2e) [0x654e00
spstarr_desk: e]
spstarr_desk: 5: /usr/lib/xorg/modules/extensions//libglx.so [0x6a877e]
spstarr_desk: 6: /usr/lib/dri/r300_dri.so(__driUtilUpdateDrawableInfo+0xbe) [0x7cced8]
spstarr_desk: X now dumps the exception instead
spstarr_desk: i can live with that .. just leave composite on
spstarr: airlied: i think now i have a stable 2D kms experience
spstarr: we should blacklist the following 1002:4e50
spstarr: thats the card
spstarr: 8086:3341 that's the agpgart (AGP Controller)
spstarr: finally, i can use kms
spstarr: again i got X to stall 3 seconds
spstarr: [ 835.112748] mtrr: base(0xe1144000) is not aligned on a size(0x5a4000) boundary
spstarr: tries again
spstarr: stalled again on heavy video blitting
spstarr: but it is not crashing
airlied: so spstarr you are running in PCI mode with DFS off?
spstarr_desk: yes
spstarr_desk: it is still ok
spstarr_desk: im just shutting down minicom here
spstarr: :)
spstarr: ro root=/dev/VolGroup00/LogVol00 slub_debug=- printk.time=1 quiet radeon.agpmode=-1
spstarr: tries glxgears
spstarr: ugh, it would help if my DRI was HW accel... stupid kdm
spstarr: thats an upstream issue
spstarr: in any case, EXA is holding and i have not gotten it to crash and there is no corruption, not even text glyph corruption
spstarr: terracon: there is hope
terracon: [driAllocateTexture:635] unable to allocate texture
spstarr: terracon: you can test this too
terracon: yay
terracon: believes
terracon: kernel?
spstarr: terracon: you will need to disable agp with kms and you need a DDX with EXA's AccelDFS disabled
terracon: give me a bit to test that
spstarr: im not going to turn on composite for a few hours and just let this go though normal use
spstarr: airlied: wouldn't this mean fglrx is either going to disable AGP (if that is the workaround they use) ?
spstarr: unless they have a workaround to kick the bus
airlied: spstarr: they may know something we don't.
airlied: we should investigate in the future.
spstarr: yep
spstarr: im quite happy this is working
spstarr: airlied: but! we should also try something else
spstarr: airlied: I tried with agp disabled with kms, but never with DFS enabled?
spstarr: since your patch now forces it off it was on before when using agp
spstarr: when we first talked today i tried the new kernel w/o the DDX change.. crash with AGP on and DFS .. on
spstarr: im going to reboot and now try with AGP on but since DFS is off with kms let's see
spstarr: if that works then it is EXA that is causing pain
spstarr: ok
spstarr: kms + AGP and no DFS... corruption immediate...
spstarr: trying to wedge it
spstarr: text glyph corruption
spstarr: various artifacts
spstarr: trying big window operations
spstarr_desk: BOOM
spstarr_desk: black scren of death
spstarr_desk: cant ssh in
spstarr_desk: airlied: i guess we can conclude AGP should be disabled for r3/4xx and DFS off
airlied: yeah I think I'll do that for final.
spstarr_desk: ok im going back non agp
airlied: and sort it out alter when I get an AGP card.
spstarr_desk: good enough, should allow for everyone to get into the kms action
spstarr_desk: airlied: this explains why i can reboot with kms on with PCI mode used...
spstarr_desk: hmmm
airlied: spstarr_desk: I think the agp release stuff fixed the reboot.
spstarr_desk: fixing kdm so i can try full DRI accel
airlied: at least it fixed my r200.
spstarr_desk: airlied: hmm i can try with agp on and reboot to see but it did lock before
spstarr_desk: [ 749.887019] [
spstarr_home: in composite mode
spstarr_home: i wonder if i should turn on some ricer options to offset the agp loss
spstarr_home: pageflip and depthmoves only
airlied: they won't do much with kms.
spstarr_home: so they're all ignored?
spstarr_home: its fast 'enough' but typing in xchat is sluggish
spstarr_home: oh well
airlied: pretty much
spstarr_home: the loss of accel EXA hurts
spstarr_home: ouch cube is out of the question
spstarr_home: cant even rotate it and see it rotate
spstarr_home: turns off composite gonna have to wait til Fedora 11
spstarr_desk: airlied: i should note i do not see corruption on DDX startup
spstarr_desk: just Xorg stipple pattern
spstarr_desk: (when using kdm as my default dm)
spstarr_desk: didnt try gdm yet
spstarr_desk: when i enable composite I would see a different backbuffer appear (when i had glx gears you can see the buffer of that) then it clears
spstarr: terracon: when you're around you can try the workaround
spstarr: otaylor: disabling AGP and DFS seems to give me a stable DDX on rv350
spstarr: 3D works other than my usual race condition, but its too slow for production use
spstarr: with kms on
terracon: ok what is this workaround
spstarr: terracon: grab this SRPM and build it boot with PCI mode, in grub boot line: radeon.agpmode=-1 try using no composite first for a while
terracon: I always have composite turned off
spstarr: terracon: http://www.sh0n.net/spstarr/xorg-x11-drv-ati-6.9.0-37.fc10.src.rpm
terracon: k
spstarr: when the real fix comes out replace from koji manually
spstarr: i could have left the version alone mind you
spstarr: but this is a test to see if its also stable for you also
terracon: allright
terracon: rpmbuild --rebuild xorg*.src.rpm , right?
spstarr: make sure you have deps
spstarr: or it'll just bitch and tell you them
terracon: building ....
terracon: terrakoji: est time to complation , Dunno
terracon: completion
terracon: terrakoji does not build ppc or x86_64. sorry
spstarr: ?
spstarr: terracon: and..
terracon: spstarr: sorry have to do something right now, give me a lil bit
spstarr: imgonna eat .. dinner..
rmh3093: which repo should I be pulling from to get latest gem kernel code and libdrm from airlied
spstarr: terracon: ok try it whenever
spstarr: im still stable
terracon: spstarr: leafs won in shootout
spstarr: wooooo
spstarr: i was watching world seried
spstarr: 6-5?!
terracon: spstarr: ok so for this file I use rpmbuild or what
spstarr: wtf
spstarr: whoa
terracon: help a noober rpm this
spstarr: rpmbuild will do it
spstarr: rpmbuild --rebuild .srpm
terracon: it goes through but where does it put the file
spstarr: you *will* notice slowdowns unfortunately
terracon: + rm -rf /root/rpmbuild/BUILDROOT/xorg-x11-drv-ati-6.9.0-37.fc10.i386
spstarr: oh as root or user?
spstarr: cd /usr/src/redhat/
spstarr: unless its in /root/rpmbuild/RPMS
spstarr: depends on your env and .rpmmacros stuff
terracon: hmm.
terracon: ok I'm building it in my home directory now
terracon: go gadget go
terracon: ok it's done. NOw install and than reboot with kms enabled , and radeon.agpmode=1
spstarr: -1
spstarr: ignore any error on bootup from kernel saying it doesnt know the option
terracon: k , brb
spstarr: pwd
spstarr: and...
terracon: I'm baaaack!
terracon: I'm still having that problem where I can't login into kde but it was weird. I did it earlier, Anyways I'm in Gnome
spstarr: can't log in?
spstarr: did you ever get into gnome before?
spstarr: with kms on
terracon: yes Gnome. no problem but kde hangs me
spstarr: KDE hangs? composite on?
terracon: composite off
spstarr: what kind of hang
terracon: usually unable to ssh in. I haven't tried to ssh in in a few kernel rev's but it's probably the same
terracon: you know the kde progress bar stars going .. than it get's to the end. and b00m
spstarr: hmmm thats odd.. im in KDE now
spstarr: boom?
spstarr: you *sure* composite is of?
terracon: hard lock
terracon: yes composite is off
spstarr: can you check your kwinrc file and look please?
spstarr: Enabled=false
spstarr: [Compositing] section
terracon: k sec
terracon: [Compositing]
terracon: Backend=OpenGL
terracon: Enabled=false
spstarr: hmm
terracon: what is weird I tried it earlier today and kde worked so when I was logged in I said in the bug report it was ok. Now I try tonight and it's locking me up
terracon: https://bugzilla.redhat.com/show_bug.cgi?id=468787
terracon: I can login into KDE now. No lockups
terracon: w000ps!
spstarr: ?
spstarr: what did you do
terracon: that's when I was logged in I edited that bug report
spstarr: we have serious problems with AGP :(
terracon: do you want me to try something. glxgears
spstarr: terracon: paste your /proc/cmdline please
terracon: ro root=/dev/VolGroup00/LogVol00 rhgb quiet radeon.agpmode=-1
spstarr: hmmm
spstarr: what xorg.conf? no file?
terracon: no file
rmh3093: terracon, i think i had that issue too
spstarr: hmm
rmh3093: everything was working and then i couldnt get into X
rmh3093: but i didnt get hardlock
rmh3093: i could reboot with ctrl alt del
rmh3093: but i couldnt switch vt's
terracon: I haven't had this problem before. This has been happening with fedora 10/rawhide and with kms enabled
terracon_: going to a certain website caused lockup
terracon_: If I boot with nomodeset it's fairly stable
terracon_: only with kms enabled things get shaky
spstarr: is puzzled
spstarr: you did install the DDX? :)
terracon: yesss
terracon: sorry I went on to play some enemy territory. I find that a good 3d stress test app
rmh3093: im getting an error when X tries to start
rmh3093: DRM Command submission failure -22
rmh3093: (EE) RADEON(0): [drm] Failed to initialize GART heap manager
rmh3093: adding fb map from c3ea3000 for b13000 ret 0 c3ea3000
terracon: I'm going on for another map or two before everyone logs off for the evening
terracon: brb
terracon: Received signal 11, exiting...
terracon: is back earlier than expected
spstarr: airlied: i can install fglrx and see what happens, i haven't tried it before
terracon: the dark side!!!!!!!!!!
spstarr: terracon: its not dark as much as AMD is good
spstarr: consider it a hack until Fedora 11
spstarr: if we can figure out the AGP woes
spstarr: knowing kms works on r3xx is good however
tlp: AGP woes are only for kms, right?
tlp: not DRI?
terracon: spstarr: the crasher type bugs I've put into bugzilla so airlied should know about those ones
spstarr: my DRI issues are some design decisions of DRI (i dont know how DRI2 will cope or not)
airlied: AGP is just a problem in general for ever.
tlp: ah :/
airlied: DRI has always had to get users to hack around it with setting in xorg.conf
terracon: well I have kms off and agp seems ok'ish
tlp: I'll help test when I get my card this week.
tlp: (if necessary)
airlied: hmm me notices no mtrrs.. fail by me.
spstarr: :)
terracon: casts epic fail on airlied
spstarr: i didnt think AGP sucked so bad.. until I saw the life of a developer of graphics drivers... oh how many kittens have died in vain
tlp: one of these days I'll get a motherboard with PCIe.
tlp: I don't like upgrading
spstarr: i cant exactly ram a PCIe controller into my old thinkpad ;(
spstarr: airlied:this is now the longest i've been in kms :)
spstarr: airlied: it really sucks when gnome-terminal/konsole has to scroll lots of text.. the whole damin screen freezes :)
airlied: spstarr: not having DFS sucks :)
spstarr: well thats just bugs in EXA
spstarr: and i can test any fixes in Xorg
airlied: okay mtrr better, console more useable.
spstarr: i'll grab your bits from koji once ready and replace this temp ddx package
rmh3093: airlied, did u see my error
spstarr: building DDX w/ mem fix
spstarr: plus the other patch
airlied: rmh3093: thats not very nice error.
airlied: anything in dmesg?
spstarr: oh nice
spstarr: can use composite, if that leak was causing the problems
spstarr: still not fast, but 'usable'
terracon: mostawesomeness
spstarr: tries XRender mode
spstarr: nice
spstarr: Xrender it is
spstarr: it offsets the sluggishness of lack of DFS :)
spstarr: airlied: kwin has XRender mode for those who cant use OpenGL f
airlied: kicks off kernel build with mtrr + agp off unless specified.
spstarr_desk: i wedged it
spstarr_desk: hahaha
spstarr_desk: tries to ssh in
spstarr_desk: no ssh
spstarr_desk: maybe serial will let me in
spstarr_desk: no go
spstarr_desk: upstart didnt spawn a listener for ttyS0
spstarr_desk: oh well, im sure i will get that to trigger again eventually
rmh3093: airlied, i've rebooted since then
terracon: radeon: try and workaround AGP badness with kms + enable VRAM mtrr hrmmmmmm
terracon: badness
spstarr: tries non-kms and is in composite mode....
spstarr: VT switch...
airlied: so my pci r100 does DFS fine by the look of it
spstarr_home: but but..
spstarr_home: its an r100
spstarr_home: airlied: stress it
spstarr_home: airlied: open gnome-terminal maximize it and then click resize/maximize as fast as you can
spstarr_home: then full maximize windows and minimize
spstarr_home: if you get it.. just right it will just go boom
spstarr_home: if you do it all rapidly, you might trigger a lock