Nightwulf|work: hi all
spreeuw: 2.6.35 rcs act weird
spreeuw: .3 load in rest
spreeuw: kslowd
spreeuw: I read some article this is related to a drm issue
spreeuw: a forum thread
dileX: tytso was investigating a kslowd issue on intel-gfx
dileX: http://permalink.gmane.org/gmane.comp.video.dri.devel/47217
spreeuw: ok hope it gets fixed before release
spreeuw: because it makes it rather useless
spreeuw: usb acts up too here
spreeuw: UPS kept disconnecting
dileX: spreeuw: http://www.gossamer-threads.com/lists/linux/kernel/1236723
dileX: "OK. From this hint I looked at the log between -rc1 and -rc2 and found
dileX: commit fbf81762e385d ("drm/kms: disable/enable poll around switcheroo
dileX: on/off").
dileX: Reverting this commit brings everything back to normal."
spreeuw: yes that thread
dileX: airlied: ^^
spreeuw: theres also a warning with git mesa that its too old
spreeuw: for 6.35
dileX: what is too old?
dileX: spreeuw: BTW, which GPU(s)?
spreeuw: 700
dileX: you have some combo-gfx with intel/radeon?
spreeuw: "ATI RV730XT [Radeon HD 4670]" (ChipID = 0x9490)
spreeuw: no its an amd board
spreeuw: it has built in gpu too
spreeuw: maybe thtas the issue
DanaG1: hmm, you on 64-bit?
spreeuw: also a radeon thing
spreeuw: no
DanaG1: Packages of mesa tend to have old 32-bit parts.
spreeuw: ill figure it out later once 35 has a release
DanaG1: oh, and I'm still eyeing those power savings.... need to be able to customize min and max profile used by dynpm.
dileX: spreeuw: it would be helpful when you revert the above mentionned commit, compile a new 2.6.35-rc3 kernel and report
airlied: yeah reverting would help a lot
airlied: as I havne't seen this at all
spreeuw: is trying rc1 enough too?
airlied: well it might have other issues
spreeuw: is it a one line fix?
spreeuw: I dont have a kernel git tree handy
rhodan: Can I just set my GART to any value significantly smaller than 512MB?
glisse: rhodan: you can but it's not recomanded to do so
glisse: note that 512MB is not wasted
rhodan: How ist that?
glisse: it's just the size of the GART, ie how much ram we can bind to the GPU
rhodan: X11 uses it up.
glisse: and binding happen on consumption basis
rhodan: At least when running in NoAccel=1 mode.
glisse: if it uses 512M it's because you have 512 of texture or whatever
rhodan: I shouldn't run in that mode anyway, so it's fine.
glisse: but it's unlikely
glisse: unless you got 30tabs in firefox
rhodan: Or make -j5 on OO.o.
rhodan: Or nessus and metasploit at the same time.
glisse: such memory isn't bind to gpu
rhodan: But X shows up in htop using ~400MB of RES after some hours.
rhodan: With EXA, it doesn't.
rhodan: By the way, how would I install the gallium state tracker?
glisse: xrestop is better to know how much memory is use
glisse: don't trust figures of htop
glisse: it's mostly address space
glisse: and likely very few of it is actualy use and consume memory
glisse: and changing gart size won't change what you see in htop
glisse: it's completely unrelated
rhodan: OK.
rhodan: I run xorg-server-1.7.6 and x11-drivers/xf86-video-ati-6.13.0. Would tracking GIT bring better 2D performance?
glisse: 5~http://www.kdedevelopers.org/node/1445
glisse: i am not sure how much 2d perf improved, but i think newer xorg server had several fixes & improvement
gormux: hi
gormux: I would like to know, how good are radeon drivers with HD3450 cards ?
gormux: good 3D support ? everything works well ?
spreeuw: more or less
spreeuw: but theres no s3tc
spreeuw: but games like ut2004 work flawless
gormux: s3tc ?
gormux: ok, wikipedia told me :)
gormux: hum, i'll see
chithead: gormux: 3d desktop effects and simple games work
gormux: chithead: ok, thanks
krushik: i've upgraded my debian system and xv/dri not works now
krushik: I see in Xorg.0.log "[dri] This chipset requires a kernel module version of 1.17.0,"
krushik: "[dri] but the kernel reports a version of 2.0.0.[dri]"...
krushik: it is at my 2.6.32 kernel
krushik: if I boot to new 2.6.34, then system hangs during boot process
krushik: wtf is going on?
chithead: do you have firmware installed?
chithead: also if you use kms, you need xserver-xorg-video-ati 6.13
krushik: xserver-xorg-video-ati: 1:6.13.0-2
krushik: i A firmware-linux; i A firmware-linux-free; i A firmware-linux-nonfree
chithead: pastebin dmesg and Xorg.0.log
chithead: hang during boot may mean firmware not found. maybe the radeon module is in initramfs but the firmware is not
Ke: I remember seeing something similar, when my xf86-video-ati was in 6.12
Ke: but you seem to already have 6.13
krushik: http://pastebin.com/rhxq5VHT http://pastebin.com/gnYmqLYp
chithead: krushik: did you ensure that radeon is loaded before starting X, as line 402 in Xorg.0.log says?
Ke: I bet debian developers would hate you so much they would compile radeon without KMS support just to spite you
Ke: (though unlikely)
jcristau: yes, we're like that
Ke: ;o)
krushik: does "This chipset requires a kernel module version of 1.17.0,<...>" mean that I have latest xorg drivers with kms and kernel module w/o kms?
jcristau: or, more likely, you built your own kernel and it doesn't autoload radeon
Ke: modprope radeon and then restart X
Ke: modprobe
krushik: i tried 2.6.34 from experimental and 2.6.34 from liquorix
krushik: kernel's radeon wasn't loaded before xorg starts..
krushik: thank you all
krushik: i've added modprobe radeon to init.d/gdm before gdm binary is invoked.. do you know a better solution?)
Ke: modules.autoload.d
Ke: modprobe.d
Ke: apparently it's modprobe.d in debian
jcristau: krushik: use the debian kernel, or a kernel with CONFIG_DRM_RADEON_KMS=y
Ke: yup stock kernel is typically the best, if applicable
krushik: I successfully booted up to debian's 2.6.34 from experimental. but only after adding "modprobe radeon" to init.d/gdm
krushik: I have "options radeon modeset=1" in modprobe.d/radeon-kms.conf
jcristau: yeah known problem with the kernel from experimental
jcristau: will be fixed next time. the kernel from sid works.
krushik: oh, i see. thanks all again
Terrax121: Hi guys
Terrax121: I am facing a problem programming this galium vdpau backend
Terrax121: I want to do some device handling and VdpDevice is if the type uint32_t
Terrax121: of*
Terrax121: What I want, is to save a pointer to the uint32_t variable. The problem is, that pointers will be a 64-bit adress on 64 bit systems
Terrax121: Anyone got any tricks to evade this fault in typeconversions?
_05de07bb: Terrax121: use union
_05de07bb: but anyway, you're probably doing something wrong if you run into such issues
Terrax121: _05de07bb, well it isn't a problem, (yet), but could be on 64 bit systems
_05de07bb: integers and pointers are totally distinct types
_05de07bb: you should never cast one onto another
Terrax121: _05de07bb, it would make my devicehandling much easier though
Terrax121: I have to keep an eye of the devices, which has been made by the application
_05de07bb: and your bugsearch and fixing much harder
Terrax121: If the application stores the pointers to my device_handles, it is much easier
TGEN: Terrax121: what are you talking about? &foo if foo is of type uint32_t is transparent
Terrax121: _05de07bb, well I'll try another approach then, if you don't like it :)
_05de07bb: you have probably to use some 'id table' then
Terrax121: Yeah
_05de07bb: Terrax121: btw for which card hw accel will be available? :P
Terrax121: _05de07bb, I will try to make it general. Every card which supports galium.
Terrax121: TGEN, The application asks the vdpau backend for a VdpDevice. I need to give it that.
TGEN: just a value on the stack? how hard can that be
Terrax121: To make it smart I have a struct internal in the backend, and giving the address of that struct as the VdpDevice value will make things easier
TGEN: that is ugly
TGEN: but I guess you only need some unique identifier?
Terrax121: Well _05de07bb tried to tell me that. So I'll try something different
Terrax121: TGEN, yes
TGEN: you could run the contents of your struct through some hashing function
TGEN: :)
Terrax121: TGEN, I have though of that too, but the other way just seemed simpler.
_05de07bb: TGEN: hashing doesn't seem not really useful here
_05de07bb: if app gives back a hash, you need to iterate over all structures anyway
TGEN: _05de07bb: whatever you're doing, if you need to supply a unique 32-bit identifier, you're basically hashing
Terrax121: _05de07bb, but I haven't done any galium specific code yet, so I can't really say anything about the support. Right now I'm working on the backend framework.
Terrax121: It would be much easier, if I could use std::vectors :)
zhasha: Terrax121: ever had a look at DRI2?
zhasha: http://cgit.freedesktop.org/xorg/proto/dri2proto/tree/dri2proto.txt#n165
Terrax121: zhasha, yes I have. Once. What should I look at? Anything related to my above issue?
zhasha: well, DRI2 provides a VDPAU interface, sort of
zhasha: I fail to see why you'd need to cast an int to a ptr
_05de07bb: TGEN: I guess the structure contents can change, and identifier needs to be unique
TGEN: _05de07bb: yeah, then a simple k-v map would suffice
TGEN: hash as key, pointer as value
_05de07bb: TGEN: what's the point of hashing if you could just give incremental values?
Terrax121: zhasha, DRI2 does only provide a vdpau identifier AFAIK
TGEN: _05de07bb: incremental values are a hash too, in a way
zhasha: it should give you a list of devices
TGEN: all that matters is that they're unique
Terrax121: _05de07bb, I have though of just incrementing a simple int and using that as the identifier
_05de07bb: Terrax121: use the exactly same type as the identifier does
Terrax121: zhasha, but the vdpau dri2 module has to be made for radeon also though. but it is not crusial.
Terrax121: _05de07bb, yeah uint32_t.
Terrax121: I just have to keep an eye of the devices, which has been made
zhasha: Terrax121: hash table?
Terrax121: zhasha, I might end up using that, yes :)
zhasha: if you're doing what I think you're doing, do this: http://cgit.freedesktop.org/~jsindholt/mesa/tree/src/gallium/state_trackers/nine/libnine/drivers.c?h=gallium-nine#n100
krushik: why do my new radeon driver with kms is veeery slow?
krushik: glxgears laggs and shows 45.994 FPS in small window =o
_05de07bb: krushik: you have written your own driver?
spreeuw: krushik: glxgears is no benchmark
spreeuw: the number is completely useless
krushik: I did upgrade my debian systme recenlty. we've discussed my problem an hour ago here
spreeuw: fire up some game for real life performance
krushik: it definitely laggs
krushik: I can't even choose a game at teeworlds for ex.
spreeuw: are you using direct rendering?
spreeuw: and for the best performance you need the last mesa
krushik: glxinfo |grep rend
krushik: direct rendering: Yes
krushik: OpenGL renderer string: Mesa DRI R300 (RV530 71C2) 20090101 x86/MMX/SSE2 TCL DRI2
_05de07bb: krushik: kernel, driver and xorg versions
krushik: 2.6.34-1-686; (II) Loading /usr/lib/xorg/modules/drivers/ati_drv.so; compiled for 1.7.7, module version = 6.13.0; (II) Loading /usr/lib/xorg/modules/drivers/radeon_drv.so; compiled for 1.7.7, module version = 6.13.0; xserver-xorg: 1:7.5+6
spreeuw: teeworld works ok on my 4670
spreeuw: funny game
krushik: all was fine before last upgrade. but now laggs unbelievable
spreeuw: krushik: you're not using 3d windowmanagers or so?
krushik: i'm using kde4, but all such features are disabled. and I could even turn 'em on before upgrade
[Enrico]: krushik: you might want to try disabling kms (currently KMS is slower unless you use gallium3d r300g driver)
krushik: disabling kms helps. thanks
[Enrico]: krushik: :)
_05de07bb: btw is 'jumping' screen with 'center' scaler a known issue?
_05de07bb: hm, another funny issue is when you set some non-native res on LVDS and then switch scaler to 'none'
_05de07bb: the screen goes blank and you have to blindly switch to the native mode
Terrax121: zhasha, looking at you code now
Terrax121: did you make a direct3d state tracker?
Terrax121: zhasha, the hashmap you have used. Do you have the source-code for that?
Terrax121: zhasha, found it
mentor: I've updated to DDX master and I'm still seeing corruption like http://www.bells23.org.uk/{Corrupt,Predator}.png
Jonimus: mentor: which kernel are you running?
mentor: 2.6.34
mentor: oh
mentor: hmmm
Jonimus: and what libdrm version?
mentor: libdrm master
mentor: No, actually I pulled from drm-radeon-testing
mentor: Arse, I forgot that
Jonimus: hmm is this corruption instant or only after running 3d apps?
mentor: It is present without using 3D apps
Jonimus: and what Video Card?
mentor: VGA compatible controller [0300]: ATI Technologies Inc Mobility Radeon HD 3400 Series [1002:95c4]
mentor: An RV620, I believe
Jonimus: hmm, I was having a similar issue with my r730 but it went away with a recent mesa update.
mentor: There did look like there were some fixed in the DDX, but they seemed to have not helped
spreeuw: thats not a valid url
spreeuw: I had corruption too with yesterdays build
spreeuw: but a rebuild today worked ok
mentor: It needs to be interpreted before use
spreeuw: but the build with corruption was built against a non running kernel
spreeuw: http%3A%2F%2Fwww.bells23.org.uk%2F%7BCorrupt%2CPredator%7D.png
mentor: It's supposed to specify two images
spreeuw: ok, one never knows with this web 2.0
spreeuw: yeah I had something similar
spreeuw: try building todays git
spreeuw: now
mentor: of which?
spreeuw: everything
spreeuw: drm ddx and mesa
spreeuw: unless you use packages
mentor: I always build them as packages anyway
spreeuw: oh
mentor: No git, when I add a wildcard pattern which references something in git ignore, I want you to ignore that and add everything else, not do nothing and fatal.
dileX_: spreeuw: could you rebuild and test .35-rc3 with reverted commit?
mentor: Aha
mentor: r600 tiling changes
mentor: regression in CS checker
Jonimus: mentor: so your kernel is not a recent build then :P
mentor: All of 3 days ago
Jonimus: hmm then IDK, I had that issue a while a gor but recent Mesa+DDX+libdrm+Kernel seem to have fixed it so IDK
mentor: I'm expecting this new kernel will fix it
spreeuw: dileX: ok will try and report back to you later
spreeuw: mentor: they are not in any released kernel yet
spreeuw: the tiling fixes
spreeuw: AFAIK
spreeuw: maybe in the drm kernel tree
spreeuw: of the drm devs
spreeuw: looking forward to them though
spreeuw: they will boost performance immensely
spreeuw: I remember when r200 got it
spreeuw: it suddenly made q3a true combat playable
spreeuw: with windows like performance
DanaG: hmm, I oughtta' try the open drivers again, with drm-next.
DanaG: My wish: an option to tweak dynpm and dynamic. Instead of having one "power_profile" sysfs setting, you could have two: power_profile_min and power_profile_max. "Auto" would switch based on power state, and "dynpm" would switch based on load.
mentor: spreeuw: As I said, I've pulled the drm-radeon-testing tree
DanaG: Say, is drm-next supposed to support the internal sensor?
DanaG: Thermal, I mean.
DanaG: [drm] Internal thermal controller with fan control
spreeuw: dileX: I checked out rc3 , then did revert of that commit, but I still have this .3 load
frojnd: Hello there I have radeon drivers 6.13.0-1 for mobility x1400 and when I plug the tv s-video cable in xrandr says this: http://paste.pocoo.org/show/229924/
spreeuw: might be something else than drm though, I see my usb UPS reconnect loop all the time too
frojnd: it doesn't even recognize it?
frojnd: Tips and tricks?
frojnd: tips and tricks? :D
spreeuw: so?
spreeuw: select the mode you want to use
spreeuw: or do you mean the monitor isnt there?
frojnd: spreeuw: when I plug the monitor to vga I can see what sizes it is
spreeuw: for svideo 1024x768 is probably the max
frojnd: spreeuw: I can't even see s-vide
frojnd: when I type in xrandr
frojnd: and tv is plugged in
spreeuw: o
frojnd: s-video yes
frojnd: so..
frojnd: any ideas?
frojnd: yes
frojnd: found it
frojnd: no :(
frojnd: why wouldn't xrandr recognize s-video?
frojnd: when I do xrandr --addmode S-video 800x600 I get xrandr: cannot find output "S-video"
Jonimus: xrandr -q?
frojnd: Jonimus: http://paste.pocoo.org/show/229933/
frojnd: any yes s-video is plugged in
Jonimus: hmm from the looks of it xrandr doesn't even know your tv-out connector exists.
frojnd: jeah
frojnd: that's funn
frojnd: y
Jonimus: I'd say try a force tv detection option in your xorg.conf, if you use one
frojnd: Jonimus: nope
frojnd: I don't
Jonimus: well I'd look into that, I know there is an option for it.
frojnd: http://wiki.x.org/wiki/radeonTV ?
Jonimus: yeah something like that.
frojnd: erm
frojnd: I tried to add Device Section "Device" Driver "radeon" EndSection
frojnd: and I couldn't get into X
frojnd: Ok.. now I'm confused
frojnd: I did exactly as on the wiki http://paste.pocoo.org/show/229939/
frojnd: and all I got working was changing the resolution to 800x600
frojnd: xrand still won't show TV out :s
agd5f: frojnd: if you are using ums, you need Option "ATOMTVOut" "True" in the device section of your config
agd5f: or use kms
dileX: spreeuw: OK. thanks for testing.
brixsat: hello :)
brixsat: where can i find the driver for ubuntu lenny of an ati radeon x2300
dileX: brixsat: ubuntu *or* debian/lenny
brixsat: dileX, debian
frojnd: agd5f: I add option Option "ATOMTVOut" "True" under the "Device" section and now I see in the xrandr output s-video
frojnd: agd5f: but the picture still isn't on the TV
frojnd: agd5f: I've even set xrandr --addmode S-video 800x600 xrandr --output S-video --mode 800x600
Ke: brixsat: btw. iirc lenny is somewhat archaic, update might do you some good
brixsat: squid :)
agd5f: frojnd: make sure the tv standard is set properly. Also make sure you are using 6.13.0
frojnd: agd5f: I do have
frojnd: agd5f: doesn't help..
agd5f: frojnd: might try kms
brixsat: Ke, i have updated my system :D
brixsat: and still no compiz running :(
Ke: upgraded to testing?
brixsat: iv upgraded to squeze
Ke: so that's testing apparently
brixsat: is it ok?
Ke: well apparently not
Ke: but in testing you can still get bugfixes
brixsat: i was on a stable one and you told me to update :(
Ke: well you can only get bugfixes for severe bugs in stable, so the situation was not going to improve ever
brixsat: taking that off, how can i view if my driver is ok ?
Ke: I don't really know that much about compiz
brixsat: i want to know if my driver is setted up ok on debian
spreeuw: fire up a game of openarena
spreeuw: if its sort of playable it's worjing
brixsat: sorry internet went off
dileX: brixsat: show dmesg output and Xorg.log
brixsat: dileX, http://pastebin.com/BtF8M1id & http://pastebin.com/87BeNdgA
dileX: (II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so
Ke: g(WW) RADEON(0): Direct rendering disabled
dileX: you are missing the mesa dri/glx driver/libs I guess
chithead: [ 20.992377] radeon_cp: Failed to load firmware "radeon/R520_cp.bin"
chithead: you need to install firmware, see channel topic
dileX: install libgl1-mesa-dri and libgl1-mesa-glx
brixsat: dileX, all up to date
dileX: firmware-linux-nonfree
dileX: yeah, missing firmware files
Ke: I thought those came with the kerne
Ke: for r300-r500
Ke: unless debian stripts those
soreau: I think debian shafts it back out
soreau: so they can be super-free
Ke: -t
dileX: Ke: should be installed w/ latest kernel
chithead: debian does not ship the firmware because it is proprietary
brixsat: i dont have thar i have firmware-linux-free
dileX: brixsat: why do you use a backport kernel? 2.6.32-bpo.4-amd64
brixsat: dileX, wifi
soreau: brixsat: It's in the nonfree repo IIRC
brixsat: how do i add that?
dileX: brixsat: how did you add bpo repo :-)?
brixsat: well i now how to add i just dont know what to add :p
chithead: add non-free after main
chithead: in sources.list
brixsat: ok
dileX: add to the line containing squeeze... main blablubbs non-free
brixsat: done
brixsat: updating
brixsat: done :D installed now what?
dileX: reboot
brixsat: brb then :D
brixsat: back
brixsat: dileX :)
brixsat: xorg log --> http://pastebin.com/Yak8fQNx
Ke: still disabled
brixsat: :(
brixsat: :'(
Ke: perhaps you should have rebuilt initramfs, if radeon is loaded from there
brixsat: i found the line you guys told me int he http://www.x.org/wiki/radeonBuildHowTo
brixsat: troubleshouting session but i get zero from that geek talk :p
Ke: did you install the firmware?
brixsat: yes
_ds_: TroubleSHOUTING? :-)
brixsat: http://www.x.org/wiki/radeonBuildHowTo#Troubleshooting
Ke: did it rebuild initramfs?
brixsat: i du not know ke apt-get install .....
Ke: you could pastebin the dmesg
brixsat: yes
brixsat: ke http://pastebin.com/1zbkAkw9
Ke: well at least firmware loading works now
brixsat: =D
Ke: and again
Ke: modprobe radeon before starting X
brixsat: :s
Ke: there is some way to do that using modprobe.d, ask #debian or something
brixsat: do what?
Ke: (01:12:08) < Ke> modprobe radeon before starting X
Ke: someone here had this problem earlier with debian
brixsat: is that what i should ask? how to modprobe radeon before starting X
Ke: something like that
brixsat: :)
Ke: or automatically modprobe radeon
Ke: just in case, you do have xf86-video-ati-6.13
brixsat: yes 2
Ke: ie. this one http://packages.debian.org/squeeze/xserver-xorg-video-radeon
brixsat: one called xserver-xorg-video-ati and another called xserver-xorg-video-radeon
brixsat: thoose 2 in the version 6.13
brixsat: ke i think i must unninstall the xserver-xorg-video-ati don i?
Ke: nope
brixsat: so...
brixsat: ke any other ideia?
Ke: so loading the kernel module in advance doesn't help?
brixsat: no answer on that in debian
mwc: brixsat: IIRC, on debian, the xserver-xorg-video-ati is a dummy package that pulls in -radeon, -r128, and some older stuff
brixsat: .... so.........?
brixsat: mwc, .... so.........?
mwc: I don't think you don't need to install it
mwc: out of curiosity, what do you have in /etc/modprobe.d?
brixsat: http://pastebin.com/NEwwYHbQ
mwc: waht are the contents of radeon-kms.conf?
brixsat: mwc, where is thatt?
mwc: in your /etc/modprobe.d
brixsat: http://pastebin.com/EvYJFVDi
mwc: Hmmm, should already be inserted with modesetting then
brixsat: .....
mwc: do a zcat /boot/initramfs.img-$(uname -r) | cpio -it | grep radeon
mwc: see if the module and that file are in the ramfs
mwc: oh, it's initrd-img on debian
brixsat: http://pastebin.com/TTytZZrv
mwc: ^
mwc: /boot/initrd.img-$(uname -r)
brixsat: http://pastebin.com/eG1mJHry
mwc: wtf
mwc: what do you have in /boot?
brixsat: http://pastebin.com/JyyANqZ4
mwc: cpio -it < /boot/initrd.img-2.6.32-bpo.4-amd64 | grep radeon
mwc: for some reason your zcat is adding a .gz, weird
mwc: er
mwc: sorry
mwc: zcat - < initrd.img-2.6.32-bpo.4-amd64 | cpio -it | grep radeon
brixsat: etc/modprobe.d/radeon-kms.conf
mwc: good
mwc: so the module isn't loading with modeset=1?
brixsat: :)
mwc: brixsat: hmm
brixsat: out of ideias?
mwc: no, what do you mean?
mwc: what's not working?
brixsat: compiz :p
mwc: so you've verified it is a driver problem or what?
brixsat: sorry my pc crasshed
brixsat: mwc what have you told before?
mwc: are you sure this is a problem with how the module is being loaded or what?
brixsat: i dunno but they advised me to come here
brixsat: on #compiz
mwc: glxinfo | grep -i direct
mwc: ues or no?
brixsat: direct rendering yes
mwc: you're running debian, yes?
brixsat: yes
soreau: brixsat: you still haven't installed your firmware?
brixsat: yes i have
soreau: Does 'dmesg|grep firmware' confirm that?
brixsat: [ 29.486609] platform radeon_cp.0: firmware: requesting radeon/R520_cp.bin
soreau: What does 'glxinfo|grep renderer' say now?
brixsat: OpenGL renderer string: Software Rasterizer
soreau: It's still not working. Pastebin your current X log
brixsat: http://pastebin.com/GEWnHikQ
brixsat: any tip?
krytzz: brixsat: (EE) RADEON(0): [dri] RADEONDRIGetVersion failed because of a version mismatch.
krytzz: perhaps you mixed some versions that dont go together?
brixsat: and how can i know?
MostAwesomeDude: You need to load the kernel module prior to starting X.
brixsat: :(
brixsat: ill quit!!!
soreau: brixsat: Does it help if you restart X?
brixsat: Solefald_, no :(
brixsat: soreau, no :(
spreeuw: Solefald_: nice band
soreau: Have you checked the version of libgl1-mesa-dri you have installed?
brixsat: Solefald_, 7.7.1.4
brixsat: 7.7.1.3 :p
soreau: It's loading the radeon ddx 6.13.0 so unless it was built without kms support, MADs suggestion sounds probable
soreau: AFAIC, this is a debian package mismatch and/or out-of-date issue
mwc: if you want to be dead sure the module gets loaded, edit /etc/initramfs-tools/modules and add a line saying "radeon" to that, then update-initramfs -k all -u and
mwc: reboot
mwc: I do something similar on my debian laptop, except there it's i915
brixsat: the /etc/initramfs-tools/module is empty?
mwc: brixsat: /modules
brixsat: :)
mwc: should be some comments in there
brixsat: updating
mwc: zcat - < initrd.img-2.6.32-bpo.4-amd64 | cpio -it | grep radeon
mwc: see that the module found its way into the initram fs, and reboot
brixsat: mwc, http://pastebin.com/Jex688TC
brixsat: mw is it ok?
mwc: looks good
mwc: reboot
brixsat: brb :D
brixsat: back
mwc: brixsat: if all went well, you probably saw your console shift into high resolution early in the boot
brixsat: did not checked :p
brixsat: i was looking to a book :D
brixsat: how can i check?
mwc: dmesg | grep -i fb
mwc: say anything about the radeon framebuffer there?
brixsat: last line --> [ 23.364488] fb0: radeondrmfb frame buffer device
mwc: KMS is definitely working
brixsat: so driver is ok?
mwc: Any problems remaining aren't on the kernel side of things
brixsat: this is what i get when starting compiz
brixsat: http://pastebin.com/NdD746aJ
mwc: very strange. did you ever have fglrx installed?
mwc: the AMD binary driver?
TheBrayn: jehova (scnr)
brixsat: the amd driver maybe /(iv tried to install)
mwc: did you use debian's packages, ie, from apt-get install fglrx-driver
mwc: or did you use AMD's installer
brixsat: amd installer
mwc: sigh
brixsat: :S
mwc: I wonder if you have cruft from that left over
brixsat: "cruft"?
mwc: it overrites the mesa libs with its own implementation of things
brixsat: so ....
brixsat: resinstall mesa?
mwc: debsums libgl1-mesa-glx
brixsat: debsums?
brixsat: not found
mwc: yeah, you'd need to install it then ;)
brixsat: http://pastebin.com/avXNW4Eu
mwc: how about libgl1-mesa-dri? if everything's ok, no need to paste
brixsat: all ok
mwc: Hmm, well, I'm kinda fresh out of ideas
brixsat: :)
brixsat: you have done much :D and i must thank you
mwc: maybe somebody else knows more about fglrx than I can figure out if there's anything left over
mwc: pastebin your /var/log/Xorg.0.log and the output of glxinfo
brixsat: http://pastebin.com/p4dT1BSn
brixsat: http://pastebin.com/1ZTEKnV0
mwc: l. 337: (II) [KMS] drm report modesetting isn't supported.
mwc: wtf.
brixsat: :|
brixsat: what does that mean?
mwc: lines 402-408:
mwc: #
mwc: (EE) RADEON(0): [dri] RADEONDRIGetVersion failed because of a version mismatch.
mwc: #
mwc: [dri] This chipset requires a kernel module version of 1.17.0,
mwc: #
mwc: [dri] but the kernel reports a version of 2.0.0.[dri] If using legacy modesetting, upgrade your kernel.
mwc: #
mwc: [dri] If using kernel modesetting, make sure your module is
mwc: #
mwc: [dri] loaded prior to starting X, and that this driver was built
mwc: #
mwc: [dri] with support for KMS.
mwc: #
mancha: !!!!!!
mwc: very strange
mwc: yeah, sorry about the flood
MostAwesomeDude: Stop flooding.
mancha: pastebin is better than sorry
soreau: I don't think he has kms enabled
MostAwesomeDude: I wrote that message. It means that you have KMS, but didn't load the kernel module before starting X.
mwc: which is strange, because apparently according to dmesg he has the drm framebuffer
MostAwesomeDude: Very strange.
mwc: 20:25 < brixsat> last line --> [ 23.364488] fb0: radeondrmfb frame buffer device
soreau: brixsat: What does 'dmesg|grep modeset' say?
brixsat: [ 22.822790] [drm] radeon kernel modesetting enabled.
brixsat: [ 22.828137] [drm] radeon: Initializing kernel modesetting.
soreau: What about 'lsmod|grep radeon'?
mwc: what do you make of the comment about the kernel providing 2.0.0.[dri] when it requires 1.17.0?
mwc: brixsat: exactly what kernel is this?
brixsat: http://pastebin.com/DaDiUrFb
brixsat: how do i know what kernel?
TheBrayn: uname -a
brixsat: Linux brix 2.6.32-bpo.4-amd64 #1 SMP Thu Apr 8 10:20:24 UTC 2010 x86_64 GNU/Linux
TheBrayn: which distro are you using?
brixsat: TheBrayn, devian squeeze
mwc: brixsat: my debian/testing box doesn't have that -bpo.4-amd64, but instead if 2.6.32-5-amd64
brixsat: mwc, i was told to update it so wifi would work
brixsat: and it does :D
brixsat: any other ideia?
mwc: brixsat: I would try rebooting with the stock debian/squeeze kernel and see if it works
brixsat: 0k
brixsat: back
mwc: what kernel?
brixsat: Linux brix 2.6.32-5-amd64 #1 SMP Tue Jun 1 04:34:03 UTC 2010 x86_64 GNU/Linux
mwc: good
mwc: if you can't get HW rendering to work, check your /var/log/Xorg.0.log for any trace of that incompatibility alert I pasted above
brixsat: http://pastebin.com/CJW064Ty
mwc: line 337. That's frankly bizarre
mwc: I don't have debian running on a box with ATI graphics, so I'm not sure what else to try
mecanork: brixsat, I do not know if this could help your case : http://www.ott.net/knowledge/radeon-kms-on-debian-testing
MVXA: hi, updated my box to linux 2.6.34, xorg-server 1.8.1.902-1, xf86-video-ati 6.13.0 and starting gdm leads to a lot of fun...
MVXA: first the screen goes blank, after switch to console and back to x shows a nice with random data filled screen
MVXA: and dmesg is full of a "wait" blablabla message (couldn't copy the exact message...)
MVXA: at least radeonhd is starting. Anyone here so kind and could help me please?
mecanork: MVXA, anything suspect in your /var/log/Xorg.0.log ?
MVXA: nope, seems fine. No error message and just some warnings about dri being nasty and changing memory map
MVXA: i have a radeon hd 4650 AGP btw...
Droste: brixsat: 2 things: try to start X without xorg.conf and pastebin dmesg | grep -E "drm|radeon"
Droste: MVXA: pastebin xorg.log and dmesg | grep -E "drm|radeon"
MVXA: I need to restart X first, i'm currently using radeonhd... brb
mecanork: Grrr I am trying to track down a nasty bug by myself but no idea about where this beast live :-(
mecanork: does anyone experience random Xorg freezes and/or have some "INFO: rcu_preempt_state detected stalls on CPUs/tasks" logged ?
Daekdroom: Does ubuntu lucid radeon driver have any issue with Radeon X200M (RS482)?
MVXA: dmesg: http://pastebin.org/359472 xorg0.log: http://pastebin.org/359473
Droste: MXVA: custom kernel?
MVXA: i'm using the kernel provided by archlinux
Droste: that's probably a kernel config problem. you could try to work around the problem and use UMS by adding "radeon.modeset=0" to your kernel command line. do you have a package installed named "linux-firmware"?
MVXA: i have
MVXA: shouldn't radeon.modeset=0 implied by nomodeset?
Droste: ah... try using KMS ;-)
MVXA: also happens with KMS enabled...
MVXA: i'm doing something wrong. Something is always breaking up on a system ugprade *sigh*
MVXA: most of the time it hits xorg..
Droste: the output of dmesg with KMS would be more helpful.
MVXA: indeed
MVXA: sadly my box locks up with KMS enabled
Droste: hm
Droste: currently the kernel is resetting you GPU all the time... that's not really a good sign
Droste: MVXA: did you install linux-firmware?
MVXA: yes, i did
Droste: did it work with your old kernel?
MVXA: it did
Droste: which version did you use before 2.6.34?
MVXA: mhhh....
MVXA: 2.6.32
mecanork: brb
Droste: ok I would suggest to downgrade the kernel to 2.6.32. this would disable KMS by default (because it wasn't implemented :-D). I don't think it's a userspace problem.
Droste: and also to file a bug
Droste: or try 2.6.35-rc3
MVXA: requires me to compile the kernel on my own which takes some time...
MVXA: i try to downgrade first
MVXA: and hop this will not break even more things
MVXA: brb