Re: XDG_RUNTIME_DIR
On Mon, 26 Apr 2021, Steffen Nurpmeso wrote: RVP wrote in : | |Use POSIX shm_open+sem_open? That should let you do proper reference |counting w/o a server. You'll have to pull in -lrt on Linux & NetBSD |for this though... Well, that module had (file-locked file-based) reference counting. It will not work with programs backgrounding away, like tmux. Unless you PAMify them all. Even then. Any shell script can background away. You thus need a global authority collecting all per-user programs that execve(2) away from a (child of a) program who enabled a session, which was what i (who never looked into this, being Yes. Programs which do exec will be a problem with PAM. Worse if the program does daemon() then exec(). Then, even login won't be able to keep track of them. It'll have to handled by init itself. (We haven't even considered X11 programs here...) We come back full circle to a sort-of systemd impl. it seems... -RVP
Re: XDG_RUNTIME_DIR
On Mon, 26 Apr 2021, Steffen Nurpmeso wrote: RVP wrote in : ... |There should be a removal of the dirs. on the user's final session |logout, I think. This is impossible to do with pam that i never liked (nor understood, in FreeBSD ~twenty years ago), Use POSIX shm_open+sem_open? That should let you do proper reference counting w/o a server. You'll have to pull in -lrt on Linux & NetBSD for this though... -RVP
Re: XDG_RUNTIME_DIR
RVP wrote in : |On Mon, 26 Apr 2021, Steffen Nurpmeso wrote: | |> RVP wrote in |> : |> ... |>|There should be a removal of the dirs. on the user's final session |>|logout, I think. |> |> This is impossible to do with pam that i never liked (nor |> understood, in FreeBSD ~twenty years ago), |> | |Use POSIX shm_open+sem_open? That should let you do proper reference |counting w/o a server. You'll have to pull in -lrt on Linux & NetBSD |for this though... Well, that module had (file-locked file-based) reference counting. It will not work with programs backgrounding away, like tmux. Unless you PAMify them all. Even then. Any shell script can background away. You thus need a global authority collecting all per-user programs that execve(2) away from a (child of a) program who enabled a session, which was what i (who never looked into this, being a fan of runit or just nothing but SysV init or say OpenBSD, and who never touched FreeBSD PAM stuff but just used what shipped) would have expected .. it seems. Because i was surprised to find out that was not what was happening (and shouldn't it be nothing but a single bit and some kind of notification). I dislike all the people liking systemd for allowing exactly this. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: xhci "device problem, disabling port 5"
On Sun 25 Apr 2021 at 21:32:27 +0200, Rhialto wrote: > $ egrep 'uhub|usb|xhci' /var/run/dmesg.boot > xhci0 at pci0 dev 20 function 0: Intel 300 Series USB 3.1 xHCI (rev. 0x10) > xhci0: 64-bit DMA > xhci0: interrupting at msi1 vec 0 > xhci0: xHCI version 1.10 > usb0 at xhci0: USB revision 3.1 > usb1 at xhci0: USB revision 2.0 > uhub0 at usb0: NetBSD (0x) xHCI root hub (0x), class 9/0, rev > 3.00/1.00, addr 0 > uhub0: 6 ports with 6 removable, self powered > uhub1 at usb1: NetBSD (0x) xHCI root hub (0x), class 9/0, rev > 2.00/1.00, addr 0 > uhub1: 16 ports with 16 removable, self powered > uhidev0 at uhub1 port 7 configuration 1 interface 0 > uhidev1 at uhub1 port 7 configuration 1 interface 1 > uhidev2 at uhub1 port 8 configuration 1 interface 0 So those usb sticks were USB-2, attaching to uhub1. Today I tried a USB-3 device, attaching to uhub0 (a real external spinning disk). I plugged it in 3 times in succession and it went ok every time. It is not only an umass but also a ses device. My "BIOS setup" has something about "XHCI handoff", supposingly something for compatibility with some OSes. I turned it on on the general principle that anything "for compatibility" would apply to non-Windows OSes. For the USB-2 case, could it help to keep it disabled instead? Is it even clear what the option might do? A quick googling didn't reveal anything interesting. -Olaf. -- ___ Q: "What's an anagram of Banach-Tarski?" -- Olaf "Rhialto" Seibert \X/ A: "Banach-Tarski Banach-Tarski." -- rhialto at falu dot nl signature.asc Description: PGP signature
Re: nvmm doesn't work on "Intel(R) Core(TM) i5-9600K CPU @ 3.70GHz"?
On Sun 25 Apr 2021 at 23:10:48 +0100, Chavdar Ivanov wrote: > Did you 'modload nvmm' ? It doesn't get loaded automatically. Duh! Of course, that was it. I forgot about that detail; on my old machine I had put it in /etc/modules.conf. -Olaf. -- ___ Q: "What's an anagram of Banach-Tarski?" -- Olaf "Rhialto" Seibert \X/ A: "Banach-Tarski Banach-Tarski." -- rhialto at falu dot nl signature.asc Description: PGP signature
Re: XDG_RUNTIME_DIR
RVP wrote in : |On Sat, 24 Apr 2021, Steffen Nurpmeso wrote: | |> If you run Linux you could also use the pam_xdg module i have |> written. For example my /etc/pam.d/common-session is |> |> session optional pam_xdg.so notroot |> |> session requiredpam_unix.so quiet |> |> and the stuff is as attached. It handles the other directories of |> the standard as well. |> | |This is, I presume, for Linux systems without systemd and pam_env.so? systemd yes, pam_env no. pam_env is pretty fat and does a lot of things which are not needed here. And of course it does not create directories. ... |There should be a removal of the dirs. on the user's final session |logout, I think. This is impossible to do with pam that i never liked (nor understood, in FreeBSD ~twenty years ago), but CRUX gained it with 3.6, and i was right when looking from the code side. 'Thing is, while doing this, i looked at code from login (of shadow) and all that, and it is a pity if you see all the construction sites ..the possibilities that have been buried there .. because of pam .. because of systemd. You rather look to some BSD with steady iterations and improvements on login.conf or another mechanism. I mean there is "finit", but that is a complicated mess also it seems. Yeah i mean, all this started because someone here was using a server (written in R or another new/strange language that came in as a depency) that was doing pam to do only the RUNDIR part of the game. But it is bitter, only the real unshare(1) with a new PID 1 can do real book keeping, from user space. I would have expected actual support for this, yes. Like it is, PAM sessions are a gracy thing (imho). I personally use my /run/user/UID only for unshare(1) box roots. I do not have graphical programs but st(1) and firefox-bin (with audacity still in the line to come). But the thing does it and is used. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: xhci "device problem, disabling port 5"
On Sun, Apr 25, 2021 at 08:39:10PM -, Michael van Elst wrote: > rhia...@falu.nl (Rhialto) writes: > > >hexander$ sudo drvctl -r uhub1 > >drvctl: DRVRESCANBUS: Invalid argument > > A bus can have the notion of an "interface attribute" that you must > pass. uhub knows about "usbifif" for network interfaces and "usbdevif" > for other devices like umass. > Actually, "usbifif" is for attaching USB Interfaces, of which a device can have multiple instances and/or varieties. "usbdevif" is for attaching the entire USB device. Typically USB standard Classes use USB Interfaces. Whether the USB device or USB Interface has network interface functionality is unrelated to the above terms.
Re: xhci "device problem, disabling port 5"
On Sun, Apr 25, 2021 at 09:44:06PM -, Michael van Elst wrote: > rhia...@falu.nl (Rhialto) writes: > > >> sudo drvctl -r -a usbdevif uhub1 > >>=20 > >> should work. > > >It works in the sense that it doesn't give any error. But it has no > >noticable effect either, unfortunately. No messages printed on the > >console, visible via dmesg or /var/log/messages. > > It does not clear the error condition nor re-enable a port. I'm not > sure if you can recover from that condition except by a reboot. On unplug the port gets back to working conditions. I have USB/serial adapters which needs several unplug/replug cycles ... It may be a NetBSD issue, I've not seen this with linux -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
