mamarley | tseliot: I was just looking at log files and I found that I have the same problem as darkxst with nvidia-drm not loading. | 10:57 |
---|---|---|
mamarley | Or, not loading with modeset=1. It does load automatically later. | 10:58 |
mamarley | I can also see that modinfo doesn't work for any of the alias module names. (module not found) | 11:01 |
tseliot | mamarley: yes, I'll have a look at that | 11:02 |
mamarley | I was actually going to see if I could fix it myself. I don't know how to get modules to be included in the initramfs though. | 11:03 |
mamarley | I fail to see how the "alias nvidia nvidia_364" doesn't work though, since "modinfo nvidia_364" does work. | 11:05 |
mamarley | It is almost like the aliases are being ignored entirely. I can't see why. | 11:16 |
ricotz | mamarley, tseliot, added/tweaked aliases locally (using underscores only) | 11:33 |
tseliot | ricotz: ok. BTW I'm working on nvidia right now | 11:35 |
ricotz | tseliot, I was counting on that ;) | 11:35 |
tseliot | mamarley: "automatically" means maybe the driver loads that module? | 11:36 |
tseliot | tjaalton: I don't see the kms drivers in the initramfs. They are not built as modules, so I suppose there is nothing to include | 11:44 |
tjaalton | tseliot: huh? i915.ko etc | 11:46 |
tjaalton | /usr/share/initramfs-tools/hooks/framebuffer copies them | 11:46 |
tseliot | tjaalton: yes, I will have to write a hook for nvidia. I simply could not file the files in the initramfs | 11:48 |
mamarley | tseliot: Yes, I think nvidia-drm is getting loaded automatically by either nvidia-modeset or nvidia and that is why the driver works even though the modprobe in the udev configuration fails. | 11:51 |
tseliot | whatever it is, I'll fix it all ;) | 11:53 |
mamarley | Thanks :) | 11:55 |
tseliot | tjaalton: I extracted the initramfs and I used find to get a list of the .ko files: http://paste.ubuntu.com/15486764/ | 11:59 |
tseliot | this is what puzzles me | 11:59 |
tjaalton | you're on trusty still.. | 12:00 |
tjaalton | check if it has that hook | 12:00 |
tseliot | yes | 12:00 |
tseliot | and yes, the hook is there | 12:00 |
tjaalton | dunno then | 12:00 |
tseliot | are you sure that we do that even on systems that are not encrypted? | 12:01 |
tjaalton | yes | 12:01 |
tjaalton | http://sprunge.us/JUfW | 12:03 |
tseliot | - Restore the framebuffer hook and script, copying KMS and other | 12:03 |
tseliot | framebuffer drivers into the initramfs, but make them optional; you | 12:03 |
tseliot | need to set FRAMEBUFFER=y for these to be included. | 12:03 |
tseliot | tjaalton: ^ Do you have FRAMEBUFFER=y in grub or is your system encrypted? | 12:04 |
tjaalton | FRAMEBUFFER where? | 12:05 |
tjaalton | this one isn't encrypted | 12:05 |
tseliot | well, actually not grub, somewhere in /etc/initramfs-tools/conf.d/ | 12:07 |
tjaalton | no | 12:07 |
tjaalton | grep gives no hits | 12:07 |
tjaalton | where did you get that text? | 12:08 |
tseliot | from the changelog of the initramfs-tool package | 12:09 |
tseliot | *tools | 12:09 |
tseliot | if you add FRAMEBUFFER=y, plymouth will start much earlier in the boot process | 12:10 |
tjaalton | add where? | 12:18 |
tjaalton | upgrade to xenial already | 12:18 |
tjaalton | :) | 12:18 |
tseliot | /etc/initramfs-tools/conf.d/splash | 12:20 |
tjaalton | don't have that | 12:21 |
tjaalton | you're on an obsolete distro ;) | 12:21 |
tseliot | yes, well, echo FRAMEBUFFER=y > /etc/initramfs-tools/conf.d/splash | 12:21 |
tjaalton | my initrd already has all the modules | 12:21 |
tjaalton | the hook does not check for that option | 12:21 |
tseliot | I'm trying to understand why we don't have the modules on trusty | 12:21 |
tjaalton | just ask apw? | 12:22 |
tseliot | yes, that's why I'm confusedf | 12:22 |
tseliot | *confused | 12:22 |
tseliot | yes, I'll try that | 12:22 |
apw | splash is only needed in the initramfs if you have encrypted things to open to get to root | 12:22 |
tjaalton | oh you're here :) | 12:23 |
apw | so we don't include that lot unless you have crypt thing on there | 12:24 |
tseliot | which is what I suggested before | 12:25 |
tseliot | apw: but how about the single drm drivers? | 12:25 |
tseliot | I don't have them in trusty, but tjaalton does in xenial | 12:25 |
tjaalton | my initrd has all of them, this is a fairly recent install | 12:26 |
* tseliot -> lunch | 12:30 | |
apw | tjaalton, it is dependant on you needing them | 12:35 |
apw | so encrypted root, or actually iirc stypidly having crypttools installed at all | 12:35 |
tjaalton | nope, neither | 12:36 |
apw | tseliot, ^ | 12:40 |
apw | well something is triggering them being in there, it is not a normal situation | 12:41 |
apw | basically any hook which needs them sets that FRAMEBUFFER thing and that triggers it | 12:41 |
apw | iirc | 12:41 |
apw | so look at your hooks and one will be asking for it | 12:41 |
apw | or it is broken, which is also possible | 12:41 |
tjaalton | i have a fresh server vm, and it has them too :) | 12:43 |
tjaalton | so maybe it's a bug then | 12:43 |
mamarley | Does the nvidia-modeset module need to be loaded for DRM KMS to work or just nvidia-drm? | 12:44 |
apw | tjaalton, could be, could you file a bug against initramfs-tools for me, and tell me the number | 12:58 |
tseliot | mamarley: both, as KMS stands for kernel mode setting, so nvidia-modeset is definitely needed | 14:30 |
mamarley | That's what I thought. | 14:30 |
tseliot | apw: thanks, that's what I thought | 14:31 |
tseliot | tjaalton: so, yes, that does look like a bug: | 15:34 |
tseliot | * mkinitramfs: Allow scripts to specify OPTION=VAR, and unless VAR is | 15:34 |
tseliot | set to something other than "n", the script will not be included. | 15:34 |
tseliot | the framebuffer hook has OPTION=FRAMEBUFFER | 15:34 |
tseliot | so, if OPTION=FRAMEBUFFER is ignored, and the script is included regardless of that, it's a bug | 15:35 |
tseliot | darkxst: are you using an encrypted system? | 15:35 |
tseliot | if not, fixing the aliases should do it | 15:37 |
tseliot | I am certainly going to add an initramfs hook for encrypted systems though | 15:42 |
* tseliot building the driver with the correct aliases first... | 15:43 | |
tseliot | ricotz, mamarley: the aliases seem to work fine now: http://pastebin.ubuntu.com/15488195/ | 16:24 |
tseliot | modinfo doesn't seem to resolve the aliases but I think we are fine as long as modprobe does ;) | 16:25 |
mamarley | tseliot: Cool, thanks! | 16:35 |
tseliot | so the last step will be a hook for encrypted systems. Then things should be fine. I'm not sure about nvidia-persistence though | 16:36 |
ricotz | tseliot, is this working for you now? "sudo cat /sys/module/nvidia_drm/parameters/modeset" | 16:36 |
mamarley | tseliot: Maybe also have it obey that override that apw mentioned? | 16:36 |
tseliot | ricotz: I still get "N", but I don't see any errors in journactl | 16:36 |
ricotz | tseliot, mhh, I see | 16:37 |
tseliot | mamarley: yes, I could have to look at initramfs-tools | 16:37 |
apw | tseliot, or get a bug filed on it and shove it at me | 16:39 |
apw | sounds like something i would have screwed up in my merge with debian if anything | 16:39 |
tseliot | apw: yes, that would be much better (for me) ;) | 16:39 |
apw | tseliot, shove what you have in a bug, and tell me the number and i'll put it on my todo | 16:41 |
apw | its making peoples initramfs' large and slwo, so i want to wack it | 16:41 |
mamarley | tseliot: Sorry, I didn't mean for you to fix the initramfs-tools bug, I just meant to make it so when that bug gets fixed that the flag there will affect the nvidia modules too. | 16:41 |
tseliot | apw: sure, thanks. I'm updating my xenial installation right now, so that I can use ubuntu-bug to file the report, just in case | 16:42 |
apw | tseliot, ack thanks | 16:42 |
tseliot | mamarley: I'm all for solutions that don't involve me doing the work :P | 16:42 |
* mamarley too :) | 16:42 | |
mamarley | I just confirmed that manually loading the nvidia_drm module with modeset=1 results in "sudo cat /sys/module/nvidia_drm/parameters/modeset" returning Y. | 16:44 |
tseliot | mamarley: ok, so maybe the udev rule should try to remove the module first (as per the nvidia docs) | 16:45 |
mamarley | I'm not sure why it would be loaded at all at that point. Unless udev loads it automagically... | 16:45 |
tseliot | mamarley: ok maybe their X driver? | 16:46 |
mamarley | Would something in /etc/modprobe.d/ that says "options nvidia_drm modeset=1" work by any chance? | 16:46 |
mamarley | Would the X driver have started by that point? I was under the impression that the udev thing happened earlier than X starting. | 16:47 |
mamarley | Also, I would think if X is running, "modprobe -r"ing the module would fail anyway. | 16:47 |
tseliot | it's worth a shot | 16:47 |
mamarley | I can try that on my laptop real quick, just a sec... | 16:48 |
tseliot | and yes modprobe -r failed for me above ^ | 16:48 |
tseliot | udev starts earlier than X though | 16:48 |
tseliot | just guessing. I have no idea what else could be pulling that in | 16:48 |
mamarley | tseliot: That ("options nvidia_drm modeset=1") appeared to work. :) | 16:52 |
tseliot | mamarley: wouldn't that be nvidia-drm though? (to match the alias) | 16:53 |
mamarley | I actually put four different lines though, with and without the 364 and -s and _s, because of the alias madness. | 16:53 |
tseliot | :) | 16:53 |
tseliot | I'll test it here too | 16:54 |
mamarley | Hmm, will that work if the module is in initramfs too? | 16:55 |
tseliot | well, the aliases are in the initramfs | 16:55 |
mamarley | OK, it should work fine then. I stuck my options in the same file as the aliases. | 16:56 |
tseliot | and the actual module name would be nvidia_364_drm, whereas nvidia_drm shouldn't exist | 16:56 |
* tseliot rebuilding and testing... | 16:56 | |
mamarley | I understand; I just wanted to cover all the bases since I am not running the version with the fixed aliases yet. | 16:57 |
tseliot | right | 16:57 |
tseliot | I think I'll work on the hook tomorrow, as it's EOD for me | 16:57 |
mamarley | Explosive Ordnance Disposal? ;P | 16:58 |
tseliot | hehe | 16:59 |
tseliot | in addition to being almost guitar o'clock | 16:59 |
tseliot | apw: LP: #1561643 | 17:14 |
ubottu | Launchpad bug 1561643 in initramfs-tools (Ubuntu) "initramfs-tools ignores the FRAMEBUFFER option" [High,Confirmed] https://launchpad.net/bugs/1561643 | 17:14 |
tseliot | mamarley: nvidia-drm options didn't work here. I'll mess with it again tomorrow | 17:15 |
* tseliot -> off | 17:15 | |
mamarley | tseliot: OK. It actually didn't work setting options on the alias for me either. | 17:15 |
mamarley | I think I have to set options with the full module name. | 17:15 |
tseliot | yes, that would be easy to do | 17:16 |
mamarley | Yeah, that works. | 17:17 |
furkan | anybody know why I would be getting this error? first time i'm seeing it: | 20:45 |
furkan | furkan@furkan-pc:~$ Xorg -version | 20:45 |
furkan | /usr/lib/xorg/Xorg.wrap: Only console users are allowed to run the X server | 20:45 |
furkan | also, tjaalton: MrCooper wrote a patch for the cursor bug https://bugs.freedesktop.org/show_bug.cgi?id=94560#c16 | 20:53 |
ubottu | Freedesktop bug 94560 in Server/General "[regression, bisected] Xorg 1.18.2 stray cursor appears when some applications are launched maximized on rotated display" [Normal,New] | 20:53 |
darkxst | tseliot, no my system is not encrypted | 22:14 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!