00:18 ilmostro: I'm having issues with 4.17.{0,1} and nouveau handover from fb to nouveau during boot. I'm wondering if others have noticed any changes or problems. I don't see relevant changes to nouveau development in 4.17, AFAIK, but perhaps other kernel configuration changes have an effect on how it's built?
00:19 ilmostro: nouvea probe fails with error -12, based on the journal logs during bootup
00:20 ilmostro: gentoo, AMD Ryzen 1950x, nvidia-gefore-gtx-750-ti
00:22 ilmostro: one noticeable config change, which is not shown in menuconfig, is CONFIG_DMA_DIRECT_OPS=y. I'm not sure if/how it would be relevant, but I can't figure out why it's selected or how to deselect it. :(
03:30 imirkin: ilmostro: logs would be nice
03:31 ilmostro: imirkin: I can provide the journal logs; mayb ethe kernel config. Other than that, any others that could be of use?
03:32 imirkin: kernel logs
03:32 imirkin: pastebin those
03:34 ilmostro: the systemd journal log is at https://ptpb.pw/AcN4
03:36 ilmostro: though, I have to admit, that's from when I tried to remove legacy fbdev, adding efifb and simplefb.
03:36 imirkin: ilmostro: disable SME
03:36 imirkin: that should generally not be required
03:37 imirkin: but something in 4.17 broke SME for GPUs at least
03:37 imirkin: iirc you can boot with something like sme=off but i'm not 100% sure
03:38 ilmostro: imirkin: I'll give it a try. I would disable SME altogether in the kernel config, but, IIRC, something (important) depends on it :p
03:39 ilmostro: btw, the following shows the kernel that's built when using olddefconfig as the make target https://ptpb.pw/iO9T
03:39 ilmostro: where the older kernel, 4.16.15, has nouveau working just fine
03:40 ilmostro: and this is the working 4.16.15 kernel https://ptpb.pw/v7dV
03:41 imirkin: revert b468620f2a1dfdcfddfd6fa54367b8bcc1b51248 locally if you like
03:41 imirkin: that should also fix it. linus has done it in his tree.
03:46 ilmostro: Interesting; I wonder if 4.17.2 has that in place now as well
03:48 imirkin: the revert is e16c4790de39dc861b749674c2a9319507f6f64f upstream
03:48 imirkin: i don't see it in 4.17.2
03:50 ilmostro: imirkin: great find. Thank you :)
03:51 imirkin: this will also presumably disable the need for CONFIG_DMA_DIRECT_OPS
03:51 imirkin: at least for now
03:51 imirkin: [no clue what that does]
03:52 ilmostro: I know! That was the one thing I had zoomed in on; I see it mentioned in the revert
03:59 imirkin: that said, i can't imagine SME being a good idea for high-perf DMA
03:59 imirkin: but i don't know how it all works
04:05 ilmostro: I wonder if the following work added to those issues as well; or at least brought them to light https://www.spinics.net/lists/linux-block/msg25103.html
04:06 ilmostro: The discussion in that mailing-list you first posted here shows that swiotlb mentioned. This is what I came across when I initially stated searching for that CONFIG_DMA_DIRECT_OPS https://www.spinics.net/lists/linux-block/msg25103.html
04:06 ilmostro: sorry about the duplicate link
04:17 ilmostro: The easier solution is to disable SME via kernel configuration. It appears to be geared toward hypervisor memory encryption, mainly https://www.phoronix.com/scan.php?page=news_item&px=AMD-SME-SEV-Epyc
04:22 ilmostro: I'll test by using "mem_encrypt=off", as eluded to in the kernel documentation
04:36 ilmostro: recompiled 4.17.2 without SME; works like a charm. imirkin: I'm eternally grateful :)
05:59 rhyskidd: been playing around with the Falcon ctxsw microcode, some additions to rrndb coming out of that
05:59 rhyskidd: on FECS and GPCCS
22:27 rhyskidd: the major commands provided by the interface to FECS ctxsw microcode: https://github.com/Echelon9/envytools/commit/2f6dea818e5110aa36bfc92bea4efb7dc481ca7e
22:28 rhyskidd: there's sixteen, including those that appear to be for debugging purposes
22:29 rhyskidd: some notable gaps as well, might be worth fuzzing
22:59 mwk: why would you want to fuzz that if you can just disas the microcode that handles them?
23:00 mwk: also, this is not the place to store this
23:00 mwk: since this is a firmware interface, not a hardware one
23:01 mwk: as in, the meaning of these numbers depends on the firmware