02:36 mlankhorst: hm so far parallel piglit is running on my nv96..
02:44 mlankhorst: some kernel spam, nothing major though
02:48 mupuf: mlankhorst: nice!
02:48 mlankhorst: wasn't that supposed to be broken?
02:49 mupuf: never heard it worked without crashing
02:50 mupuf: it means that creating more than 12 contexts does not crash nouveau anymore?
02:50 mlankhorst: lol dno
02:50 mlankhorst: I was doing some crazy stuff P
02:50 mlankhorst:has some patches in his tree
02:51 mlankhorst: mostly debug stuff though
02:52 mlankhorst: one patch that adds guard pages to all vm mappings, another patch to dump the vm space in debugfs, and a patch that removes unneeded duplicate vm mappings..
02:52 mlankhorst: wondering if it's the last patch that made the difference
02:55 mlankhorst: http://paste.debian.net/156254/ debugfs output
03:05 mlankhorst: [27760/27760] crash: 4, fail: 250, pass: 15605, skip: 11899, warn: 2 |
03:17 mlankhorst: meh, d9 still fails inexplicably
03:34 mlankhorst: # grep chid /sys/kernel/debug/dri/0/nouveau_clients
03:34 mlankhorst: chid 1, fence bad0fb4a/b0
03:34 mlankhorst: meh :s
04:20 imirkin: mlankhorst: was that with a full piglit run, or with -x? iirc the glx tests are the ones that tend to cause hangs
04:26 mlankhorst: full, but multithreaded had a hang
04:27 mlankhorst: well crash with random data
04:27 mlankhorst: nvd9 dies somewhere :/
04:27 mlankhorst: not sure how it happens now, but getting a HOST_MEM_TIMEOUT interrupt in PBUS, and PMEM is unreadable..
04:33 imirkin: super...
04:34 imirkin: so basically vram fell off the bus :)
04:36 mlankhorst: probably
04:41 mlankhorst: which is an accomplishment, wonder how you can even do that..
04:54 mlankhorst: hmm.. with proprietary firmware I get a SIG_MISMATCH error..
04:58 imirkin: no clue what that even is
05:52 mlankhorst: looks like the IB playlist has some kind of crc like sig, that one probably has a mismatch
05:54 imirkin: ah
07:07 JethroTux: is that possible to use nvclock-gtk with nouveau driver? thanks
07:12 RSpliet: JethroTux: no
07:14 JethroTux: i've just installed it and it seems working..
07:15 RSpliet: last thing I've heard is that the project was "abandoned", not updated for new GPUs and made mouse cursors magically vanish
07:15 RSpliet: nouveau has it's own clock control code
07:16 JethroTux: i have an old Geforce 4 MX 440
07:16 RSpliet: for that you might be able to have some fun with nvclock
07:16 JethroTux: do you know any program to check gpu-clock?
07:17 JethroTux: to check if the program change the clock for real
07:17 RSpliet: in nouveau? check /sys/class/drm/card0/device/pstate (the pstate node is hidden behind a kernel param)
07:18 RSpliet: there's some toys in envytools too like nvatiming
07:18 JethroTux: cool
07:18 RSpliet: although that last might not work for such an ancient card
07:19 JethroTux: /sys/class/drm/card0/device/pstate. i dont't have that file actually
07:19 RSpliet: (the pstate node is hidden behind a kernel param)
07:19 JethroTux: what does that mean?
07:20 RSpliet: sry, at work, don't have lots of time, but there's plenty to find on pstate on our wiki and/or google
07:20 JethroTux: i got some pstate among kernel headers
07:20 JethroTux: ok
07:20 RSpliet: boot with nouveau.pstate=1 I think and the file should magically appear... I think
07:21 awilliam: does 4.0-rc1 nouveau compile? getting fatal error: subdev/vm.h: No such file or directory #include <subdev/vm.h>
07:22 JethroTux: RSpliet, ok
07:37 JethroTux: RSpliet, you were right. Just need to add "nouveau.pstate=1" as a kernel paramater on grub and reboot
07:38 buhman: of course he's right, it's RSpliet.
08:02 JethroTux: RSpliet, cat /sys/class/drm/card0/device/pstate
08:02 JethroTux: cat: /sys/class/drm/card0/device/pstate: Argomento non valido (invalid argument) why is that?
08:10 RSpliet: JethroTux: if you do that as root: probably because it's not implemented for a card this old
08:10 RSpliet: I thought it was...
08:10 RSpliet: (but then again, I can't say who might have... there's very little use for clock support if the driver doesn't get to change it anyway)
08:11 JethroTux: got it. thanks for support!
08:11 RSpliet: yeah, sorry... normally I'd check code to verify this
08:12 JethroTux: it's strange coz it should support fermi gpus too that are also older than mine
08:13 JethroTux: i have NV18
08:13 RSpliet: JethroTux: no Fermi isn't older
08:13 RSpliet: Fermi is about... 7 years newer
08:15 JethroTux: umh
08:16 JethroTux: sorry fermi stands for NVC0 family
11:03 anarkylibre: is it possible to use nouveau work for bootloading an nvidia card? as in starting up pc with vga via nvidia card without blobs?
11:03 imirkin: nouveau does not provide any VGA emulation
11:03 imirkin: (but i'm not really sure what you're asking)
11:04 imirkin: although you could certainly write a VGA emulator and run it on top of nouveau...
11:06 anarkylibre: imirkin: Thanks. I mean vga init. don't think that deals with emulation, but basically not using any of the binary blobs on the nvidia card while providing vga graphics on machine init. AFAIK the nvidia cards have proprietary bootloaders too, no?
11:07 imirkin: anarkylibre: i think that all modern (at least nvidia) cards emulate VGA via software (installed by the vbios). not 100% sure on that point.
11:07 anarkylibre: so basically are there any free vgabios replacements
11:07 imirkin: anarkylibre: and yeah, the option rom contains code that runs on boot
11:09 imirkin: also note that the vbios contains a bunch of board-specific info, like which connectors are hooked up where, which gpio's, etc
11:18 anarkylibre: imirkin: so the vbios is also vendor-specific
11:18 imirkin: not just vendor-specific... board-specific
11:19 aaronp: imirkin, it's a little of both. VBE is software installed by the VBIOS and triggered by int10 calls. VGA also has low-level register access via I/O reads/writes and the A000 / C000 segment memory regions, and those are handled in hardware.
11:19 imirkin: aaronp: doesn't it have to play nice with whatever software? it's been a while since i've looked at VGA, but you can do a lot more than modify FB contents... color maps... etc
11:20 mlankhorst: every time i look for vga stuff i find all kind of DOS stuff
11:20 aaronp: Yeah. Your OS is expected not to poke the low-level VGA stuff while a real driver is running.
11:20 mlankhorst: party like it's 1992!
11:20 imirkin: aaronp: and pre-nv50 had it all in hw i think, right?
11:20 aaronp: The int10 stuff is always software.
11:21 aaronp: I don't think there's any way of handling an int10 in hardware, since it traps into a CPU interrupt vector.
11:21 imirkin: hm, right.
11:21 imirkin: i just remember using int10 for modesetting
11:21 imirkin: but there's probably more to it.
11:22 aaronp: Right. The int10 vector traps into a VBIOS-installed chunk of software that does "something" to program the display hardware to the required mode.
11:22 imirkin: aaronp: what about text modes?
11:22 aaronp: After switching into protected mode, the only way to execute that is with an x86 emulator or vm86 mode (which is no longer supported)
11:22 imirkin: and then writes to 0b8000 or whereever (it's been so long)
11:23 imirkin: does it have a shader preprogrammed that takes the text and renders it using a font texture or something?
11:23 aaronp: No, that's handled by the hardware somehow. I don't know how it works exactly.
11:23 imirkin: (which gets triggered on writes in that region)
11:23 imirkin: ah hm.
11:23 aaronp: I look forward to the day when we only have to worry about UEFI and efifb.
11:24 mlankhorst: imirkin: vga is sw mode only
11:24 mlankhorst: draw directly to fb
11:24 imirkin: mlankhorst: right... but text mode still works
11:24 imirkin: mlankhorst: in text modes, you write text to "shadow" memory
11:24 imirkin: and then magically that text shows up on the screen
11:25 mlankhorst: probably in sw
11:25 imirkin: [when i say 'text', i mean 'ascii']
11:25 aaronp: mlankhorst, xf86-video-fb accesses the 0xC000 segment directly. xf86-video-vesa gets a physical address that points at one of the GPU BARs through VBE somehow.
11:25 imirkin: sure. just curious what the mechanism is.
11:25 aaronp: er, xf86-video-vga rather.
11:25 aaronp: I'm not sure what the kernel does, but presumably it's something similar.
11:25 mlankhorst: imirkin: just look for old dos docs about vga
11:26 imirkin: mlankhorst: heh. i know what the API is. i used to use it
11:26 mlankhorst: :P
11:26 imirkin: what i'm curious is how modern cards implement it
11:26 imirkin: coz the api is "switch to text mode; write to 0b8000h (or a similar address)"
11:26 aaronp: Yeah, text mode is magical in the hardware somehow.
11:26 mlankhorst: you dont have shaders at that point yet
11:26 imirkin: so it must (a) trap the writes and (b) cause them to get displayed to some FB *somehow*
11:27 aaronp: I think the FB literally contains what you write to 0xb800 and the translation happens at scanout time.
11:27 imirkin: that's how it used to work back in the day. i assumed that modern hw did something a little less special-cased
11:28 mlankhorst: why?
11:28 imirkin: coz you can't get VGA mode back on new cards anymore
11:28 anarkylibre: Im unfamiliar with the nouveau/hardware vga init world, but I suppose from seeing the responses it can be summed up "coreboot-like replacement for vgabios, nope"
11:28 imirkin: i figured it was due to the fact that we overwrite some sw and we could never get it back
11:29 imirkin: anarkylibre: if you're unfamiliar with VGA, you shouldn't be looking into the feasibility of replacing vbios's
11:29 mlankhorst: you need to init too much to replace it..
11:30 anarkylibre: imirkin: thanks for the help. my goal is to become familiar with it so that's why I was asking.
11:30 imirkin: anarkylibre: it'd be an intense first project :)
11:30 mlankhorst: you could work on more beneficial stuff with better payoff
11:30 anarkylibre: well, yes. start smaller.
11:31 imirkin: anarkylibre: besides, not sure if vbios is usually flashable...
11:31 anarkylibre: but really i wanted to see if i can get by with just a hack so I can use my nvidia card and still say my machine is "blob-free"
11:32 imirkin: anarkylibre: not if you're using a modern CPU
11:32 imirkin: (post-2005 or so)
11:32 mwk: imirkin: vbios is perfectly flashable
11:32 anarkylibre: imirkin: yes, unfortunately
11:32 anarkylibre: ive flashed vbios before but it was proprietary
11:32 imirkin: mwk: ah really? on all GPUs [which have one]?
11:32 mwk: should be even quite easy to do
11:33 mwk: imirkin: yep
11:33 mwk: as long as it's visible via PROM, we can flash it
11:33 imirkin: neat, didn't know they had the programming logic on there
11:33 mwk: the programming logic is trivial
11:33 mwk: er, or rather
11:33 anarkylibre: via software, which means it could be done by hardware as well if necessary
11:33 imirkin: i meant electrically
11:33 mwk: in their implementation it is :)
11:33 mwk: imirkin: the electric layer is on the eeprom itself
11:33 imirkin: iirc you need much higher voltages to program EEPROMs
11:34 mwk: your knowledge is outdated :)
11:34 imirkin: hehe ok
11:34 mwk: anyway
11:34 imirkin: at least it's not the x-rays that you need for EPROMs :)
11:34 mwk: the way it works for SPI eeproms (the only kind that matters since NV30 or so) is that the SPI port on GPU can be in two modes
11:34 mwk: normal or manual override
11:35 mwk: in normal mode, the SPI lines are controlled by the cards and any reads to PCI ROM or MMIO ROM range are translated to read commands on the SPI interface
11:35 mwk: in manual override mode.... yeah, you can guess what happens, you get to bitbang the SPI protocol in software
11:36 mwk: just take flashrom, code up a programmer implementation in 100 lines or so, and you should be good to go
11:36 imirkin: hm, how does that actually work though?
11:36 imirkin: don't you need higher voltages to get the electrons to jump to the intermediate gate?
11:37 imirkin: anyways, cool that you don't need a programmer anymore
11:37 imirkin: (i haven't done this in... quite a while... it probably shows)
11:37 mwk: that's not your problem
11:37 mwk: modern chips can make those internally, AFAIK
11:38 imirkin: oh right. with charge pumps and whatnot. never figured out how those worked.
11:38 mwk: and the "higher voltages" are 12V FWIW... nothing exotic for a graphics card
11:39 mwk: the GPU *is* a programmer
11:39 mwk: you can actually take any SPI chip, stuff it on the graphics card, and use it as one
11:39 mwk: except for the "it doesn't have a socket" detail
11:40 imirkin: so some soldering required :)
11:40 mwk: though my NV01 *does* have a socket...
11:40 mwk: it's a parallel chip though, not SPI... those are even easier to program, you just write to the PROM MMIO range instead of reading, heh
11:41 imirkin: i just remember burning a lot of roms for nic to enable network booting... etherboot? something like that. heh.
11:41 mwk: heh
11:41 imirkin: [back before pxe became the thing everyone did]
11:42 mwk: I considered that
11:42 mwk: but none of my NICs had rom sockets... just empty place on the board
11:42 mwk: stupid cheapo crap
11:42 imirkin: they were also EPROMs... so... annoying to rewrite. heh.
11:42 mwk: in the end I just bought ones with pre-burned gpxe [formerly etherboot]
14:01 hakzsam: does someone have recently tried demmio on d9 with nouveau? Because, I have a lot of RAMIN32 stuff and the mmiotrace doesn't seem to be correctly decoded
14:02 imirkin: hakzsam: mind posting your trace?
14:02 hakzsam: sure
14:04 hakzsam: can I send it to mmio.dumps at gmail.com ?
14:04 hakzsam: around 17M
14:06 imirkin: uhm
14:06 imirkin: can you just hastebin the first 1K lines of it?
14:06 hakzsam: okay
14:06 imirkin: or... is it on reator?
14:07 hakzsam: no
14:07 hakzsam: http://paste.awesom.eu/cLL1
14:08 imirkin: you didn't start the trace correctly
14:08 imirkin: note how there's nothing before X is up or glxgears end for that matter
14:09 hakzsam: my bad, yes
14:09 hakzsam: my old script is probably wrong
14:09 imirkin: you probably had the nouveau module loaded before you ran it
14:10 hakzsam: yes, it is
14:10 imirkin: er
14:10 imirkin: nvidia
14:10 imirkin: same diff :)
14:10 hakzsam: yeah :)
14:10 imirkin: you have to start the trace before you load the module
14:10 imirkin: otherwise it doesn't pick up all the mappings it makes
14:11 hakzsam: my script was actually wrong
14:11 hakzsam: let's make an other trace
14:12 imirkin: yes... let _us_
16:28 TD-Linux: imirkin, there are internal charge pumps in the eeprom / flash memory that create the required high voltages
16:29 imirkin: ah cool
19:01 csziacobus_: how do i get nouveau to stop spamming in my kernel log "nouveau E[ DRM] DDC responded, but no EDID for LVDS-1"?
19:02 imirkin: hmmmm....
19:06 imirkin: only thing i can think of is to supply an edid binary on boot
19:06 imirkin: or stop running whatever is forcing it to try to redetect edid on your connectors -- probably some userspace component
19:07 csziacobus_: well, it gives me the message before i even login to tty so it probably wont be a userspace component i can disable...
19:08 imirkin: well, getting it once or twice on boot would be expected
19:08 csziacobus_: true, although i get spammed with it at the login prompt at the console
19:08 imirkin: but if you get spammed, even before starting X, that's unexpected
19:08 csziacobus_: ^
19:09 csziacobus_: yes, it is spamming before X starts
19:09 imirkin: weird
19:10 csziacobus_: how would i supply an edid binary, if that is what
19:10 csziacobus_: s needed
19:10 imirkin: iirc you boot with edid=<path to edid binary>
19:11 csziacobus_: prefixed with nouveau?
19:11 imirkin: no
19:11 imirkin: it's not a nouveau thing
19:11 csziacobus_: ok
19:12 imirkin: drm_kms_helper.edid_firmware
19:12 imirkin: i was close :)
19:12 imirkin: there are a bunch of blobs built-in... what resolution is your screen?
19:12 csziacobus_: 1920x1080
19:13 imirkin: ok, so boot with drm_kms_helper.edid_firmware=edid/1920x1080.bin
19:13 csziacobus_: alrighty, thanks
19:14 imirkin: actually might want to make that drm_kms_helper.edid_firmware=LVDS-1:edid/1920x1080.bin
19:14 imirkin: in case you plug other screens and they're not 1920x1080
19:34 csziacobus_: still spam
19:35 csziacobus_: with this mixed in occasionally nouveau E[ PDISP][0000:01:00.0] INVALID_STATE [UNK05] chid 0 mthd 0x0080 data 0x00000000
20:24 vin_: hi
20:24 vin_: can anyone help me with a problem?
20:25 vin_: i'm having trouble getting the nouveau X driver to work at full res
20:25 imirkin: pastebin dmesg + xorg log
20:25 vin_: the nouveau console is ok, but as soon as i try to run X, the screen gets garbled
20:26 vin_: the interesting thing is, if i try to lower the resolution in xorg config, the screen renders ok
20:32 vin_: http://www.pinerecords.com/kala/_/dmesg.txt
20:32 vin_: http://www.pinerecords.com/kala/_/Xorg.0.log.txt
20:33 vin_: kernel 3.19.0, nouveau_drv.so 1.0.11
20:38 imirkin: nouveau W[ PFB][0000:01:00.0] memory controller reports 512 MiB VRAM
20:38 imirkin: interesting
20:41 imirkin: also interesting that you're using a fairly old X, although i doubt that's related
20:41 vin_: yeah, couldn't get myself to compile a newer one in a couple years :)
20:42 vin_: anyway the older card worked just fine (and it was also a GT210), had to swap it, because it was overheating all the time
20:48 imirkin: can you describe the garbling of the screen?
20:48 imirkin: or perhaps take a photo?
20:48 vin_: very fast flicker
20:48 vin_: 20Hz or so
20:48 imirkin: but nothing in dmesg?
20:49 vin_: yup, zilch
20:49 imirkin: sounds like PDISP get stuck or something, but i thought we detected that now
20:50 imirkin: the only thing that's odd is that warning
20:50 imirkin: do you know how much vram it's _supposed_ to have?
20:50 vin_: 512 MiB is what they sold me
20:51 imirkin: could you boot with nouveau.debug=debug and pastebin that?
20:51 vin_: oh and only the topmost ~5% of vertical screen estate is actually displyed
20:51 vin_: displayed
20:51 vin_: sure
20:58 vin_: http://www.pinerecords.com/kala/_/dmesg_debug.txt
20:59 vin_: the end part lists messages from an attempt to run X at the problematic resolution
21:01 imirkin: hmmm... weird.
21:01 imirkin: nouveau D[ PFB][0000:01:00.0] memcfg 0x00222800 0x0166a020 0x00000001 0xf3010001
21:02 imirkin: that suggests you should have 1G of ram
21:03 imirkin: sorry, dunno what's going on :(
21:04 vin_: it's pretty weird
21:04 imirkin: file a bug
21:04 imirkin: on bugs.freedesktop.org
21:04 vin_: ok
21:04 imirkin: also try a slightly older kernel to see if we messed something up recently
21:04 imirkin: like 3.16 or something
21:04 vin_: what strikes me as totally odd is that the console works at the very same resolution
21:05 vin_: tried 3.14 in the evening
21:05 imirkin: yeah, it _should_ all be the same as far as the kernel module is concerned
21:06 imirkin: same issue with 3.14 i assume?
21:06 vin_: i'm afraid so
21:07 vin_: ok, thanks anyway
21:25 vin_: ehhh
21:26 vin_: 'Option "ShadowFB" "on"' fixes the problem
21:26 vin_: tried all the options one by one
21:26 imirkin: yeah, i mean i bet NoAccel also fixes it
21:26 imirkin: i think it has to do with some form of memory size misdetection and we end up writing too far or... something
21:27 vin_: you're right
21:27 vin_: noaccel also helps
21:40 imirkin: joi: did you ever add a thing to demmt to print out stdout/stderr writes by the program?
21:42 imirkin: joi: i'm trying to add -e sys_write but that doesn't seem to help
22:08 imirkin: joi: hm, i may have been using an old mmt... or maybe a new one. weird.