MostAwesomeDude: I would like to report that suspend does NOT work on my laptop.
MostAwesomeDude: And given that it worked on 2.6.18, on this laptop's sibling, which had an nVidia, I would like to blame either the fingerprint reader (which doesn't even have drivers!) or the Radeon.
MostAwesomeDude: Suspend is okay, but the kernel hangs, hard, when coming back up. It's not a panic, and the magic sysrq keys don't work.
MostAwesomeDude: Is there any way to get a dump or trace somehow, or am I just stuck?
MostAwesomeDude: Oh, and it doesn't matter whether or not drm and radeon are loaded, or whether it's done from X or the FB.
airlied: MostAwesomeDude: could be wireless or USB or anything.. suspend/resume is always messed up
MostAwesomeDude: airlied: Well, before it was stolen, this laptop's older cousin could suspend. Previous model in the same line, nearly everything's the same except: Fingerprint reader, video card, CPU (Core 2 Duo).
MostAwesomeDude: Yeah, I know it could be a lot, but my gut tells me it's the video card.
MostAwesomeDude: Or it's the BIOS, in which case all hope is lost. But I was more wondering if there's a way to trace where the kernel's going in hangs like that.
airlied: MostAwesomeDude: there is.. a kernel suspend/resume tracer
airlied: MostAwesomeDude: it stores things in the RTC (it over-writes the clock)
icewaterman: MostAwesomeDude: also: you can find out during resume what exactly makes the kernel die by adding some debug info to wakeup scripts (if it doesnt die instantly)
icewaterman: mount some filesystem with the sync option and then have the scripts write debug info onto that filesystem.
icewaterman: if it dies instantly you are left with the debug methods the kernel has to offer
MostAwesomeDude: "rdlogger"? Is that the channel bot from radeonhd.org?
airlied: MostAwesomeDude: yup logger.
airlied: MostAwesomeDude: so have you any code that even compiles :)
prahal: couldn't it be the issue I had that is vesafb and vanilla radeonfb does not resume from suspend ?
airlied: prahal: possibly.. suspend/resume can be so many things
airlied: agd5f: so the nice surface format pics don't include C4_10
airlied: agd5f: also how to do C_1_5_5_5 sounds like fun
airlied: agd5f: I think some more info on US_OUT_FMT does exactrly..
airlied: as r300 never seems to have programmed it
sirlark: howdy, I was told I should come here from the gentoo forums
matteo: does the 6.8 driver work much more well than the 6.7.195?
matteo: the update costs me 150MB of download via ISDN
arekm: try git version, it works even better
matteo: will the compiled module load in xorg?
arekm: it should
matteo: I have to compile even the DRM from GIT?
MrCooper: no
matteo: good
matteo: i'l try
MrCooper: well, unless you have an R5xx card and want to use some of the newer features maybe
matteo: radeon 9600
matteo: r350 IIRC
MrCooper: then you don't need drm Git
agd5f: airlied: supposedly to swizzles the outputs from the shaders. A8 was busted until I changed it. The others may not matter I guess... I'm not real clear either
chithead: some time ago I reported (bug 13533) that on my x700 mobility, the lvds would remain blank if a crt is attached on boot. I read on phoronix forums that r400 uses atombios only for tmds. so is it possible to use atombios for lvds on r4xx?
chithead: could it be enough to replace IS_AVIVO_VARIANT by info->IsAtomBios in some places of radeon_output.c or would that cause horrible breakage?
glisse: chithead: it already likely use atombios voir lvds too
glisse: chithead: i would need to look at code to be sure
chithead: from radeon_output.c it seems that most atombios calls are behind if (IS_AVIVO_VARIANT), and agd5f said http://www.phoronix.com/forums/showpost.php?p=27542&postcount=17
glisse: chithead: so no its isn't used for lvds
glisse: chithead: btw this might be a choice your bios does if it sees a screen is connected
glisse: and there is no easy way to change bios, can you light up the lvds once in xorg with xrandr ?
chithead: glisse: the screen will light up, but remain completely white
glisse: chithead: did you played with xrandr ?
chithead: glisse: yes, disable LVDS/CRT and enable again, nothing helps. interestingly by playing with suspend-to-disk I could reach some half-working states
glisse: chithead: well so dump will likely be needed to compare btw booted with ext screen and without
chithead: glisse: I attached dumps to bug 13533 already
glisse: chithead: well then just wait for someone (likely agd5f) to take a look at this :)
chithead: yes, he was very helpful and tried some things back then, but to no avail. I came back here because I read about the limited use of atombios on r4xx on phoronix yesterday, and wondered whether atombios might setup the lvds correctly
glisse: if your bios doesn't this means atombios won't
glisse: you video bios execute atombios
glisse: chithead: you can try to fix this using radeon tool
glisse: diff -u btw bad and good
glisse: and set different register to the good value until you find which one
glisse: my guess is that RS480_UNK_e38 might help
glisse: there isn't much different register
chithead: sounds like some work. there is not by chance a bisect utility for registers? :)
glisse: chithead: its not difficult at all
glisse: example: radeontool setreg RS480_UNK_e38 0x80002d4e
glisse: and there is only 10reg in the diff
glisse: so atmost 10 command
chithead: glisse: thanks I'll try that. at least it's easier than messing around in radeon_output.c
glisse: see radeonttool on how to properly set a reg i can't remember the syntax off hand
chithead: ok, brb
glisse: myself going to eat somethings bbl
agd5f: glisse, chithead: the RS4xx regs only apply to XPRESS chips
chithead: yes, setting the RS480_* registers did not make a difference
agd5f: chithead: you could try using atom calls for LVDS. the atom implementation on r4xx was not complete however, so only certain things work
agd5f: chithead: have you tried any more recent versions of the driver? you problem may have been related to the pll div select bug, which should be fixed
chithead: the system hung after messing with COMPOSITE_SHADOW_ID
chithead: I am using git checkout from today
chithead: agd5f: I replaced IS_AVIVO_VARIANT by info->isAtomBios in radeon_output.c, let's see if it breaks
chithead: meh, if failed to compile
chithead: it made a difference, now the lvds is all black instead of white (backlight is on)
chithead: agd5f: I'm tempted to do the same to radeon_crtc.c, but there seems to be genuine AVIVO stuff in there instead of atombios calls
chithead: agd5f: I noticed no ill effects in replacing every occurence of IS_AVIVO_VARIANT with info->IsAtomBios in radeon_output.c. when playing with radeon_crtc.c however I noticed that my system locks up hard when calling atombios_crtc_mode_set()
rx__: wow.. a mobility radeon hd 3870x2 part
edgecase: ten pound battery?
GerbilSoft: Hi, I just noticed a weird problem with radeon. (FireGL V5200, EXA) If I enable a second monitor via xrandr, the mouse pointer shows up, but the contents of any window placed on the second monitor doesn't.
GerbilSoft: ah it seems it's an xorg-server problem - i'm using xorg-server 1.4.0.90-r3 (gentoo)
GerbilSoft: though on 1.3.0.0-r5 i wasn't getting any acceleration at all - with 1.4* Exa's working
CRXLPY: w0000t
CRXLPY: watching tv
osiris_: airlied: i'm tracking texture filtering problem on rs690. so far I found that the artifacts show only with mipmap filtering. any suggestions how to investigate it further? maybe comparing radeon and fglrx dumps taken with revenge?
edgecase: crxlpy, what did you do?
CRXLPY: I forgot to include xv support in xdtv
CRXLPY: recompiled it
CRXLPY: now to figure out the aspect ratio
CRXLPY: well this bites edgecase
CRXLPY: xdtv is a dead project, Of course it would be what I get to work lol
CRXLPY: well well well, I got tv working. but whenever I leave X afterwards I have a messed up console
ghepeu: hi. I upgraded to the latest xserver git with two EXA commits
ghepeu: x11perf -aa10text is still stuck to ~22000 char/s, but according to top i'm using just 10-15% of the cpu
z3ro: osiris_: hmm I guess it's possible we might use some bad values there, but I think they are reasonably correct.
z3ro: osiris_: feel free to verify that, though.
ghepeu: I also tried to change the value of Options "MigrationHeuristic" and found that with "greedy" x11perf jump to 135000 char/s, but there's a significant increase in CPU usage and render_bench is way slower
z3ro: ah I really should rebuild the X server. that input deadlock bug is nasty.
mattst88: Radeon 9100 is the fastest PCI radeon, right?
airlied: mattst88: you can R500 based PCI cards
mattst88: could you find me a link? I've never heard of those.
rx__: http://www.techspot.com/review/15-visiontek-radeon-x1300-pci/
rx__: but then again.. is a low end x1300 really faster?
mattst88: wow, thanks for the link
mattst88: I had no idea there were PCI radeons newer than r200
Magnade: rx__: id hope a x1300 is quicker than a 9100...
edgecase: can't let Matrox lording their quad heads over us!
edgecase: we need PCI radeons!
rx__: ;)
Magnade: i was more thinking if it wasnt would ati be going the wrong direction performance wise?
Sadako: < mattst88> Radeon 9100 is the fastest PCI radeon, right?
Sadako: aren't there _plenty_ of 9250 pci cards?
mattst88: 9250 are have 64-bit memory buses iirc
mattst88: and the 9200's memory is clocked 50MHz lower than a 9100
Sadako: oh...
mattst88: according to Wikipedia, 9100 is the fastest r200 pci card
Sadako: goes back to his corner
mattst88: haha, come back here! :P
mattst88: any predictions about an X1550 PCI and compatibility with a DEC Alpha box?
airlied: mattst88: some pain and suffering..
mattst88: more than with a 9100?
airlied: mattst88: not sure..
mattst88: hmm, I bet radeonfb doesn't support the X1550 though, right?
airlied: mattst88: not a hope
edgecase: radeonfb doesn't do atombios does it?
mattst88: I can actually get an X1550 PCI for ~10 USD less than a 9100 PCI
edgecase: what about r300 pci?
mattst88: wikipedia doesn't list any
edgecase: how about ati.com ?
mattst88: airlied, the 2D engine isn't fundamentally different from R300 to R500, right?
airlied: mattst88: the modesetting or the accel?
mattst88: both
mattst88: edgecase, http://products.amd.com/en-us/GraphicCardFilter.aspx <-- lists none but r500 when PCI is selected
airlied: mattst88: modesetting is completly different
mattst88: thanks
edgecase: how about discontinued ones
edgecase: ebay
edgecase: hmm 9800, claims 10bit per channel DAC, what use would that be?
mattst88: no idea
mattst88: so I can get a 9100 for 30ish, and an X1550 for 20ish.
mattst88: is it worth gambling on the X1550 whereas I know the 9100 is supported and working?
edgecase: i'd check for 3rd party card
mattst88: like what?
mattst88: you mean Matrox, etc?
airlied: mattst88: I'd go with the 9100 :)
mattst88: don't like gambling? or just fewer forseen headaches?
airlied: mattst88: well if you need a fraembuffer ;)
mattst88: true. X-related things, with the exception of 3D, should be on par though, right?
airlied: mattst88: if you can get running, yes..7
mattst88: any guesses on ETA for the modesetting stuff moving into the kernel?
edgecase: airlied, 10bit per channel ?
edgecase: mattst88, someone is working on it
airlied: mattst88: 6-12 mths..
airlied: edgecase: 10-bit what :)
edgecase: airlied, 10bit per channel DAC
edgecase: Dual integrated 10-bit per channel 400 MHz DACs <-- 9800 series
roh: edgecase well.. so what?
roh: propably there is some gamma-table you can programm which translates regular 24bit rgb-colorspace to whatever you want to push the ramdacs with
roh: or the lower 2 bits are clamped to 0 which just gives you less 'noise'
airlied: or you just use a 64-bit framebuffer..
airlied: or 2-10-10-10 is still 32-birts