Re: About special configs to do in OpenBSD for KVM environments
On Fri, Dec 19, 2014 at 7:51 AM, Peter Hessler phess...@theapt.org wrote: On 2014 Dec 19 (Fri) at 07:35:28 + (+), C. L. Martinez wrote: :b) OpenBSD/amd64: set up vio flags to 0x02 The man page for vio(4) says: Setting the bit 0x2 in the flags disables the RingEventIndex feature. This can be tried as a workaround for possible bugs in host implementations of vio at the cost of slightly reduced performance. What bugs in the host implementation, which versions are affected, how bad is the performance hit, and should this be the default? Yep, sorry Peter, you are right: OpenBSD 5.6 release. And, when some weeks ago I have tried to copy several files (4 GiB) using virtio for nics and disks, I've got the same problem like Michael describes here: http://blather.michaelwlucas.com/archives/2083
Re: About special configs to do in OpenBSD for KVM environments
On 2014 Dec 19 (Fri) at 08:01:00 + (+), C. L. Martinez wrote: :On Fri, Dec 19, 2014 at 7:51 AM, Peter Hessler phess...@theapt.org wrote: : On 2014 Dec 19 (Fri) at 07:35:28 + (+), C. L. Martinez wrote: : :b) OpenBSD/amd64: set up vio flags to 0x02 : : The man page for vio(4) says: : Setting the bit 0x2 in the flags disables the RingEventIndex feature. : This can be tried as a workaround for possible bugs in host : implementations of vio at the cost of slightly reduced performance. : : What bugs in the host implementation, which versions are affected, how : bad is the performance hit, and should this be the default? : : :Yep, sorry Peter, you are right: OpenBSD 5.6 release. : I more mean: which versions on the host will trigger this behaviour. :And, when some weeks ago I have tried to copy several files (4 GiB) :using virtio for nics and disks, I've got the same problem like :Michael describes here: : :http://blather.michaelwlucas.com/archives/2083 : -- Call on God, but row away from the rocks. -- Indian proverb
Re: About special configs to do in OpenBSD for KVM environments
On Fri, Dec 19, 2014 at 11:57:19AM +0400, Vadim Zhukov wrote: I have few 5.5/amd64 in production under CentOS 6.2, without either direct or indirect access to Internet. No problems so far, no adjustments on OpenBSD side. Time to upgrade hosts? It's time of 6.6 now :) j.
Re: About special configs to do in OpenBSD for KVM environments
On Fri, Dec 19, 2014 at 8:04 AM, Peter Hessler phess...@theapt.org wrote: On 2014 Dec 19 (Fri) at 08:01:00 + (+), C. L. Martinez wrote: :On Fri, Dec 19, 2014 at 7:51 AM, Peter Hessler phess...@theapt.org wrote: : On 2014 Dec 19 (Fri) at 07:35:28 + (+), C. L. Martinez wrote: : :b) OpenBSD/amd64: set up vio flags to 0x02 : : The man page for vio(4) says: : Setting the bit 0x2 in the flags disables the RingEventIndex feature. : This can be tried as a workaround for possible bugs in host : implementations of vio at the cost of slightly reduced performance. : : What bugs in the host implementation, which versions are affected, how : bad is the performance hit, and should this be the default? : : :Yep, sorry Peter, you are right: OpenBSD 5.6 release. : I more mean: which versions on the host will trigger this behaviour. KVM hosts?? CentOS 6.5 and CentOS 6.6, both x86_64. And OpenBSD 5.6/amd64
bgpd.conf macros on 5.5 and up
From 5.5 and up it looks like bgpd macros are broken.
ton...@obc2.rad$ cat bgpd.conf
good={ 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }
AS 65001
deny from any prefix { $good }
ton...@obc2.rad$
On 5.4:
ton...@obc2.rad$ bgpd -f bgpd.conf
-n
configuration OK
ton...@obc2.rad$
On 5.5:
ton...@obc0.rad$ bgpd -f bgpd.conf -nv
good = { 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }
bgpd.conf:3: syntax error
ton...@obc0.rad$
On 5.6 snapshot:
tonsar@obc1$ uname -mrsv
OpenBSD 5.6 GENERIC.MP#701 amd64
tonsar@obc1$ bgpd -f bgpd.conf -nv
good = { 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }
bgpd.conf:3: syntax error
tonsar@obc1$
Also, the example from bgpd.conf man page fails on 5.4-5.6.
I haven't tested on 5.3 and lower.
On 5.6 snapshot:
tonsar@obc1$ uname -mrsv
OpenBSD 5.6 GENERIC.MP#701 amd64
tonsar@obc1$ cat bgpd.conf-2
good={ 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }
bad={ 224.0.0.0/4 prefixlen = 4, 240.0.0.0/4 prefixlen = 4 }
ugly={ 127.0.0.1/8, 169.254.0.0/16 }
# global configuration
AS 65001
deny from any prefix { $good $bad $ugly }
tonsar@obc1$ bgpd -f bgpd.conf-2 -nv
good = { 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }
bad = { 224.0.0.0/4 prefixlen = 4, 240.0.0.0/4 prefixlen = 4 }
ugly = { 127.0.0.1/8, 169.254.0.0/16 }
bgpd.conf-2:6: syntax error
tonsar@obc1$
Regards Tony
Re: About special configs to do in OpenBSD for KVM environments
19 дек. 2014 г. 11:53 полÑзоваÑÐµÐ»Ñ Jiri B ji...@devio.us напиÑал: On Fri, Dec 19, 2014 at 11:57:19AM +0400, Vadim Zhukov wrote: I have few 5.5/amd64 in production under CentOS 6.2, without either direct or indirect access to Internet. No problems so far, no adjustments on OpenBSD side. Time to upgrade hosts? It's time of 6.6 now :) Ouch. How did it happen that I missed 5 years??? More seriously - yes, of course. Just no hurry needed there. -- Vadim Zhukov
Re: ospf point to point network
On 18/12/14 22:38, Stuart Henderson wrote: On 2014-12-17, Kapetanakis Giannis bil...@edu.physics.uoc.gr wrote: Hi, I'd like to ask if point-to-point support has been added in ospfd. I've read this http://marc.info/?l=openbsd-miscm=136580208222751w=2 but I cant seem to find relevant entries in the source tree so probably is still out? regards, Giannis No, diff didn't work so it wasn't added. Thanks for the update. G
Re: xfce4/apm Power-Management falls off a cliff
Hi Jason being the author of GNUstep's batmon and being owner of several laptops and having developed and tested on them, I have some un-authoritative information. Jason Adams wrote: Upon, pulling the plug from the wall on my older Toshiba Satellite (which has a new-ish battery) both xfce4 and apm agree while reporting declining battery power down to about 85% The problem here is new-ish. The behaviour you describe is typical of a dying battery and/or a screwed-up power management chip. Just some questions: 1) define newish. How old and if you know how many cycles? 2) Is it original or a genuine replacement anything which has 6 months or 50-100 cycles is not new anymore. Good batteries (which might be luck, quality of elements, how well they are paired and other factors) will work and perhas age very gracefully for the years to come. Bad batteries start showing jumps. I think this is most often due to elements being mismatched. Usually manufacturer batteries are better than cheap ones from China, but I also had the opposite experience! then both fall off a cliff and immediately indicate 8% and start warning about imminent battery exhaustion. 85% to 8% in the blink of an eye. And nothing in between. If I plug it back in, let it charge for a 10 minutes, it will be back up around 24%. If I again unplug, it will drop roughly in a linear fashion. with no sudden drops. This seems like a bug in what ever apm and xfce4 use to obtain readings. Any clue where I should start looking for this? Do you have a way of knowing the battery status without using the OS? For example, you might have a battery led that starts blinking or gets orange at about 5%. Will it turn on after say 10 minutes apm reports your battery to 8%? Most probably it is then not an OS/apm/software bug. Perhaps your battery has LEDs showing its charge or you can access it from the bios. E.g. certain DELL laptops allow that (thus reboot and check). When it is 8%, how long can it actually run? then what happens BIP or a LED turns on? Sadly, I did not port yet batmon.app to ACPI on OpenBSD so it will just say the same thing as apm does, so no cell health data info. Riccardo
Re: OpenBSD sound system
Alfonso Sabato Siciliano wrote: hello, I am willing to know the sound system of OpenBSD, so I started to read the manpages. I summarized with a graph below, it is right? I'm not the expert but it seems about right to me. I think you could draw two additional connections for raw device access. One from sio_open(3) to audio(4) (rsnd) and one from mio_open(3) to midi(4) (rmidi).
Re: OpenBSD sound system
On Fri, Dec 19, 2014 at 04:28:38AM +0100, Alfonso Sabato Siciliano wrote: hello, I am willing to know the sound system of OpenBSD, so I started to read the manpages. I summarized with a graph below, it is right? Yes this is right. Note that pograms can bypass sndiod seamlessly and use sio_xxx and mio_xxx functions to connect directly to the audio(4) and midi(4) layers. This is determined at runtime by sio_open() and mio_open() arguments and/or environment variables.
Re: Dell R630 high interrupts on acpi0
On Thu, Dec 18, 2014 at 11:14:54PM +0100, Frederic Nowak wrote:
Hi!
The diff for extracting memory ranges from ACPI was obviously not tested
with ACPI disabled...so we definitely have to check if the values in
pcimem_range make some sense. The diff below now uses the old values in
case ACPI is disabled or does not return valid values.
I hope this is somewhat interesting for someone else as well :)
Please let me know if this is just noise or if there is anything else I
am missing.
This looks like the right direction, except I think we only really want to use
the ACPI range information to add new ranges to the existing one that covers
the 36-bit address space, rather than relying on it for everything. No point
relying on the ACPI stuff being correct if we don't need to.
I hacked this around a bit today and ended up with the diff below. This only
deals with ranges outside the 36-bit space, so it makes no difference on most
machines, and on the r630 that needs it, it adds two ranges,
0x0300 to 0x033F and 0x0340 to
0x037F.
Index: arch/amd64/pci/pci_machdep.c
===
RCS file: /cvs/src/sys/arch/amd64/pci/pci_machdep.c,v
retrieving revision 1.60
diff -u -p -r1.60 pci_machdep.c
--- arch/amd64/pci/pci_machdep.c16 Dec 2014 23:13:20 - 1.60
+++ arch/amd64/pci/pci_machdep.c19 Dec 2014 12:54:44 -
@@ -90,12 +90,17 @@
#include dev/pci/ppbreg.h
#include ioapic.h
+#include acpi.h
#if NIOAPIC 0
#include machine/i82093var.h
#include machine/mpbiosvar.h
#endif
+#if NACPI 0
+#include dev/acpi/acpivar.h
+#endif
+
/*
* Memory Mapped Configuration space access.
*
@@ -622,17 +627,13 @@ pci_init_extents(void)
* here. As long as vendors continue to support
* 32-bit operating systems, we should never see BARs
* outside that region.
-*
-* Dell 13G servers have important devices outside the
-* 36-bit address space. Until we can extract the address
-* ranges from ACPI, expand the allowed range to suit.
*/
pcimem_ex = extent_create(pcimem, 0, 0xUL,
M_DEVBUF, NULL, 0, EX_NOWAIT);
if (pcimem_ex == NULL)
return;
- extent_alloc_region(pcimem_ex, 0x400UL,
- 0xfc00UL, EX_NOWAIT);
+ extent_alloc_region(pcimem_ex, 0x10UL,
+ 0xfff0UL, EX_NOWAIT);
for (bmp = bios_memmap; bmp-type != BIOS_MAP_END; bmp++) {
/*
@@ -657,6 +658,14 @@ pci_init_extents(void)
/* Take out the video buffer area and BIOS areas. */
extent_alloc_region(pcimem_ex, IOM_BEGIN, IOM_SIZE,
EX_CONFLICTOK | EX_NOWAIT);
+
+#if NACPI 0
+ /*
+* Free up any regions outside the 36-bit address space
+* specified via ACPI.
+*/
+ acpi_pciroots_extents(pcimem_ex, 0x10UL);
+#endif
}
if (pcibus_ex == NULL) {
@@ -665,7 +674,6 @@ pci_init_extents(void)
}
}
-#include acpi.h
#if NACPI 0
void acpi_pci_match(struct device *, struct pci_attach_args *);
pcireg_t acpi_pci_min_powerstate(pci_chipset_tag_t, pcitag_t);
Index: dev/acpi/acpivar.h
===
RCS file: /cvs/src/sys/dev/acpi/acpivar.h,v
retrieving revision 1.79
diff -u -p -r1.79 acpivar.h
--- dev/acpi/acpivar.h 8 Dec 2014 07:12:37 - 1.79
+++ dev/acpi/acpivar.h 19 Dec 2014 12:54:44 -
@@ -47,6 +47,7 @@ extern u_int8_t acpi_lapic_flags[LAPIC_M
struct klist;
struct acpiec_softc;
struct acpipwrres_softc;
+struct extent;
struct acpivideo_softc {
struct device sc_dev;
@@ -357,6 +358,7 @@ int acpi_acquire_glk(uint32_t *);
intacpi_release_glk(uint32_t *);
void acpi_pciroots_attach(struct device *, void *, cfprint_t);
+void acpi_pciroots_extents(struct extent *, u_int64_t);
#endif
Index: dev/acpi/amltypes.h
===
RCS file: /cvs/src/sys/dev/acpi/amltypes.h,v
retrieving revision 1.40
diff -u -p -r1.40 amltypes.h
--- dev/acpi/amltypes.h 7 Sep 2012 19:19:59 - 1.40
+++ dev/acpi/amltypes.h 19 Dec 2014 12:54:44 -
@@ -346,6 +346,12 @@ struct aml_value {
#define aml_pkglen(v) ((v)-length)
#define aml_pkgval(v,i)((v)-v_package[(i)])
+struct acpi_pci_range {
+ SLIST_ENTRY(acpi_pci_range) next;
+ uint64_tbase;
+ uint64_tlen;
+};
+
struct acpi_pci {
TAILQ_ENTRY(acpi_pci) next;
@@ -362,6 +368,8 @@ struct acpi_pci {
int _s3w;
int
Re: Dell R630 high interrupts on acpi0
Date: Fri, 19 Dec 2014 23:41:56 +1000
From: Jonathan Matthew jonat...@d14n.org
On Thu, Dec 18, 2014 at 11:14:54PM +0100, Frederic Nowak wrote:
Hi!
The diff for extracting memory ranges from ACPI was obviously not tested
with ACPI disabled...so we definitely have to check if the values in
pcimem_range make some sense. The diff below now uses the old values in
case ACPI is disabled or does not return valid values.
I hope this is somewhat interesting for someone else as well :)
Please let me know if this is just noise or if there is anything else I
am missing.
This looks like the right direction, except I think we only really want to use
the ACPI range information to add new ranges to the existing one that covers
the 36-bit address space, rather than relying on it for everything. No point
relying on the ACPI stuff being correct if we don't need to.
I hacked this around a bit today and ended up with the diff below. This only
deals with ranges outside the 36-bit space, so it makes no difference on most
machines, and on the r630 that needs it, it adds two ranges,
0x0300 to 0x033F and 0x0340 to
0x037F.
This is going in the right direction. The way I designed things
though was that the acpi code would build up the complete extent
purely from information provided by _CRS, and set pcimem_ex before
pci_init_extents() gets called.
Index: arch/amd64/pci/pci_machdep.c
===
RCS file: /cvs/src/sys/arch/amd64/pci/pci_machdep.c,v
retrieving revision 1.60
diff -u -p -r1.60 pci_machdep.c
--- arch/amd64/pci/pci_machdep.c 16 Dec 2014 23:13:20 - 1.60
+++ arch/amd64/pci/pci_machdep.c 19 Dec 2014 12:54:44 -
@@ -90,12 +90,17 @@
#include dev/pci/ppbreg.h
#include ioapic.h
+#include acpi.h
#if NIOAPIC 0
#include machine/i82093var.h
#include machine/mpbiosvar.h
#endif
+#if NACPI 0
+#include dev/acpi/acpivar.h
+#endif
+
/*
* Memory Mapped Configuration space access.
*
@@ -622,17 +627,13 @@ pci_init_extents(void)
* here. As long as vendors continue to support
* 32-bit operating systems, we should never see BARs
* outside that region.
- *
- * Dell 13G servers have important devices outside the
- * 36-bit address space. Until we can extract the address
- * ranges from ACPI, expand the allowed range to suit.
*/
pcimem_ex = extent_create(pcimem, 0, 0xUL,
M_DEVBUF, NULL, 0, EX_NOWAIT);
if (pcimem_ex == NULL)
return;
- extent_alloc_region(pcimem_ex, 0x400UL,
- 0xfc00UL, EX_NOWAIT);
+ extent_alloc_region(pcimem_ex, 0x10UL,
+ 0xfff0UL, EX_NOWAIT);
for (bmp = bios_memmap; bmp-type != BIOS_MAP_END; bmp++) {
/*
@@ -657,6 +658,14 @@ pci_init_extents(void)
/* Take out the video buffer area and BIOS areas. */
extent_alloc_region(pcimem_ex, IOM_BEGIN, IOM_SIZE,
EX_CONFLICTOK | EX_NOWAIT);
+
+#if NACPI 0
+ /*
+ * Free up any regions outside the 36-bit address space
+ * specified via ACPI.
+ */
+ acpi_pciroots_extents(pcimem_ex, 0x10UL);
+#endif
}
if (pcibus_ex == NULL) {
@@ -665,7 +674,6 @@ pci_init_extents(void)
}
}
-#include acpi.h
#if NACPI 0
void acpi_pci_match(struct device *, struct pci_attach_args *);
pcireg_t acpi_pci_min_powerstate(pci_chipset_tag_t, pcitag_t);
Index: dev/acpi/acpivar.h
===
RCS file: /cvs/src/sys/dev/acpi/acpivar.h,v
retrieving revision 1.79
diff -u -p -r1.79 acpivar.h
--- dev/acpi/acpivar.h8 Dec 2014 07:12:37 - 1.79
+++ dev/acpi/acpivar.h19 Dec 2014 12:54:44 -
@@ -47,6 +47,7 @@ extern u_int8_t acpi_lapic_flags[LAPIC_M
struct klist;
struct acpiec_softc;
struct acpipwrres_softc;
+struct extent;
struct acpivideo_softc {
struct device sc_dev;
@@ -357,6 +358,7 @@ int acpi_acquire_glk(uint32_t *);
int acpi_release_glk(uint32_t *);
void acpi_pciroots_attach(struct device *, void *, cfprint_t);
+void acpi_pciroots_extents(struct extent *, u_int64_t);
#endif
Index: dev/acpi/amltypes.h
===
RCS file: /cvs/src/sys/dev/acpi/amltypes.h,v
retrieving revision 1.40
diff -u -p -r1.40 amltypes.h
--- dev/acpi/amltypes.h 7 Sep 2012 19:19:59 - 1.40
+++ dev/acpi/amltypes.h 19 Dec 2014 12:54:44 -
@@ -346,6 +346,12 @@ struct aml_value {
#define aml_pkglen(v)
Re: OpenBSD sound system
I have update the graph about the sound system On Fri, 19 Dec 2014 14:38:49 +0100 Alexandre Ratchov a...@caoua.org wrote: Yes this is right. Note that pograms can bypass sndiod seamlessly and use sio_xxx and mio_xxx functions to connect directly to the audio(4) and midi(4) layers. This is determined at runtime by sio_open() and mio_open() arguments and/or environment variables. and I have added the border between userspace and kernelspace (I hope it is right now). |--| |--| |--| | app1 | | app2 | | appN | |--| |--| |--| || | \|/ \|/ \|/ |---| |sndio.h| | sio_open(3)/mio_open(3) | | interface to audio devices and MIDI streams | |---| || | | \|/ | ||---| | ||sndiod(1) | | || audio/midi server | | ||---| | ||| | User ||| | space - ||| | Kernel ||| | space \|/ \|/ \|/ \|/ || |-| | audio(4) | | midi(4) | | device-independent | | raw device | | driver layer | | independent | || | interface | | |-| | | \|/ \|/ |-| |device dependent driver | | (azalia(4), ac97(4), ...) | |-| | \|/ |--| | [audio][MIDI] | | | | Hardware| |--| Regards Alfonso -- Alfonso Sabato Siciliano alfi...@gmail.com
Re: DigitalOcean's BSD debut is FreeBSD only
Using any OS on top of any virtual machine is like scratching your left year with your right leg as human. What is the noble purpose of doing that?
Re: DigitalOcean's BSD debut is FreeBSD only
On Fri, Dec 19, 2014 at 8:45 AM, Mihai Popescu mih...@gmail.com wrote: Using any OS on top of any virtual machine is like scratching your left year with your right leg as human. What is the noble purpose of doing that? Gee whiz. How incredibly insightful.
Problem getting or finding core dumps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I've got a problem with a piece of non-BSD software that I'm running on my OpenBSD 5.4 system. I'm not looking to you guys for help with it at all; I'm working closely with the developers on it. However, it turns out that it's not at a stage where it's receiving almost daily segfaults knocking it out of the active processes. Strangely enough, though I'm able to get .core files from many of the related programs that are along with it, when bad things happen to them, this one primary daemon won't leave a core file. I've checked my ulimits, specifically 'ulimit -u' under the user that this is running as, and I'm only finding that it's 'unlimited'. As far as I know, that means that I _should_ be getting a core file somewhere. The process name is 'sbbs', and I've searched (as root) my entire filesystem, not just the small separate filesystem that this resides on, doing a general search, grepping for 'core', and then searching through it for 'sbbs', and I'm not finding the file that I need anywhere. The developers do not have any OpenBSD machines available for work on this software, but they do want to help. Getting that stack trace is the only thing that might get around any issues, at this point, or point in the right direction for where to go with things. I know OpenBSD fairly well, but when it comes to kernel internals and things along the lines of core debugging and [a lot of the] ulimits, I'm still somewhat in the dark. Can anybody tell me if I'm missing anything obvious, and what I might be able to do to force a core dump next time this guy segfaults? I really need to get my hands on that stack and I'm clueless here. I use this package as a fully featured communications hub for myself and several other users, and short of the kludgy solution of running a cron script job that checks for the process, verifies its health, and respawns a new process if necessary every few minutes, I don't know what to do. I'd much handle things the right way, and learn a bit more about my favorite OS along the way. Any help is appreciated, feel free to get ahold of me any which way; telnet to tinfoil.synchro.net if you'd like to see the small text portion of the system in action. ;) All of the other provided services in the suite are temporarily blocked by the firewall due to my not having admin privileges on this network. -Damon Getsman - -- Opinions expressed are not necessarily those of the owner of this corporeal, rotting porksuit, nor its fiat-currency waving handlers. - -Damo iF4EAREIAAYFAlSUk+kACgkQerX40lUXtCPACAD7By2Fpp222QHyp0Iu2TAD+p71 79wp9Duc+W4/cxkpNPEBAJeFLuJd/PJHgXQht4ffcHg4QXSoElgPK7L/LjF2XnCI =Lnqk -END PGP SIGNATURE-
Re: Problem getting or finding core dumps
I've checked my ulimits, specifically 'ulimit -u' under the user that this is running as, and I'm only finding that it's 'unlimited'. As far as I know, that means that I _should_ be getting a core file somewhere. The process name is 'sbbs', and I've searched (as root) my entire filesystem, not just the small separate filesystem that this resides on, doing a general search, grepping for 'core', and then searching through it for 'sbbs', and I'm not finding the file that I need anywhere. Probably a uid/gid changing daemon. % man core ... CAVEATS Programs which are started with either the set-user-ID or set-group-ID bits set, or which change their UID or GID after starting, will normally not dump core. This is to prevent sensitive information from inadvertently ending up on disk. This behaviour can be changed (for debugging purposes) by changing the kern.nosuidcoredump sysctl(3) variable to the right settings. % man sysctl ... To place core dumps from issetugid(2) programs (in this example bgpd(8)) into a safe place for debugging purposes: # mkdir /var/crash/bgpd # chmod 700 /var/crash/bgpd # sysctl kern.nosuidcoredump=3
Re: Problem getting or finding core dumps
Hi Damo, Damo Gets wrote on Fri, Dec 19, 2014 at 01:08:57PM -0800: I've got a problem with a piece of non-BSD software that I'm running on my OpenBSD 5.4 system. I'm not looking to you guys for help with it at all; I'm working closely with the developers on it. However, it turns out that it's not at a stage where it's receiving almost daily segfaults knocking it out of the active processes. Strangely enough, though I'm able to get .core files from many of the related programs that are along with it, when bad things happen to them, this one primary daemon won't leave a core file. [...] Just guessing, but it sounds a bit like that primary daemon does privilege dropping (which would indeed be reasonable for a daemon). In that case, did you allow it to dump core? The sysctl(8) manual contains a very brief entry and an example, sysctl(3) some more information, look for core in both. In case you are forced to loosen these settings on a production system, you might wish to loosen them as little as possible, for example creating a directory /var/crash/sbbs, granting no unnecessary permissions on it to anyone, and run with sysctl kern.nosuidcoredump=3 Yours, Ingo
Re: clementine stutters when playing local files
Marko CupaÄ marko.cu...@mimar.rs hat am 18. Dezember 2014 um 16:41 geschrieben: What remains unanswered is why my 50⬠SSD gives worse throughput than 5⬠wifi adapter, but let's leave it for another thread. The problem is not thruput but latency. Regarding thruput, a Mp3 file anywhere today is like a raindrop in the ocean. Clementine may have special code which expects the network to be slow and flaky, code which helps in keeping playback smooth over the network, code which does not run when acessing local files. From what thou write, it seems indeed, that thy local filesystem has a problem.
Re: Dell R630 high interrupts on acpi0
On 17.12.2014. 6:34, Philip Guenther wrote: Uh, ACPI *requires* that C1 exist. The halt instruction is defined as entering C1, so not having C1 would mean your CPU lacks a basic manadatory ia32 instruction. Hopefully the BIOS docs explain that you're just disabling deep C-states or something like that. If not, yell at the company that made it. With the exception of C1E, I wouldn't tell a BIOS to disable C-states unless it was causing the OS to have a problem or you're actively trying to use the computer to heat your house. C1E is a cross between C1 and C3; the issue is that bugs in multiple early hardware implementations mean it'll behave poorly depending on exactly how the OS handles it. This is something to test...and then test again with each release you install... Thank you, this is very informative. I have disabled C states because I have seen ifq.drops and netlivelocks when I run udp tcpbench over ix interface and C-states are enabled. This is between two Dell R620. With Dell R630 I have bigger problems so i can't test them right now. tcpbench client sends around 350kpps for 20s tcpbench server gets around 212kpps tcpbench udp server drops: Without C states and C1E: net.inet.ip.ifq.maxlen=2048 net.inet.ip.ifq.drops=0 kern.netlivelocks=3 With C states and C1E (DAPC): net.inet.ip.ifq.maxlen=2048 net.inet.ip.ifq.drops=19143 kern.netlivelocks=86 so I explained to myself that C states are bad for packet bursts and these boxes will be uber high speed firewalls :) and of course after reading you mail I only disable C1E and everything is fine. With C states and without C1E net.inet.ip.ifq.maxlen=2048 net.inet.ip.ifq.drops=0 kern.netlivelocks=3 Monitor/Mwait - Disabled I would suggest leaving that on. We ain't using it *right now*, but, well, the source tree on my laptop is, and more than ever. :-) mwait is enabled :)
Re: mouse spontaneously detaches in console
We've been having a similar issue with keyboards on 5.1 with no X, and when we upgraded to 5.5 recently we seem to still have it. All HP hardware about 3 years old. You have to unplug the keyboard and plug it into a different port, then return it back to the original to get it back. Sometimes you have to walk around to the other side of the rack to do it. Very frustrating ... After the holidays I'll get a dmesg with more details
Best way to upgrade latest OpenBSD version
I know that one of the goals of OpenBSD dev team is launch a new version every six months. I'm new here, and, I want to know, what is the best way to update OpenBSD? There is an automated way to do it? Thanks -- Ignacio Ocampo Millán
Re: Best way to upgrade latest OpenBSD version
On Fri, Dec 19, 2014 at 9:51 PM, Ignacio Ocampo naf...@gmail.com wrote: I know that one of the goals of OpenBSD dev team is launch a new version every six months. I'm new here, and, I want to know, what is the best way to update OpenBSD? There is an automated way to do it? Thanks -- Ignacio Ocampo Millán Read the upgrade guide: http://www.openbsd.org/faq/upgrade56.html Run the installer, choose the upgrade option, reboot, run sysmerge, I reboot again, pkg_add -u. I think it can be automated with PXE boot, site.tgz and some scripting, but I've not needed to. If you're new to OpenBSD, read through the FAQ. Read the man page of any command or config file mentioned. Read, read, read. Tim.
