spstarr: airlied: can you set yours to 256?
spstarr: i wonder if you'll see corruption
airlied: nope, iots limited in my bios to 32MB
airlied: but I would think that would give me more chances of seeing it than not
airlied: checks bios again
spstarr: the driver can't override bios setup?
airlied: not for AGP bridges.
airlied: damn can't enter my BIOS remotely.
spstarr: PAT is disabled on this
spstarr: PAT WC disabled due to known CPU erratum.
airlied: I'll boot with pat off
spstarr: ok
spstarr: corruption?
spstarr: airlied: -62 i have detected very, very small corruption with non-KMS + EXA
spstarr: airlied: http://www.sh0n.net/spstarr/exa-icon-corruption.png
spstarr: DFS enabled though
airlied: spstarr: does the kernel print out any setting agp_base agp_location for you?
spstarr: messages:Dec 10 00:02:38 segfault kernel: [ 1.937013] [drm] setting agp_base to d0000000
spstarr: agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0xd0000000 <- matching base addr
spstarr: [ 1.937013] [drm] setting agp_location to d0000000
airlied: okay sounds fine then.
spstarr: Dec 10 00:02:38 segfault kernel: [ 1.936741] [drm] Detected VRAM RAM=65536K, accessible=65536K, BAR=131072K
spstarr: is not familiar with PCI BAR
spstarr: sleep will read backlog from spstarr_work
ossman: airlied, I managed to get a kernel GPF when doing some video torture tests. nomodeset and git HEAD
ossman: anything you've seen before?
ossman: I was hoping to get more details, but for some reason I cannot reproduce it this morning. I got the crash on every attempt last night...
spstarr_work: hmm
spstarr_work: looks at koji
rsleza: je tam neco, co hodne potrebujes?
spstarr_work: doesn't speak Czech :/
rsleza: is stupid and types in a bad pane
spstarr_work: hehe
rsleza: wrong pane
adamk_: rnoland, No luck. Direct rendering fails. Give me a second to get you the error.
rnoland: hrm
adamk_: rnoland, "(EE) RADEON(0): [pci] Out of memory (-12)"
adamk_: (EE) RADEON(0): [pci] PCI failed to initialize. Disabling the DRI.
adamk_: The drm tree, without your patch, works fine.
adamk_: At least as far as I can tell from here :-)
rnoland: hum
rnoland: let me see why it is reporting ENOMEM
adamk_: I'm not seeing anything interesting in dmesg. I see requests for pci_enable_busmaster and pci_disable_busmaster, and leaked memory.
rnoland: leaked memory?
adamk_: rnoland, Warning: memory type drm_bufs leaked memory on destroy (2 allocations, 64 bytes leaked).
rnoland: hrm.... ok...
rnoland: hrm, it isn't obvious to me why it's failing...
adamk_: Think I need to reboot and can't just kldunload the old driver and load the new one?
rnoland: well, i have seen issues with that on intel...
rnoland: it *should* work, but things get confused sometimes...
adamk_: Hmmm.
adamk_: I'll reboot and let you know.
rnoland: ok thanks...
rnoland: if that doesn't get it... i'll need to add some debugging...
ossman: I'm getting "fragprog wants coords for tex1, vp doesn't provide them!" on RS690. is there some limitations with drm on that chip?
ossman: oh, and X goes into some busy loop and refuses to die
glisse: ossman: with which applications ?
glisse: ossman: this is mesa which is complaining i believe
ossman: glisse, mplayer, using its yuv420p conversion fragment program
glisse: mplayer with glbackend ?
ossman: yes
ossman: -vo gl:yuv=2
adamk_: rnoland, Wow, that did it :-)
glisse: well then there is likely a bug in mplayer glbackedn
rnoland: cool
glisse: a missing texture coordinate
ossman: glisse, since it locked up X, I'm not entirely convinced :)
rnoland: adamk_: so i'm looking for any performance differences, good or bad... artifacts better or worse...
ossman: and mplayer worked fine on an R500
glisse: ossman: well lockup is likely to happen when you get such message
ossman: with the same backend settings
adamk_: rnoland, For that I'll have to wait till I'm home.
rnoland: adamk_: can you show me an xorg.log?
glisse: basicly somewhere there is somethings missing and gpu doesn't like when it doesn't have all data
rnoland: adamk_: ok, no worries...
glisse: then this could be a driver bug, in swtcl path
ossman: glisse, this message is sent based on feedback from the chip, not by the driver analysing the calls?
glisse: which never was solid
adamk_: rnoland, Looking at my log file, I noticed a new problem... /usr/local/lib/dri/r300_dri.so doesn't exist though the graphics/dri port is installed.
glisse: send from driver analysis
adamk_: rnoland, http://pastebin.ca/1281777
glisse: somewhere in cmdbuffer iirc
glisse: r300_cmdbuffer.c
ossman: glisse, why does it lock up X though if it figures out the problem before sending stuff to the hw?
glisse: maybe in r300_state.c
ossman: that file is mentioned elsewhere in the output, yes
glisse: because i think it stills send stuff to chip hopping for the best :)
ossman: ah
glisse: but as usual the worst happen
ossman: I need the cynical version of the driver then :)
adamk_: rnoland, I'm rebuilding the port now to see if anything jumps out at me.
ossman: glisse, so fixing this would require poking around in mesa?
rnoland: adamk_: ok, cool
chithead: adamk_: isn't r300_dri.so part of mesa?
rnoland: chithead: yes, that is what we are looking at now...
adamk_: Well on my work machine, it's part of the graphics/dri port
rnoland: adamk_: yes, that is part of the mesa goo that is in ports...
rnoland: adamk_: mesa is broken up into about 5 ports...
adamk_: Yeah, pkg_info -L dri-7.2,2 reports /usr/local/lib/dri/r300_dri.so but /usr/local/lib/dri does not exist.
rnoland: the dir doesn't exist?
adamk_: Nope.
rnoland: you try reinstalling?
adamk_: Juyst did.
rnoland: still not there?
adamk_: Nope.
adamk_: One second.
adamk_: It's not building the drivers.
adamk_: http://pastebin.ca/1281784
adamk_: Driver: xlib
rnoland: oh, hrm... wonder if i accidentally screwed up the mesa port while testing osmesa....
adamk_: lol :-)
rnoland: bah....
rnoland: yes, looks like thats it....
adamk_: Cool. My drm problems were my own fault. My DRI problems are yours :-)
adamk_: At least I'm not 2 for 2 :-)
rnoland: hehe....
adamk_: brb
rnoland: k
rnoland: adamk_: paste me the Makefile for that port...
rnoland: brb....
adamk_: rnoland, http://pastebin.ca/1281793
rnoland: hrm, ok... it's graphics/libGL/bsd.mesalib.mk that is screwed up...
rnoland: adamk_: i don't have access to that ports tree right now, so if you wanna paste it, i can tell you what i broke
adamk_: http://pastebin.ca/1281800
rnoland: adamk_: hrm, now i'm suspecting flz....
adamk_: lol
rnoland: adamk_: ok, i'm confused... I don't see any of my OSMesa stuff here... or any reason it would be trying to build it...
glisse: ossman: yup
rnoland: adamk_: something is messed up with your ports tree...
adamk_: Damn.
adamk_: I guess I can wipe it clean and re-csup it.
rnoland: the patch i posted does have the osmesa stuff in it, which it shouldn't, but...
rnoland: it doesn't match what you pasted me...
adamk_: The xorg 7.4 patch?
adamk_: Hmm... I have a working ports tree on my x86 machine here. I wonder if I should just rsync it over and use that till Xorg 7.4 is in ports.
rnoland: xorg-7.4-111608.patch is the one that I'm looking at...
rnoland: flz has the master xorg ports repo... mine is in chaos right now working on xserver 1.6 and friends...
adamk_: Hmmm.. The patch I have is dated October 28th, so that one is newer.
rnoland: http://people.freebsd.org/~rnoland/xorg-7.4-111608.patch
adamk_: Thanks :-)
rnoland: it does have the osmesa stuff in it, like i said... but i don't think it broke anything... osmesa might not work though...
adamk_: That's fine with me :-)
lbt: hi - I'm playing with NVLoadProgram which is crashing NWN - are "vertex programs" NVidia specific?
glisse: no
lbt: OK - the only doc I've found : http://oss.sgi.com/projects/ogl-sample/registry/NV/vertex_program.txt isn't clear
lbt: When NWN calls NVLoadProgram it crashes; https://bugs.freedesktop.org/show_bug.cgi?id=18452
lbt: I'm trying to change the vertex program to stop it crashing or identify the opcode that is problematic
lbt: I have an LD_PRELOAD interceptor for glLoadProgramNV and I can see the vp that's being loaded
lbt: does this sound like a sensible way to go about debugging this?
glisse: lbt: how does it crash ?
lbt: sadly it just says "Aborted"
lbt: however when I just do a 'return' on NVLoadProgram
lbt: any character cloaks appear invisible
tilman: http://files.code-monkey.de/nwn-fix_stderr.tar.gz
tilman: that might help... if mesa puts some information on stderr :p
glisse: lbt: your hw is rv350 ?
lbt: rv500
lbt: (my wife has RV350)
glisse: if so the shader is likely too big for this card and we might not report it back to applications
lbt: tilman: ah, I was intercepting fclose - which is why it didn't work :)
lbt: I open /dev/tty for my debug - ta!
tilman: lbt: i used it to mostly fix nv vp related bugs in mesa myself, some years ago :D
lbt: OK - getting a segfault on crash now, let me see
airlied: ossman: its the swtcl code
ossman: airlied, known offender? :)
airlied: well it needs more work.
airlied: it doesn't get that well tested.
airlied: and people break it a lot.
ossman: k
lbt: OK - segfault was me screwing up opening a file - nwmain: main/state.c:1030: update_program: Assertion `ctx->VertexProgram._Current->Base.Parameters' failed.
lbt: and I have the vp in a logfile
lbt: http://pastebin.com/d2e4122bb
lbt: does that error help?
lbt: glisse: tilman: does that error help
lbt: so glLoadProgramNV is declared as void APIENTRY glLoadProgramNV - which suggests that it doesn't return a value... which seems odd
spstarr_work: airlied: any info? :)
airlied: spstarr_work: no I try to sleep at nights.
spstarr_work: :)
lbt: can anyone help me to narrow down this problem? just some pointers :)
lbt: can anyone help me to narrow down this problem? just some pointers :)
lbt: Assertion `ctx->VertexProgram._Current->Base.Parameters' failed.
airlied: agd5f_: ping
spstarr: hmmm
VerticalAsymptot: hmm
z3ro: hmm I got to work way too early. there's noone here :P
spstarr: work?
spstarr: it's 12:20am ;-)
z3ro: 7:23 here
z3ro: (am)
VerticalAsymptot: spstarr, what state?
z3ro: helsinki, finland
spstarr: Canada ;)
VerticalAsymptot: :P
spstarr: Ontario, Canada
VerticalAsymptot: not many people are in eastern standard time
VerticalAsymptot: like myself
tlp: Having some trouble getting a 1366x768 HDTV display to work properly at any resolution on an AGP R500 card.
tlp: when the screen manages to display anything at all, it's all screwed up, like the modeline is wrong or something.
agd5f_: airlied: pong