00:00 NanoSector: imirkin_: intel devs suspect KWin now, going to try GNOME
00:02 mooch2: mwk: any idea what non-standard nvidia features might cause this: http://imgur.com/a/zjwNw
00:08 mwk: uh... not really
00:16 mooch2: mwk: the standard vga regs are at 4 bpp
00:16 mooch2: so this is something to do with the dac
01:04 mooch2: mwk: i'm having an issue with nvidia cards where they upload the wrong dac palette, resulting in the wrong colors
01:04 mooch2: do you know of anything nvidia-related that could cause this?
01:06 nyef: mooch2: As unfamiliar as I am with stuff at this level, I'd suggest either something funky with an endianness control, or some sort of offset magic with the dac.
01:07 mooch2: i don't implement any endianness controls as nv4 doesn't have them
01:08 mooch2: also, i don't see any dac registers being touched other than standard vga ones
01:08 mooch2: mwk: maybe i should have you probe the extended CRTC state on NV3 and NV4
01:09 mooch2: just to see EXACTLY what secrets lie there
01:09 mwk: mooch2: I'm not particularly familiar with the DAC
01:09 mwk: though there should be a 6-bit/8-bit switch somewhere, at least NV1 has one
01:10 mwk: well
01:11 mwk: I've scanned the Kelvin RDI state and a good chunk of its PIPE
01:11 mwk: this is going to *hurt*.
01:13 mwk: though if I can suffer through modeling 100 or so different memory spaces, I should be able to look at rendered stuff at pretty much every stage of processing
01:19 mooch2: yeah, there is one of those, but if you just emulate that and nothing else about the DAC, you get dark colors in the bios
01:39 nyef: ... Damnit, now I'm thinking about emulation again. /-:
01:41 nyef: Actually, along the lines of emulation, reverse engineering, and nvidia hardware, how hard is it to do a pci and usb passthrough and run the windows drivers with an I/O monitor?
01:42 imirkin: should work in theory. i dunno if anyone's ever really done it.
01:44 nyef: I guess my next problem in that direction would be usable windows install media...
01:46 mooch2: nyef: run nv4 drivers on a machine with an nv4 in it AND pci passthrough running nt4 in a vm
01:46 mooch2: log all accesses and get back to me
01:46 mooch2: i need that
01:46 mooch2: also win9x lol
01:46 imirkin: nyef: you're about where i got to on that line of thinking ;)
01:47 mooch2: imirkin, maybe you can do that for nv4 on both nt4 and win9x
01:47 mooch2: that would actually help me A LOT
01:47 imirkin: mooch2: i don't have a nv4. and i don't have win9x install media.
01:48 mooch2: just pirate win 98se lol
01:48 nyef:has 98SE and XP media.
01:48 mooch2: great, nyef! now all you need is an nv4 lol
01:48 mwk: you'd need to find some hardware that supports PCI passthrough *and* supports actual PCI
01:48 mwk: or AGP, but I think that's impossible
01:49 mooch2: agp is pretty close to pci software-wise, actually
01:49 mooch2: agp passthrough shouldn't be that much of an issue tbh
01:49 nyef: The problem is that I want to be testing something specific on a card that came on a Win7 machine.
01:49 mwk: yes, but PCI passthrough support is something new hardware supports
01:49 mooch2: ah
01:49 mwk: and AGP is something that old hardware supports
01:49 mwk: these are hard to combine :p
01:49 imirkin: mwk: i think it should work if you pass the whole PCI bus through
01:50 imirkin: mwk: dunno if there were PCI NV4's, i def have a PCI NV5
01:50 mooch2: mwk: well, do you have any way of logging stuff like that?
01:50 nyef: What's needed for the PCI passthrough, an IOMMU, specific CPU virtualization, or something else?
01:50 mooch2: imirkin, i'm emulating a pci nv4 with an agp bios
01:50 mwk: I dunno about NV4, but yeah, NV5s exist
01:50 mooch2: so it was definitely POSSIBLE
01:50 mooch2: i also have nv3 and nv5
01:51 mwk: and NV3s for that matter
01:51 nyef: Hunh. I can actually set up hardware with a dedicated PCI bus that isn't needed for anything else.
01:51 nyef: As in, I have such hardware lying around.
01:51 mooch2: ooooooooooooh
01:51 nyef: With the problem being that it's SGI Octane hardware.
01:51 mooch2: i might need you to run some nv4 tests for me then!
01:51 mooch2: oh
01:52 mooch2: yeah, that would be a problem
01:52 nyef: ... Okay, or Origin 300.
01:52 nyef: I'm fairly sure the Origin 300 has an XBridge for the PCI slots that is separate from the one for the built-in hardware.
01:54 mooch2: wait, why isn't pci passthrough of one device possible in software without an IOMMU?
01:54 imirkin: suh-low
01:54 mooch2: i mean, you could just take the physical address that the OS in the VM writes to, pass that along
01:54 mooch2: ???
01:55 nyef: At least one problem is DMA.
01:55 mwk: yeah... PCI devices have DMA capabilities to host memory
01:55 mwk: that ends very badly
01:55 mwk: so you need an IOMMU
01:56 nyef: You need some sort of per-busmaster address mapping at the PCI bus level.
01:56 mwk: also, shared IRQs on PCI are also a bit of a problem
01:57 nyef: ... Which might actually need completely separate bus lines to each PCI slot, if I'm correctly remembering how PCI works.
01:57 mooch2: welp
01:58 mwk: nyef: should be enough for the IOMMU to watch the request/grant lines
01:58 mwk: so, doable in principle without extra mb traces
01:58 mwk: well, except the IRQ mess
01:58 nyef: Right, plausibly need per-slot IRQ lines.
01:58 mwk: right
01:58 nyef: And that doesn't help if you have a PCI-PCI bridge, unless you passthrough the entire bridge.
01:59 mwk: of course
01:59 mooch2: i really need some help with my nvidia emulation :(
01:59 mwk: so: it's a horrible mess
02:03 mwk: eh
02:03 mwk: so many things to do, so little time
02:17 nyef: Okay, next angle: I pick up an MXM Quadro from eBay, and fire up usbmon.
02:19 mwk: ... what?
02:20 nyef: I'm trying to get the 3D Vision emitter going.
02:20 mooch2: mwk: what other things are you working on besides nvidia stuff???
02:21 mwk: mooch2: well... work
02:21 nyef: I found sample code that somewhat-works, in that it gets the glasses to flicker, but the timing is wrong for my hardware.
02:21 mooch2: i thought that was part of your work???
02:22 mwk: mooch2: https://codisec.com/veles/ that's what pays my bills... might be a great tool some day
02:22 mwk: not really, no
02:23 nyef: So I figure, get the "proper" drivers going, somehow, with a monitor on the USB transactions to the emitter, and known display configuration (EDID on record, as many refresh frequencies as are supported), and work out the details from there.
02:27 nyef: Now, for the card I have, the only "proper" drivers that will drive the emitter are some directx thing, and that means dealing with windows in some fashion.
02:28 nyef: Which is an option, but not a good one.
02:29 nyef: But the linux nvidia drivers will drive an emitter if you have a suitable quadro card.
02:29 imirkin: heh, but i doubt there's a lot of care left for the sync'd 3d glasses via 3-pin din thing
02:29 nyef: With the follow-on problem being "sure, they'll drive an emitter, just not the emitter that's actually built into a laptop".
02:30 imirkin: probably more worthwhile to get it talking to a hdmi 3d screen
02:30 nyef: Mmm. In this case, it's a sync over USB, but I know what you mean.
02:30 nyef: Overall, though? I want BOTH.
02:33 imirkin: *at the same time* :)
02:34 nyef: That... would actually be useful for multiplayer games.
02:42 mooch2: <mooch2> the dac write index register is set twice (!!) instead of once like it should be
02:43 mooch2: any idea what this could mean?
02:44 nyef: mooch2: Too many possibilities. Is it set to different values each time?
02:46 mooch2: no, it's always set to 0
02:47 mooch2: mwk, imirkin: wtf does this do? https://github.com/envytools/envytools/blob/master/rnndb/display/nv3_pramdac.xml#L92
02:47 mooch2: it's set to 1 in the nvidia bios
02:48 mwk: oh, that
02:49 mwk: it's a weirdo feature of NV1 and NV3
02:49 mwk: likely NV4 too
02:49 mooch2: yeah, the nv4 bios is using it
02:49 mooch2: what does it do?
02:50 mwk: basically: when in 16bpp or 32bpp mode, the highest bit of a pixel selects its mode
02:50 mwk: if 0, it's an indexed pixel, and it'll be looked up in the palette
02:50 mwk: if 1, it's a truecolor pixel, and it'll go straight to the DAC
02:50 mooch2: oh god
02:50 mooch2: well, this is in text mode that it's using it tho
02:50 mwk: so you can have per-pixel indexed color vs direct color selection
02:50 mooch2: and it sets it to 1, not 0 or 3
02:51 mwk: that's strange
02:51 mwk: but then, I wouldn't trust rnndb too much
02:51 mooch2: some other docs i have call that setting NV_PRAMDAC_GENERAL_CONTROL_PIXMIX_POS
03:04 nyef: At least in some respects, you know what the colors are supposed to be, though, right?
03:05 nyef: Maybe you can work from that to figure out what's going on with the card?
03:05 mooch2: IT WORKS
03:06 mooch2: it turns out the bug was in my pci handling lol
03:06 nyef: Congratulations.
03:09 mwk: huh, Rankine seems to actually have fewer weirdo memory spaces than Kelvin
03:10 imirkin: curie should be a breeze ;)
03:11 mooch2: mwk: it turns out the latest nt4 drivers for nv4 require not only sp4, but also ie4
03:12 mwk: hmm
03:12 mwk: no Curies plugged in to any machine I have turned on...
03:12 mwk: I can fix that..
03:13 imirkin: did nt4 ship with ie4? or ie3?
03:13 imirkin: yeah, probably not ie4. win98 came with that.
03:13 mwk: weren't these the good old times when web browser was actually separate from the OS?
03:15 mwk: well, fuck. RDI is gone on Curie.
03:15 mwk: or at least moved somewhere I can't find it
03:15 imirkin: i thought you were out of agp slots :p
03:15 imirkin: oh, but i guess it's probably pcie
03:16 mwk: IGP, actually
03:17 mwk: FWIW I ran out of AGP slots with Kelvin, the Rankine I'm using is a PCI craptastic NV34
03:17 mwk: ie. half-Celsius
03:17 mwk: poor thing.
03:18 imirkin: heh
03:18 imirkin: i have that same one plugged in too
03:18 imirkin: 09:01.0 VGA compatible controller [0300]: NVIDIA Corporation NV34 [GeForce FX 5200] [10de:0322] (rev a1)
03:18 mwk: it makes me think of the Frankenturrets from Portal 2
03:19 mwk: yeah, same thing here
03:23 nyef: Okay, plan... D, I think: I found the windows restore CDs for this machine. Pull the disks, throw in a spare disk, install windows, install usbsnoopy or something like that, get the traces that I need, swap the disks back, analyze the data.
03:25 mooch2: imirkin: nt4 came with ie2
03:26 imirkin: nyef: i've had good experience with installing into a vm directly
03:26 imirkin: by passing some minor items through
03:26 nyef: imirkin: Problem is, the "minor item" that I'd need to pass through is the only video card in the system.
03:27 imirkin: ah yeah
03:27 nyef: Also possibly the DMI data and whatnot, since it's an oemact license.
03:28 imirkin: yeah, that's the bit i've been able to pass through fine
03:29 imirkin: https://hastebin.com/ukukeweqos.rb
03:29 imirkin: you get the various values from dmidecode
03:29 imirkin: feed them to qemu
03:30 imirkin: but yeah, if you have to pass your only gpu through, that becomes a little more tedious
03:44 mwk: well, Curie doesn't want to talk to me
03:45 mwk: I guess I'd have to involve a ctxprog... messy, messy
03:51 mooch2: hey, does anybody know a modern linux distro that works on pentiums?
03:51 mooch2: like the original pentium 1
03:52 imirkin:wonders if debian still has a 586 build
03:52 imirkin: i think most binary distros are 686+
03:52 imirkin: i.e. ppro and up
03:52 mooch2: well, this emulator has VERY shoddy 686 support
03:53 mooch2: win2k and xp bugcheck during setup with it for instance
03:53 imirkin: debian is nominally i386, but i'm sure they don't build it for literal i386 support
03:53 imirkin: esp since linux dropped the original 80386 from its supported list
03:54 mooch2: yeah
03:54 mooch2: i just need 586 support
03:54 mooch2: 586 is fairly well working in 86box
03:55 nyef: Gentoo, maybe? You might need to cross-build, though.
03:55 mooch2: i need one that comes with x11
03:56 nyef: So?
03:57 mooch2: gentoo doesn't come with that already installed
03:58 nyef: True, and I'm talking about possibly having to do a bootstrap and stage-1 build of it anyway.
03:59 nyef: Maybe try fixing the pentium support? It's all about the pentiums, after all. d-:
04:02 mooch2: pentium 1 works
04:02 mooch2: pentium pro, not so much
04:02 mooch2: we don't even know where the problem is
04:05 imirkin:can't even remember what ppro added... pentium had cmov and a bunch of other stuff...
04:06 imirkin: ah no. it *was* cmov that it added.
04:06 imirkin: and the ever-important ud2 :)
04:14 mooch: imirkin, ud2 was there before ppro
04:14 imirkin: yeah, but ppro documented it
04:15 imirkin: before it was just like any illegal op
04:15 imirkin: whereas ppro+, it's reserved as a forever-illegal op
04:15 mooch: also, we still don't emulate smm or apm
04:29 mooch2: mwk: maybe you should make some more human readable docs too!
04:33 nyef: mooch2: Maybe you could make some more human readable docs as you figure things out?
04:33 mooch2: i tried that
04:33 mooch2: but i'm just not good with docs
04:33 mooch2: AW SWEET, SLACKWARE SUPPORTS 486!
04:41 nyef: ... I think that the last time I ran slackware I *had* a 486. d-:
04:41 imirkin: i had a pentium mmx ;)
04:42 imirkin: oh wait, i also ran it on my amd tbird and later tbred. good times.
04:42 imirkin: and then i discovered gentoo
05:47 orbea: after switching from 4.9.0 to 4.10.0-rc2 my screen will freeze if I resume from a xscreensaver after too long. The mouse cursor and keyboard still work so I can just close xorg and open it again... xorg log: http://dpaste.com/2FFVD7V dmesg: http://dpaste.com/1873T1Z syslog: http://dpaste.com/29XB0DY
05:47 orbea: the firmware bug in the syslog was in 4.9.0 so can be ignored...
05:53 mooch2: lmao i'm downloading envytools in an emulator using a pci ne2000 clone
05:53 mooch2: 88 KB/s
07:37 Cerpin: Is it likely nvenc is ever going to be supported sans nvidia sdk stuff?
07:42 funfunctor: does anyone have a useful bit of python script or something to help deal with refining out repeating patterns in mmiotrace(s) ?
12:56 mwk: mooch2: I definitely plan to write some human readable docs too
12:56 mwk: but RE comes first
12:56 mwk: right now there are only a couple bits I could fully describe
16:13 imirkin: skeggsb: sounds like orbea might be having issues with the new atomic modesetting...
16:13 imirkin: orbea: what do you mean by "close xorg and open it again"? like switching back and forth between vty's?
16:14 orbea: i use a window manager called spectrwm, it has a keybind to close itself / xorg and go back to a non-graphical environment, I just press that
16:15 orbea: its happened twice so far btw, I will need to test further if I can find a good way to reproduce it
16:16 imirkin: "close xorg" is not an action i'm familiar with
16:16 orbea: switching to ttys works too though
16:16 orbea: well, my very impercise way of saying it...
16:17 imirkin: WMs can restart themselves without killing xorg or any of the applications
16:17 orbea: it has that too
16:17 orbea: i just use startx so when spectrwm closes xorg goes with it
16:18 orbea: and my screen is no longer stuck at that point
16:19 imirkin: sounds like switching vty's is the easier solution...
16:19 orbea: yea, the vtys won't be stuck, but going back to my xorg session and screen is the same, still stuck
16:20 imirkin: interesting. perhaps i don't understand what you mean by "stuck"
16:20 orbea: the video input is frozen, only the mouse cursor and keyboard still work (keybinds work)
16:21 imirkin: huh. ok. this is definitely one for ben ;)
16:21 orbea: alright :)
16:21 imirkin: and this only happens after DPMS?
16:22 orbea: that is what IM not sure on yet, only has happened when I hav gotten up and came back to teh computer maybe 15-30 minutes later
16:22 imirkin: k
16:23 orbea: xscreensaver will first activate, than lock the screen and then blank / suspend the screen and monitor. so it has to be something in that...
16:23 orbea: but it doesn't happen right away
16:25 imirkin: well, i think the new logic triggers a full modeset on dpms resume
16:40 orbea: i can't trigger it with xset dpms force off / standby / suspend.
16:44 orbea: imirkin: spoke too soon, I can reproduce it....: sleep 10 && xset dpms force suspend (Now immediately activate xscreensaver / lock screen)
16:57 orbea: i'll just disable power management in xscreensaver so it doesn't happen automatically I guess :)
18:13 mooch2: mwk: ah okay
19:49 NanoSector: imirkin: around?
19:50 imirkin_: .
19:50 NanoSector: heh
19:50 NanoSector: going to netconsole to my laptop now, see if that results in anything
19:51 imirkin_: so noted.
19:51 NanoSector: wut
19:52 imirkin_: http://english.stackexchange.com/questions/239350/what-does-it-mean-when-someone-says-noted-to-you
19:53 NanoSector: you didn't want to know? :(
19:53 imirkin_: what would you like me to do with that information?
19:53 NanoSector: i dunno, thought you wanted to know
19:53 imirkin_: anyways, those answers make it sound a lot more negative than i intended
19:53 imirkin_: i use it as more like "understood, but there's nothing for me to do here"
19:54 NanoSector: :)
19:54 NanoSector: there isn't
20:05 nyef: Mmm. I typically use "so noted" as "I hear you, and may keep it in mind for future reference."
20:07 nyef: Well, not "I hear you", but "communication recieved".
20:08 nyef: For me, "I hear you" means "communication recieved, you're completely wrong or off-base, I'm not about to take action on this, but I'm also not going to spend time or energy arguing with you about it now."
20:09 NanoSector: 'i hear you' comes over as 'i can relate to that'
20:12 mooch: i'm compiling envytools in 86box lmao
20:22 NanoSector: ugh, can't get netconsole to work
20:41 orbea: I have an interesting potential issue? RetroArch is currently experiencing a silly crash when any core is loaded and then a special core is loaded next (i.e. Remote Retropad). While this has nothing to do with nouveau, running the crash in valgrind shows that nouveau seems to leak a lot when RetroArch crashes. Is this expected? See the valgrind log (its big) -
20:41 orbea: http://ks392457.kimsufi.com/orbea/stuff/logs/libretro/nouveau-retroarch-crash-valgrind.log
20:41 imirkin_: leak is probably too strong a comment
20:42 imirkin_: it's memory that's not freed as a result of the contexts not being destroyed
20:42 imirkin_: and/or library
20:42 imirkin_: also, this has nothing to do with nouveau - this is mesa core
20:42 orbea: ah, my mistake
20:43 orbea: would it be something worth bringing up with mesa?
20:44 imirkin_: maybe... i think it's just retroarch not properly calling dlclose. dunno.
20:44 imirkin_: or perhaps mesa isn't handling it
20:45 orbea: i'll se if the retroarch devs feel they got it right or ot
20:45 orbea: *not
20:45 imirkin_: it's a tricky issue
20:45 NanoSector: imirkin_: netconsole doesn't give me any output after sleep
20:45 imirkin_: there might not be a great way to resolve it given retroarch's architecture. dunno.
20:45 imirkin_: NanoSector: :(
20:45 imirkin_: NanoSector: i assume there's no serial port on the laptop?
20:45 NanoSector: nope :P
20:46 NanoSector: usb and ethernet, and then displayport and hdmi
20:46 NanoSector: ends there
20:49 NanoSector: imirkin_: suppose there's nothing more to try?
20:49 imirkin_: sorry, not sure.
20:49 NanoSector: :(
21:29 nyef: NanoSector: Can you ssh into the machine post-sleep?
21:29 NanoSector: nope
21:29 NanoSector: looks like it gets completely stuck somewhere
21:30 nyef: ... There's some sort of RTC sleep debug trace thing, maybe that can help narrow it down?
21:31 imirkin_: fwiw i've tried that, and it can cause various unhappiness in the hw
21:31 imirkin_: and is not particularly easy to use
21:31 nyef: Oh, lovely.
21:31 imirkin_: i'm 95% sure that this is what caused my thinkpad to not boot 50% of the time for a while
21:31 nyef: Yeah, it didn't seem very friendly, but it's a tool for tracking down not very friendly suspend problems, so...
21:31 imirkin_: (where when it got into a non-booting state, it would require 10-20h of "off" time until it booted)
21:32 imirkin_: but then it magically started working again. i haven't complained.
21:32 NanoSector: my laptop sometimes takes 10s after power button press to actually turn on
21:32 NanoSector: sometimes creeps me out
23:19 Arbition: Does anyone know if using DRI_PRIME=1 is inhereted by all spawned processes of that program? That is, if I am launching a game that uses a launcher using DRI_PRIME=1, would the spawned actual game also do that?
23:24 karolherbst: Arbition: same rules apply as for all environmental variables
23:24 Arbition: guess I have some research to do then
23:25 karolherbst: well usually the environment is copied, but child processes can mess with things, and also the kind of launching that child process matters
23:28 Arbition: That's what I suspected, there isn't any certainty
23:28 Arbition: I'll try to launch the process directly I guess
23:31 Arbition: hmm it is launched with an sso token, so I just copied the process arguments as launched from the launcher and transferred it manually
23:31 Arbition: didn't like the auth token...
23:31 Arbition: oh well
23:37 imirkin: Arbition: depends on how the exec is done
23:38 imirkin: Arbition: a whole new separate environment could be created
23:38 imirkin: e.g. look at execve args
23:38 Arbition: yeah that's what I'm wondering. Given it is going through wine, there could be a whole slew of stuff that happens
23:49 nyef: ... That sudden realization that looking for the appropriate configuration for a bluetooth apple keyboard in gentoo on your main gentoo box is inappropriate because you've only ever paired them with debian boxes before. /-:
23:52 nyef: And, of course, there are two completely different mechanisms to use, depending on if the HID driver is a module or built-in.