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