02:44mystified: Hi guys can you help pls with my nouveau driver issues.
02:44gnarface: probably not, but i'm willing to try once
02:46gnarface: of course, you'll have to actually describe some of the issues for anyone to be able to help you with them. there's more potential problems than anyone is capable of guessing at.
02:46gnarface: (incidentally, its also a good idea on IRC to lead with the description of the problem, instead of waiting for permission)
02:48mystified: Thx @gnarface
02:48mystified: Just off pasting the issues
02:49mystified: brief descrip. Just installed Alpine for the 1st time.
02:49gnarface: mystified: well, i can't say i've seen this before, but at first glance it looks like you've somehow installed a nouveau driver version that wasn't compiled to match the rest of your Xorg install...
02:49mystified: I've followed an install guide off youtube.
02:50gnarface: mystified: those "symbol not found" errors mean the library is missing a variable that whatever tried to load it was expecting to be there. this is a classic example of version mismatch. youtube is a TERRIBLE place to get linux help.
02:50mystified: Maybe. It had to do with them including in the guide. VM drivers
02:51gnarface: most types of VMs require special video drivers
02:51mystified: so if i remove the vm drivers
02:51gnarface: then nothing will work
02:52gnarface: its important to note that a VM is NOT the same thing as a bare-metal install when it comes to things like your video card drivers.
02:52gnarface: they cannot be used interchangeably
02:52gnarface: (usually not, at least)
02:53gnarface: if this is VMware you're trying to use, i know they do provide special packages, and i believe they're in debian's non-free branch
02:53mystified: This is a bare metal install
02:54gnarface: for best results, you should get the nouveau driver, Xorg and kernel packages all from your distro's official repos, and for the right version of your install (don't mix&match)
02:54gnarface: if this was an install you copied from a VM originally, or if you followed a video whose instructions were VM-specific, that could also lead to these types of trouble
02:55mystified: I followed the install guide, they were installing it on a vm, and the first Gpu driver installed was vm
02:56gnarface: so you followed a 3rd-party VM installation video for your distro, but did it on the bare metal? yea, i wouldn't expect that to work
02:58mystified: no was on vm
02:58gnarface: hmm. earlier you said it was a bare metal install?
02:58mystified: mine was bare metal
02:59gnarface: try a guide that is for bare metal
02:59gnarface: do not use a VM installation guide for a bare metal install
03:00gnarface: chances are you did extra work that broke it
03:00gnarface: this did not save you time
03:00mystified: I'm on the machine at this moment
03:01mystified: it's a resolution issue.
03:01mystified: no glxgears
03:02gnarface: in the log you showed me, it failed to even load the nouveau driver at all. this means the resolution issue is a red herring. you're falling back to vesa or svga
03:03mystified: max res 1024 *768
03:03mystified: I have an old Nvidia g210
03:04mystified: usally 1920*1280
03:05gnarface: well the first thing you need to do is fix your driver issue. unfortunately i can't see how to do that
03:05mystified: thanks for your guideance
03:06gnarface: its not clear what went wrong here to me, but i'm sticking with my hypothesis of a version mismatch, and my recommendation that you try this again using only stock distro-provided components this time
03:06mystified: will do that
03:06mystified: thx again :)
03:06mystified: really appreciated
03:06gnarface: no problem. sorry i couldn't be more help.
03:27 < ZipCPU|Laptop> imirkin: As to your question from last night, I have a GeForce GT640 ... or at least that's what lspci identifies.
14:16NanoSector: is there something special about the gtx 970?
14:16NanoSector: so many issues are having issues booting Linux on those cards
14:16NanoSector: *so many users
14:16karolherbst: NanoSector: yes
14:17karolherbst: it's the card with the silly memory bus
14:17NanoSector: ah, the 3.5gb + 500 mb thing?
14:17Idix: Yes I have exactly this one...
14:17NanoSector: i see
14:17karolherbst: we need to find out how to detect those cards properly
14:18karolherbst: and apply workarounds based on the actual memory layout
14:18Idix: Is the official blob also using some workaround you think?
14:18karolherbst: Idix: of course they do
14:18karolherbst: Idix: they have to use the last 512MB as a swap area for rarely used stuff
14:18karolherbst: also the memory needs to be configured a little different
14:18NanoSector: yeah i've been recommending users to install Arch/Antergos with their onboard GPU, install proprietary drivers, adn then switch back to nvidia
14:18Idix: I'm no driver developer
14:19Idix: I would have though they have some special registry to signal this strange layout
14:19karolherbst: there are
14:19karolherbst: but it isn't just one afaik
14:19karolherbst: and we don't know all
14:19Idix: That would be too isn't, wouldn't it ?
14:21Idix: Still I'm wondering why they did this
14:21Idix: Do they like making their life harder
14:22karolherbst: they didn't want to sell the GPU with more memory
14:22karolherbst: I think they would have had to put 6GB on it
14:22karolherbst: or so
14:23karolherbst: 3.5GB is the normal size they could have done
14:23Idix: Well it's sure not very good in term of marketing...
14:23Idix: Here is our awesome graphic card with 3.5GB, yes you have read that right, 3.5GB!
14:24karolherbst: I think you need at least bus width * 16M
14:24karolherbst: so 224 bit * 16M = 3.5GB
14:24karolherbst: and they put an additional 32bit to get 512MB
14:24karolherbst: 32 bit * 16M = 512MB
14:25karolherbst: it would have been pefectly fine with 3.5GB :/
14:26karolherbst: or using same memory controllers with 256 bit
14:26karolherbst: then 4GB would be good
14:26Idix: Speaking of 3.5GB, I'm using this patch https://bugs.freedesktop.org/attachment.cgi?id=127508
14:27karolherbst: it limits your memory to 3GB
14:27Idix: Is there any way I can use 3.5GB instead of 3G
14:27karolherbst: but this should be maily fine
14:27Idix: Or is this the only way to do it?
14:27karolherbst: Idix: with an even uglier hack, yes
14:27Idix: ok ^^
14:27karolherbst: but nobody wrote it yet
14:27karolherbst: this is the easiest hack for now
14:27Idix: ok, not that it really matters
14:27Idix: I was just curious
14:29karolherbst: well you could try to figure it out
14:29karolherbst: I don't have access to such card
16:31Echelon9: @imirkin: I provided some additional comments on your query to my envytools PR#70
16:49AndrewR: hello. I booted my old machine with nv43 agp card.. It works, but I think there is regression on mpeg acceleration (running src/gallium/state_trackers/xvmc/tests/test_context says: "Acceleration level: IDCT
16:49AndrewR: Creation failed: No such device (-19)" . As far as I can see those msg come from src/gallium/drivers/nouveau/nouveau_video.c - around line 553 . I'm running kernel 4.10-rc5 with two still applicable patches for thermal sensor (my vbios lack some info, so I hacked something simple just for seeing some numbers), and second patch for enabling parsing some voltage table - without it reclock failed. Now card seems to run with 20: core 300 MHz shader 300 MHz
16:49AndrewR: memory 1000 MHz clocks - for some 11 hrs.
16:50AndrewR: I tried to see if it was issue like one fixed in https://cgit.freedesktop.org/mesa/mesa/commit/src/gallium/drivers/nouveau?id=38fcf7cbadc748816f99b2c3c9f2f55d0f1635fe - but probably whole nouveau_video.c will need much more rework :/
17:16jdiez: hi, I'm having a very strange issue on a Pascal card (GTX 1070). I can't get my mouse cursor to move, it stays stuck to the top left corner of the screen. `evtest` shows that my mouse is sending REL_X and REL_Y events.
17:16jdiez: it works fine with the proprietary nvidia driver
17:16jdiez: any clues?
17:25pmoreau: jdiez: I think you need some patches that will land with 4.10
17:25jdiez: pmoreau, care to point me to them? :)
17:26pmoreau: If I can find them, sure :-)
17:30pmoreau: jdiez: I think those 3: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4391d7f5c79a9fe6fa11cf6c160ca7f7bdb49d2a https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2a32b9b1866a2ee9f01fbf2a48d99012f0120739 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e50fcff15fe120ef2103a9e18af6644235c2b14d
17:31jdiez: pmoreau: brilliant, thank you
17:36imirkin: AndrewR: hm... that used to work!
17:36imirkin: AndrewR: let me see if i can make a patch
17:38imirkin: AndrewR: argggh, i think a kernel patch will be necessary :(
17:41imirkin: AndrewR: er wait no, kernel should be fine. good.
17:47imirkin: AndrewR: er hm. no. the issue is something else. odd. the patch you pointed out was an issue because we were using the wrong class id. however for all pre-nv50, the class id is NV31_MPEG. so it's all correct.
17:48imirkin: AndrewR: i think something's not hooked up kernel-side, causing the error... not sure what.
17:48imirkin: skeggsb: perhaps you can have a look?
17:49imirkin: AndrewR: i assume this broke starting kernel 4.3?
17:50imirkin: AndrewR: specifically i'm suspecting commit "mpeg: convert to new-style nvkm_engine" - could you check?
19:01jdiez: fun fact: nouveau + llvmpipe is is better than the proprietary driver on a GTX 1070
19:02nyef: jdiez: Wouldn't that depend on your host CPU?
19:02jdiez: with the proprietary driver, if I have a chromium window with youtube playing, scrolling is incredibly slow on other windows
19:02jdiez: nyef: well, sure
19:03jdiez: s/is incredibly slow/stutters/
19:03jdiez: not sure why that happens, or why it doesn't happen with nouveau
19:04imirkin: jdiez: probably because chrome stops doing stupid shit when you only have llvmpipe
19:06jdiez: imirkin: there may be something to that; firefox works fine in that scenario
19:07jdiez: unfortunately it disables webgl :(
19:10imirkin: yeah, until nvidia can release redistributable firmware for getting accel going, you're stuck.
19:11imirkin: if you're looking for good open-source support, you should definitely consider amd or intel for your next build.
19:11jdiez: imirkin: that sounds pretty unlikely (nvidia releasing redistributable firmware)
19:12imirkin: they did it for a part of the necessary maxwell bits (but not all, e.g. not enough to be able to change the fan speeds)
19:46nyef: The critical bit with the firmware is that it needs to be cryptographically signed, and we don't have the keys, right?
19:50nyef: ... Would it be plausible to write custom firmware for it and then ask nvidia to sign it?
19:51RSpliet: well, that's the critical bit preventing us from running our own simplified firmwares... the other half is that so far NVIDIA has hardly delivered on their promises for redistributable firmwares
19:51nyef: Basically, try to take most of the maintenance burden off them.
19:52RSpliet: as an outsider, I get the feeling that their hold-up is not engineering related, but caused by management and/or prioritisation
19:53imirkin: nyef: sure, but it's impossible to test it without a signature, so it'd be pretty tricky to develop it
19:53imirkin: nyef: also i doubt they want to be on the hook for random auditing of firmware submitted to them
19:53RSpliet: anybody up for developing a falcon implementation in VHDL or Verilog?
19:53imirkin: [and it's not like there are existing processes for this that it'd fit into]
19:54nyef: Fair enough, I guess.
19:55nyef: Should I presume that there's no unsecured platform that is "close enough" to the secured platforms that it can be used for initial development?
19:55RSpliet: nyef: we have home developed firmwares for everything up to first generation maxwell
19:56imirkin: every generation requires little tweaks
19:56RSpliet: ^ that
19:56imirkin: although a lot of the logic is shared
19:56nyef: That sucks.
19:57nyef: And the only other thing that comes to mind is finding some hardware/firmware hack to "un-secure" maxwell so that at least the tweaking could be done.
20:05imirkin: yeah... i think the literal crypto verification has been verified as being pretty secure. however the firmware that ends up running on it - not necessarily so. so there could definitely be a PS4-style situation in the future. dunno.
20:06imirkin: but it'd still be with un-redistributable firmware, so ... pretty annoying.
21:37AndrewR: imirkin, yes, I will check, but compiling kern on this machine will take time... (and me failed asleep until now, so late reply...)
21:38imirkin: AndrewR: well, no rush :) basically the NV31_MPEG class should be creatable on your nv42
21:38imirkin: (or nv43 or whatever)
21:38imirkin: the problem with vp3 decoding was that we had been a bit lax in which classes we were choosing, since the hw didn't really care
21:38imirkin: and then the kernel tightened up the interface a bit
21:39imirkin: however that's not the case at all for the PMPEG stuff
21:41AndrewR: imirkin, yea, i also found this strange - because I was testing this vpe stuff just days ago with my nv92, on same kernel version and recent git mesa, and it was working fine ..moment, I think I have Slackware's official binary kern around, but need to rev. my mesa hacks
21:42imirkin: yeah it should work ok there
21:42imirkin: note that i suspect that cpu decoding will be faster than using PMPEG if you have a recent cpu
21:43imirkin: it was useful in an era when you couldn't decode a DVD without substantial cpu usage, and later when you couldn't decode a MPEG2-TS stream at 18mbps or so on cpu.
21:48AndrewR: imirkin, does Celeron 1Ghz count as decent? :)
21:49imirkin: probably not, unless it's recent
21:49imirkin: is this like a p4-era celeron/
21:49imirkin: iirc i had an Athlon XP 1700+ (which was really 1.4ghz) and that couldn't keep up with an over-the-air ASTC transmission
21:49imirkin: [same basic deal as DVB-T]
21:50imirkin: but the NV34 that i had at the time was fully capable of decoding it.
21:50imirkin: a mere 10 years ago...
21:50AndrewR: imirkin, I think you can close fdo bug 58615 - because my motherboard apparently just ..flacky, right now it runs with lapic disabled in bios, and "pnp os" set to yes...and appear stable ..even networks survived 1.4 Gb incoming traffic (before it tended to hang after just 300Mb or so). So, I think it was not strict nouveau fault
21:51imirkin: feel free to close it yourself :)
21:53AndrewR: imirkin, for this I need to log in to bugzilla, will try this with mozilla + forced GL accel there (it worked with this card at boot clocks, but may hang with upclocked...so, I'm a bit nervous)
21:53AndrewR: https://bugs.freedesktop.org/show_bug.cgi?id=92377 - this one still applicable to 4.10-rc5
21:54imirkin: AndrewR: you should mail a patch.
21:54imirkin: ideally one without random printk's
21:55AndrewR: imirkin, yeah ...
22:37AndrewR: imirkin, so, slackware's 4.4.14 fails like my 4.10-rc5. 4.2 allow test to run, but mplayer with actual mpeg2 video fails to show real picture, dmesg filled with errors
22:37imirkin: AndrewR: it definitely *used* to work
22:38imirkin: are you use xvmc or vdpau?
22:38imirkin: coz the vdpau hookup is buggy
22:38imirkin: [well, not so much that, just that vdpau happily passes through ... something. i used to remember. i just forgot. and our decoding doesn't super-handle it]
22:39imirkin: but that sort of thing is impossible with the xvmc protocol
22:39AndrewR: imirkin, xvmc of course
22:42AndrewR: https://paste.fedoraproject.org/538936/ - last dmesg errs.
22:43AndrewR: may be I still foobared my mesa/ install (but I run git reset --hard before recompiling)
22:47imirkin: well remember that xvmc runs via xvmcw, which reads /etc/something
22:47imirkin: hrmph ok. looks like something gets confused.
22:47imirkin: that's the 3d class having issues, not the mpeg class
22:48imirkin: so that makes sense that things aren't being displayed
22:48imirkin: (class = 0x4097 = nv40 3d class)
22:48AndrewR: imirkin, /gallium/state_trackers/xvmc/tests/xvmc_bench still display same corrupted (pink) window, so no need for mplayer + mpeg2 file
22:55imirkin: unfortunately i only have a nv34 plugged in, and iirc that one gets hangs whenever i tried to get xvmc working
23:09AndrewR: imirkin, I can try and test some earlier mesa versions, but this will req. some libdrm downgrades
23:19imirkin: AndrewR: i'd start with older kernels
23:20imirkin: anyways, this stuff definitely worked around kernel 3.13 and mesa 10.0 or so.
23:20imirkin: there have been several rewrites since that could easily have mucked things up
23:20AndrewR: imirkin, yes, from this ocmmit alone it looks like nv40 class was not converted completely? (much less code insertion than for nv44) https://github.com/ulli-kroll/linux-comcerto/commit/7624fc011e56902a83e409b14d6c1efa75aa4a58
23:21imirkin: mmmm unclear
23:22imirkin: this stuff is subtle.
23:22imirkin: i think nv44 needs something new and special
23:22imirkin: whereas nv40 mostly reuses the nv31 bits
23:22imirkin: that stuff was shared until i fixed it up in be0dd4ddefebb35915979e280047eb6f5ecc3235