00:17imirkin: we got temperature sensors
00:17imirkin: nmschulte: hm, weird
00:17imirkin: or rather
00:18imirkin: the error is weird
00:18imirkin: it's not weird that after you got it that everything went downhill
00:18imirkin: normally things sorta recover. if not, you can unbind the pci device and rebind it
00:18imirkin: or reboot
00:22nmschulte: TIL about unbind/rebind pci devs. nice. working again.
00:23imirkin: it's the same as module reload
00:23nmschulte: [152856.721854] nouveau 0000:01:00.0: msvld: intr 00000040
00:23imirkin: but sometimes you have 3 nvidia GPUs plugged in
00:23imirkin: and only want to reset 1
00:24nmschulte: [152856.721854] nouveau 0000:01:00.0: msvld: intr 00000040
00:24nmschulte: [152856.721902] nouveau 0000:01:00.0: fb: trapped read at 0000000000 on channel 3 [1f9b4000 ffmpeg] engine 09 [PBSP] client 0d [PBSP] subclient 07  reason 0000000f [DMAOBJ_LIMIT]
00:24nmschulte: sorry for the pastes^
00:24imirkin: no worries
00:24imirkin: the DMAOBJ_LIMIT is the weird one
00:24imirkin: the intr is some unknown interrupt - potentially related
00:24nmschulte: DMAOBJ_LIMIT -- ffmpeg just going to fast? not sure if that happened before or after my CTRL+C to it
00:24imirkin: maybe we're supposed to handle something we don't? dunno
00:25imirkin: no, DMAOBJ_LIMIT = nouveau developers don't know what they're doing
00:25imirkin: the dma object shouldn't have a reachable limit :)
00:26imirkin: which is why i'm confused by that one
00:27nmschulte: CPU RAM constraint?
00:27imirkin: maybe i just have the wrong idea about what that error means though
00:27imirkin: it's a bit tricky to explain what it is
00:27imirkin: it's not a thing that makes sense on these GPUs
00:27imirkin: it's a holdover from earlier generations
00:28nmschulte: like AGP-era?
00:28imirkin: but basically we just create a "all of vram" and "all of system ram" dma objects
00:28imirkin: and use those throughout
00:28imirkin: there's no way to hit a limit
00:28imirkin: if we configured them differently then yes, but not here
00:29imirkin: but also the various engines sometimes cheat
00:29imirkin: in the way they access stuff
00:30nmschulte: fwiw, I'm simply: ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi -i <h264 (High) (avc1 / 0x31637661), yuv420p, 1600x1200, 1807 kb/s, 30 fps, 30 tbr, 15360 tbn, 60 tbc>.mp4 -an -f null -
00:42nmschulte: maybe this is one of those strange fallback cases, because the rendering proceeds, but _extremely_ slowly, and a whole CPU core gets thrashed by the kernel
00:48imirkin: let me put it this way - i would not advise using nouveau, esp video decoding, in a production setting
00:49imirkin: this is all best-effort stuff
00:49imirkin: we try, but going from "working" to "stable" is a very difficult step, esp when hardware has various edge conditions
00:50imirkin: we don't exactly get programming guides for these things
00:51nmschulte: trust me I understand. I'm not looking for support here, just sharing my experience.
00:52imirkin: there are a lot more ways to hang it than to not hang it
00:53imirkin: i'm the last person to have touched the video stuff, and that was eons ago
00:54nmschulte: the vaapi -> yuv color-space transform, or perhaps simply moving the output from GPU to CPU memory, causes massive CPU use (~70% of one core on this old AMD K8).
00:54imirkin: can you see where exactly the cpu goes?
00:54imirkin: (using perf)
00:54imirkin: it might be something unexpectedly stupid
01:54imirkin: pmoreau: hey, so do you want to look at the rest of those compute shader prep patches, or should i just push?
01:55imirkin: mostly just the "fix emission of xyz" by now, so fairly safe i'd think
02:56kreyren: I have a Z68A-D3-B3 system with i7-2600K and GTX970 on devuan connected to the monitor from GPU using HDMI
02:56kreyren: I have display, but i can't use the GPU in any application.. why?
02:56kreyren: tested using supertuxkart which feels like running on iGPU
02:57kreyren: (devuans doesn't know)
02:59HdkR: Because your GPU is running at idle clocks
02:59HdkR: Anything Maxwell and higher need signed PMU blobs that Nvidia won't allow distribution of
03:00kreyren: i though that's for pascal only? This GPU worked before on nouveau better then proprietary tested in rocket league
03:00nmschulte: kreyren: we established just before you joined, that it should be possible to load nvidia proprietary driver to set the clocks, then unload it and load nouveau, and it should not reset the clocks
03:00nmschulte: kreyren: it's possible your display manager is having drm device conflicts, especially if wayland I bet
03:01kreyren: this is X11
03:01nmschulte: (as it sounds like you have two GPUs; integrated intel and discrete nvidia)
03:01kreyren: using XFwm4 VM
03:01kreyren: yes two GPUS (iGPU and dGPU)
03:01nmschulte: I assume you're familiar with DRI_PRIME and glxinfo?
03:02kreyren: yes DRI_PRIME=1 glxinfo | grep OpenGL\ ren gives me LLVM pipe
03:02kreyren: kreyren@dreamon:~$ DRI_PRIME=1 glxinfo | grep OpenGL\ ren
03:02kreyren: OpenGL renderer string: llvmpipe (LLVM 11.0.1, 256 bits)
03:03kreyren: From experience with AMD this is a sign of it using iGPU?
03:03HdkR: llvmpipe is software rasterizer
03:04nmschulte: "Support for manual performance level selection (also known as "reclocking") on GM10x Maxwell" according to website; GTX 970 is listed.
03:04HdkR: Oh right, that one is GM10x, not GM20x :D
03:04kreyren: so does that mean that this GPU can do clocks?
03:06imirkin: kreyren: is this with with the linux-libre kernel?
03:06kreyren: this should be using linux kernel with DKMS modules distributed by debian
03:07imirkin: pastebin xorg log
03:08kreyren: kreyren@dreamon:~$ cat ~/.local/share/xorg/Xorg.0.log | ix
03:09imirkin: [ 31.967] (II) AIGLX: Screen 0 is not DRI2 capable
03:09imirkin: that's not good
03:09kreyren: > [ 30.849] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
03:09imirkin: [ 31.302] (EE) modeset(0): glamor initialization failed
03:09kreyren: <imirkin "that's not good"> elaborate?
03:10imirkin: that's the cause of the issue
03:10imirkin: well - it just means there's a problem
03:10imirkin: it can't get accel going with glamor
03:10imirkin: so you (a) don't get X accel and (b) don't get GLX / DRI for X clients
03:10imirkin: i've never had to debug this sort of thing. normally i use the nouveau ddx.
03:10kreyren: FWIW the screen seems to have a delay when i move with windows
03:11imirkin: instead of the modesetting one.
03:11kreyren: what's ddx
03:11imirkin: although this feels like a permissions issue
03:11imirkin: but i'm saying this based on zero information
03:11imirkin: ddx = device-dependent X
03:11kreyren: like user not being in a video group?
03:11kreyren: kreyren@dreamon:~$ groups
03:11kreyren: kreyren cdrom floppy sudo audio dip video plugdev netdev scanner lpadmin
03:11imirkin: you apepar to be on systemd, so it's more complicated than that.
03:11kreyren: <imirkin "you apepar to be on systemd, so "> nope OpenRC
03:12kreyren: using sysvinit for init
03:12imirkin: really? what's with the .local/Xorg log?
03:12kreyren: <imirkin "really? what's with the .local/X"> eh?
03:12imirkin: why isn't it in /var/log/Xorg.0.log ?
03:12imirkin: why is the X process running as you?
03:12imirkin: that implies you've got some kind of cleverness going on
03:12kreyren: i started it using startx O.o
03:13imirkin: i see references to 'systemd-logind'
03:13imirkin: [ 30.710] (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 13 paused 0
03:13kreyren: systemd-logind is standalone from systemd i was told
03:13imirkin: well i have no idea how it works :)
03:13kreyren: afaik provided for compatibility with other packages that have hard dependency on systemd
03:14imirkin: anyways, debian sadly patches Xorg to explicitly prefer using modesetting for nvidia GPUs newer than nv50 or so
03:14imirkin: so you have to override that preference if you're going to use the nouveau ddx. but also i'm not sure that that would actually help.
03:15nmschulte: does the render vs video group matter?
03:15imirkin: nmschulte: normally video = /dev/dri/card*, render = /dev/dri/renderD*
03:15nmschulte: FWIW, I was able to startx as root on my box to get Xorg vdpau working; didn't work w/ startx as user (possibly that was due to lack of render group, though; unsure)
03:15kreyren: should i startx as root to see what kind of log it generates?
03:15kreyren: to exclude perm issue?
03:16imirkin: sure, you could do that.
03:16nmschulte: that's my prop
03:16kreyren:goes to check
03:18imirkin: [ 2001.464] (EE) modeset(0): glamor initialization failed
03:18imirkin: still fail
03:18imirkin: stupid question ...
03:18kreyren: anything relevant is not stupid!
03:18imirkin: actually, several stupid questions
03:19imirkin: (a) pastebin dmesg
03:19imirkin: (b) do you have nouveau_dri.so installed? (mesa-dri-nouveau maybe? dunno debian packaging)
03:19kreyren: <imirkin "(a) pastebin dmesg"> http://ix.io/2SiO
03:19imirkin: [ 3.996347] nouveau 0000:01:00.0: DRM: failed to create kernel channel, -22
03:19kreyren: <imirkin "(b) do you have nouveau_dri.so i"> kreyren@dreamon:~$ dlocate nouveau_dri.so
03:19imirkin: that means NO ACCEL FOR YOU!
03:20imirkin: [ 3.930994] nouveau 0000:01:00.0: firmware: failed to load nvidia/gm204/acr/bl.bin (-2)
03:20imirkin: [ 3.930998] firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware
03:20imirkin: maybe do that.
03:21imirkin: not that.
03:21kreyren: > kreyren@dreamon:~$ apt list --installed mesa
03:21kreyren: > Listing... Done
03:21kreyren: Mesa not installed?
03:21imirkin: kreyren: don't worry about that.
03:21imirkin: that's next-level
03:22kreyren:is looking at the references
03:22imirkin: first get your kernel in order
03:22imirkin: i dunno how you get linux-firmware on debian
03:22nmschulte: libgl1-mesa-dri: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so
03:22imirkin: but you need to get linux-firmware, or at least the nvidia drirectory
03:22imirkin: nmschulte: that VideoAcceleration stuff is only for older GPUs
03:23imirkin: mutually exclusive with the later ones which require signed firmware which is shipped with linux-firmware
03:23nmschulte: firmware-misc-nonfree: /lib/firmware/nvidia/gm204/acr/bl.bin
03:24kreyren:sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/XKuOSWOQLVXjSJbGCeOLpXep/message.txt >
03:24kreyren: so i guess firmware-linux?
03:25kreyren: > kernel not having access to the GPU??? are they saying you need the firmware for that? because the only thing i knew of that could cause that other than a physical power issue (or hardware damage) would be needing to specify a pci id in the xorg.conf because auto-detect is failing for whatever weird reason -- Devuan
03:25imirkin: kernel can access the GPU just fine
03:25imirkin: just doesn't expose acceleration without firwmare.
03:26imirkin: and you'd like some of that sweet sweet acceleration
03:26kreyren: > firmware-misc-nonfree: /lib/firmware/nvidia/gm204/acr/bl.bin
03:26kreyren: So this?
03:26nmschulte: firmware-misc-nonfree is the specific package w/ the blobs. firmware-linux and friends might get it via dep, unsure
03:28imirkin: nmschulte: we don't know how to use your distro
03:28imirkin: kreyren: --^
03:28imirkin: sorry, wrong person :)
03:29kreyren: consulting with devuan atm
03:29imirkin: ok. you need linux-firmware. however you get that.
03:29imirkin: it needs to be available at the time that the nouveau module loads
03:29imirkin: so if the distro loads modules from initrd for some silly reason, the firmware needs to be in initrd, etc
03:30nmschulte: I'm running debian. you need firmware-misc-nonfree. however you want to get it, that's up to you. I'd just `aptitude install firmware-misc-nonfree`
03:30kreyren:is rebooting with the firmware
03:30nmschulte: it will automatically poke update-initramfs etc.
03:32kreyren: kreyren@dreamon:~$ cat ~/.local/share/xorg/Xorg.0.log | ix
03:32kreyren: kreyren@dreamon:~$ DRI_PRIME=1 glxinfo | grep OpenGL\ ren
03:32kreyren: OpenGL renderer string: NV124kreyren@dreamon:~$ DRI_PRIME=1 glxinfo | grep OpenGL\ ren
03:32kreyren: OpenGL renderer string: NV124
03:33kreyren: oops double pasted it x.x
03:34kreyren: thanks ^-^
03:34nmschulte: kreyren: how is devuan?
03:34nmschulte: kreyren: I've grown used to systemd, pulseaudio, etc.
03:36kreyren: <nmschulte "Krey: how is devuan?"> I use it as a fallback for my OS as it's the most stable and painless to use from available alternatives
03:36kreyren: i would prefer source-based distro such as exherbo if it was better maintained though
03:37nmschulte: debian packaging is too removed for you?
03:37kreyren: rather the lack of options and ability to compile for the system instead of using generic binaries
03:38kreyren: i have a fork of bedrock that i plan to deploy here to get some source-based packages such as firefox though
03:38imirkin:won't even mention gentoo
03:39kreyren: i was considering gentoo, but the package manager is too annoying for me to use as it has constant blocked packages and bad decisions made in downstream
03:39imirkin: if you say so
03:39kreyren: was even using gentoo for a while, but it's not worth it in a long run
03:39nmschulte: not familiar w/ bedrock. you installing that w/in/alongside the devuan, or ?
03:39imirkin: i've been using it exclusively since ... 2005?
03:39kreyren: <nmschulte "not familiar w/ bedrock. you in"> not yet deployed on this system
03:40nmschulte: what about archlinux?
03:40kreyren: basically it's a wrapper for chroot() that sets custom PATH to access components from it's sandboxes in one terminal
03:40kreyren: e.g. using nano from gentoo on devuan
03:40nmschulte: honestly that sounds like a nightmare.
03:41kreyren: <nmschulte "what about archlinux?"> not as stable compared to devuan
03:41nmschulte: archlinux is "from source" right?
03:41kreyren: and i came to a conclusion that it's not worth it comparing the result on devuan to arch
03:41kreyren: as arch lacks the options that gentoo/exherbo has
03:42imirkin: nmschulte: as a consumer, you're using binaries
03:42imirkin: which are built once for everyone
03:42kreyren: same for GUIX would love to have options on that thing
03:42imirkin: vs built specifically based on your settings/specifications
03:42kreyren: but not a thing so far even though it's planned
03:44kreyren: where is the reference to kernel options and CMD line variabes for nouveau? I got variable before that got me more performance O.o
03:46nmschulte: kreyren: https://nouveau.freedesktop.org/KernelModuleParameters.html
03:47kreyren: thanks ^-
03:48nmschulte: nouveau.agpmode=0 -- that's the ticket.
03:48kreyren: so like NvBoost=1 command ?
03:48kreyren: ah i see
03:49kreyren: it's not a CMDline variabe?
03:49nmschulte: I think these are all kernel module parameters, as the title states.
03:49kreyren: ah oke O.o
03:53kreyren: How can i make it to use iGPU for the desktop and dGPU or specified applications e.g. using DRI_PRIME=1 ?
03:55nmschulte: I think you have to configure Xorg to tell it to use iGPU "For the desktop" and then use DRI_PRIME=1 for each application you want
03:55nmschulte: there may be performance concerns with that, I'm uncertain how that works. imirkin knows I bet.
03:56kreyren: doesn't seem to recognize DRIPRIME
03:56kreyren:sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/kiyhAfKpMUDvghlraXmIseAy/message.txt >
03:56kreyren: seems that element-desktop is getting very slow on this config i get one word per sec
03:56nmschulte: I don't know if newer Xorg / mesa/things do this, but I used to have to: xrandr --setprovideroffloadsink (see xrandr --listproviders). I think newer codes handle (some of) this automatically, in certain contexts with certain assumptions
03:56kreyren: *5 sec
03:57kreyren: kreyren@dreamon:~$ xrandr --listproviders
03:57kreyren: Providers: number : 1
03:57kreyren: Provider 0: id: 0x48 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 4 outputs: 5 associated providers: 0 name:modesetting
03:57nmschulte: ls /dev/dri/
03:58kreyren: kreyren@dreamon:~$ ls /dev/dri
03:58kreyren: by-path card0 renderD128
03:58nmschulte: the system only knows about one card right now.
03:58kreyren: ye seems to have unloaded the iGPU driver
03:59kreyren: so i guess devuan issue?
04:04kreyren_: Devuan doesn't seem to know x.x suggested maybe xorg.conf
04:05nmschulte: lspci will tell you if the iGPU is a real thing
04:05nmschulte: from there, I believe it's simply `insmod i915`
04:06kreyren[irssi]: insmod: ERROR: could not load module i915: No such file or directory
04:06nmschulte: lspci only shows one VGA device.
04:07kreyren[irssi]: this CPU (i7-2600K) has Intel® HD Graphics 3000 btw
04:07kreyren[irssi]: nmschulte: O.o
04:09nmschulte: have to check the motherboard config (BIOS) then
04:09kreyren[irssi]: the modprobe i915 gets the driver loaded
04:09nmschulte: and now /dev/dri/ shows card1?
04:10kreyren[irssi]: kreyren@dreamon:~$ ls /dev/dri
04:10kreyren[irssi]: by-path card0 renderD128
04:10nmschulte: dmesg will have the answers about what i915 was/is doing. that your lspci doesn't show two VGA devices seems problematic still
04:10kreyren[irssi]: kreyren@dreamon:~$ sudo dmesg | ix
04:11kreyren[irssi]: > [ +0.031633] nouveau 0000:01:00.0: gr: DATA_ERROR 0000000c [INVALID_BITFIELD] ch 5 [103eac1000 Xorg] subc 0 class b197 mthd >
04:11nmschulte: seems like a problem but unrelated to the issue here. that was 80s after poweron, likely a while ago?
04:11nmschulte: no newer kernel log messages than that?
04:15kreyren[irssi]: dunno x.x
04:15nmschulte: cat /var/log/kern.log
04:18nmschulte: you'll have to look at the BIOS then
04:18kreyren[irssi]: what to look for ?
04:20kreyren[irssi]: (the log shows AMD FX-6100 because i installed the OS on different system)
04:23kreyren[irssi]: eh O.o
04:23kreyren[irssi]: oke let me check BIOS for anything relevant
04:29kreyren_: nothing relevant that i could see x.x
04:30nmschulte: try booting without the discrete card
04:30nmschulte: EFI may be getting in the mix too; folks talk about CMS/compatibility mode booting
04:31kreyren_: is there something like nouveau_support=0 to disable the dGPU? I don't have connection to the display from the mobo
04:32nmschulte: you can probably disable the pci-express/gpu port in the bios.
04:32nmschulte: but that won't solve your no-video issue, unless the system boots and you can e.g. ssh into it
04:32nmschulte: or kill it and inspect logs after reboot
04:33kreyren_: oke rebooting
04:40HdkR: Some older motherboards stick iGPU disabling in some deep menu
04:40HdkR: Something like System Agent -> Graphics Configuration
04:41HdkR: Back before Intel QuickSync was a thing, so it wasn't really worth having iGPUs enabled when dGPU was inserted :P
04:42nmschulte: and I think bc/ of that, some even don't expose a knob and force it off (sometimes rightfully so, due to north/south-bridge heavy-handed-ness/limitation)
04:42nmschulte: (force it on...)
04:43kreyren_: kreyren@dreamon:~$ sudo cat /var/log/kern.log | tail -3000 | ix
04:46kreyren_: seems sane to me?
04:50nmschulte: Advanced Bios Features -> Init Display First: PCI (vs PCIE x16, PCIE x4).
04:51kreyren_: yes that is there afaik
04:51kreyren_: set to PCIEx16
04:51kreyren_: nmschulte: you want me to set it to PCI or ?
04:52nmschulte: yeah try PCI
04:52nmschulte: did you boot w/o the PCIE card in yet?
04:52kreyren_: nmschulte: yes log provided
04:53nmschulte: your last boot in 2Sj5 log shows detecting NVIDIA card --
04:53nmschulte: Mar 10 05:38:47 dreamon kernel: [ 3.784632] nouveau 0000:01:00.0: NVIDIA GM204 (124020a1)
04:55kreyren_: ah x.x
04:55nmschulte: oh I see it's a combined log -- the boot just before does not show nouveau log line
04:55kreyren_:is rebooting to try the PCI
04:58kreyren_: without change it seems
04:59nmschulte: maybe try updating the BIOS version
04:59kreyren[irssi]: nmschulte: this is the latest version afaik
05:00nmschulte: it's interesting that that motherboard seems to have no video-out ports on it
05:00kreyren[irssi]: hm O.o
05:00kreyren[irssi]: you think that the CPU has iGPU, but mobo doesn't support it?
05:00nmschulte: "(Some Intel® Core™ processors require a graphic card, please refer "CPU support List" for more information.)" -- https://www.gigabyte.com/Ajax/SupportFunction/Getcpulist?Type=Product&Value=3863 and https://www.gigabyte.com/us/Motherboard/GA-Z68A-D3-B3-rev-10/support#support-cpu
05:01kreyren[irssi]: it showed LLVM pipe before though
05:01nmschulte: indicates that the CPU has a GPU w/ clock, so I guess it's not under that "require a graphic card" category, but the mobo has no video ports...
05:01kreyren[irssi]: and the main issue is element-desktop getting sluggy after X amount of second.. maybe that's becaue of the spam that nouveau is placing in the kernel log?
05:01kreyren[irssi]: ah doesn't seem to do that now
05:02nmschulte: the llvmpipe renderer means CPU-based math, not CPU-integrated-GPU math
05:02kreyren[irssi]: i see
05:02nmschulte: it's able to use the dGPU in a "dumb" way to put out video content, but it's not "accelerated"
05:02kreyren[irssi]: ah so i guess that's what i though is iGPU
05:03nmschulte: try #intel-gfx, they may know off-hand what the issue is
05:03kreyren[irssi]: oke thanks ^-^
05:38imirkin: pmoreau: fixed up 1d arrays and some more formats, and now both KHR-GL45.shader_image_load_store.basic-allTargets-loadStoreCS and KHR-GL45.shader_image_load_store.basic-allFormats-loadStoreComputeStage pass on nv50
05:38imirkin: i think that's a pretty good indicator that the core logic works
07:26kreyren: > [ +0.034990] nouveau 0000:01:00.0: gr: DATA_ERROR 0000000c [INVALID_BITFIELD] >
07:26kreyren: How do i fix this? It seems to make some application to have huge delay on input
07:29kreyren: (observed in element-desktop which is electron and in Steam which should also be electron)
07:29kreyren: seems to happen on random
07:35HdkR: Steam is CEF not Electron. So still Chromium :P
07:36kreyren: i see O.o
15:11imirkin: karolherbst: how do (load/store) images work in CL? is the format specified in the source, or is it all format-less and based on the bound image's format? or can you do it both ways?
15:39karolherbst: the function decides the format in most cases
15:40karolherbst: but there might be formatless functions? dunno...
15:40imirkin: it's not immediately apparent to me how the format is specified...
15:40karolherbst: but you specify the return value and I think the conversion happens implicitly
15:40karolherbst: images itself have no format declaration
15:41karolherbst: but you specify it when creating the images through the API
15:41imirkin: ah ok. so in the shader, there is zero info
15:41imirkin: so it's all formatless
15:41imirkin: based on the bound images' definitions
15:42karolherbst: unless there is anything I missed
15:42karolherbst: but you essentially have a "image2d_t img" kernel func parameter and that's it
15:42imirkin: and the read_image() call also doesn't have that info?
15:42karolherbst: typed return value
15:43imirkin: right ... it differentiates between i/ui/f
15:43imirkin: but not e.g. the channel widths
15:43imirkin: ok. that's what i assumed. thanks!
15:45karolherbst: CL just says unmapped channels have 0.0/1.0 values, so it's all defined
16:09imirkin: karolherbst: so i guess we'll need a shader key anyways for fermi/kepler. so what i'm doing for tesla is not pointless.
16:09imirkin: (maxwell+ can do formatless images natively)
16:09imirkin: karolherbst: are there any provisions for "raw" access to image data?
16:10imirkin: i.e. getting the packed data directly in CL?
16:10imirkin: and/or storing the packed data
16:12karolherbst: there is the concept of buffer images
16:12karolherbst: where you just back it with an memory object
16:12imirkin: but are the shader-level accesses typed or untyped?
16:12imirkin: i.e. do you get format conversion/etc?
16:12karolherbst: in the kernel it's all the same
16:13karolherbst: in the kernel it's all typeless
16:13imirkin: right ok. so it's like imageBuffer in GL then?
16:13imirkin: well... formatless
16:13imirkin: but typed
16:13karolherbst: well, not really
16:13karolherbst: you can use different types on the same image
16:13karolherbst: so the image itself is typeless, but the operation types it
16:14imirkin: so ... typed access.
16:14karolherbst: so what you do at runtime is to have an image per typed operation or so
16:14imirkin: and more importantly, there's no way to ignore the format of the image
16:14imirkin: i.e. the image has some format and that's that
16:14karolherbst: I don't know
16:14imirkin: the shader doesn't know what it is
16:14karolherbst: CL 2.0 might have stupid crap
16:14karolherbst: right, the shader doesn't know
16:14karolherbst: you have a cl_image_format thing when creating the iamge
16:14imirkin: i guess what i'm getting at is whether, in nv50 ir parlance, only SUSTP / SULDP are supported
16:15imirkin: or whether there's also SUSTB and SULDB
16:15imirkin: that's all outside the shader
16:15karolherbst: it's more complex
16:15karolherbst: for simple read only images we use tex ops
16:15karolherbst: with samplers
16:15imirkin: *P provide "typed" values, which are converted to/from image format
16:15karolherbst: so it's tex* whatever
16:15imirkin: *B provide "raw" values which are stored as-is without any sort of conversions
16:15karolherbst: only if you have writeable images or samplerless read only ones we actually use image ops
16:15imirkin: yea, forget those.
16:16imirkin: i'm talking about image ops.
16:16karolherbst: soo. I think you have to specify the format when creating an image
16:16imirkin: so the *B variants are inaccessible from the sounds of it
16:16karolherbst: there is no CL_NONE or whatever
16:16imirkin: i was more like looking for
16:17imirkin: write_image_packed() or something
16:17imirkin: whereby instead of giving it (1, 2, 3, 4) you'd give it 0x1234 or whatever
16:17karolherbst: ahh, no
16:17imirkin: (obviously not that ... RGBA4444 isn't a common image format, but you get the idea)
16:18karolherbst: I think the conversion has to be done implicitly
16:18karolherbst: CL is quite nice in exposing supported formats
16:18karolherbst: so you can just not support what the hw can't do
16:18imirkin: the hw can't do anything
16:18imirkin: it all has to be done by the shader
16:18karolherbst: mhh, right
16:18imirkin: (for pre-maxwell)
16:19imirkin: it can write, but it can't read
16:19karolherbst: yeah.. sadly there is a minimum of formats you ahve to support
16:19karolherbst: you read with tex ops
16:19imirkin: (and on tesla, it can't do either)
16:19karolherbst: not with suld
16:19imirkin: i guess ... implicitly you support all the *32 formats ;)
16:19imirkin: since there's nothing to be done for those
16:19imirkin: what if you write?
16:19karolherbst: write_read images and samplerless are all CL 2.0 features
16:20karolherbst: then you use sust
16:20karolherbst: but an image is either read only or write only :)
16:20imirkin: but that won't update the tex cache
16:20karolherbst: it can't be both
16:20imirkin: i see
16:20karolherbst: unless you have CL 2.0
16:20imirkin: i was unaware of that.
16:20imirkin: so then fermi/kepler are covered
16:20imirkin: since writing formatted data works fine there
16:21imirkin: still need it for tesla though ;)
16:21imirkin: and for fermi/kepler for read_write images
16:21imirkin: makes sense.
16:21imirkin: thanks for the info!
16:21karolherbst: but I would focus on image_load first and deal with read_write images once we get there
16:21karolherbst: or samplerless ones
16:21imirkin: well, it's all-in-one for what i'm doing right now
16:21imirkin: i have to add it for tesla
16:21imirkin: so it's just a question of "do i hook up for nvc0 or not"
16:22karolherbst: I guess as with CL 3.0 we can expose certain features
16:22karolherbst: so we can support CL 1.2 + samplerless images + read write images and that's it
16:22imirkin: btw, what's the status on CL?
16:22karolherbst: CL 3.0 is released and clover has the API support for it afaik
16:22imirkin: i know there are a bunch of overlapping efforts
16:23imirkin: but i have no idea what the progress is on any of them :)
16:23karolherbst: what do you mean by overlapping efforts?
16:23karolherbst: it all boils down to different areas of the code afaik
16:23imirkin: clover support for stuff, driver support, etc
16:23imirkin: ok, so maybe not overlapping then
16:23imirkin: overlapping in that they're all related to CL :)
16:23karolherbst: yeah, that's a mess and I would ignore it for now :) clover doesn't really check what the driver supports
16:23karolherbst: ahh yeah
16:24karolherbst: but it's all in different ares, like vtn, clover, drivers, nir, etc...
16:24imirkin: right ...
16:24karolherbst: still have some patches to fix images with CL :D
16:24imirkin: so what can i get, and how do i get it?
16:24imirkin: (if there's a doc on this, feel free to point me at it)
16:24karolherbst: that's essentially what you need for proper image support
16:24karolherbst: in clover
16:25karolherbst: with that it just works on turing and so on
16:25imirkin: "it" = ?
16:25karolherbst: but 2d images already work out of the box
16:25karolherbst: CL 1.2 image features
16:25imirkin: images are part of CL 1.2 iirc?
16:25imirkin: ah ok
16:25karolherbst: but CL 1.2 adds 1D, array and buffer images
16:25karolherbst: but it's all optional
16:25imirkin: ah i see
16:25karolherbst: so you can expose CL 1.2 without supporting images
16:26karolherbst: and before 1.2 you had only 2D and 3D images
16:26imirkin: ok, so ... let's say i build with clover
16:26imirkin: i still need some sort of libclc/etc thing?
16:26imirkin: maybe git llvm?
16:26karolherbst: then you get 1D, 2D and 3D image support in nouveau :)
16:26karolherbst: whtever llvm
16:26karolherbst: spirv libclc
16:26karolherbst: that's it
16:26imirkin: how/where do i get those?
16:27karolherbst: uhm... I think you can build the spirv libclc upstream already.. not sure
16:27karolherbst: spirv-llvm-translator: https://github.com/KhronosGroup/SPIRV-LLVM-Translator
16:27imirkin: probably that one.
16:27karolherbst: just select the fitting llvm branch
16:27karolherbst: that's probably it going by its name
16:27imirkin: seems reasonable
16:28karolherbst: the opencl cts has a bunch of image tests in case you are too lazy to write some
16:28karolherbst: but... it's annoying to build as you need newest CL headers most of the time
16:29imirkin: or an older cts
16:30karolherbst: that's what I usually do
16:31imirkin: hm, the gentoo libclc is too old for spirv i think =/
16:31imirkin: that's nov 2020
16:32karolherbst: I can give you the files :D
16:32imirkin: how might a normal person obtain these?
16:33imirkin: just install libclc-git?
16:33karolherbst: depends on the pckaging
16:33karolherbst: I can just send them to you by email
16:33imirkin: let's not worry about the packaging
16:33karolherbst: ohhh wait
16:33imirkin: well i'd like it to be reasonable in gentoo
16:33karolherbst: you need 32 bit ones...
16:33karolherbst: I only have 64 bit ones
16:34imirkin: anyways, i'll dig into it a bit i guess
16:34karolherbst: yeah.. dunno if the packaging is wired up
16:34karolherbst: only one way to find out
16:34imirkin: so for clover, i just need the spirv-llvm-translator and libclc and that's it right?
16:35imirkin: and by 64/32-bit you mean gpu address space right?
16:35imirkin: diff spirv for diff pointer sizes
18:35imirkin: karolherbst: quick ack on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9487 ?
18:58karolherbst: will take a look at the MR tomorrow, short on time.. maybe in a few hours, depending how late it will get
18:59karolherbst: imirkin: wasn't there a NV extension?
18:59karolherbst: ohh, there wasn't
18:59imirkin: not for this
18:59imirkin: well, the EXT_* one is sort of the NV extension ;)
18:59karolherbst: weird.. only nv people worked on it though :D
18:59imirkin: coz NV are the only ones to implement it
18:59karolherbst: maybe that's the reason I thought there was one
18:59imirkin: everyone else had limitations
19:00karolherbst: did you test it on pascal?
19:00imirkin: only pascal
19:00imirkin: but it's reported on gpuinfo as working on maxwell2
19:00imirkin: so ... i just went with it
19:00karolherbst: yeah, makes sense
19:01karolherbst: my desktop is kind if trashed right now anyway.. just made a clean RHEL installation but I wanted to figure out multi OS boot with multiple linux distros on the same machine....
19:01karolherbst: but.. uff
19:02karolherbst: they all add their own folders inside the efi partition and then each OS gets its own boot/root and if I use lvm I can even resize at will mhhhhhhhhhhhhhhhhhhh
19:02karolherbst: I think I will try that
19:04karolherbst: imirkin: did you ever tried something funny like this?
19:04imirkin: i've used gummiboot with EFI
19:04imirkin: seemed to suit my needs
19:05imirkin: i tend not to go with the "defaults", whatever they might be
19:05karolherbst: sure, but when you install a distribution besides gentoo they kind of want to install their efi files
19:06karolherbst: and I kind of don't want to have like multiple partitions for each distribution
19:06imirkin: and i tell them to go f themselves
19:06karolherbst: right, but I have this job, which sometimes I feel an obligation to fix bugs for distribution my employer cares about :p
19:06imirkin: kind of need separate disks for each distro i'd think...
19:06karolherbst: why though?
19:06karolherbst: so fedora installs grub inside /boot/efi/EFI/fedora
19:07karolherbst: and RHEL installs it into /boot/efi/EFI/redhat
19:07imirkin: well, the libc in one distro might not be the same as libc in another
19:07karolherbst: so I could share one efi fs
19:07karolherbst: and just have each distribution with their own root
19:07imirkin: right, one efi fs
19:07karolherbst: and if I use lvm I can just resize if I need more space
19:07imirkin: didn't think you could have multiple
19:07karolherbst: I was just never thinking about sharing one efi...
19:07karolherbst: but that should work
19:08karolherbst: I just have to try if I can get rid of /boot
19:08imirkin: i'm not sure you can have multiple EFI executables
19:08imirkin: in one EFI
19:08imirkin: maybe you can
19:08karolherbst: why not?
19:08imirkin: well, it's whatever the bios supports :)
19:08imirkin: if it wants a fixed path
19:08imirkin: then it wants a fixed path
19:08imirkin: you can have 1000 binaries, won't help a bit
19:08karolherbst: my motherboard goes deepshit crazy and lists like bazillion things
19:09imirkin: iirc it's pretty picky about paths
19:09imirkin: but i don't remember specifics
19:09imirkin: i just use gummiboot for the diff linux configs i might use
19:09karolherbst: efibootmgr can be used to add more entries to the firmwares bootloader
19:09karolherbst: it just would be annoying if something deletes the old ones
19:09karolherbst: my firmware tends to remove entries to removed files
19:09karolherbst: so as long as the files stay it should be fine
19:10karolherbst: anyway.. should be easy to try out :)
19:10karolherbst: I am just wondering how picky distributions are about single root without /boot
19:11imirkin: /boot is the EFI, no?
19:11karolherbst: /boot/efi is
19:11karolherbst: in /boot you have the installed kernels and stuff
19:11imirkin: think about it this way
19:11karolherbst: at least with fedora and rhel
19:11imirkin: do these fancy distros
19:11imirkin: support dual-boot with windows?
19:12imirkin: and how is windows different than another random linux distro installed in another disk?
19:12karolherbst: but it doesn't really matter
19:12karolherbst: grub is inside /boot/efi/
19:12karolherbst: but my concern is rather if I can ditch /boot/ as well
19:12karolherbst: because then I have 1 efi + 1 partition for each distribution
19:12karolherbst: instead of 2 for each
19:13imirkin: but /boot can be in the root
19:13imirkin: no harm in that
19:13karolherbst: I know that I need a path being /boot/ for the package manager to install shit
19:13imirkin: (unless you want to also use LILO :) )
19:13karolherbst: the question is, do the installer configure grub in a way that it mounts root and finds the kernels ;)
19:14imirkin: one way to find out!
19:14karolherbst: but there is so much magic in the installer these days, it probably detects it based on the table
19:14imirkin: presumably you tell it where /boot is in the first place
19:14imirkin: so it'd have to have a "disk id" of some sort
19:14karolherbst: I have to configure it
19:14imirkin: and then it's all just paths
19:14karolherbst: I always do manual layout so I can ditch swap as well
19:14karolherbst: and /home because fedora/rhel are stupid
19:14karolherbst: still doing /home
19:14karolherbst: and 50GB /
19:14karolherbst: it's so painful
19:15imirkin: yeah, i stopped doing that shit when disks hit a few GB
19:15karolherbst: I ran out of space at some point
19:15karolherbst: because cuda
19:15karolherbst: and... libvirt putting vms in a stupid place
19:16karolherbst: I have a 256GB SSD and a 2TB HDD in the desktop..
19:16karolherbst: plenty of space
19:17karolherbst: anyway, gtg and will take a deeper look at the MR later as I am sure I will watch an installer install stuff
19:17imirkin: see ya
20:26kwizart: Hello, it looks like the new allocator is hitting kernel BUG on get_page on jetson-tk1 (armhfp) with nouveau:
20:26kwizart: 461619f5c3242aaee9ec3f0b7072719bd86ea207 is the first bad commit
20:26kwizart: drm/nouveau: switch to new allocator
20:31kwizart: hum, It's possible that there is a fix as linux-next is working with me...
20:33imirkin: airlied has a fix for that one iirc
20:33imirkin: dunno if it's in -next yet or not
20:48RSpliet: kwizart: this vaguely sounds like a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1930977
20:50RSpliet: Oh, no it isn't ,sorry. Or well, too vaguely to be true/valuable :-P
20:50kwizart: RSpliet, looks like there are few bugs in few components... here my problem is bissected within the kernel
20:52kwizart: imirkin, at least linux-next from 20210302 works... I'm testing few candidates from anything related to ttm...
20:53kwizart: 2b1b3e544f65f40df5eef99753e460a127910479 and 811ee9dff58072742644da2c07641728f5e078e4
20:58imirkin: kwizart: there was something like ... today
20:59kwizart: imirkin, you means todays's linus next ?
20:59imirkin: kwizart: oh, no, that was fixing something else
20:59imirkin: i meant a patch sent today. except it wasn't today
20:59imirkin: and it was fixing a different commit
20:59imirkin: 'drm/nouveau: fix dma syncing for loops', fixes f295c8cfec83
21:00imirkin: kwizart: there's also a thread about this
21:00imirkin: `drm/nouneau: 5.11 cycle regression bisected to 461619f5c324 "drm/nouveau: switch to new allocator"`
21:01imirkin: ckoenig had a fix to it last month
21:01imirkin: `drm/ttm: make sure pool pages are cleared`
21:01imirkin: i think that one's upstream too ... but perhaps in the wrong branch
21:13kwizart: linus master still misses the fix apparently
21:14imirkin: airlied: --^
21:18karolherbst: kwizart: you are the one from bug 1937236, right?
21:19karolherbst: your dmesg looks totally weird
21:19kwizart: karolherbst, hi! yes
21:19karolherbst: nouveau doesn't print... much
21:21karolherbst: doesn't print the chipset and stuff
21:22karolherbst: kwizart: do you have figured out a patch which fixes your issue?
21:22imirkin: karolherbst: yes, see above when you joined
21:23imirkin: ckoenig has a patch for it, from Feb
21:23imirkin: but i guess it's not made it to the right place yet?
21:23imirkin: `drm/ttm: make sure pool pages are cleared`
21:23karolherbst: guess so
21:23karolherbst: it's in master
21:23karolherbst: 5.11 even
21:24imirkin: ah, so then perhaps a bad bisect
21:24karolherbst: I guess
21:24imirkin: i.e. picked up a problem, just not the problem you were looking for
21:24karolherbst: bisecting on arm is a terrible experience
21:24imirkin: the other patch can also be important i think, and that one's much more recent:
21:24imirkin: 'drm/nouveau: fix dma syncing for loops', fixes f295c8cfec83
21:24karolherbst: imirkin: did you see the dmesg?
21:25kwizart: well, actually there are two different problem (at least). one is a bug on get_page (rhbz#1937129), the other is nouveau discarded and llvm been used. rhbz#1937236)
21:25karolherbst: I bet nouveau bails out in a weird place
21:25karolherbst: imirkin: https://bugzilla.redhat.com/attachment.cgi?id=1762377
21:25imirkin: gah, why does everything want to download
21:25kwizart: the first issue, there is a fix between 5.12-rc2 (actually current master and linux-next 20210302
21:26karolherbst: either low debug level
21:26imirkin: bz used to show stuff inline just fine
21:26karolherbst: or it skips a bunch for... reasons
21:26karolherbst: probably a server setting
21:26imirkin: whoa, weird one.
21:26karolherbst: that was my thought as well
21:26imirkin: i like it :)
21:26imirkin: how does it not print a device id?
21:27imirkin: perhaps the platform thing got broken in ben's rework?
21:27karolherbst: the error is that channel allocation fails
21:27karolherbst: ehh no
21:27karolherbst: I used 5.11 on my jetson nano
21:27karolherbst: but maybe master is broken? dunno
21:28karolherbst: kwizart: which kernel versions did you hit the issue on?
21:28karolherbst: 5.11 as well, right?
21:28karolherbst: anyway, I have no tk1 to debug this
21:28imirkin: i have a tk1, but it dies when there's network activity
21:28kwizart: for 5.11 I'm hitting the get_page bug before anything else
21:28karolherbst: imirkin: sad
21:28imirkin: which doesn't jive well with nfsroot
21:28karolherbst: maybe update the firmware?
21:29imirkin: didn't know that was a thing
21:29karolherbst: then you even get uefi support
21:29imirkin: it stays up longer with lkp
21:29imirkin: not lkp
21:29imirkin: what's the thign ...
21:29karolherbst: you have pins on the board
21:29kwizart: imirkin, yep seems like I've reported an issue with pci NIC and AER (maybe the same issue ? I'm using usb nic instead)
21:29karolherbst: two special ones
21:29imirkin: kwizart: wait, so i'm not just dreaming?
21:29karolherbst: with that you can flash an update firmware with the l4t package
21:30imirkin: as soon as it tried to do anything semi-heavy on network -- massive fail
21:30imirkin: kwizart: do you remember offhand if it has a working OTG port?
21:30karolherbst: power of or something else?
21:30imirkin: that i could use for gadget?
21:30karolherbst: when I use USB to power my nano it also powers of at some random points
21:31karolherbst: hence I am using the jack connector
21:31karolherbst: but I guess the tk1 is too big for usb
21:31imirkin: karolherbst: that's not an issue ... tk1 is wall-powered
21:31karolherbst: fair enough
21:31imirkin: building could lose power i guess
21:31imirkin: fuses can blow
21:31karolherbst: question is, what happens if the shit happens? :p
21:31karolherbst: usually the serial console will print something or it just powers off
21:31kwizart: imirkin, recent kernel has otg, indeed, you could setup a ethernet function
21:32karolherbst: anyway using jetson devices without uefi is pain
21:32kwizart: tested on tk1
21:32imirkin: kwizart: hmmm eeeinteresting. how does it boot? it has a fastboot thing? or?
21:32imirkin: oh no, it's some uboot thing
21:32karolherbst: so happy I am beyond dts
21:32karolherbst: but uboot is like stage 2
21:32imirkin: i remember weirdness.
21:32kwizart: imirkin, I'm using u-boot with dts full floss bootloader
21:33imirkin: kwizart: since you seem to know things about the tk1 ... can you point me to a good guide?
21:33karolherbst: imirkin: the updated firmware can to TFTP booting in case that makes it less annoying :p
21:33kwizart: on jk1 it's still possible to have a full floss bootloader (not jtx1)
21:33imirkin: karolherbst: not if network is the problem.
21:33karolherbst: kwizart: why not on later boards?
21:33kwizart: I think tftp is possible indeed
21:33imirkin: kwizart: my goal is to do nfsroot, fwiw
21:33imirkin: ideally i'd set up the ethernet function from within the initrd
21:34kwizart: karolherbst, aarch64 boards are using a very different bootloader flow with cboot,etc
21:34imirkin: that'd be clever of me.
21:34karolherbst: sure, but cboot is flashed, so it doesn't count :p
21:34karolherbst: but cboot is also open source, no?
21:34kwizart: here u-boot is also flashed on spi
21:34karolherbst: yeah, but I am using fedoras uboot
21:35kwizart: but cboot is only open-source on recent soc (not t210 on nano and jtx1)
21:35karolherbst: let me see...
21:36kwizart: yep, fedora u-boot on nano and tx1 are chainloaded after cboot (from l4t)
21:36karolherbst: the most annoying bit is how tar can create files only root can delete...
21:36karolherbst: why isn't that a bug
21:37karolherbst: ahh right...
21:37karolherbst: cboot sources only for the newer ones
21:38karolherbst: so TX2 and up
21:38karolherbst: oh well
21:56karolherbst: imirkin: look what I've found: https://www.amazon.de/dp/B075963KB2?linkCode=xm2&camp=2025&creative=165953&smid=A2OLLM5U3LXOGB&creativeASIN=B075963KB2&tag=geizhals10-21&ascsubtag=RQr7v211E3TOZzCh8ckgQ
21:58imirkin: my german ain't great, but i'm going to assume it's what the picture is
21:58imirkin: probably worth the 2E investment :)
21:59karolherbst: heh, for me it was in english :D
21:59karolherbst: yeah.. but I only have a 4 pin serial console
21:59imirkin: there's a little icon at the top
21:59karolherbst: I am wondering if I buy a proper serial console
21:59karolherbst: with 6 or 8 pins
21:59imirkin: get a proper vt220 console ;)
21:59imirkin: wave of the future!
22:00karolherbst: what I need is this bundle with all cables and everything
22:00imirkin: oh, so i got this thing...
22:00imirkin: hold on
22:00imirkin: need to track down my order
22:01imirkin: karolherbst: https://www.amazon.com/gp/product/B07TD94W58/
22:01imirkin: this gives maximum flexibility
22:02imirkin: which i needed for hooking up to various ARM boards
22:02karolherbst: annoying though
22:02imirkin: yeah, but the pins are all over the place and in random order
22:02karolherbst: I guess
22:02imirkin: so beggars can't be choosers
22:02imirkin: literally on ifc6410 it's like A,B,C next to each other, and ifc6540 it's B,A,C next to each other
22:02karolherbst: and how do you deal with this TTL vs RS232 thing?
22:03imirkin: it's a usb adapter on one side
22:03imirkin: and the arm board on the other
22:03imirkin: it worked out.
22:03karolherbst: what serial console do you have?
22:03imirkin: you mean usb/serial thing?
22:04karolherbst: I mean, the USB thingy
22:04imirkin: some ancient ftdi one
22:04imirkin: i literally got it in like 2004 or so
22:04karolherbst: I have some of those as well but I have nfi where
22:04imirkin: probably don't make that exact one anymore :)
22:05imirkin: i got it to plug my laptop (which already was serial port-less at the time) into cell-enabled gps receivers
22:05imirkin: (so that i could configure them to do the thing i wanted)
22:07karolherbst: if it would be easier to find that stuff D:
22:08karolherbst: now I found a cable which an integrated internal 4 PIN TTL to RS232 converter module :D
22:14karolherbst: mhh https://www.seeedstudio.com/USB-TO-RS232--RS485--TTL-Industrial-Isolated-Converter-p-3231.html
22:15karolherbst: that looks nice, but also a bit expensive :D
22:17karolherbst: but I think I will go for the following: a proper USB to RS232 console with a RS232 to 9 pin cable, because that's more or less standard, + a RS232 to TTL converter with flexible pins
22:19karolherbst: or I just buy two
22:22karolherbst: imirkin: https://www.amazon.de/-/en/Aihasd-1-1pcs-CP2102-USB-Serial-RS485-3-3/dp/B07G983DY7/ref=sr_1_29?dchild=1&keywords=USB+RS232&qid=1615414889&s=computers&sr=1-29
22:26imirkin: wow, so it includes a passthrough
22:26imirkin: where the USB is just not hooked up to anything
22:26imirkin: so you can convert RS232 to RS485
22:27karolherbst: I need something with a longer cable anyway :D
22:27karolherbst: but this tiny piece just stood out
22:47karolherbst: imirkin: now I bought a console with a rs232 cable and this thing: https://www.amazon.de/gp/product/B006DYQNIK/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1
22:47karolherbst: the pins are correct for my desktop so this is less hazzle than trying to get them right every time
22:47karolherbst: fun fact: with the slot it's cheaper, that's why
22:49damo22: that is what i bought
22:49karolherbst: I even have a spare slot, so maybe I just leave it inside forever
22:50damo22: i ported quite a few boards to coreboot with that
22:50karolherbst: those 9 pin ones are all the same layout, aren't they?
22:50karolherbst: just the TTL ones are always differnt
22:51damo22: almost, i think there was one board that had a different layout but i didnt need to port it
22:51damo22: i only recall because a friend of mine was annoyed his didnt work
22:52karolherbst: I also don't get how you can get this one wrong
22:52karolherbst: because to do it like everybody else is just simplier
22:52karolherbst: they also have those mb USB ports to PCIe slot
22:52karolherbst: oh well
22:52karolherbst: already have enough USB on this mb
22:53karolherbst: but in case those 9 usb ports aren't enough, the mb has pins for 6 more
22:53damo22: are there TTL rs232 on the nv gpus?
22:53karolherbst: no clue?
22:54karolherbst: or do you mean jetson?
22:54damo22: to write the keys
22:54karolherbst: probably not
22:55karolherbst: the keys are all fixed so what would be the benefit?
22:55damo22: the benefit would be for the end user clearly
22:55karolherbst: it's nv :p
22:56damo22: i am still hoping there is an override
22:56damo22: like a flag that disables it
22:56karolherbst: maybe there is somewhere
22:56karolherbst: they also have debug keys for the signed firmware shit only working for dev machines
22:57damo22: in the .sig files there is a trailing few bytes, i think there is room for toggles there
22:59damo22: that is my theory but i dont have hw to test
22:59karolherbst: I am sure they don't make it that easy
23:00karolherbst: and again
23:00karolherbst: they have dev and production hardware
23:00karolherbst: so why even bother?
23:00karolherbst: it might be those things only do something on dev boards
23:00karolherbst: wouldn't be the first thing
23:01damo22: hey, intels management engine lazy loads modules and doesnt care if some are missing
23:01karolherbst: intel is a disaster
23:01damo22: so there is plenty of ways to stuff up the security
23:01karolherbst: I expect more from nvdia than from intel
23:02karolherbst: intels hw is so broken, you might even have to disable multithreading to be safe
23:02karolherbst: because as it turns out, the interconnect is also broken
23:03damo22: im tired of booby trapped hardware
23:03damo22: that is one reason i gave up hacking on coreboot
23:04damo22: so even if you can figure out raminit, you probably cant run it on the hardware
23:05karolherbst: x86 is a terrible ISA anyway
23:06damo22: but nv bought arm
23:08damo22: they'll put all their secret sauce into CrustZone
23:08karolherbst: yeah... we'll see
23:10damo22: then they can claim their gpus have open source driver
23:10HdkR: Not bought yet, might not even happen
23:12damo22: i hope the deal falls apart
23:13damo22: or quantum computing becomes available to crackers
23:15Lyude: i hope the deal falls apart too, mergers are never good for anyone who isn't a higher up at the companies involved
23:15Lyude: it is pretty funny though that it's mostly nvidia's history that is behind why the merger is even being questioned in the first place
23:16damo22: i have this 604 digit number that is difficult to factorise...
23:17imirkin: pick a different one, that's much easier to factor ;)
23:17damo22: yeah if i could choose my own, that would be easeier
23:20imirkin: i recommend n! ;)
23:24damo22: or p*q
23:24imirkin: but then you have to remember p and q
23:24imirkin: whereas with n!, you can pick any small number, and have it be right ;)
23:25damo22: well i guess that is the problem, i need to know p and q
23:29damo22: oh you meant n factorial
23:29damo22: that would work i guess
23:30damo22: just not very secure
23:31karolherbst: I can offer you hand choosen p and qs which look nice if printed out
23:31imirkin: damo22: but much easier to factor
23:31imirkin: i thought that's what you wanted :)
23:32imirkin: you were dissatisfied with your 604-digit number
23:32imirkin: so i'm just suggesting strategies for picking another one that better fits your needs :p