Re: Best way to upgrade latest OpenBSD version
On Fri, Dec 19, 2014 at 9:51 PM, Ignacio Ocampo 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.
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: 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
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: clementine stutters when playing local files
"Marko CupaÄ" 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: 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: 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
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: DigitalOcean's BSD debut is FreeBSD only
On Fri, Dec 19, 2014 at 8:45 AM, Mihai Popescu 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.
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: OpenBSD sound system
I have update the graph about the sound system On Fri, 19 Dec 2014 14:38:49 +0100 Alexandre Ratchov 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
Re: Dell R630 high interrupts on acpi0
> Date: Fri, 19 Dec 2014 23:41:56 +1000 > From: Jonathan Matthew > > 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 > > #include "ioapic.h" > +#include "acpi.h" > > #if NIOAPIC > 0 > #include > #include > #endif > > +#if NACPI > 0 > +#include > +#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 a
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 #include "ioapic.h" +#include "acpi.h" #if NIOAPIC > 0 #include #include #endif +#if NACPI > 0 +#include +#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 _s4d; int
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: 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: 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: ospf point to point network
On 18/12/14 22:38, Stuart Henderson wrote: On 2014-12-17, Kapetanakis Giannis 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-misc&m=136580208222751&w=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: About special configs to do in OpenBSD for KVM environments
19 дек. 2014 г. 11:53 полÑзоваÑÐµÐ»Ñ "Jiri B" напиÑал: > > 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
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
On Fri, Dec 19, 2014 at 8:04 AM, Peter Hessler 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 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
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 2014 Dec 19 (Fri) at 08:01:00 + (+), C. L. Martinez wrote: :On Fri, Dec 19, 2014 at 7:51 AM, Peter Hessler 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 7:51 AM, Peter Hessler 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