Re: print usb printer by [ Google Cloud Print for Chromium ]
hi all . i do not understand lpr . so my settings are # ls -l /usr/bin/lpr lrwxr-xr-x 1 root wheel 18 Jun 1 05:52 /usr/bin/lpr -> /home/snap/lpr.bat # cat /home/snap/lpr.bat lp -dEP-901A then seamonkey and leafpad print easily . --- regards
Logging to Elasticsearch with syslog-ng
Hi Misc, I am revisiting the idea of storing log files in Elasticsearch DB for quick search, analytics, and visualization (Kibana). I would like to keep my current OpenBSD syslog-ng centralized logging server and just write logs into ElasticsearchDB instead of flat files. Looks like Elastricsearch runs happily on OpenBSD http://openports.se/textproc/elasticsearch just like Kibana http://openports.se/www/kibana I was wondering if the syslog-ng version in ports 3.12.1 (the latest release seems to be 3.15.1) supports Java plugin needed to send logs from syslog-ng to Elasticsearch. It looks like 3.12.1 is high enough version which supports syslog-ng-incubator which was not the case last time https://marc.info/?l=openbsd-misc=143249546020820=2 However I don't see incubator in ports https://github.com/balabit/syslog-ng-incubator To be frank by looking quickly through incubator GitHub pages it is not even clear to me that Java module currently necessary to send things to Elasticsearch is even the part of the incubator. I stumbled somewhere on Balabit official documentation which recommends Linux (binary blob plugins) as the syslog-ng server OS for that very reason. I do see that Balabit is contemplating writing a native Elasticsearch destination driver per Google Summer of Code https://github.com/balabit/syslog-ng/wiki/GSoC-2018-Proposal-:-ElasticSearch-destination:-native(C)-REST-API Can anybody who is more informed than I on the topic shed some light onto this topic? Best, Predrag
Re: The compiler error about modifying libcrypto
Hi Theo, Thanks for your kind reply! Best Regards Nan Xiao On Thu, May 31, 2018 at 7:24 PM, Theo Buehler wrote: > On Thu, May 31, 2018 at 10:50:35AM +0800, Nan Xiao wrote: >> My OS is OpenBSD 6.3. > > -current? > > If not, please install the latest snapshot before trying to build > -current from source. > > See also https://www.openbsd.org/faq/current.html > >> Since now the -current modify the interface of >> libcrypto, there is error in "make": >> .. >> ===> lib/libcrypto > > Don't do "make" from /usr/src. > > Please read https://man.openbsd.org/release.8 and follow at least > up through step 3. > > If you have things prepared as described in release(8) and you do > "make build", it will do "make includes" and install the current > headers, thus preventing the compilation failure you ran into.
Re: Programming for OpenBSD
I would advise start with reading the OpenBSD Mailing List Netiquette first: (https://www.openbsd.org/mail.html) Particularly the 5th point from top: *- Stay on topic*... On Thu, May 31, 2018 at 7:57 PM, Marc Espie wrote: > On Wed, May 30, 2018 at 11:41:00PM -0400, Kevin Burke wrote: > > Hey guys, > > fell asleep waiting for a point. > >
Problem using usb audio device
Hello misc, I am currently trying to get an usb audio device to work on my system which fails. My motherboard has an onboard audio interface that gets detected as azalia device and works without issues. Additionally I have a Griffin iMic usb audio adapter that I would like to use instead of the onboard audio device. It gets detected as uaudio0. Disabling the onboard audio in BIOS lets sndiod automatically connect the usb device but audio playback results in not working at all and repeating the following errors in dmesg: uaudio_chan_open: error creating pipe: err=INVAL endpt=0x01 audio1: failed to start playback uaudio_chan_open: error creating pipe: err=INVAL endpt=0x84 audio1: failed to start recording With both audio devices present I also tried to switch the default device for sndiod to the usb device according to https://www.openbsd.org/faq/faq13.html which results in the same errors appearing in dmesg. rc.conf.local: sndiod_flags=-f rsnd/1 My audio application (quodlibet) freezes and crashes after a while with a core dump. Video playback in Firefox also freezes but firefox isn't crashing. Has anybody tried this and probably seen this before? Is there more I can do to debug the issue? Using different usb ports on the system makes no difference. Any hint is highly apprechiated Thanks and regards Lars OpenBSD 6.3-current (GENERIC.MP) #55: Thu May 31 07:21:36 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8438255616 (8047MB) avail mem = 8174370816 (7795MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xd939b018 (75 entries) bios0: vendor American Megatrends Inc. version "2501" date 07/22/2015 bios0: ASUS All Series acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT LPIT SSDT SSDT MCFG HPET SSDT SSDT BGRT acpi0: wakeup devices UAR1(S4) PXSX(S4) RP01(S4) PXSX(S4) PXSX(S4) RP03(S4) PXSX(S4) PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S4) EHC2(S4) XHC_(S4) HDEF(S4) PEG0(S4) PEGP(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i3-4360 CPU @ 3.70GHz, 3691.89 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges using xsaveopt cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i3-4360 CPU @ 3.70GHz, 3691.46 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Core(TM) i3-4360 CPU @ 3.70GHz, 3691.46 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 1, core 0, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i3-4360 CPU @ 3.70GHz, 3691.46 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 2 (RP01) acpiprt2 at acpi0: bus 3 (RP03) acpiprt3 at acpi0: bus 1 (PEG0) acpiprt4 at acpi0: bus -1 (PEG1) acpiprt5 at acpi0: bus -1 (PEG2) acpiec0 at acpi0: not present acpicpu0 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
Re: Programming for OpenBSD
On Wed, May 30, 2018 at 11:41:00PM -0400, Kevin Burke wrote: > Hey guys, fell asleep waiting for a point.
Re: Programming for OpenBSD
Books related to OpenBSD: https://www.openbsd.org/books.html If you're hacking the OpenBSD base, you'll get very good advice by submitting patches to tech@. You'll find that the OpenBSD community isn't overly fond of political debate or security theater, most people just stick to technical discussion.
Re: programs crash on Dell Latitude E7470
On 31 May 16:32 Stuart Henderson wrote:
> On 2018/05/31 17:24, Marco van Hulten wrote:
> > Stuart,
> >
> > On 31 May 15:10 Stuart Henderson wrote:
> > > The gdb output there doesn't include anything that will help track
> > > things down. At least a backtrace is needed ("bt" at the gdb
> > > prompt), but there will be more information included in the
> > > backtrace if you build from ports like this
> > >
> > > pkg_delete calcurse
> > > cd /usr/ports/productivity/calcurse
> > > make clean
> > > make DEBUG=-g repackage
> > > make install
> > >
> > > Since it's threaded you might get something more useful with
> > > "thread apply all bt full".
> >
> > I'll send that to them but so far have not recompiled it, because
> > of an issue with the source tree:
> >
> > marco@ultron:/usr/ports/productivity/calcurse$ make clean
> > Fatal: Unknown flavor(s) centered_tilde (in productivity/calcurse)
> >(No flavors for this port). (in productivity/calcurse)
> > *** Error 1 in /usr/ports/productivity/calcurse
> > (/usr/ports/infrastructure/mk/bsd.port.mk:3462 '.BEGIN': @exit 1)
> >
> > I tried checking out a clean ports tree (download + cvs up), but it
> > resulted in the same error. Same for just the "make" command in any
> > port, for instance /usr/ports/mail/z-push/.
>
> Perhaps you have something setting this FLAVOR in /etc/mk.conf or the
> shell environment?
Yes, I had that set as a shell variable. I don't know why I ever put
that there.
Now I get other problems:
marco@ultron:/usr/ports/productivity/calcurse$ make
Fatal: Missing support for module x11/tk. (in lang/python/3.6)
Fatal: Missing support for module x11/tk. (in lang/python/3.6)
*** Error 1 in /usr/ports/lang/python/3.6
(/usr/ports/infrastructure/mk/bsd.port.mk:3462 '.BEGIN': @exit 1)
Problem with dependency lang/python/3.6
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2057
'/usr/ports/pobj/calcurse-4.3.0/.dep-lang-python-3.6')
*** Error 1 in /usr/ports/productivity/calcurse
(/usr/ports/infrastructure/mk/bsd.port.mk:2380 'all')
I have x11/tk and Python 3.6 installed.
I should've said I don't regularly build packages, but it shouldn't be
that hard :-)
Marco
Re: programs crash on Dell Latitude E7470
On 2018/05/31 17:24, Marco van Hulten wrote:
> Stuart,
>
> On 31 May 15:10 Stuart Henderson wrote:
> > The gdb output there doesn't include anything that will help track
> > things down. At least a backtrace is needed ("bt" at the gdb prompt),
> > but there will be more information included in the backtrace if you
> > build from ports like this
> >
> > pkg_delete calcurse
> > cd /usr/ports/productivity/calcurse
> > make clean
> > make DEBUG=-g repackage
> > make install
> >
> > Since it's threaded you might get something more useful with
> > "thread apply all bt full".
>
> I'll send that to them but so far have not recompiled it, because of an
> issue with the source tree:
>
> marco@ultron:/usr/ports/productivity/calcurse$ make clean
> Fatal: Unknown flavor(s) centered_tilde (in productivity/calcurse)
>(No flavors for this port). (in productivity/calcurse)
> *** Error 1 in /usr/ports/productivity/calcurse
> (/usr/ports/infrastructure/mk/bsd.port.mk:3462 '.BEGIN': @exit 1)
>
> I tried checking out a clean ports tree (download + cvs up), but it
> resulted in the same error. Same for just the "make" command in any
> port, for instance /usr/ports/mail/z-push/.
Perhaps you have something setting this FLAVOR in /etc/mk.conf or the
shell environment?
Re: programs crash on Dell Latitude E7470
Stuart,
On 31 May 15:10 Stuart Henderson wrote:
> The gdb output there doesn't include anything that will help track
> things down. At least a backtrace is needed ("bt" at the gdb prompt),
> but there will be more information included in the backtrace if you
> build from ports like this
>
> pkg_delete calcurse
> cd /usr/ports/productivity/calcurse
> make clean
> make DEBUG=-g repackage
> make install
>
> Since it's threaded you might get something more useful with
> "thread apply all bt full".
I'll send that to them but so far have not recompiled it, because of an
issue with the source tree:
marco@ultron:/usr/ports/productivity/calcurse$ make clean
Fatal: Unknown flavor(s) centered_tilde (in productivity/calcurse)
(No flavors for this port). (in productivity/calcurse)
*** Error 1 in /usr/ports/productivity/calcurse
(/usr/ports/infrastructure/mk/bsd.port.mk:3462 '.BEGIN': @exit 1)
I tried checking out a clean ports tree (download + cvs up), but it
resulted in the same error. Same for just the "make" command in any
port, for instance /usr/ports/mail/z-push/.
> Normally I'd suggest reporting to the port maintainer first
> (perhaps CC po...@openbsd.org) and see if they have an idea,
> but since it's already reported upstream it would be good to
> followup there with the backtrace as well.
Yes, that would have been better!
Marco
Re: programs crash on Dell Latitude E7470
On 2018/05/31 15:47, Marco van Hulten wrote:
> whereas calcurse stops in rthread.c, which I thought could be a
> calcurse bug so I reported it [1], but I'm not sure at all anymore.
>
> [1]: https://lists.calcurse.org/bugs/msg00261.html
The gdb output there doesn't include anything that will help track
things down. At least a backtrace is needed ("bt" at the gdb prompt),
but there will be more information included in the backtrace if you
build from ports like this
pkg_delete calcurse
cd /usr/ports/productivity/calcurse
make clean
make DEBUG=-g repackage
make install
Since it's threaded you might get something more useful with
"thread apply all bt full".
Normally I'd suggest reporting to the port maintainer first
(perhaps CC po...@openbsd.org) and see if they have an idea,
but since it's already reported upstream it would be good to
followup there with the backtrace as well.
Re: programs crash on Dell Latitude E7470
On 31 May 10:15 Stuart Henderson wrote: > On 2018/05/31 10:06, Marco van Hulten wrote: > > Stuart, > > > > [...] > > > > I now see there are some limits [...] as normal user > > [now given from ksh(1)] $ ulimit -a time(cpu-seconds)unlimited file(blocks) unlimited coredump(blocks) unlimited data(kbytes) 786432 stack(kbytes)4096 lockedmem(kbytes)5303878 memory(kbytes) 15888396 nofiles(descriptors) 512 processes128 I put myself in login class "staff", which increased limits, and then increased limits a bit further where I could: $ ulimit -a time(cpu-seconds)unlimited file(blocks) unlimited coredump(blocks) unlimited data(kbytes) 15728640 stack(kbytes)4096 lockedmem(kbytes)5503878 memory(kbytes) 15888396 nofiles(descriptors) 1024 processes512 >From this shell I started abiword, and get an immediate crash: $ rm -rf ~/.config/abiword $ abiword Abort trap (core dumped) $ gdb abiword abiword.core [...] Loaded symbols for /usr/local/lib/abiword-3.0/plugins/pdf.so #0 thrkill () at -:3 3 -: No such file or directory. in - (gdb) whereas calcurse stops in rthread.c, which I thought could be a calcurse bug so I reported it [1], but I'm not sure at all anymore. [1]: https://lists.calcurse.org/bugs/msg00261.html Two days or so ago Firefox and Claws Mail crashed at arbitrary moments. Just maybe this behaviour will stop now. > Limits are grouped by login class (5th field in master.passwd). root > is usually in "daemon" and the initial user created during install is > in "staff" (default 1.5GB for datasize-cur, no limit for > datasize-max). Users that you've added separately are likely to be in > the default class (768MB datasize-cur and datasize-max). > > datasize-cur is a "soft limit", a user can increase it themselves with > "ulimit -d " up to the hard limit in datasize-max. I learnt something! > I'd start by putting the relevant user/s into "staff" class (as root, > vipw, or "chsh " and edit the Class: line), logout/login and > retry. If it needs more than this, it maybe better to raise the soft > limit for the individual program by using a shell alias or wrapper > script rather than raising it across the board (OpenBSD doesn't cope > very well if the entire system runs out of memory and this is a useful > brake on runaway processes). For example you could use an alias like > this: > > alias firefox="(ulimit -d $((3*1024*1024)); /usr/local/bin/firefox)" Thanks, I'll do that when appropriate. At the moment it does not seem to be a memory limitation issue. By decreasing ulimit -d $((128*1024)), I can reproduce an immediate crash of firefox-esr and get the same traceback message as generated by abiword above. But there I *increased* the limits. Thanks for the apropos(1) tip! Marco
Re: Upgrade 6.0 -> 6.1: ix mmba is not mem space
On 2018/05/31 15:16, mxb wrote: > With -stable kernel and modded syspatch I was able to pull down all the > patches I needed to have this machine to be fully up to date. As ever, you get to keep both pieces if it breaks, and please make sure you mention this if you report any problems :-)
Re: Upgrade 6.0 -> 6.1: ix mmba is not mem space
With -stable kernel and modded syspatch I was able to pull down all the patches I needed to have this machine to be fully up to date. Sent from my iDevice > 30 мая 2018 г., в 18:59, Stuart Henderson написал(а): > >> On 2018-05-30, Maxim Bourmistrov wrote: >> I ended up with a -stable kernel and syspatch refusing to pull down patches, >> but this is another story. > > syspatch is only for releases or systems which have been syspatch'ed directly > from a release - it can't work with -stable, own-built kernels or kernels > modified > with config(8). > >
Re: The compiler error about modifying libcrypto
On Thu, May 31, 2018 at 10:50:35AM +0800, Nan Xiao wrote: > My OS is OpenBSD 6.3. -current? If not, please install the latest snapshot before trying to build -current from source. See also https://www.openbsd.org/faq/current.html > Since now the -current modify the interface of > libcrypto, there is error in "make": > .. > ===> lib/libcrypto Don't do "make" from /usr/src. Please read https://man.openbsd.org/release.8 and follow at least up through step 3. If you have things prepared as described in release(8) and you do "make build", it will do "make includes" and install the current headers, thus preventing the compilation failure you ran into.
Re: Dell Latitude and E-Port II: system hangs
On 25 May 17:22 Marco van Hulten wrote:
> On 25 May 13:50 Marco van Hulten wrote:
> > I have a Dell Latitude E7470 with the latest OpenBSD snapshot. It
> > boots fine when not connected to a docking station. When I connect
> > it to a DELL E-Port II (Model No: PR03X) docking station, it
> > crashes with the following kernel error:
> >
> > error: [drm:pid8048:i915_gem_init_hw] *ERROR* Failed to initialize
> > GuC, error -9 (ignored) error:
> > [drm:pid73911:intel_dp_link_training_clock_recovery] *ERROR* too
> > many full retries, give up error:
> > [drm:pid73911:intel_dp_aux_wait_done] *ERROR* dp aux hw did not
> > signal timeout (has irq: 1)! error:
> > [drm:pid73911:intel_dp_set_idle_link_train] *ERROR* Timed out
> > waiting for DP idle patterns
>
> This specific issue appears to have disappeared (for now). I'm typing
> this on the laptop, running OpenBSD, with the docking station
> attached.
During the last boot, just after fs check, I got this:
kernel: double fault trap, code=0
Stopped at Xsyscall+0x3: movq %r15,%gs:0x8
ddb{0}>
The system was unresponsive. Next boot, it came up (writing this
e-mail on the system, dmesg attached), but the console log shows issues:
error: [drm:pid47136:intel_pipe_update_start] *ERROR* Potential atomic update
failure on pipe B
error: [drm:pid38604:check_wm_state] *ERROR* mismatch in DDB state pipe A plane
1 (expected (0,860), found (0,438))
error: [drm:pid38604:check_wm_state] *ERROR* mismatch in DDB state pipe A
cursor (expected (860,892), found (438,446))
WARNING !wm_changed failed at /usr/src/sys/dev/pci/drm/i915/intel_pm.c:3609
WARNING !wm_changed failed at /usr/src/sys/dev/pci/drm/i915/intel_pm.c:3609
Possibly, only the first one sits close to the hardware (I don't know).
The other four messages sugges interaction with the window manager
(current spectrwm package).
Marco
OpenBSD 6.3-current (GENERIC.MP) #52: Wed May 30 13:42:02 MDT 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 16811323392 (16032MB)
avail mem = 16293675008 (15538MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xeb460 (106 entries)
bios0: vendor Dell Inc. version "1.12.3" date 12/11/2016
bios0: Dell Inc. Latitude E7470
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT LPIT SSDT SSDT SSDT DBGP
DBG2 SSDT UEFI SSDT SSDT MSDM SLIC TCPA DMAR ASF!
acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4)
PXSX(S4) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4)
PXSX(S4) RP13(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz, 2095.86 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
using xsaveopt
cpu0: apic clock running at 23MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz, 2095.11 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz, 2095.11 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz, 2095.11 MHz
cpu3:
Re: VMM can't boot from *.iso files, right?
On Wed, May 30, 2018 at 08:25:43PM -0700, Mike Larkin wrote: > FreeBSD requires some work still. Not sure about DFly. > > -ml > Does that mean I can only boot OpenBSD and GNU/Linux? I tried to boot NetBSD, it panics too.
Re: programs crash on Dell Latitude E7470
On 2018/05/31 10:06, Marco van Hulten wrote: > Stuart, > > On 29 May 14:18 Stuart Henderson wrote: > > On 2018-05-28, Marco van Hulten wrote: > > >> Sounds like ether you're running out of system memory, or running > > >> into ulimit limits. > > > > > > `ulimit` == unlimited > > > > ulimit [-acdfHlmnpSst > > [value]] ... Display or set process limits. If no options are used, > > the file size limit (-f) is assumed. > > > > What does ulimit -a say? > > I now see there are some limits (root, using ksh): > > # ulimit -a > time(cpu-seconds)unlimited > file(blocks) unlimited > coredump(blocks) unlimited > data(kbytes) 33554432 > stack(kbytes)8192 > lockedmem(kbytes)5303876 > memory(kbytes) 15888388 > nofiles(descriptors) 128 > processes1310 > > and as normal user, using Bash: > > $ ulimit -a > core file size (blocks, -c) unlimited > data seg size (kbytes, -d) 786432 > file size (blocks, -f) unlimited > max locked memory (kbytes, -l) 5303876 > max memory size (kbytes, -m) 15888388 > open files (-n) 512 > pipe size(512 bytes, -p) 1 > stack size (kbytes, -s) 4096 > cpu time (seconds, -t) unlimited > max user processes (-u) 128 > virtual memory (kbytes, -v) 790528 Limits are grouped by login class (5th field in master.passwd). root is usually in "daemon" and the initial user created during install is in "staff" (default 1.5GB for datasize-cur, no limit for datasize-max). Users that you've added separately are likely to be in the default class (768MB datasize-cur and datasize-max). datasize-cur is a "soft limit", a user can increase it themselves with "ulimit -d " up to the hard limit in datasize-max. I'd start by putting the relevant user/s into "staff" class (as root, vipw, or "chsh " and edit the Class: line), logout/login and retry. If it needs more than this, it maybe better to raise the soft limit for the individual program by using a shell alias or wrapper script rather than raising it across the board (OpenBSD doesn't cope very well if the entire system runs out of memory and this is a useful brake on runaway processes). For example you could use an alias like this: alias firefox="(ulimit -d $((3*1024*1024)); /usr/local/bin/firefox)" > Apropos, why doesn't "apropos ulimit" show up ksh(1)? Only shortly > after typing "which ulimit", I realised that ulimit is part of the > shell. By default apropos searches in manual page names and descriptions, but not the rest of the manual. OpenBSD manuals have rich semantic layout and you can search on various types of identifier; try apropos or "man -k" with either of these: Ic=ulimit any=ulimit
Re: programs crash on Dell Latitude E7470
Stuart, On 29 May 14:18 Stuart Henderson wrote: > On 2018-05-28, Marco van Hulten wrote: > >> Sounds like ether you're running out of system memory, or running > >> into ulimit limits. > > > > `ulimit` == unlimited > > ulimit [-acdfHlmnpSst > [value]] ... Display or set process limits. If no options are used, > the file size limit (-f) is assumed. > > What does ulimit -a say? I now see there are some limits (root, using ksh): # ulimit -a time(cpu-seconds)unlimited file(blocks) unlimited coredump(blocks) unlimited data(kbytes) 33554432 stack(kbytes)8192 lockedmem(kbytes)5303876 memory(kbytes) 15888388 nofiles(descriptors) 128 processes1310 and as normal user, using Bash: $ ulimit -a core file size (blocks, -c) unlimited data seg size (kbytes, -d) 786432 file size (blocks, -f) unlimited max locked memory (kbytes, -l) 5303876 max memory size (kbytes, -m) 15888388 open files (-n) 512 pipe size(512 bytes, -p) 1 stack size (kbytes, -s) 4096 cpu time (seconds, -t) unlimited max user processes (-u) 128 virtual memory (kbytes, -v) 790528 Apropos, why doesn't "apropos ulimit" show up ksh(1)? Only shortly after typing "which ulimit", I realised that ulimit is part of the shell. Marco
