Re: Why I screwed up my NetBSD system?
On Fri, Dec 08, 2023 at 05:03:21PM +0100, Ramiro Aceves wrote: > [...] > What was my mistake? Sorry for the lack of detail but is what I can recall > from my poor memory. Just want to know what I did wrong and never do it in > the future. NetBSD 10.99 to 10.0_RC1 is not an upgrade but a downgrade actually. This is not supported. What probably happended is that some 10.99 dynamic libraries were still around (because they have a higher number than their 10.0 counterpart), but a 10.0 kernel would not support them -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD-10.0RC
On Thu, Dec 07, 2023 at 11:03:55PM -0500, Todd Gruhn wrote: > Got a result: > > cd /dev/dri > chmod 640 card? # all 4 card devices > > > I need to change all 4 cards in my system. > I tried this on renderD1??? ; dont do anything good for render devices. > > in .xinitrc: xrandr -s 1280x1024. > This gets me the window-size I want; but games freeze. > How do I fix this? > > Errors in /var/messages went away -- put some of these errors > popup when I shutdown the system... If you make the card devices mode 640 it means that Mesa can't use the GPU any more and will switch to software rendering. It may make the driver less verbose but some software may refuse to work without hardware rendering -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD-10.0RC
On Tue, Dec 05, 2023 at 12:40:31PM -0500, Todd Gruhn wrote: > Found problem with NetBSD-10.0RC > > I play DOOM, screen goes black. > I see error: > > Recommended Mode > 1920x1080 What does print this ? > > I think I know "what it is" -- but how do I set this (or several Modes) ? with the xrandr command -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD-10.0RC
On Mon, Dec 04, 2023 at 03:28:56PM -0500, Todd Gruhn wrote: > Make software (EMACS) > > I want to do: > >/bin/ksh configure --without-all --with-a-toolkit=athena > > Why doesnt this build? > i want emacs in /usr/local/* -- I have alot of my own stuff I put in > /usr/local/* At some point you'll have to tell it to look at /usr/pkg to find the includes and libraries What option(s) does this is software-dependant -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD-10.0RC
On Mon, Dec 04, 2023 at 11:06:20AM -0500, Todd Gruhn wrote: > REALLY??? > > How does NetBSD and X11 figger out what graphics card I have? NetBSD knows as it did attach the nouveau driver at boot. Likewise, X11 will scan the PCI bus for graphic cards. Maybe it will also probe /dev/dri/card0 for the graphic device found by the kernel (I don't know the details) -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD-10.0RC
On Mon, Dec 04, 2023 at 08:18:23AM -0500, Todd Gruhn wrote: > ./meta-pkgs/module-xorg is now installed. > > Lets retry this. > I have 2 xorg.conf sitting in another dir... > > I want to get X working with xorg-GTX -680.conf, then to xorg-GTX-1660.conf > ... With modular xorg you should not need any xorg.conf On my T400 it did work this way -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD-10.0RC
On Sun, Dec 03, 2023 at 08:02:16AM -0500, Todd Gruhn wrote: > DOHH! > > NetBSd started /bin/sh and print this: > > "/etc/rc.conf: 44: Syntax error" > > I cant do anything -- /bin and /sbin dont exist. I don't know how you came in this situation. But if the boot goot as far as trying to parse /etc/rc.conf, at last /bin/sh and /sbin/init could be started > > Many years ago, I would boot 23in floppies; them mount the hard-disk > (wd0a); then copy /etc/rc.conf to ./mnt2/etc. I can't do this anymore... > (YEPPP -- NetBSD on 2005. So much changed...) Yes, the rc.conf is not on the install media I believe. But you can still boot the install media, get a shell and mount /dev/wd0a -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD-10.0RC
On Sat, Dec 02, 2023 at 05:01:44PM -0500, Todd Gruhn wrote: > Screwed up NetBSD -- need wizardly: > > in /etc (on wd0) i screwed up rc.conf ; how do I copy an original-version > to the hard disk? You can either extract etc.tar.xz to /tmp (for example) and copy rc.conf from here. Or you can download it from there: http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/etc/rc.conf?rev=1.97_with_tag=MAIN Remeber to set rc_configured to YES in the new rc.conf before rebooting -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD-10.0RC
On Fri, Dec 01, 2023 at 09:24:55AM -0500, Todd Gruhn wrote: > WOW! Native xorg is too old. > > I never hear this before. Why is this? It's too old for recent nvidia boards (more specifically, NetBSD 10 has Mesa 19.1.17, pkgsrc has 21.3.9) As xorg depends on Mesa, you have to build xorg from pkgsrc too -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD-10.0RC
On Fri, Dec 01, 2023 at 09:14:28AM -0500, Todd Gruhn wrote: > " just make sure to not install the X11 sets (as you'll be > installing X11 from pkgsrc) " > > Why install X11 this way?? Because with your card you want the modular xorg from pkgsrc, not the native xorg. native xorg is too old -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD-10.0RC
On Fri, Dec 01, 2023 at 08:59:44AM -0500, Todd Gruhn wrote: > YEP! > > I forgot the dir -- but the name is "motif". > > I had another idea: > I upgraded many times from NetBSD-9.9x.foo ; so reinstall NetBSD-10.0RC > and rebuild must of the stuff from pkgsrc-Q3. Good idea; just make sure to not install the X11 sets (as you'll be installing X11 from pkgsrc) > > ALSO -- Can I upgrade the pkgsrc using pkgsrc using something like > cvs update -r foo -dPprior to making everything?? Yes, this works. Just make sure to remove the work directories -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD-10.0RC
On Fri, Dec 01, 2023 at 07:37:03AM -0500, Todd Gruhn wrote: > mwm is motif > > Motif windows manager It's a package then ? All package built with /usr/X11R7 needs to be rebuilt with native Xorg -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD-10.0RC
On Thu, Nov 30, 2023 at 06:46:04PM -0500, Todd Gruhn wrote: > I did not remove /usr/X11R7 -- should I ?? Yes > > X11R7 is now down -- I cannot bring MWM up... what is mwm ? -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD-10.0RC
On Thu, Nov 30, 2023 at 05:17:03PM +, Todd Gruhn wrote: > OKY -- A Q: > > I backed up /usr/X11R7; then make pkgsrc/meta-pkgs/modular-xorg > ( rm'ed nothing) > > Did I mess this up? Did you actually remove /usr/X11R7 ? In your Xorg.0.log I see references to /usr/X11R7, especially for modules. If the modular X server load modules from the native X server things will certainly go wrong. They're not the same version -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD-10.0RC
On Thu, Nov 30, 2023 at 03:39:35PM +, Todd Gruhn wrote: > Finished commenting the section; found and fixed one spelling > > > # Section "Device" > ### Available Driver options are:- > ### Values: : integer, : float, : "True"/"False", > ### : "String", : " Hz/kHz/MHz", > ### : "%" > ### [arg]: arg optional > #Option "SWcursor" # [] > #Option "HWcursor" # [] > #Option "NoAccel"# [] > #Option "ShadowFB" # [] > #Option "VideoKey" # > #Option "WrappedFB" # [] > #Option "GLXVBlank" # [] > #Option "ZaphodHeads"# > #Option "PageFlip" # [] > #Option "SwapLimit" # > #Option "AsyncUTSDFS"# [] > #Option "AccelMethod"# > #Option "DRI"# > #Identifier "Card0" > #Driver "nouveau" > #BusID "PCI:1:0:0" > ## EndSection > > ### > ## Setting for GEFORCE GTX-1660 > ### > > Section "Device" > Identifier "Nvidia T400" > Driver "mode setting" > BusID "PCI:1:0:0" > EndSection With modular Xorg you can remove this too. On my machine, modular Xorg did start with an empty Xorg.conf > > > +---+---+---+---++++++ > > The time-stam was 15:01 -- before I switched graphics cards. > Xorg.0.log below: > > [ 118.366] > X.Org X Server 1.21.1.9 > X Protocol Version 11, Revision 0 > [ 118.366] Current Operating System: NetBSD gandalf.gruhn-net.net > 10.0_RC1 NetBSD 10.0_RC1 (GENERIC) #0: Sun Nov 5 18:30:08 UTC 2023 > mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC > amd64 > [ 118.366] > [ 118.367] Current version of pixman: 0.38.4 > [ 118.367] Before reporting problems, check http://wiki.x.org > to make sure that you have the latest version. > [ 118.367] Markers: (--) probed, (**) from config file, (==) default > setting, > (++) from command line, (!!) notice, (II) informational, > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > [ 118.367] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Nov 30 > 14:53:28 2023 > [ 118.424] (++) Using config file: "xorg.conf.new" > [ 118.467] (==) ServerLayout "X.org Configured" > [ 118.467] (**) |-->Screen "Screen0" (0) > [ 118.467] (**) | |-->Monitor "Monitor0" > [ 118.467] (==) No device specified for screen "Screen0". > Using the first device section listed. > [ 118.467] (**) | |-->Device "Nvidia T400" > [ 118.467] (**) |-->Input Device "Mouse0" > [ 118.467] (**) |-->Input Device "Keyboard0" > [ 118.467] (==) Automatically adding devices > [ 118.467] (==) Automatically enabling devices > [ 118.467] (==) Not automatically adding GPU devices > [ 118.467] (==) Automatically binding GPU devices > [ 118.467] (==) Max clients allowed: 256, resource mask: 0x1f > [ 118.548] (**) FontPath set to: > /usr/X11R7/lib/X11/fonts/misc/, > /usr/X11R7/lib/X11/fonts/TTF/, > /usr/X11R7/lib/X11/fonts/Type1/, > /usr/X11R7/lib/X11/fonts/75dpi/, > /usr/X11R7/lib/X11/fonts/100dpi/, Are your really using modular Xorg ? With modular Xorg there should be no references to X11R7 > /usr/pkg/share/fonts/X11/misc/, > /usr/pkg/share/fonts/X11/TTF/, > /usr/pkg/share/fonts/X11/Type1/, > /usr/pkg/share/fonts/X11/75dpi/, > /usr/pkg/share/fonts/X11/100dpi/, > /usr/X11R7/lib/X11/fonts/misc/, > /usr/X11R7/lib/X11/fonts/TTF/, > /usr/X11R7/lib/X11/fonts/Type1/, > /usr/X11R7/lib/X11/fonts/75dpi/, > /usr/X11R7/lib/X11/fonts/100dpi/, > /usr/pkg/share/fonts/X11/misc/, > /usr/pkg/share/fonts/X11/TTF/, > /usr/pkg/share/fonts/X11/Type1/, > /usr/pkg/share/fonts/X11/75dpi/, > /usr/pkg/share/fonts/X11/100dpi/ > [ 118.548] (**) ModulePath set to "/usr/X11R7/lib/modules" this is wrong for modular Xorg. You should rm -rf /usr/X11R7 anyway, modular Xorg is installed in /usr/pkg/ and you should not keep both - these won't mix well. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD-10.0RC
#Option "DRI"# > Identifier "Card0" > Driver "nouveau" > BusID "PCI:1:0:0" > EndSection > > ### > ## Setion for GEFORCE GTX-1660 > ### > > Section "Device" > Identifier "Nvidia T400" > Driver "mode setting" > "PCI:1:0:0" > EndSection You can't have 2 device sections for the same busid Anyway, with modular xorg I don't need any device section at all, xorg finds the right device by itself. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD-10.0RC
On Wed, Nov 29, 2023 at 03:52:34PM +, Todd Gruhn wrote: > Just tried: > > run 'make install' in pkgsrc/meta-pkgs/modular-xorg > > It failed. You didn't set X11_TYPE= modular in /etc/mk.conf -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD-10.0RC
On Wed, Nov 29, 2023 at 01:19:33PM +, Todd Gruhn wrote: > Here is Xorg.0.log I can't see what would look like a crash here. I had to force the use of the modesetting driver to get a working X (with the xorg.conf fragment I posted earlier). But to get a working X with acceleration I had to switch to modular Xorg: - remove /usr/X11R7/ - add to /etc/mk.conf X11_TYPE= modular - run 'make install' in pkgsrc/meta-pkgs/modular-xorg you may want to install graphics/glx-utils too -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD-10.0RC
On Wed, Nov 29, 2023 at 12:19:21PM +, Todd Gruhn wrote: > WELL > > Section "Device" > > Identifier "Nvidia T400" > > Driver "modesetting" > > BusID "PCI:1:0:0" > > EndSection > > > Nov 29 11:31:17 gandalf /netbsd: [ 3.2176022] nouveau0: NVIDIA TU116 > (168000a1) > Nov 29 11:31:17 gandalf /netbsd: [ 3.2876012] nouveau0: bios: > version 90.16.25.40.63 > Nov 29 11:31:17 gandalf /netbsd: [ 3.3376022] nouveau0: interrupting > at msi6 vec 0 (nouveau0) > Nov 29 11:31:17 gandalf /netbsd: [ 3.3376022] nouveau0: fb: 6144 MiB GDDR5 > Nov 29 11:31:17 gandalf /netbsd: [ 3.3576008] Zone kernel: > Available graphics memory: 9007199252283634 KiB > Nov 29 11:31:17 gandalf /netbsd: [ 3.3576008] Zone dma32: > Available graphics memory: 2097152 KiB > Nov 29 11:31:17 gandalf /netbsd: [ 3.3576008] nouveau0: DRM: VRAM: 6144 MiB > Nov 29 11:31:17 gandalf /netbsd: [ 3.3576008] nouveau0: DRM: GART: > 536870912 MiB > Nov 29 11:31:17 gandalf /netbsd: [ 3.3576008] nouveau0: DRM: BIT > table 'A' not found > Nov 29 11:31:17 gandalf /netbsd: [ 3.3576008] nouveau0: DRM: BIT > table 'L' not found > Nov 29 11:31:17 gandalf /netbsd: [ 3.3576008] nouveau0: DRM: TMDS > table version 2.0 > Nov 29 11:31:17 gandalf /netbsd: [ 3.3576008] nouveau0: DRM: DCB version 4.1 > Nov 29 11:31:17 gandalf /netbsd: [ 3.3576008] nouveau0: DRM: DCB > outp 00: 02800f66 04600020 > Nov 29 11:31:17 gandalf /netbsd: [ 3.3576008] nouveau0: DRM: DCB > outp 01: 02000f62 04620020 > Nov 29 11:31:17 gandalf /netbsd: [ 3.3576008] nouveau0: DRM: DCB > outp 03: 02011f52 00020010 > Nov 29 11:31:17 gandalf /netbsd: [ 3.3576008] nouveau0: DRM: DCB > outp 04: 01822f36 04600010 > Nov 29 11:31:17 gandalf /netbsd: [ 3.3576008] nouveau0: DRM: DCB > outp 05: 01022f32 04620010 > Nov 29 11:31:17 gandalf /netbsd: [ 3.3576008] nouveau0: DRM: DCB > outp 06: 01833f46 04600020 > Nov 29 11:31:17 gandalf /netbsd: [ 3.3576008] nouveau0: DRM: DCB > outp 07: 01033f42 04620020 > Nov 29 11:31:17 gandalf /netbsd: [ 3.3576008] nouveau0: DRM: DCB > conn 00: 00020046 > Nov 29 11:31:17 gandalf /netbsd: [ 3.3576008] nouveau0: DRM: DCB > conn 01: 00010161 > Nov 29 11:31:17 gandalf /netbsd: [ 3.3576008] nouveau0: DRM: DCB > conn 02: 1246 > Nov 29 11:31:17 gandalf /netbsd: [ 3.3576008] nouveau0: DRM: DCB > conn 03: 2346 > Nov 29 11:31:17 gandalf /netbsd: [ 3.3576008] nouveau0: DRM: MM: > using COPY for buffer copies > Nov 29 11:31:17 gandalf /netbsd: [ 3.4076003] [drm] Supports vblank > timestamp caching Rev 2 (21.10.2013). > Nov 29 11:31:17 gandalf /netbsd: [ 3.4076003] [drm] Driver supports > precise vblank timestamp query. > Nov 29 11:31:17 gandalf /netbsd: [ 3.4976013] nouveaufb0 at nouveau0 > Nov 29 11:31:17 gandalf /netbsd: [ 3.4976013] [drm] Initialized > nouveau 1.3.1 20120801 for nouveau0 on minor 0 > Nov 29 11:31:17 gandalf /netbsd: [ 3.4976013] nouveaufb0: > framebuffer at 0x4040, size 1920x1080, depth 32, stride 7680 > Nov 29 11:31:17 gandalf /netbsd: [ 3.5776005] wsdisplay0 at > nouveaufb0 kbdmux 1: console (default, vt100 emulation), using wskbd0 > > > > My first Q is this: > Identifier "Nvidia T400" -- above it says"TU116 (168000a1)" > > Should this be "TU400" OR "TU116" OR "T116" ? > Is spelling correct? It doens't matter, it's a user string What's important is the busid string > > > When I started X as root, I got hashed screen, then had to do hard-reboot... > > Want to see something in /var/log/Xorg.0.log ? Can't you post the whole file ? -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD-10.0RC
On Wed, Nov 29, 2023 at 07:04:21AM -0500, Todd Gruhn wrote: > X just stuck for about 1 min -- then quitl. > > At the bottom, I saw an error: > > nouveau0 ... What is the exact error ? What is in Xorg.0.log ? To get X working with the native Xorg in netbsd-10 I had to add in xorg.conf: Section "Device" Identifier "Nvidia T400" Driver "modesetting" BusID "PCI:1:0:0" EndSection You'll have to adjust BusID to match your setup; pcictl pci0 list should tell you where you card is. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD-10.0RC
On Tue, Nov 28, 2023 at 06:04:16PM +, Todd Gruhn wrote: > KAA. Fould this in /var/log/messages. > > On first line below, I see "TU116". Do you see something useful here?? > (Box says 6GB GDDR5) > > > Nov 28 14:37:42 gandalf /netbsd: [ 3.2091305] nouveau0: NVIDIA TU116 > (168000a1) > Nov 28 14:37:42 gandalf /netbsd: [ 3.2791282] nouveau0: bios: > version 90.16.25.40.63 > Nov 28 14:37:42 gandalf /netbsd: [ 3.3391278] nouveau0: interrupting > at msi6 vec 0 (nouveau0) > Nov 28 14:37:42 gandalf /netbsd: [ 3.3391278] nouveau0: fb: 6144 MiB GDDR5 > Nov 28 14:37:42 gandalf /netbsd: [ 3.3691275] Zone kernel: > Available graphics memory: 9007199252283640 KiB > Nov 28 14:37:42 gandalf /netbsd: [ 3.3691275] Zone dma32: > Available graphics memory: 2097152 KiB > Nov 28 14:37:42 gandalf /netbsd: [ 3.3691275] nouveau0: DRM: VRAM: 6144 MiB > Nov 28 14:37:42 gandalf /netbsd: [ 3.3691275] nouveau0: DRM: GART: > 536870912 MiB > Nov 28 14:37:42 gandalf /netbsd: [ 3.3691275] nouveau0: DRM: BIT > table 'A' not found > Nov 28 14:37:42 gandalf /netbsd: [ 3.3691275] nouveau0: DRM: BIT > table 'L' not found > Nov 28 14:37:42 gandalf /netbsd: [ 3.3691275] nouveau0: DRM: TMDS > table version 2.0 > Nov 28 14:37:42 gandalf /netbsd: [ 3.3691275] nouveau0: DRM: DCB version 4.1 > Nov 28 14:37:42 gandalf /netbsd: [ 3.3691275] nouveau0: DRM: DCB > outp 00: 02800f66 04600020 > Nov 28 14:37:42 gandalf /netbsd: [ 3.3691275] nouveau0: DRM: DCB > outp 01: 02000f62 04620020 > Nov 28 14:37:42 gandalf /netbsd: [ 3.3691275] nouveau0: DRM: DCB > outp 03: 02011f52 00020010 > Nov 28 14:37:42 gandalf /netbsd: [ 3.3691275] nouveau0: DRM: DCB > outp 04: 01822f36 04600010 > Nov 28 14:37:42 gandalf /netbsd: [ 3.3691275] nouveau0: DRM: DCB > outp 05: 01022f32 04620010 > Nov 28 14:37:42 gandalf /netbsd: [ 3.3691275] nouveau0: DRM: DCB > outp 06: 01833f46 04600020 > Nov 28 14:37:42 gandalf /netbsd: [ 3.3691275] nouveau0: DRM: DCB > outp 07: 01033f42 04620020 > Nov 28 14:37:42 gandalf /netbsd: [ 3.3691275] nouveau0: DRM: DCB > conn 00: 00020046 > Nov 28 14:37:42 gandalf /netbsd: [ 3.3691275] nouveau0: DRM: DCB > conn 01: 00010161 > Nov 28 14:37:42 gandalf /netbsd: [ 3.3691275] nouveau0: DRM: DCB > conn 02: 1246 > Nov 28 14:37:42 gandalf /netbsd: [ 3.3691275] nouveau0: DRM: DCB > conn 03: 2346 > Nov 28 14:37:42 gandalf /netbsd: [ 3.3791274] nouveau0: DRM: MM: > using COPY for buffer copies > Nov 28 14:37:42 gandalf /netbsd: [ 3.4291270] [drm] Supports vblank > timestamp caching Rev 2 (21.10.2013). > Nov 28 14:37:42 gandalf /netbsd: [ 3.4291270] [drm] Driver supports > precise vblank timestamp query. > Nov 28 14:37:42 gandalf /netbsd: [ 3.5691259] nouveaufb0 at nouveau0 > Nov 28 14:37:42 gandalf /netbsd: [ 3.5691259] [drm] Initialized > nouveau 1.3.1 20120801 for nouveau0 on minor 0 > Nov 28 14:37:42 gandalf /netbsd: [ 3.5691259] nouveaufb0: > framebuffer at 0x4040, size 1920x1080, depth 32, stride 7680 > Nov 28 14:37:42 gandalf /netbsd: [ 5.5691108] nouveau0: > autoconfiguration error: error: DRM: wndw-0: timeout So the nouveau driver can handle this card, at last well enough to provide a framebuffer. The timeout may be related to the old firmware, the newer sec2 firmware which has been pulled up to netbsd-10 yesterday could fix it. What does X tell you ? -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD-10.0RC
On Tue, Nov 28, 2023 at 03:29:02PM +, Todd Gruhn wrote: > WEL ... > I stuck in GTX-1660; it failed. How did it fail ? > > Is there a log file I should look for? First the dmesg, especially the lines with nouveau > I saw xorg*.log was written. This can be interesting too -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD-10.0RC
On Tue, Nov 28, 2023 at 12:17:20PM +, Todd Gruhn wrote: > "If you can start X, glxinfo -B should tell you if it's using the GPU for > acceleration " > > HERE ... Acceleraed = yes > This was just run on GTX-680 > Does that tell you something good??? It tells that it runs on the GTX-680, nothing more -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD-10.0RC
On Tue, Nov 28, 2023 at 10:40:31AM +, Todd Gruhn wrote: > The NEXT Q would be this: > > Is there any software to test GTX * and see if it can find TUabc or Tabc ? If you can start X, glxinfo -B should tell you if it's using the GPU for acceleration -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD-10.0RC
On Tue, Nov 28, 2023 at 09:18:54AM +, Todd Gruhn wrote: > Here is the result from dmesg. > > What do you see? > > I changed graphics card: GTX-680; that works fine... > The goal is to upgrade to GTX-1660 It seems that you booted with the GTX-680 (this matches the GK104 below). If you know it works this isn't very usefull. If I got it right, the GTX 1660 is TU116, which should work with the updated firmware (or maybe with the actual firmware even). To make sure you should boot with this card plugged in. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD-10.0RC
On Mon, Nov 27, 2023 at 08:16:46PM +, Todd Gruhn wrote: > "live image" --- a NetBSD-10.0_RC ? > > I made a CD to upgrade to 10.0_RC ... ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-10.0_RC1/images/NetBSD-10.0_RC1-amd64-live.img.gz but if you already have NetBSD 10.0_RC1 installed, you should see the nouveau driver in dmesg -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD-10.0RC
On Mon, Nov 27, 2023 at 02:20:02PM +, Todd Gruhn wrote: > I just looked (on BOX)... > > On bottom it says "Turing Shades / GDDR5 / Directx12 / Ansel" . > > Is this correct? How do I test this?? It came wit the computer > when I had it made about 4yr ago. 4y ago it should work then. My T400 is from a brand new computer. Maybe trying the live image would help ? check for nouveau in the boot messages -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD-10.0RC
On Mon, Nov 27, 2023 at 03:10:54PM +, Mr Roooster wrote: > On Mon, 20 Nov 2023 at 03:20, Todd Gruhn wrote: > > > > On the bottom of nv(4) it says "GeForce GTX" . > > > > I have a GTX-1660 -- will NetBSD now work with this? > > It doesn't look like it. > > You have a Turing based card, with a TU116 core. Actually I have a T400, which has a TU117 core, and it's supported in netbsd-10 by the nouveau driver. For full acceleration you need modular-xorg and a small firmware update (hopefully the firmware update will be in 10_RELEASE, but you'll still need modular-xorg for acceleration). -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD as an NTP stratum 1 server
On Thu, Nov 16, 2023 at 11:21:03AM -0500, Greg Troxel wrote: > If within 1s is good enough, NMEA only is ok. > > If you have a system that is well-connected and you set up NMEA you will > find out that there are delays and that these vary by type of receiver. > You use 'time1' in ntp.conf to adjust this. I have 3 devices that need > values of > 0.116 > 0.0445 > 0.072 > to be close. > > That is very coarse compared to 1 ms for PPS. But indeed, if you have a > machine that is not connected at all, it's really hard to tell it is a > second off. > > So basically you might think > NMEA only: 200 ms > USB PPS: 1 ms > gpio PPS: 100 us > > and to do better (or to know you are doing better) you need to really > pay attention. To do better I think I'd go with an implementation of ntpd on a microcontroller (maybe an ESP32, which has native ethernet) and use the PPS signal with a capture channel. Doing true real time on more complex CPUs is really hard. I know there is an implementation on arduino, but I think a 32 bit MCU would be a better choice. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD as an NTP stratum 1 server
On Thu, Nov 16, 2023 at 07:58:33AM -0500, Greg Troxel wrote: > > As for stability and accuracy... using just the USB data alone will > > yield very poor results, as has been mentioned. That can, however, be > > used for a quick test with the NEMA driver that ntpd has, just don't be > > impressed by it. By adding the digital PPS signal into the mix that > > will deal with the USB problems and you will get a good result once the > > device and ntpd stabilizes. My modules present their NEMA output as > > digital tty (uart) signals that I hook to a FTDI chip and into a USB > > port... so the effect is very simular to what you are probably doing. I > > also use ntpd which can deal with both a /dev/ttyXX NEMA device and > > /dev/gpioppsX PPS device at the same time. In this arrangement, you > > won't be using shared memory and your output would look something like > > this: > > It is true that using USB PPS has 1 ms of fuzz. However, people say > "stratum 1" and make varying assumptions about what they care about. > > If the concern is to keep time sync when the Internet is down, 1 ms of > fuzz is ok. If you are trying to build something to distribute time to > other people, and especially to be a public stratum 1, then it's not ok. Sure; my feeling (but I may be wrong) is that is this case the 1s NMEA messages may be good enough for NTP to sync, and the PPS may not bring much. I have a setup where I only use the NMEA message with gpsd and ntpd, no PPS. ntpd has to problem to sync but I don't know how acurate it is (this host is not connected to internet). For this use case 1s acuracy is good enough :) -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD as an NTP stratum 1 server
On Thu, Nov 16, 2023 at 02:41:42AM -, jo...@sdf.org wrote: > Hello -- Does NetBSD support PPS output from a USB GPS? I'm > using NetBSD 10 RC1. > > I have a USB GT-U7 GPS module attached, and I have gpsd running on > /dev/ttyU0 and receiving GPS data. This looks good. > > After configuring ntpd, when I run ntpshmmon, I'm seeing NTP0, but no > NTP2. If I understand correctly, NTP2 is PPS. This seems to be confirmed > with ntpq -p, where I don't see a PPS peer. > > I unfortunately couldn't find anything when searching on this topic. > > My goal is to replace an aging RPi3 with a Rock64 running NetBSD as an NTP > stratum 1 server. If it's a pure USB device (with no additional wriring for a PPS signal) it won't make a good stratum-1 server. USB signals have a 1ms jitter (minimum) so I don't think you can get a clock more precise than +-1ms with this. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: rc.local nightmare
On Sun, Oct 29, 2023 at 08:39:54PM +0100, Ramiro Aceves wrote: > Hi all, > > I am using a raspberrypi and NetBSD 10-BETA and as we all know the flaky > bwfm wifi driver is not very stable. Sometimes network fails and "ifconfig > bwfm0 down" and "ifconfig bwfm0 up" does not fix it, so the raspberrypi > remains unreachable from SSH, needing a physical reboot. > > I have written a little script that checks ping to a known site and reboots > the machine if it fails after several retries: > > *** > > netbsd-nuc# cat /etc/rc.local > > # $NetBSD: rc.local,v 1.32 2008/06/11 17:14:52 perry Exp $ > # originally from: @(#)rc.local 8.3 (Berkeley) 4/28/94 > # > # This file is (nearly) the last thing invoked by /etc/rc during a > # normal boot, via /etc/rc.d/local. > # > # It is intended to be edited locally to add site-specific boot-time > # actions, such as starting locally installed daemons. > # > # An alternative option is to create site-specific /etc/rc.d scripts. > # > > echo -n 'Starting local daemons:' > > # Add your local daemons here, eg: > # > #if [ -x /path/to/daemon ]; then > # /path/to/daemon args > #fi > > if [ -x /root/nettest ]; then > /root/nettest & > fi maybe: nohup /root/nettest & ? -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD 10 Beta: Updating The Base System -- October 20 Followup
On Fri, Oct 20, 2023 at 03:39:49PM -0500, Jay F. Shachter wrote: > > Centuries ago, Nostradamus predicted that Michael van Elst would write on Tue > Oct 10 15:14:31 2023: > > > > >> > >> And does my PKG_PATH variable remain > >> http://ftp.NetBSD.org/pub/pkgsrc/packages/NetBSD/amd64/10.0/All or > >> do I now change it to something else? Thank you in advance for any > >> and all replies. > >> > > > > The path stays the same. > > > > No, it does not. > > http://ftp.NetBSD.org/pub/pkgsrc/packages/NetBSD/amd64/10.0 still does not > exist. > I found http://ftp.NetBSD.org/pub/pkgsrc/packages/NetBSD/amd64/10.0_2023Q3 > but it is impossible to access that URL, or the /All URL beneath it. I guess it's because it's not ready for use yet Maybe a symlink will show up before this directory gets unlocked -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD & disks with 4K sector size
On Thu, Jul 20, 2023 at 10:16:16AM -0400, Greg Troxel wrote: > Probably best to use port-xen now that we think it's a xen thing. I > would suggest investigating everything suggested to you and then sending > a new message based on your future understanding to port-xen. > > 1) I am unclear on if the xbd abstraction has the concept of 4K sizes, > and if so how that is communicated, and if not how the dom0 is supposed > to map things. > > With any luck, this is supported and the xbd driver in NetBSD is just > not noticing the sector size variable and it's a fairly small matter of > programming. > > Looking quickly at sys/arch/xen/xbd_xenbus.c, I see some concept of > sector size, but it would take me a while to understand and trace all > this. > > I suggest trying a current or netbsd-10 PV or PVH domU and seeing what > happens. Also could you post the output of xenstore-ls from the dom0 (you can strip it to the relevant domU only, but we need entries for both the frontend and backends). -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Experience with NetBSD on 13-gen Framework 13 laptop
On Tue, Jun 06, 2023 at 06:22:52PM +0200, Sijmen J. Mulder wrote: > Op maandag 5 juni 2023 19:15:05 CEST schreef Manuel Bouyer: > > > OK - so it's working as a basic mouse on NetBSD, but not as a two > > > finger capable device. I'm... going to have to drop out and hope > > > someone else knowing more can chime in :) > > > > It looks like it's a I2C HID device. We have a driver for this: > > # DesignWare I2C controller as found in some Intel PCH and AMD FCH devices. > > dwiic* at acpi?# DesignWare I2C controller > > dwiic* at pci? # DesignWare I2C controller > > iic*at dwiic? > > > > # I2C HID devices > > ihidev* at iic? > > > > # I2C Mice > > ims*at ihidev? reportid ? > > wsmouse* at ims? mux 0 > > > > The i2c controller are probably: > > [ 1.050437] Intel 600 Series PCH-LP I2C 0 (miscellaneous serial bus, > > revision 0x01) at pci0 dev 21 function 0 not configured > > [ 1.050437] Intel 600 Series PCH-LP I2C 1 (miscellaneous serial bus, > > revision 0x01) at pci0 dev 21 function 1 not configured > > [ 1.050437] Intel 600 Series PCH-LP I2C 3 (miscellaneous serial bus, > > revision 0x01) at pci0 dev 21 function 3 not configured > > > > (this matches the linux dmesg). So you could try rebuilding a kernel with > > this patch: > > Index: sys/arch/x86/pci/dwiic_pci.c > > === > > Thanks for diving in there and suggesting a patch! I've rebuilt with > the patch but it appears dwiic fails to configure the devices: > > [ 1.052303] dwiic0 at pci0 dev 21 function 0autoconfiguration error: : > can't map register space > [ 1.052303] dwiic1 at pci0 dev 21 function 1autoconfiguration error: : > can't map register space > [ 1.052303] dwiic2 at pci0 dev 21 function 3autoconfiguration error: : > can't map register space > > No further mention of dwiic beyond that. Could you send the output of pcictl pci0 dump -b 0 -d 21 -f 3 -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Experience with NetBSD on 13-gen Framework 13 laptop
On Mon, Jun 05, 2023 at 05:29:41PM +0100, David Brownlee wrote:
> > [...]
> > For Linux, these seem to be the relevant bits from the Fedora 38
> > installation:
> >
> > [3.776427] input: ImExPS/2 Generic Explorer Mouse as
> > /devices/platform/i8042/serio1/input/input4
> > [3.828419] memfd_create() without MFD_EXEC nor MFD_NOEXEC_SEAL, pid=1
> > 'systemd'
> > [3.850162] usb 3-9: new full-speed USB device number 4 using xhci_hcd
> > [3.932086] input: FRMW0001:00 32AC:0006 Wireless Radio Control as
> > /devices/pci:00/:00:15.1/i2c_designware.1/i2c-1/i2c-FRMW0001:00/0018:32AC:0006.0002/input/input5
> > [3.932217] input: FRMW0001:00 32AC:0006 Consumer Control as
> > /devices/pci:00/:00:15.1/i2c_designware.1/i2c-1/i2c-FRMW0001:00/0018:32AC:0006.0002/input/input6
> > [3.932252] input: FRMW0001:00 32AC:0006 as
> > /devices/pci:00/:00:15.1/i2c_designware.1/i2c-1/i2c-FRMW0001:00/0018:32AC:0006.0002/input/input7
> > [3.932291] hid-generic 0018:32AC:0006.0002: input,hidraw1: I2C HID
> > v1.00 Device [FRMW0001:00 32AC:0006] on i2c-FRMW0001:00
> > [3.939039] input: PIXA3854:00 093A:0274 Mouse as
> > /devices/pci:00/:00:15.3/i2c_designware.2/i2c-2/i2c-PIXA3854:00/0018:093A:0274.0003/input/input8
> > [3.951140] input: PIXA3854:00 093A:0274 Touchpad as
> > /devices/pci:00/:00:15.3/i2c_designware.2/i2c-2/i2c-PIXA3854:00/0018:093A:0274.0003/input/input9
> > [3.963142] hid-generic 0018:093A:0274.0003: input,hidraw2: I2C HID
> > v1.00 Mouse [PIXA3854:00 093A:0274] on i2c-PIXA3854:00
> > ...
> > [4.031656] input: PIXA3854:00 093A:0274 Mouse as
> > /devices/pci:00/:00:15.3/i2c_designware.2/i2c-2/i2c-PIXA3854:00/0018:093A:0274.0003/input/input10
> > [4.031750] input: PIXA3854:00 093A:0274 Touchpad as
> > /devices/pci:00/:00:15.3/i2c_designware.2/i2c-2/i2c-PIXA3854:00/0018:093A:0274.0003/input/input11
> > [4.031800] hid-multitouch 0018:093A:0274.0003: input,hidraw1: I2C HID
> > v1.00 Mouse [PIXA3854:00 093A:0274] on i2c-PIXA3854:00
> >
> > Full pre-login dmesg attached.
>
> OK - so it's working as a basic mouse on NetBSD, but not as a two
> finger capable device. I'm... going to have to drop out and hope
> someone else knowing more can chime in :)
It looks like it's a I2C HID device. We have a driver for this:
# DesignWare I2C controller as found in some Intel PCH and AMD FCH devices.
dwiic* at acpi?# DesignWare I2C controller
dwiic* at pci? # DesignWare I2C controller
iic*at dwiic?
# I2C HID devices
ihidev* at iic?
# I2C Mice
ims*at ihidev? reportid ?
wsmouse* at ims? mux 0
The i2c controller are probably:
[ 1.050437] Intel 600 Series PCH-LP I2C 0 (miscellaneous serial bus,
revision 0x01) at pci0 dev 21 function 0 not configured
[ 1.050437] Intel 600 Series PCH-LP I2C 1 (miscellaneous serial bus,
revision 0x01) at pci0 dev 21 function 1 not configured
[ 1.050437] Intel 600 Series PCH-LP I2C 3 (miscellaneous serial bus,
revision 0x01) at pci0 dev 21 function 3 not configured
(this matches the linux dmesg). So you could try rebuilding a kernel with
this patch:
Index: sys/arch/x86/pci/dwiic_pci.c
===
RCS file: /cvsroot/src/sys/arch/x86/pci/dwiic_pci.c,v
retrieving revision 1.9
diff -u -p -u -r1.9 dwiic_pci.c
--- sys/arch/x86/pci/dwiic_pci.c19 Oct 2022 22:28:35 - 1.9
+++ sys/arch/x86/pci/dwiic_pci.c5 Jun 2023 17:13:21 -
@@ -80,6 +80,14 @@ static const struct device_compatible_en
{ .id = VIDDID(INTEL, 100SERIES_LP_I2C_3) },
{ .id = VIDDID(INTEL, 100SERIES_LP_I2C_4) },
{ .id = VIDDID(INTEL, 100SERIES_LP_I2C_5) },
+ { .id = VIDDID(INTEL, 6HS_LP_I2C_0) },
+ { .id = VIDDID(INTEL, 6HS_LP_I2C_1) },
+ { .id = VIDDID(INTEL, 6HS_LP_I2C_2) },
+ { .id = VIDDID(INTEL, 6HS_LP_I2C_3) },
+ { .id = VIDDID(INTEL, 6HS_LP_I2C_4) },
+ { .id = VIDDID(INTEL, 6HS_LP_I2C_5) },
+ { .id = VIDDID(INTEL, 6HS_LP_I2C_6) },
+ { .id = VIDDID(INTEL, 6HS_LP_I2C_7) },
{ .id = VIDDID(INTEL, 2HS_I2C_0) },
{ .id = VIDDID(INTEL, 2HS_I2C_1) },
{ .id = VIDDID(INTEL, 2HS_I2C_2) },
I'm not sure all the 8 entries are dwiic-compatible, maybe you'll have to
remove some of them.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
Re: Which ARM SBC would work well with NetBSD?
On Fri, Mar 10, 2023 at 05:30:05PM +0100, Manuel Bouyer wrote: > On Fri, Mar 10, 2023 at 09:46:50PM +0530, Mayuresh wrote: > > On Fri, Mar 10, 2023 at 09:10:04AM +0100, Manuel Bouyer wrote: > > > The olimex boards have an embeeded LIPO charger, it is part of > > > the AXP209 PMU used on the board. You can even monitor the battery status > > > from NetBSD: > > > > Can you also control the charging - say I want to switch off charging at > > 80% charge level and switch it on again when it drops to 40%? > > Not with the NetBSD driver; I don't know if the axp209 can do it. But you could put a mosfet on the main power supply and drive it with a GPIO :) -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Which ARM SBC would work well with NetBSD?
On Fri, Mar 10, 2023 at 09:46:50PM +0530, Mayuresh wrote: > On Fri, Mar 10, 2023 at 09:10:04AM +0100, Manuel Bouyer wrote: > > The olimex boards have an embeeded LIPO charger, it is part of > > the AXP209 PMU used on the board. You can even monitor the battery status > > from NetBSD: > > Can you also control the charging - say I want to switch off charging at > 80% charge level and switch it on again when it drops to 40%? Not with the NetBSD driver; I don't know if the axp209 can do it. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Which ARM SBC would work well with NetBSD?
On Fri, Mar 10, 2023 at 08:53:47AM +0530, Mayuresh wrote: > On Thu, Mar 09, 2023 at 09:34:05AM +0900, Henry wrote: > > Because of the battery options which would allow me to do without a UPS, > > Hi. Curious about this usage pattern. For devices that are deployed for > some purpose, to work without frequent manual intervention, the question > is when would you charge the battery? > > Either you can keep the charger connected - which may possibly swell the > battery soon, unless the device has some way to auto-stop charging at some > upper threshold and auto-restart the charging only when the battery > reaches a lower threshold. The olimex boards have an embeeded LIPO charger, it is part of the AXP209 PMU used on the board. You can even monitor the battery status from NetBSD: /home/bouyer>envstat Current CritMax WarnMax WarnMin CritMin Unit [axp20x0] AC input: TRUE AC input voltage: 4.940 V AC input current: 0.363 A VBUS input: FALSE VBUS input voltage: N/A VBUS input current: N/A battery: TRUE battery voltage: 4.157 V battery current: 0.000 A APS output voltage: 4.855 V internal temperature:32.200 -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Which ARM SBC would work well with NetBSD?
On Thu, Mar 09, 2023 at 09:34:05AM +0900, Henry wrote: > I've been listening in, and I thank you all very much for your input. > I have 0 experience with an SBC, but want to move to a > low-power-consumption basic web and file server. Because of the > battery options which would allow me to do without a UPS, I'm > seriously considering the olimex a20-onlinuxino-lime2. I'm using 2 of them this way :) > > Some questions from this newbie: > o can I create a NetBSD bootable micro SD card, or does one have to > use Debian or Android on these A-20 Olimex SBCs? NetBSD runs fine on A20. You can look at http://wiki.netbsd.org/ports/evbarm/allwinner/ for details on creating a bootable SD card > o can I hook up a serial concole via a standard RS232 cable? No, most SBC use a serial port with TTL levels (usually 0 and +3.3V), not RS232 levels. You need a USB-UART adapter like FTDI-based one, or this one: https://www.olimex.com/Products/Breadboarding/BB-CH340T/open-source-hardware > o after the initial install of NetBSD, can I have the computer boot > from a USB (preferably C-type, but standard type okay)? Or is it > better to just get a board with the eMMC flash memory option and boot > from that? The A20 only has USB 2.0. the eMMC flash is OK and is a bit faster than SD card. Note that the A20 has a native SATA port (i.e. not behind a USB-SATA bridge), so if you need speed or capacity, adding a SATA 2.5" disk or SSD is a good option (I run one with a SSD too). > o is there a cookbook-kind of howto document on installing NetBSD on > ARM architecture SBCs? Start from http://wiki.netbsd.org/ports/evbarm/ -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Which ARM SBC would work well with NetBSD?
On Sun, Mar 05, 2023 at 01:22:58PM +0530, Mayuresh wrote: > I am in need of an SBC - like the raspberry pi. Ethernet, analog speaker > output and 2/3 USB ports (2.0 will do) is the requirement. RAM 1G should > suffice. HDMI output only for configuration and setup. Wifi not required. > > I am using one each of RPI2,3,4 for different purposes, RPI2 running > NetBSD and RPI3,4 running Raspbian. > > For a new requirement I can either use one of the RPI models or look for > others like orange pi, nano pi, banana pi and so on - more out of > curiosity. > > Feedback on any of the low cost SBC devices that you may be using > successfully with NetBSD will be of great help. Please do share. I've been using A20-based boards: Cubieboard 2 and olimex a20-onlinuxino-lime2 (the a20-onlinuxino-lime2 base version, and the a20-onlinuxino-lime2-e16gs16m version) without problems. Not sure if the Cubieboard 2 is still available, but a20-onlinuxino-lime2 is still produced. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Bluetooth woes
On Mon, Jan 02, 2023 at 02:33:55PM +0100, Marc Baudoin wrote: > Hi, > > I'm trying to use a Bluetooth mouse on my NetBSD/amd64 9.3 laptop > but I can't get it to work: > > % dmesg | grep ubt > [ 3,395938] ubt0 at uhub1 port 5 > [ 3,395938] ubt0: vendor 8087 (0x8087) product 0a2b (0xa2b), rev > 2.00/0.01, addr 1 > > % cat /etc/rc.conf.d/bluetooth > btconfig_ubt0="name laptop-hostname" I use an external USB/BT adapter, I only have bluetooth=YES in /etc/rc.conf But I can't get the internal BT adapter of my laptop to work. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD on older Macbook Pro: Wi-Fi and trackpad
On Fri, Dec 23, 2022 at 07:47:12AM +1030, Brett Lymn wrote: > On Thu, Dec 22, 2022 at 01:48:54PM +0100, Manuel Bouyer wrote: > > > > They do work on btmagic(4): > > [29.023479] btmagic0 at bthub0 remote-bdaddr e8:80:2e:e5:20:6f > > link-mode auth: 3 buttons, W and Z dirs > > [29.023479] wsmouse1 at btmagic0 mux 0 > > > > Wow - bluetooth for what is an internal device, interesting. It's not internal, it's an "apple magic trackpad" > > > > layer that takes raw trackpad data and synthesizes them? Is this > > > > At this point it's in the btmagic driver itself; but maybe it would be > > possible to abstract this. > > > > Maybe we should look at this, there are some gestures and emulations > that are done in the synaptics driver that may be useful for btmagic and > it doesn't make sense to replicate the code into another trackpad > driver. I think it would require a design of a layer that would sit > between the underlying trackpad device and the wsmouse driver. This > intervening layer could take the underlying raw finger positions and > perform things like button emulation, two finger scroll, scrolling > regions and the like. Sure. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD on older Macbook Pro: Wi-Fi and trackpad
On Thu, Dec 22, 2022 at 07:08:40AM -0500, Greg Troxel wrote: > [...] > > 2. Trackpad gestures do not work at all. Basic pointing and clicking > > is okay but no two-finger scroll and no right click. > > I have never tried that. I don't really understand how the gestures > work. Do they work on NetBSD on any trackpad? Is there some software They do work on btmagic(4): [29.023479] btmagic0 at bthub0 remote-bdaddr e8:80:2e:e5:20:6f link-mode auth: 3 buttons, W and Z dirs [29.023479] wsmouse1 at btmagic0 mux 0 > layer that takes raw trackpad data and synthesizes them? Is this At this point it's in the btmagic driver itself; but maybe it would be possible to abstract this. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Low power server ideas
On Fri, Sep 02, 2022 at 06:15:19PM +0200, tlaro...@polynum.com wrote: > Le Fri, Sep 02, 2022 at 07:38:19AM -0700, Andy Ruhl a écrit : > > Hello all, > > > > I've been running a NetBSD server on i386 for about 20 odd years, I > > should go back and check when I actually started it. I sort of > > accidentally upgraded it to amd64 a while back but it worked. > > > > Anyways, it seems like time to move to something else, maybe lower > > power if possible. > > > > I found this which is very interesting: > > > > https://blog.netbsd.org/tnf/entry/making_rockpro64_a_netbsd_server > > > > Using a 128gig internal MMC would be plenty for OS and some local > > storage then I would add some other disks, possibly SSD. > > > > Looking for other ideas if anyone has any. > > I use this with NetBSD: > > https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXino-LIME2/open-source-hardware I use some of these too. At home I have one running as router and small file server (thanks to the SATA port :) At $work I use one as a ssh gateway. As it supports a LiPo battery, it even has its builtin UPS :) -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD 10 -- new way of attaching virtual interfaces to bridge?
On Wed, May 25, 2022 at 02:45:50PM +0200, Matthias Petermann wrote: > > Hi, > > Am 23.05.2022 um 13:02 schrieb s...@mailbox.org: > > > On 2022/05/23 11:55 Manuel Bouyer wrote: > > > > > > > > How are vether interfaces created and connected to a bridge? > > > > > > The same way you do with tap I guess: > > > ifconfig vether0 create > > > ifconfig vether0 up > > > brconfig bridge0 add vether0 up > > > > Well, that's just as straightforward as tap was. I was expecting something > > a lot more complicated but I had forgotten how elegantly simple NetBSD is. > > > > Thank you, Manuel. > > so is my understanding correct - for NetBSD 10 as Xen Dom0 it is required to > migrate from tap to vether? May I ask how to tell xentools415 to create a > vether device instead of a tap? If your talking about the devices used for qemu's emulated ethernet devices (in HVM guests), these are real tap devices so don't need to be migrated. vether is for the case where a tap device was used without the "other end" (and in the Xen case, qemu is the other end) -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: XEN3_DOMU on KVM
On Thu, Mar 24, 2022 at 11:23:03AM +0100, Mario Marietto wrote: > But you talked about netbsd and kvm. What's the relationship between netbsd > and kvm if kvm is not supported on netbsd ? It depends on what you mean with "supported". NetBSD can run as a guest in a KVM virtual machine. > Anyway,some time ago I tried to > create a vm with qemu and nvmm on DragonFLY and netbsd but it didn't work > because of a bug. Don't know if it has been fixed now. This is the bug : > > https://bugs.dragonflybsd.org/issues/3310 > > Yes,I have reported it for Dragonfly,but It was also present on NetBSD. > So,I haven't been able to virtualize any kind of OS. I used only BIOS, not UEFi ... -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: XEN3_DOMU on KVM
On Thu, Mar 24, 2022 at 11:15:43AM +0100, Mario Marietto wrote: > whats mean as guest ? are u talking about nested vm ? No, host means the OS running on the hardware, guest the OS running in a VM -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: XEN3_DOMU on KVM
On Thu, Mar 24, 2022 at 10:36:30AM +0100, Mario Marietto wrote: > Is KVM supported by NetBSD ? As a guest, yes. As a host, no, we have nvmm instead. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: XEN3_DOMU on KVM
On Thu, Mar 24, 2022 at 12:00:57PM +0300, Dima Veselov wrote: > Greetings, > > I was using XEN3_DOMU kernel for both Xen and KVM machines > since 8.0 but recent 9.0_STABLE does not boot in KVM VM. > > The booted kernel reboots right after loading with no console > output. GENERIC kernel built from same sources is booting ok. > > I am not insisting on using XEN3_DOMU on KVM, it just seemed > to be more lightweight and compatible with VMs for me. > > I would like to know if XEN3_DOMU not booting in KVM means some > issue or it was never intended to be used on other VM type? I'm not sure how it could ever have booted on KVM. Its low level interfaces is specific to Xen -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Making a Logitech Headset work with NetBSD
On Sat, Mar 12, 2022 at 04:06:29PM +, Todd Gruhn wrote: > I am running NetBSD-9.99.94 > I just compiled a custom kernel. > > I already have the following lines in my config file: > > uaudio* at uhub? > audio* at audiobus? > > What else can I try to make this thing work? > > > I know it works -- beacuse it works on Windoze when > I tested it. the dmesg output just after plugin it in would help, I guess. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: tmpfs under i386 PAE kernel swamps pgdaemon?
On Thu, Dec 16, 2021 at 07:39:01AM -0600, John D. Baker wrote: > [...] > Hmm. PAE has 2^40 addressing. Is that physical or virtual? physical. The virtual addresses are still 32bits (otherwise it wouldn't be i386 :) > Perhaps > I'm running out of virtual space before reaching the physical limits? I guess so -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Sendmail with relay (SMART_HOST), STARTTLS and AUTH
On Tue, Oct 05, 2021 at 04:27:27PM +0200, tlaro...@polynum.com wrote: > Hello, > > I'm trying to set-up a node with sendmail(8). > > In order to not be blocked, eventually, by some firewall rule on port > 25, I'm relaying mail to a smart host, listening on port 587 for > STARTTLS, and I need to authentify using LOGIN or PLAIN mechanisme. > > For relaying, forwarding to port 587 and starting TLS with sendmail, no > problem after adding the needed options for the compilation of the > package. > > But whatever I'm trying to do, having added a > /usr/pkg/etc/sasl2/Sendmail.conf configuration and having installed > cyrus-sasl2 and cyrus-saslauthd, and launching the saslauthd daemon, > sendmail, without dialoguing with the server (for this; STARTTLS > is OK) always answers: > > no worthy mechs found > > So the blocking comes from sendmail. I have verified by telnet, that > doing authenfication by hand works. > > >From a search on the Web, when this kind of message is issued with > Postfix, on Linux based distribution, the problem is solved whether > by adding sasl modules or by specifying a configuration variable > for Postfix allowing plaintext authenfications (that is not allowed > by default). > > But as far as I understand, pkgsrc cyrus-sasl2 and cyrus-saslauthd > are sufficient and there is no such thing as this sasl-security > conf variable for sendmail. For sasl suport (as a server, not as a client though) I have to build sendmail with PKG_OPTIONS.sendmail+=sasl tls -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: View an install.img file
On Thu, Sep 16, 2021 at 12:12:18PM -0400, Bob Bernstein wrote: > I have grabbed NetBSD-9.99.88-amd64-install.img.gz from > http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/latest/images/ and gunzipped > it. > > I thought to mount it for viewing before writing it to my USB stick. > > Shouldn't pester a busy vnode: > $ sudo vnconfig -l > vnd0: not in use > vnd1: not in use > vnd2: not in use > vnd3: not in use > > Create a vnode: > $ sudo vnconfig -c vnd0 ~/NetBSD-9.99.88-amd64-install.img > > Now I run aground: > $ sudo mount -t msdos /dev/vnd0a /mnt > mount: no match for `vnd0a': No such process > > I am of course guessing at 'msdos' AND vnd0a! The Guide provides examples > for iso images but I don't see any for "install.img". the install image isn't msdos but ffs. So just $ sudo mount /dev/vnd0a /mnt should work -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: I forgot to backup /etc dir when I upgraded
On Sun, Jun 27, 2021 at 01:44:13PM -0400, Todd Gruhn wrote: > I just upgraded to NetBSD 9.99* HEAD. > The root partition is mounted 'ro'. Is there a way to umount -f / then > then remount it as a "rw" filesystem ? mount -u -o rw / should work ? -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
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 --
Re: unix domain socket permissions
On Wed, Apr 21, 2021 at 02:19:26PM +0200, Jan Danielsson wrote: > Hello, > >A while back I read that unix domain sockets originally didn't care > about permissions; or rather, they had permissions, but the OS didn't > validate them when applications attempted to use socket. But the other > day I read a somewhat recent blog which stated that this is not true for > Linux, but it is true "for BSD" -- and the phrasing could be interpreted > as meaning "still to this day". > >I have serious doubts, but currently do not have a NetBSD system to > test this on. > >Permissions are checked for unix domain sockets on ~recent NetBSD, right? AFAIK yes, they do -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: OS-level virtualization
On Mon, Apr 05, 2021 at 10:41:56PM -0400, Austin Kim wrote: > Hi, > > What is NetBSD?s analogue (or the closest thing) to Illumos Zones and/or > FreeBSD Jails? Is there anything beyond chroot(2)? AFAIK no -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Controlling access to devices in NetBSD
On Wed, Feb 03, 2021 at 11:43:55AM -0500, James Lind wrote: > I think this is a quick question for a human to answer but I've been > having a heck of a time trying to Google it. I'm just curious how > NetBSD controls access to device nodes. I'm just trying to use a USB > UART device to connect to a microcontroller dev board. In Slackware, I > would add my user to the "dialout" group which gets read/write access > to this class of devices. I think the /dev files are fundamentally > different in Slackware though and are dynamically created based on > what devices are present every time you boot the system, so if you > wanted to change the actual permissions on /dev nodes you'd need to > modify the config of the systems generating them (e.g. udev rules). > > In NetBSD, my understanding is that a bunch of /dev nodes covering > what you're likely to need are created ahead of time on your > filesystem. If you need a device node beyond this, you create it with > mknod and it persists on your filesystem. Therefore, I think the way > I'm supposed to allow a normal user to access /dev/ttyU0 is to simply > 'chmod 660' it as it already has the group wheel (which my user > account is a member of), but its current permissions are 600. This > change should persist because the node is essentially a file on the > filesystem instead of being generated every boot. > > Just wanted to make sure this is actually the convention in NetBSD and > I'm not setting myself up for headaches later on :). My question is > simply is my understanding correct? It is ! -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: libusb not working properly on 9.0/9.1
On Wed, Jan 20, 2021 at 05:08:16PM +0100, Rocky Hotas wrote: > Hello! > I would like to run this executable > > <https://github.com/mvp/uhubctl/> > > on NetBSD, but even on a supported hardware platform (Raspberry Pi 3 > B+) it is unusable, due to libusb not properly working. I was using > libusb1-1.0.24 from pkgsrc 2020Q4. > > As suggested here: > > <https://github.com/mvp/uhubctl/issues/306#issuecomment-761072149> > > (bypassing pkgsrc) I cloned the repository of libusb and built from it. > After successfully completing the operations, the basic tools > examples/listdevs and example/testlibusb do not work. > > This happens both with: > > - NetBSD 9.1 on Raspberry Pi 3 B+ (evbarm); > - NetBSD 9.0 on a laptop (amd64). > > What could it be the reason? I don't know; but I'm using libusb in one of my projets, and it enumerates my device just fine. I'm not sure if it can work with anything but ugen devices, though ... -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD/Xen prompting for root filesystem although provided in boot.cfg
On Mon, Dec 21, 2020 at 12:42:24PM +0100, Matthias Petermann wrote: > > Reading raidctl(8) again, I also become more aware of my mistake. The boot > device is wd0, which is not part of the RAID set (since it consists of > dk0/dk1). Therefore the root device is not set automatically. Does this make > sense and have I interpreted this correctly? yes, it makes sense -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD/Xen prompting for root filesystem although provided in boot.cfg
On Mon, Dec 21, 2020 at 12:14:56PM +0100, Matthias Petermann wrote: > > [...] > > The reason I put GPT partitions on the RAID components is because they are > different sized SSDs and I would like to mirror my root filesystem. One is > 112GB in size and the other is 1TB. Therefore, there is a 112 GB partition > on each. And on the larger of the two is a second GPT partition with a non > raidframe file system. At least "architecturally" this setup must have > worked before - just about in summer 2018 when I got the tip from Manuel > that I have to include the root/bootdev parameter in boot.cfg. But at that > time it was under NetBSD 8.0 and Xen 4.11. Actually, if you have root-on-raid, you shouldn't need the root/bootdev parameter at all, '-A root' should be enough. I don't have it on systems where I have root on raid -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD/Xen prompting for root filesystem although provided in boot.cfg
On Mon, Dec 21, 2020 at 04:31:27AM +0100, Matthias Petermann wrote: > Hello, > > I am trying to multiboot my NetBSD 9.1/Xen 4.13 system with Xen and causes > me some headache :-( It seems like the root file system is not automatically > mounted. From the setup side, the root filesystem is located in a disklabel, > which in turn is located on a RAIDFrame device, which consists of two > components, each consisting of a GPT partition on two physical disks. > > In my boot.cfg I have: > > ``` > menu=Boot Xen:load /netbsd-XEN3_DOM0.gz bootdev=raid0a;multiboot /xen.gz > dom0_mem=512M dom0_max_vcpus=1 dom0_vcpus_pin console=com2 com2=9600,8n1 > ``` > > but for some reason the Kernel still prompts for the root device, the dump > device, file system and later for the init location. Anyway, the provided > defaults are correct and could be used right away. Thats why it needs > currently manual intervention on every boot: > > ``` > [ 3.3500231] raid0: RAID Level 1 > [ 3.3500231] raid0: Components: /dev/dk0 /dev/dk1 > [ 3.3500231] raid0: Total Sectors: 234434432 (114469 MB) > [ 3.3500231] WARNING: 1 error while detecting hardware; check system log. > [ 3.3500231] boot device: raid0 > [ 3.3500231] unknown device major 0x > [ 3.3500231] root device (default raid0a): > [ 3.4089966] dump device (default raid0b): > [ 3.9617492] file system (default generic): > ... > ``` > > In the case above it is sufficient to take over the defaults by simply > pressing the enter key. The system will boot without any problem after this. > But of course, the manual intervention is inappropriate for a production > system. > > I did some further experiments and found out when I omit the bootdev > parameter in boot.cfg, dk0 is offered as the default for the root device. > dk0 is the GPT partition of one of the raid frame components on which the > root file system is based. Logically this doesn't qualify as a valid root > filesystem and fails booting. > > So the bootdev parameter already seems to have some effect - namely to set > the defaults accordingly. I am just wondering why I am still being asked, > although everything is actually known... > > From what I've seen, it reminds me a bit of my similar topic from August > 2018[1]. > > Can anyone give me a hint as to what I am doing wrong? Did you set '-A root' on the raid0 ? -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Tunneling in NetBSD
On Thu, Nov 19, 2020 at 02:18:26PM +1030, Brett Lymn wrote: > On Thu, Nov 19, 2020 at 07:08:38AM +1030, Brett Lymn wrote: > > > > I will dig up the document I wrote about the setup. My fuzzy memory is > > that there > > were no hacks required. > > Little wonder my memory was fuzzy - I did this 13 years ago. I found > the documentation. I did use a radius server as the backend auth along > with a self-signed certificate for hybrid rsa-xauth. > > Unfortunately, the document I have not not generic and contains some > confidential details but I am happy to provide sanitised snippets to > help out. > > Below is the racoon.conf, if you need to see the radiusd.conf I have > that too but it is fairly long. > > This is the racoon.conf, there were 3 classes of users, the data entry > people, admin staff and developers. The radius server was used to map > the user to the appropriate class depending on group membership: thanks, I think this will help. We already have radius servers, so I should be able to deal with this part. racoon is the problem for me, I didn't find much documentation about it ... -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Tunneling in NetBSD
On Wed, Nov 18, 2020 at 07:28:51AM +1030, Brett Lymn wrote: > [...] > > Years ago I used NetBSD to configure a vpn end point for a clint, I used > hybrid > xauth which was a combination of a certificate as well as username/password > that > allowed two classes of access to the network, one being restricted to certain > services and another admin role that had broader access. This is interesting, I need something similar. Could you share more details on how you did this ? I though I had to hack raacon for this ... -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Help, how can i make touchpad work on my asus vivobook ?
On Wed, Nov 11, 2020 at 08:18:03AM +0200, Digital Crow wrote: > Help, how can i make touchpad work on my asus vivobook ? > On freebsd it works with ichiid driver that i compile from source. > On OpenBSD it works out of the box . which version of NetBSD are you using ? -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: HVM virtualization?
On Sun, Nov 01, 2020 at 11:38:07AM -0500, Greg Troxel wrote: > > Manuel Bouyer writes: > > > On Sun, Nov 01, 2020 at 10:40:17AM -0500, Greg Troxel wrote: > >> It would work around it, not solve it, but yes getting to a functional > >> state is really the goal. > > > > Having a dmesg of such a system would help. > > True; will see if I can get that. > > > Maybe the qemu in the stub domain is not built with DMA capabilities ? > > No, this is a case of NetBSD working badly, and many Linux flavors, > FreeBSD, OpenBSD all working fine. All of them have PV drivers out of the box, so they won't use qemu for disks and network. > > >> I realize that's a good workaround, but I also wonder if anyone else has > >> tried 9-stable GENERIC as HVM with a dom0 that is using stub domains for > >> qemu. > >> > >> (It seems obvious that NetBSD dom0s do not use stub domains.) > > > > I tried with xen 4.8 but gave up. It was too fragile. > > Do you mean "gave up with pure HVM", or "pure HVM with stub domains"? pure HVM with stub domains. pure HVM worked fine with 4.8, as it does with 4.11 and 4.13 -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: HVM virtualization?
On Sun, Nov 01, 2020 at 10:40:17AM -0500, Greg Troxel wrote: > It would work around it, not solve it, but yes getting to a functional > state is really the goal. Having a dmesg of such a system would help. Maybe the qemu in the stub domain is not built with DMA capabilities ? > > I realize that's a good workaround, but I also wonder if anyone else has > tried 9-stable GENERIC as HVM with a dom0 that is using stub domains for > qemu. > > (It seems obvious that NetBSD dom0s do not use stub domains.) I tried with xen 4.8 but gave up. It was too fragile. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: HVM virtualization?
On Sat, Oct 31, 2020 at 06:36:45PM -0400, Greg Troxel wrote: > > Manuel Bouyer writes: > > > On Sat, Oct 31, 2020 at 01:37:17PM -0500, Jeremy C. Reed wrote: > >> One of my hosting providers is converting VPSes from PV to HVM > >> virtualization due to security issue > >> https://xenbits.xen.org/xsa/advisory-286.html > >> > >> They say NetBSD does not work under HVM mode and can choose a different > >> BSD (or Linux). > >> > >> Can someone tell me about this? I did look briefly at > >> http://wiki.netbsd.org/ports/xen/howto/ but don't understand the context > >> of the wiki saying it is supported but the hosting provider saying it > >> does not work. > > > > plain HVM, with emulated devices, works without problems (and always has). > > If they only support PV devices, then it works only in HEAD (GENERIC > > supports > > it) > > I have heard that the issue with with qemu "stub domains" and with > those, NetBSD ends up with PIO on disks and is thus unusably slow. > > https://wiki.xen.org/wiki/QEMU_vs_qemu-traditionnal_Feature_Comparison So running a HEAD GENERIC, which has the PV drivers, would solve this. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: HVM virtualization?
On Sat, Oct 31, 2020 at 01:37:17PM -0500, Jeremy C. Reed wrote: > One of my hosting providers is converting VPSes from PV to HVM > virtualization due to security issue > https://xenbits.xen.org/xsa/advisory-286.html > > They say NetBSD does not work under HVM mode and can choose a different > BSD (or Linux). > > Can someone tell me about this? I did look briefly at > http://wiki.netbsd.org/ports/xen/howto/ but don't understand the context > of the wiki saying it is supported but the hosting provider saying it > does not work. plain HVM, with emulated devices, works without problems (and always has). If they only support PV devices, then it works only in HEAD (GENERIC supports it) -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Xen Hypervisor and NetBSD.
On Fri, Oct 23, 2020 at 01:35:19PM +, Jason Long wrote: > Hello, > According to "https://wiki.netbsd.org/ports/xen/howto/;, Why "PVHVM" and > "PVH" not supporting on NetBSD? The current releases of NetBSD ideed don't support PVHVM or PVH (HVM with emulated devices works fine). There is support for PVH and PVHVM in current, but this is not in a release yet. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: PR 55714
On Tue, Oct 20, 2020 at 09:59:37AM +0200, BERTRAND Joël wrote: > [...] > I suppose there is somewhere in sys/dev/ic/rtl8169.c a memory > corruption when MTU is greater than 1500 bytes. Thus, I started by > analyzing this source file, but I don't see any simple memory > corruption. I'm willing to take tile to help, but I do not know how > continue. It could also be a hardware bug. These low-price chips maybe don't get the all the testing needed for safe corner-case use ... -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: "xv" video with intel graphics?
On Tue, Sep 22, 2020 at 04:53:39PM -0500, John D. Baker wrote: > I thought it used to work, but perhaps that was with the 2014 intel driver > that could use SNA on my hardware (intel G41)... > > Playing a video file with 'mplayer' or 'mpv' defaults to "xv" video output > but this just displays a black window. > > Forcing "-vo x11" by command line or system default config file (which is > another story) works, but nags with deprecation warnings. > > Does "-vo xv" work on any intel graphics devices? If so, which ones and > under what conditions? works for me on netbsd-9, with a: [ 1.000821] pchb0 at pci0 dev 0 function 0: vendor 8086 product 29b0 (rev. 0 x02) [ 1.000821] agp0 at pchb0: G33-family chipset [ 1.000821] agp0: detected 7164k stolen memory [ 1.000821] agp0: aperture at 0xd000, size 0x1000 [ 1.000821] i915drmkms0 at pci0 dev 2 function 0: vendor 8086 product 29b2 ( rev. 0x02) [ 6.691551] kern info: [drm] Memory usable by graphics device = 1024M [ 6.691551] kern info: [drm] Supports vblank timestamp caching Rev 2 (21.10. 2013). [ 6.691551] kern info: [drm] Driver supports precise vblank timestamp query. [ 6.691551] kern info: [drm] failed to find VBIOS tables [ 6.691551] i915drmkms0: interrupting at ioapic0 pin 16 (i915drmkms0) [ 6.701635] kern info: [drm] initialized overlay support [ 6.741677] intelfb0 at i915drmkms0 -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
*.fr.netbsd.org downtime
Hello,
I will be upgrading the storage on {ftp,www,rsync,anoncvs}.fr.netbsd.org
in the next 2 days. This will requires several reboots and services
interruptions while datas are being moved around.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
Re: UEFI serial bootloader
On Tue, Jun 16, 2020 at 01:48:26PM +0300, Dima Veselov wrote: > Greetings, > > I have a server with IPMI serial console on COM2, which fails to show serial > bootloader in UEFI mode. For testing purposes I am using iPXE stack with > pxeboot_ia32 with console and serial options installed via installboot. > > UEFI shows itself on every serial port and monitor simultaneously. If > standard pxeboot is loaded it shows up on the same devices as UEFI, and > the kernel continues on monitor only, but if pxeboot with com2 option is > used - it does not show up anywhere, but the kernel works on com2. > > I've tried to check the problem on KVM VM but it works as intended - > UEFI on all devices, pxeboot on programmed device (monitor or serial), > kernel continues on same as pxeboot. > > It would be okay if kernel could have console= boot option, but as far > as I know it does not, so there is no way I can set up both bootloader > and kernel to serial device on real hardware. > > Is there any clue to check why it happens or any way to debug pxeboot? I've seen this on some supermicro hardware; AFAIK the bios swpped the com1 and com2 ports. The solution was to force the boot loader to use 0x3f8 as com1 (with the ioaddr option) -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Xmonad not installing.
On Fri, Jun 05, 2020 at 10:31:56AM +0200, Pedro Pinho wrote: > I'm using Makoto's 9.0_current builds. > The error log is too long to post here, but OK, so this repository is broken -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Xmonad not installing.
On Fri, Jun 05, 2020 at 08:08:18AM +0200, Pedro Pinho wrote: > NetBSD-9.0_STABLE, amd64 with 9.0_current > I can confirm this, > = > $ doas pkgin install xmonad > Password: > ... > 12 packages to install: > hs-dlist-0.8.0.7 hs-old-locale-1.0.0.7 > hs-data-default-instances-old-locale-0.0.1 > hs-data-default-instances-dlist-0.0.1nb4 > hs-data-default-instances-containers-0.0.1 > hs-data-default-class-0.1.2.0 hs-utf8-string-1.0.1.1 hs-setlocale-1.0.0.9 > hs-extensible-exceptions-0.1.1.4 hs-data-default-0.7.1.1 hs-X11-1.9.1 > xmonad-0.15 > > 0 to refresh, 0 to upgrade, 12 to install > 143M to download, 1926M to install > the following packages have unmet requirements: ghc-8.8.1nb2 that's strange, ghc-8.8.1nb2 is there. What happens if you pkgin in ghc-8.8.1nb2 ? what URL are you using for pkgin ? -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: find dir inode?
On Thu, May 28, 2020 at 10:37:23AM -0400, MLH wrote: > Getting a panic every night with NetBSD 9.99.64 due to a directory issue: > > [ 84702.426131] panic: /opt2: bad dir ino 209700553 at offset 0: Bad dir (too > big), reclen=0x5000, namlen=59, dirsiz=68 <= reclen=20480 <= maxsize=512, > flags=0x2001000, entryoffsetinblock=0, dirblksiz=512 Did you run fsck -fy on it (after unmounting it, of course) ? > [...] > I tried plowing around using ls -id to find a directory inode which > matches but can't find it. Back in about '84 was the last time I > used fsdb to rebuild a filesystem but I can't remember what I used > to locate inode numbers back then. Any suggestions? Thx find -inum maybe ? But you'll likely hit the panic when find will read the directory. with fsdb you can clri But then you'll have to fsck the filesystem. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: kernel source : compile from a ubuntu (gnu/linux) system : possible?
On Wed, May 27, 2020 at 04:03:50PM +0200, mayur...@kathe.in wrote: > On Wednesday, May 27, 2020 06:26 PM IST, Martin Husemann > wrote: > > > On Wed, May 27, 2020 at 02:47:44PM +0200, mayur...@kathe.in wrote: > > > i've also heard that it's possible to cross-compile the whole system > > > for a different target 'isa'. > > > > Basically what you do is something like: > > > > cd $(top-dir-where-you-put-the-netsbd-tree) > > ./build.sh -m evbarm64-el tools kernel=MYKERNEL > > > > to build cross toolchain + a single kernel. This will create "tools" in a > > special tool directory (and tell you where). > > thanks for your advice martin, but my intent is to compile the netbsd kernel > using some kind of toolchain under gnu/linux. Yes, this is what Martin suggests. You can run the above command on a linux host (I do it on RHEL7 servers) -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: I2C trackpad support?
On Sat, May 02, 2020 at 07:47:45PM +0200, Vincent DEFERT wrote: > I run NetBSD 9.0 amd64 GENERIC_KASLR on a Lenovo Ideapad 120S-14IAP > Here is the output of dmesg: I can't find where the i2c bus would be in the dmesg below. Comparing with FreeBSD we're missing a few ACPI ids in our match function, but none of them appears in the dmesg below. Also the HID device shoud appear as PNP0C50 or ACPI0C50, and I can't see it here either. There must be something else ... -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: I2C trackpad support?
On Sat, May 02, 2020 at 06:11:38PM +0200, Vincent DEFERT wrote: > I have installed GENERIC_KASLR, could this be the reason I don't see it? It shouldn't. But you don't mention which NetBSD version you're running, and on which hardware. Also posting the dmesg could help. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: I2C trackpad support?
On Sat, May 02, 2020 at 05:59:19PM +0200, Vincent DEFERT wrote: > The ims man page is there, but I can't see it in modstat, nor in > /stand/amd64/9.0/modules. > How can I load it? You can't. It's compiled in the kernel by default (it is in amd64/GENERIC at last) -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: I2C trackpad support?
On Sat, May 02, 2020 at 12:29:42PM +0200, Vincent DEFERT wrote: > Hi, > > OpenBSD 6.6 already supports I2C trackpads (iichid module) and FreeBSD 12.2 > will include support for them. > Are there any plans to support I2C trackpads in NetBSD too? They should be supported by the ims driver. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Hard Real-Time?
On Wed, Apr 15, 2020 at 01:14:02PM -0700, Michael Cheponis wrote: > Is there already a way to do "hard real time" on NetBSD? > > To me, "hard real time" means from an external pin going 'high' to the 1st > instruction of my driver executing is on the order of (up to) 10 usec. > > Many eons ago, I did this on BSD4.3 VAX 785 and achieved < about 100 usec > jitter. It was a Royal Pain to do, since so many places in the kernel > turned off interrupts as it massaged various data structures. The pain was > to find every one of those and break them down to absolutely minimize the > time interrupts were turned off. > > But it worked: Here it is controlling various hopping machines: > https://www.youtube.com/watch?v=mG_ZKXo6Rlg=youtu.be=34 I'm > sitting controlling the thing; the umbilical goes back to a UNIBUS > interface in the VAX. Timesharing only slowed down; it did not stop during > operation. > > I'm especially interested in getting the RPi to operate 'hard real time' on > NetBSD. I mainly want to use the RPi to control a robot -- low level as > well has higher-level planning/control. It should be doable in an interrupt handler running at high IPL - these days the global interrupt enable flag is turned off for very short time (a few instructions) on NetBSD. Maybe even IPL_VM would be acceptable. But your GPIO needs to be able to generate an interrupt. I know it works on Allwinner A20, but I'm much less familiar with RPI. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: cdrecord, no scsi, netbsd 9
On Thu, Apr 02, 2020 at 09:54:21AM +0200, Pierre Dupond wrote: > Hi All, > I have installed cdrecord from the precompiled packages. > The machine is running Netbsd 9, minimal installation. > > When I try to detect an external USB 2.0 dvd burner it is not recognised > with a message indicating that the SCSI driver can not be used. > > Should I do something specific (to load a specific module or > to recompile a kernel) to use SCSI layer? Did you try cdrecord dev=/dev/rcd0d ? What does dmesg show about the CD drive ? -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Terrible system slowness
On Mon, Mar 23, 2020 at 10:08:27PM -0400, Todd Gruhn wrote: > I decided to get back to running NetBSD on a new computer with a spare > drive: > > Just now I ran /bin/ksh configure for lesstif. The configure operation > alone too 45min. > (WHY!?) I have 64GB RAM, and a 1TB SATA harddrive. > > I redid the install this time using cylinders. Swap is 39000 cyl. According > to > swapctl -g -s this is 298GB (UGHH!) is there a nice way to trim the swap > partition? > > ALSO, is there a point where adding swap to a mechanical HD becomes a > liability? > > Has anyone messed with swap on a RAMDISK? I have 64GB RAM -- thats part of > the > idea for so much RAM. How would I carve out a 32GB RAMDISK and make that > the swap > device? The idea being that a RAM-to-RAM transfer is about 10,000x as fast > as a > RAM-to-mechanical-disk transfer? > > Any advice/ideas will be greatly appreciated. If it matters, I am running > NetBSD-9.99.x. Lots of changes happened in the last few weeks in kernel land, so the 'x' here is important. If not already the case, install the most recent -current. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: recording audio
On Mon, Mar 16, 2020 at 05:50:38PM +0100, Manuel Bouyer wrote: > Hello, > I tried recording audio, mainly to test if my laptop has an integrated mic: > [ 1.020260] hdaudio0 at pci0 dev 31 function 3: HD Audio Controller > [ 1.020260] hdaudio0: interrupting at msi5 vec 0 > [ 1.020260] hdafg0 at hdaudio0: vendor 10ec product 0256 > [ 1.020260] hdafg0: DAC00 2ch: Speaker [Built-In] > [ 1.020260] hdafg0: DAC01 2ch: HP Out [Jack] > [ 1.020260] hdafg0: ADC02 2ch: Mic In [Built-In] > [ 1.020260] hdafg0: 2ch/2ch 44100Hz 48000Hz 96000Hz 192000Hz PCM16 PCM20 > PCM24 AC3 > [ 1.020260] audio0 at hdafg0: playback, capture, full duplex, independent > [ 1.020260] audio0: slinear_le:16 2ch 48000Hz, blk 40ms for playback > [ 1.020260] audio0: slinear_le:16 2ch 48000Hz, blk 40ms for recording > > I tried > audiorecord -p mic /tmp/truc.au > but it returns "audiorecord: failed to set audio info: Invalid argument". > > "audiorecord /tmp/truc.au" just creates an empty file. Correction: this is a 32-bytes file, not empty. But obviously it contains no sound ... -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
recording audio
Hello, I tried recording audio, mainly to test if my laptop has an integrated mic: [ 1.020260] hdaudio0 at pci0 dev 31 function 3: HD Audio Controller [ 1.020260] hdaudio0: interrupting at msi5 vec 0 [ 1.020260] hdafg0 at hdaudio0: vendor 10ec product 0256 [ 1.020260] hdafg0: DAC00 2ch: Speaker [Built-In] [ 1.020260] hdafg0: DAC01 2ch: HP Out [Jack] [ 1.020260] hdafg0: ADC02 2ch: Mic In [Built-In] [ 1.020260] hdafg0: 2ch/2ch 44100Hz 48000Hz 96000Hz 192000Hz PCM16 PCM20 PCM24 AC3 [ 1.020260] audio0 at hdafg0: playback, capture, full duplex, independent [ 1.020260] audio0: slinear_le:16 2ch 48000Hz, blk 40ms for playback [ 1.020260] audio0: slinear_le:16 2ch 48000Hz, blk 40ms for recording I tried audiorecord -p mic /tmp/truc.au but it returns "audiorecord: failed to set audio info: Invalid argument". "audiorecord /tmp/truc.au" just creates an empty file. Anyone knows how this should work ? -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Getting slip(4) to work beyond two machines
On Wed, Mar 11, 2020 at 12:41:05AM +0100, Johnny Billquist wrote: > On 2020-03-11 00:37, Greg Troxel wrote: > > In addition to other advice: Don't use addresses that belong on an > > ethernet on a slip link. Pick a new subnet, and set up real routes, > > not proxy arp. > > Actually, that would be the very best advice, I'd say. Don't try and do a > complicated solution when there is a perfectly good simple one, which fits > in to how IP is supposed to work. Exept you can't always setup a proper routing. I use proxy arp and it works fine in most cases. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Getting slip(4) to work beyond two machines
On Tue, Mar 10, 2020 at 08:45:17PM +, Björn Johannesson wrote: > Hello. > > I'm trying to connect two machines via slip(4) and then get communication > going outside those two. > One of the machines have a NIC and I wan't to get the machine behind that one > to reach outside. > I have done this once long ago and I had jotted down these notes: > https://pastebin.com/UK43aV5x > I'm trying to get this working on again now. IP's have changed ofc. > > On the machine w/o NIC I do: > ifconfig sl0 create > slattach -s 115200 /dev/tty00 > ifconfig sl0 inet 192.168.0.51 192.168.0.50 > route add default 192.168.0.50 > > On the machine with NIC: > ifconfig sl0 create > slattach -s 115200 /dev/tty00 > ifconfig sl0 inet 192.168.0.50 192.168.0.51 > arp -s 192.168.0.51 6c:3b:e5:1f:98:d8 pub proxy > sysctl -w net.inet.ip.forwarding=1 > (The real NIC on this machine has ip 192.168.0.114 netmask ff00) 6c:3b:e5:1f:98:d8 is the mac address of your real nic, right ? > > The two machines communicate fine with each other - however the forwarding > part does not. > 192.168.0.51 cannot communicate past .0.50 and cannot be reached from outside > .0.50. > There is also a _significant_ delay when communicating from .51 to .50 after > adding the "route" command. > If I ping .50 from .51 it takes many seconds (>10) before it starts sending > packets. Probably a DNS-related timeout. You could try running tcpdump on the real NIC and watch for traffic from/to 192.168.0.51. Also watch for ARP traffic. I've used a very similar setup with netbsd-8, it works. I'm not use I tried with -9 yet. Also in my notes I see that I set the sl0 MTU to 1500, maybe because by default the MTU is too low. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: No pf in 9.0 - how to traffic shaping
On Fri, Mar 06, 2020 at 09:09:47AM +0100, Petr Topiarz wrote: > Yes, I use altq, but how to use it in NPF? AFAIK you can't. But you don't need NPF or PF to use altq; it has its own packet classifier: altqd, configured with altq.conf -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: No pf in 9.0 - how to traffic shaping
On Thu, Mar 05, 2020 at 09:35:35PM +0100, Petr Topiarz wrote: > Hi folks, > I run several routers with 8.1 and pf and I need traffic shaping. > > If I understand correctly, there is no pf in NetBSD 9.0. But there is also > no documentation about traffic shaping in npf. > > Any idea what to do? look at altq(4) -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Problems with C++ compiler on 9.0_RC2
On Thu, Feb 06, 2020 at 12:13:31PM +0100, Marc Baudoin wrote: > [...] > I can't because I gave up on C++ some 20 years ago. Anyway, > trying to compile pkgsrc/devel/cmake or pkgsrc/print/poppler > fails every time for me as indicated in my previous message. > > It could also be a pthreads problem. But it's definitely linked > to 9.0_RC2 as I didn't have it with 8.1. I guess it's from pkgsrc-current ? I'm building pkgsrc 2019Q4 on 9.0_RC2/i386 and both poppler and cmake did build fine. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: pkgsrc binary packages security with pkgin
On Fri, Jan 31, 2020 at 07:21:40PM +0100, Jan Danielsson wrote: > On 2020-01-31 08:49, yarl-bau...@mailoo.org wrote: > > Please Maya and Mr Billquist, can you be more specific about how it is > > insecure? > >There are different domains to consider. > >*Assuming you can trust the build environment (which includes the > signing process)*, and assuming that you can trust the underlying crypto: > >- HTTPS protects the connection between you and the server (assuming > server authentication, and not just encryption). So if you trust the > remote server, your client, and the HTTPS implementation, then HTTPS is > sufficient for the entire chain. Not really; for this to be true you have to trust the build process, the way the binary package is uploaded to the http server and the http server itself. With signed binary pkg you only need to trust the build process. In a world where there are multiple sources under different administrative domains for the same file, this is important. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: pkgsrc binary packages security with pkgin
On Fri, Jan 31, 2020 at 12:32:06PM +0100, Johnny Billquist wrote: > Of course you can. But then you need to have a whole list of trusted public > keys that needs to be managed, which again leads to the question of which > keys are now the acceptable ones. And how to you trust new builders? Can > anyone then be added to the list of official builders of packages, or how to > you manage that side? > Key management is not trivial. Of course it's not. But this is not really a technical issue. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: pkgsrc binary packages security with pkgin
On Fri, Jan 31, 2020 at 11:39:32AM +0100, Johnny Billquist wrote: > On 2020-01-31 11:34, Manuel Bouyer wrote: > > On Fri, Jan 31, 2020 at 11:08:05AM +0100, Johnny Billquist wrote: > > > On 2020-01-31 10:25, yarl-bau...@mailoo.org wrote: > > > > That's exactly the answer I was waiting and hoping for. Thank you. > > > > > > > > I'll follow tech-pkg from now on. Packages must be signed. > > > > > > And with that signature, you know that what you got from the server was > > > not > > > tampered with during transport to you, which is the same thing https would > > > give you. And which still means you have no idea if the software is sane, > > > proper, does what you think, or hasn't been tampered with. > > > > No it's not the same thing. > > package signature guarantees that the data have not been modified since it > > has been built. > > https guarantees that the data have not been modified between the http > > server > > and client. It doesn't tell anything about what happened to the binary pkg > > between the build server and the http server at the time you download it. > > Right you are. I was too fast and loose on that one. > > Signatures are better in that sense. However, you then also have to trust > that the signature have not been altered along with a alteration of the > package... So does a signature really tell you much at all? I guess if you > then had signatures with public/private keys. But then again, that don't > really work if you have multiple places doing builds, unless they then share > the private key, but that in turn leads to the question about how private do > you then think that key is? Why would they have to share the same private key ? You can trust multiple public keys, this is how other binary package managers works. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: pkgsrc binary packages security with pkgin
On Fri, Jan 31, 2020 at 11:08:05AM +0100, Johnny Billquist wrote: > On 2020-01-31 10:25, yarl-bau...@mailoo.org wrote: > > That's exactly the answer I was waiting and hoping for. Thank you. > > > > I'll follow tech-pkg from now on. Packages must be signed. > > And with that signature, you know that what you got from the server was not > tampered with during transport to you, which is the same thing https would > give you. And which still means you have no idea if the software is sane, > proper, does what you think, or hasn't been tampered with. No it's not the same thing. package signature guarantees that the data have not been modified since it has been built. https guarantees that the data have not been modified between the http server and client. It doesn't tell anything about what happened to the binary pkg between the build server and the http server at the time you download it. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD and User Private Groups (Unique Groups)
On Wed, Jan 29, 2020 at 11:29:54AM +, Ottavio Caruso wrote: > On 29/01/2020 10:02, Manuel Bouyer wrote: > > On Wed, Jan 29, 2020 at 09:36:02AM +, Ottavio Caruso wrote: > > > Hi, > > > > > > I'm using 9.0_RC1, so I don't know if this is a functionality that was > > > used > > > in the past and then dropped or will be introduced in the future. > > > > > > At one point in time, probably around 10+ years ago, Red Hat introduced > > > User > > > Private Groups [1]. I ignore if other OSes have had this feature before > > > (probably Mac OSX ?). Anyway, this has then spread to all other major > > > Linux > > > distros. FreeBSD calls them "unique groups" [2]. OpenBSD has this line in > > > /etc/usermgmt.conf: > > > > > > group =uid > > > > I never understood how this would be usefull > > > > [I forgot to cc: the list. Manuel, sorry for the duplicate] > > I wonder how this can possibly _not_ be useful. > > On a multi user system, all files are created readable by the group (umask > 022). If we are all in the same group, anybody can read my newly created > files (imagine a local password file for alpine or ssl certs for irc, etc). > It's then left to the user to change umask and/or adjust permissions. Why > not just make it easier for the user? Note that it's also readable by others (with umask 022, the files are created rw-r--r--), so changing the group won't help. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NetBSD and User Private Groups (Unique Groups)
On Wed, Jan 29, 2020 at 09:36:02AM +, Ottavio Caruso wrote: > Hi, > > I'm using 9.0_RC1, so I don't know if this is a functionality that was used > in the past and then dropped or will be introduced in the future. > > At one point in time, probably around 10+ years ago, Red Hat introduced User > Private Groups [1]. I ignore if other OSes have had this feature before > (probably Mac OSX ?). Anyway, this has then spread to all other major Linux > distros. FreeBSD calls them "unique groups" [2]. OpenBSD has this line in > /etc/usermgmt.conf: > > group =uid I never understood how this would be usefull -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: repo missing package
On Sat, Jan 11, 2020 at 03:43:58PM +0100, Rhialto wrote: > On Fri 10 Jan 2020 at 10:25:13 -0500, Greg Troxel wrote: > > So maybe I've been lucky. Maybe it's MAKE_JOBS. Maybe it's something > > else we don't understand. > > On my machine, rust and firefox also "just built". I did get messages in > my xconsole windown about random though, but not only during these > builds it seems. I forced MAKE_JOBS=1 for rust on the build cluster, and rust did build on 8.0/i386 this time. A parallelism issue is coherent with the error message from the previous run (trying to access a non-existent file in the build directory) -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
