Re: acpicpu _CST handling for mwait
On Sun, Dec 14, 2014 at 02:00:08PM -0800, Philip Guenther wrote: Some time ago, I had added support for using the MWAIT instruction in the idle loop. Various people found that made their boxes run hot, to the point that several developers diked it out of their own builds; I've committed one of those yesteryad pending a proper fix. So, to start on that: the diff below expands our handling of the ACPI _CST values to detect the Intel functional fixed hardware register type for C-state control and report it in the acpicpu dmesg lines, ala: acpicpu0 at acpi0: C3, C2, C1(mwait), PSS I have diff on top of this that adds callbacks and amd64 bits to properly notify CPUs of the C1 type and thus enable mwait use if the _CST specifies it, but let's first see if the _CST output matches our expectations. IN PARTICULAR, IF YOUR BOX RAN HOT WITH MWAIT, please run with this diff report your dmesg! Since mwait was enabled, my laptop ran with about 5C-10C more than before (I always run with `apm -L' except when I am impatient with something big to compile). As requested, a dmesg with your diff. Below there's the diff to the dmesg of a kernel compiled from the same sources, but without your patch. OpenBSD 5.6-current (GENERIC.MP) #319: Mon Dec 15 07:11:49 CET 2014 t...@miraculix.home:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2634596352 (2512MB) avail mem = 2560667648 (2442MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe (37 entries) bios0: vendor Apple Inc. version MB21.88Z.00A5.B07.0706270922 date 06/27/07 bios0: Apple Inc. MacBook2,1 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP HPET APIC MCFG ASF! SBST ECDT SSDT SSDT SSDT acpi0: wakeup devices ADP1(S3) LID0(S3) PXS1(S4) PXS2(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB7(S3) EC__(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz, 1995.35 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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF cpu0: 4MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 166MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz, 1994.99 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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF cpu1: 4MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 1 acpimcfg0 at acpi0 addr 0xf000, bus 0-255 acpiec0 at acpi0 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (RP01) acpiprt2 at acpi0: bus 2 (RP02) acpiprt3 at acpi0: bus 3 (PCIB) acpicpu0 at acpi0: C3, C2, C1(mwait), PSS acpicpu1 at acpi0: C3, C2, C1(mwait), PSS acpiac0 at acpi0: AC unit online acpibtn0 at acpi0: LID0 acpibtn1 at acpi0: PWRB acpibtn2 at acpi0: SLPB acpibat0 at acpi0: BAT0 model 15253732082930497 type 15253732284385612 oem 15253732284387396 acpivideo0 at acpi0: GFX0 cpu0: Enhanced SpeedStep 1995 MHz: speeds: 2000, 1833, 1667, 1500, 1333, 1000 MHz memory map conflict 0x9ef0/0x10 memory map conflict 0x9f00/0x100 memory map conflict 0xf00f8000/0x1000 memory map conflict 0xfed1c000/0x4000 memory map conflict 0xfffb/0x3 pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 Intel 82945GM Host rev 0x03 vga1 at pci0 dev 2 function 0 Intel 82945GM Video rev 0x03 intagp0 at vga1 agp0 at intagp0: aperture at 0xa000, size 0x1000 inteldrm0 at vga1 drm0 at inteldrm0 drm: Setting output timings on SDVOB failed inteldrm0: 1280x800 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) Intel 82945GM Video rev 0x03 at pci0 dev 2 function 1 not configured vendor Intel, unknown product 0x27a3 (class DASP subclass Time and Frequency, rev 0x03) at pci0 dev 7 function 0 not configured azalia0 at pci0 dev 27 function 0 Intel 82801GB HD Audio rev 0x02: msi azalia0: codecs: Sigmatel STAC9220/1 audio0 at azalia0 ppb0 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x02: msi pci1 at ppb0 bus 1 mskc0 at pci1 dev 0 function 0 Marvell Yukon 88E8053 rev 0x22, Yukon-2 EC rev. A3 (0x2): apic 1 int 16 msk0 at mskc0 port A: address 00:19:e3:38:6c:56 eephy0 at msk0 phy 0: 88E Gigabit PHY, rev. 2 ppb1 at pci0 dev 28 function 1 Intel 82801GB PCIE rev 0x02: msi pci2 at ppb1 bus 2 athn0 at pci2 dev 0 function 0 Atheros AR5418 rev 0x01: apic 1 int 17
intro(2) update regarding file names
As there are no file name restrictions for ASCII characters, I assume this requirement might be outdated. Is that correct? Index: intro.2 === RCS file: /cvs/src/lib/libc/sys/intro.2,v retrieving revision 1.53 diff -u -p -r1.53 intro.2 --- intro.2 10 Dec 2014 07:18:44 - 1.53 +++ intro.2 15 Dec 2014 11:11:06 - @@ -595,12 +595,8 @@ Names consisting of up to 255 characters may be used to name an ordinary file, special file, or directory. .Pp -These characters may be selected from the set of all -.Tn ASCII -character -excluding 0 (NUL) and the -.Tn ASCII -code for +These characters may be arbitrary eight-bit values, +excluding 0 (NUL) and the ASCII code for .Ql \/ (slash). .Pp @@ -615,7 +611,7 @@ file names because of the special meanin by the shell. .Pp Note also that -.Pq Dv NAME_MAX +.Dv NAME_MAX is an upper limit fixed by the kernel, meant to be used for sizing buffers. Some filesystems may have additional restrictions. These can be queried using @@ -623,8 +619,7 @@ These can be queried using and .Xr fpathconf 2 . .It Path Name -A path name is a -.Tn NUL Ns -terminated +A path name is a NUL-terminated character string starting with an optional slash .Ql \/ ,
Re: intro(2) update regarding file names
Forgot to mention - the sentence I changed is based on FreeBSD version of the same manpage. On Mon, Dec 15, 2014 at 01:22:21PM +0200, Kaspars Bankovskis wrote: As there are no file name restrictions for ASCII characters, I assume this requirement might be outdated. Is that correct? Index: intro.2 === RCS file: /cvs/src/lib/libc/sys/intro.2,v retrieving revision 1.53 diff -u -p -r1.53 intro.2 --- intro.2 10 Dec 2014 07:18:44 - 1.53 +++ intro.2 15 Dec 2014 11:11:06 - @@ -595,12 +595,8 @@ Names consisting of up to 255 characters may be used to name an ordinary file, special file, or directory. .Pp -These characters may be selected from the set of all -.Tn ASCII -character -excluding 0 (NUL) and the -.Tn ASCII -code for +These characters may be arbitrary eight-bit values, +excluding 0 (NUL) and the ASCII code for .Ql \/ (slash). .Pp @@ -615,7 +611,7 @@ file names because of the special meanin by the shell. .Pp Note also that -.Pq Dv NAME_MAX +.Dv NAME_MAX is an upper limit fixed by the kernel, meant to be used for sizing buffers. Some filesystems may have additional restrictions. These can be queried using @@ -623,8 +619,7 @@ These can be queried using and .Xr fpathconf 2 . .It Path Name -A path name is a -.Tn NUL Ns -terminated +A path name is a NUL-terminated character string starting with an optional slash .Ql \/ ,
avoid kdump crash on localtime() failure
So now time is printed by default afl has found that time_t values
such as -9223372035438150153 will cause localtime() to fail and
return NULL. strftime() can't deal with this and will at some point
dereference tm without checking if it is NULL causing a crash.
Index: ktrstruct.c
===
RCS file: /cvs/src/usr.bin/kdump/ktrstruct.c,v
retrieving revision 1.8
diff -u -p -r1.8 ktrstruct.c
--- ktrstruct.c 15 Dec 2014 01:48:54 - 1.8
+++ ktrstruct.c 15 Dec 2014 13:56:03 -
@@ -146,8 +146,10 @@ print_time(time_t t, int relative, int h
if (!relative) {
tm = localtime(t);
- (void)strftime(timestr, sizeof(timestr), TIME_FORMAT, tm);
- printf(\%s\, timestr);
+ if (tm != NULL) {
+ (void)strftime(timestr, sizeof(timestr), TIME_FORMAT,
tm);
+ printf(\%s\, timestr);
+ }
}
}
Re: avoid kdump crash on localtime() failure
On Tue, Dec 16, 2014 at 01:04:05AM +1100, Jonathan Gray wrote:
So now time is printed by default afl has found that time_t values
such as -9223372035438150153 will cause localtime() to fail and
return NULL. strftime() can't deal with this and will at some point
dereference tm without checking if it is NULL causing a crash.
I'd pefer to print the time_t value if it cannot be converted.
-Otto
Index: ktrstruct.c
===
RCS file: /cvs/src/usr.bin/kdump/ktrstruct.c,v
retrieving revision 1.8
diff -u -p -r1.8 ktrstruct.c
--- ktrstruct.c 15 Dec 2014 01:48:54 - 1.8
+++ ktrstruct.c 15 Dec 2014 13:56:03 -
@@ -146,8 +146,10 @@ print_time(time_t t, int relative, int h
if (!relative) {
tm = localtime(t);
- (void)strftime(timestr, sizeof(timestr), TIME_FORMAT, tm);
- printf(\%s\, timestr);
+ if (tm != NULL) {
+ (void)strftime(timestr, sizeof(timestr), TIME_FORMAT,
tm);
+ printf(\%s\, timestr);
+ }
}
}
Re: avoid kdump crash on localtime() failure
On Mon, Dec 15, 2014 at 03:21:24PM +0100, Otto Moerbeek wrote:
On Tue, Dec 16, 2014 at 01:04:05AM +1100, Jonathan Gray wrote:
So now time is printed by default afl has found that time_t values
such as -9223372035438150153 will cause localtime() to fail and
return NULL. strftime() can't deal with this and will at some point
dereference tm without checking if it is NULL causing a crash.
I'd pefer to print the time_t value if it cannot be converted.
ignore this, I was looking at old src.
-Otto
Index: ktrstruct.c
===
RCS file: /cvs/src/usr.bin/kdump/ktrstruct.c,v
retrieving revision 1.8
diff -u -p -r1.8 ktrstruct.c
--- ktrstruct.c 15 Dec 2014 01:48:54 - 1.8
+++ ktrstruct.c 15 Dec 2014 13:56:03 -
@@ -146,8 +146,10 @@ print_time(time_t t, int relative, int h
if (!relative) {
tm = localtime(t);
- (void)strftime(timestr, sizeof(timestr), TIME_FORMAT, tm);
- printf(\%s\, timestr);
+ if (tm != NULL) {
+ (void)strftime(timestr, sizeof(timestr), TIME_FORMAT,
tm);
+ printf(\%s\, timestr);
+ }
}
}
Re: avoid kdump crash on localtime() failure
On Mon, Dec 15, 2014 at 6:04 AM, Jonathan Gray j...@jsg.id.au wrote: So now time is printed by default afl has found that time_t values such as -9223372035438150153 will cause localtime() to fail and return NULL. strftime() can't deal with this and will at some point dereference tm without checking if it is NULL causing a crash. ok guenther@
lock and term in cwm menu
Revision 1.178 of xenocara/app/cwm/conf.c made lock and term always show at top of application menu. I don't see a way to remove this. Will this be permanent behavior now? -- Martin
Re: lock and term in cwm menu
On Mon, Dec 15, 2014 at 07:36:41PM +, mar...@martinbrandenburg.com wrote: Revision 1.178 of xenocara/app/cwm/conf.c made lock and term always show at top of application menu. I don't see a way to remove this. Will this be permanent behavior now? -- Martin I see this too, my brain simply can't cope and I've accidentally locked my session more than once! :-) -Bryan.
Re: UPDATE: freetype-2.5.4
On Mon, Dec 15, 2014 at 04:32:47AM -0700, David Coppa wrote: Hi all! An update to freetype-2.5.4, released on 2014-12-06. This release also contains a fix for vulnerability CVE-2014-2240 in the CFF driver. abi-compliance-checker reported 2.5.4 as being incompatible with 2.5.3, thus I've bumped shlib's major. Tested in a full xenocara build. It would be nice to have it in a ports bulk build... Given that it doesn't break ports, ok matthieu@ -- Matthieu Herrb
Re: Binary code patching and paravirtualization
On Thu, 11 Dec 2014, Mark Kettenis wrote:
From: Alexey Suslikov alexey.susli...@gmail.com
Date: Thu, 11 Dec 2014 20:51:14 + (UTC)
Stefan Fritsch sf at sfritsch.de writes:
--- a/sys/arch/amd64/include/specialreg.h
+++ b/sys/arch/amd64/include/specialreg.h
at at -158,6 +158,7 at at
#define CPUIDECX_AVX0x1000 /* Advanced Vector Extensions
*/
#define CPUIDECX_F16C 0x2000 /* 16bit fp conversion */
#define CPUIDECX_RDRAND 0x4000 /* RDRAND instruction */
+#define CPUIDECX_HYPERV 0x8000 /* Hypervisor present */
Is this flag standardized? Last time I have tried to push this, there
was an objection based on reserved for future use status of this flag.
See http://marc.info/?l=openbsd-bugsm=136907278229145w=2
Well, that thread started out with a questionable workaround for a
hypervisor bug. That may have have influenced the debate about the
flag a bit.
You can be almost certain that Intel and AMD will not use that
reserved bit for anything else. The Linux KVM virtualization business
is too important for them. And if Microsoft Hyper-V or VMWare ESX
sets that bit as well, this becomes an absolute certainty.
The intel manual says Not Used, Always returns 0 which is different from
reserved, which is stated for other bits.
FTR, jasper@ checked that vmware sets the bit while virtual box does not.
So, many but not all hypervisors set it.
I prefer the CPUIDECX_HV name used in the diff you posted in:
OK?
diff --git a/sys/arch/amd64/amd64/identcpu.c b/sys/arch/amd64/amd64/identcpu.c
--- a/sys/arch/amd64/amd64/identcpu.c
+++ b/sys/arch/amd64/amd64/identcpu.c
@@ -129,6 +129,7 @@ const struct {
{ CPUIDECX_AVX, AVX },
{ CPUIDECX_F16C,F16C },
{ CPUIDECX_RDRAND, RDRAND },
+ { CPUIDECX_HV, HV },
}, cpu_ecpuid_ecxfeatures[] = {
{ CPUIDECX_LAHF,LAHF },
{ CPUIDECX_CMPLEG, CMPLEG },
diff --git a/sys/arch/amd64/include/specialreg.h
b/sys/arch/amd64/include/specialreg.h
--- a/sys/arch/amd64/include/specialreg.h
+++ b/sys/arch/amd64/include/specialreg.h
@@ -158,6 +158,7 @@
#defineCPUIDECX_AVX0x1000 /* Advanced Vector Extensions */
#defineCPUIDECX_F16C 0x2000 /* 16bit fp conversion */
#defineCPUIDECX_RDRAND 0x4000 /* RDRAND instruction */
+#defineCPUIDECX_HV 0x8000 /* Running on hypervisor */
/*
* Structured Extended Feature Flags Parameters (CPUID function 0x7, leaf 0)
Re: intro(2) update regarding file names
Hi, Kaspars Bankovskis wrote on Mon, Dec 15, 2014 at 01:22:21PM +0200: As there are no file name restrictions for ASCII characters, I assume this requirement might be outdated. Is that correct? This patch seems good to me. Anybody wants to OK it? Yours, Ingo P.S. I consider it unwise to use non-ASCII characters in filenames, but i know that many people disagree, and either way, a section 2 manual page has to explain what the kernel supports, it's clearly the wrong place to discuss best practices for choosing filenames. Index: intro.2 === RCS file: /cvs/src/lib/libc/sys/intro.2,v retrieving revision 1.53 diff -u -p -r1.53 intro.2 --- intro.2 10 Dec 2014 07:18:44 - 1.53 +++ intro.2 15 Dec 2014 11:11:06 - @@ -595,12 +595,8 @@ Names consisting of up to 255 characters may be used to name an ordinary file, special file, or directory. .Pp -These characters may be selected from the set of all -.Tn ASCII -character -excluding 0 (NUL) and the -.Tn ASCII -code for +These characters may be arbitrary eight-bit values, +excluding 0 (NUL) and the ASCII code for .Ql \/ (slash). .Pp @@ -615,7 +611,7 @@ file names because of the special meanin by the shell. .Pp Note also that -.Pq Dv NAME_MAX +.Dv NAME_MAX is an upper limit fixed by the kernel, meant to be used for sizing buffers. Some filesystems may have additional restrictions. These can be queried using @@ -623,8 +619,7 @@ These can be queried using and .Xr fpathconf 2 . .It Path Name -A path name is a -.Tn NUL Ns -terminated +A path name is a NUL-terminated character string starting with an optional slash .Ql \/ ,
Re: Binary code patching and paravirtualization
On Wed, Dec 10, 2014 at 00:32, Stefan Fritsch wrote: --- a/sys/arch/amd64/conf/GENERIC +++ b/sys/arch/amd64/conf/GENERIC @@ -39,6 +39,8 @@ isa0at amdpcib? isa0 at tcpcib? pci* at mainbus0 +paravirt0 at mainbus0 + acpi0 at bios0 acpitimer*at acpi? acpihpet* at acpi? diff --git a/sys/arch/amd64/conf/files.amd64 b/sys/arch/amd64/conf/files.amd64 index 103b653..a73d5d8 100644 --- a/sys/arch/amd64/conf/files.amd64 +++ b/sys/arch/amd64/conf/files.amd64 @@ -80,6 +80,12 @@ device mainbus: isabus, pcibus, mainbus attachmainbus at root file arch/amd64/amd64/mainbus.c mainbus +device paravirt +attach paravirt at mainbus +file arch/amd64/amd64/paravirt.c paravirt needs-flag + +file arch/amd64/amd64/codepatch.c Can you explain why this needs to be a device? It doesn't appear to be doing any device like things.
Re: Binary code patching and paravirtualization
On Mon, 15 Dec 2014, Ted Unangst wrote: On Wed, Dec 10, 2014 at 00:32, Stefan Fritsch wrote: --- a/sys/arch/amd64/conf/GENERIC +++ b/sys/arch/amd64/conf/GENERIC @@ -39,6 +39,8 @@ isa0 at amdpcib? isa0at tcpcib? pci*at mainbus0 +paravirt0 at mainbus0 + acpi0 at bios0 acpitimer* at acpi? acpihpet* at acpi? diff --git a/sys/arch/amd64/conf/files.amd64 b/sys/arch/amd64/conf/files.amd64 index 103b653..a73d5d8 100644 --- a/sys/arch/amd64/conf/files.amd64 +++ b/sys/arch/amd64/conf/files.amd64 @@ -80,6 +80,12 @@ device mainbus: isabus, pcibus, mainbus attach mainbus at root filearch/amd64/amd64/mainbus.c mainbus +device paravirt +attach paravirt at mainbus +file arch/amd64/amd64/paravirt.c paravirt needs-flag + +file arch/amd64/amd64/codepatch.c Can you explain why this needs to be a device? It doesn't appear to be doing any device like things. Only in order to get a flags field that can be tweaked with config(8). And to allow disable via config(8), though that could also be achieved with a flag. Tweaking the behavior with a flags value is necessary because hypervisors not always announce what they are capable of. One reason for this is that qemu is responsible for setting most of the cpuid flags but the kvm kernel module offers some interfaces in all cases. Another reason seems to be simple oversight, for example Illuminos KVM forgot to add the cpuid stuff from Linux KVM. And if there is some bug it may be a good idea to have a simple way to check if it is related to the paravirt stuff. I have just noticed that there is support in config(8) to set non-devices related int values. But this does not seem to be supported in the in-kernel UKC. And I can't see right now how config finds the valid int values in the kernel. Or is it just necessary to add the name of the variable prepended by an underscore to the config tool? Would this be preferred over introducing the paravirt device? But being able to set this from the in-kernel UKC would be nice, too.
Re: Binary code patching and paravirtualization
On Mon, Dec 15, 2014 at 23:55, Stefan Fritsch wrote: Only in order to get a flags field that can be tweaked with config(8). And to allow disable via config(8), though that could also be achieved with a flag. Tweaking the behavior with a flags value is necessary because hypervisors not always announce what they are capable of. One reason for this is that qemu is responsible for setting most of the cpuid flags but the kvm kernel module offers some interfaces in all cases. Another reason seems to be simple oversight, for example Illuminos KVM forgot to add the cpuid stuff from Linux KVM. And if there is some bug it may be a good idea to have a simple way to check if it is related to the paravirt stuff. I have just noticed that there is support in config(8) to set non-devices related int values. But this does not seem to be supported in the in-kernel UKC. And I can't see right now how config finds the valid int values in the kernel. Or is it just necessary to add the name of the variable prepended by an underscore to the config tool? Would this be preferred over introducing the paravirt device? But being able to set this from the in-kernel UKC would be nice, too. I think it would be better to avoid fake device proliferation, but others may have other opinions. So the problem is that some hypervisors are broken and don't identify as such? Perhaps we ignore them to start? Then we can add a mechanism to force paravirt code patching. I think the introduction of paravirt code patching and the mechanism used to enable or disable are separate issues. It can start as a normal option PARAVIRT, and then we discuss what else needs to be done?
divert(4) m_pullup
Make divert_output() do an m_pullup only if truly needed.
ok?
Index: netinet/ip_divert.c
===
RCS file: /cvs/src/sys/netinet/ip_divert.c,v
retrieving revision 1.31
diff -u -p -r1.31 ip_divert.c
--- netinet/ip_divert.c 5 Dec 2014 15:50:04 - 1.31
+++ netinet/ip_divert.c 13 Dec 2014 04:32:23 -
@@ -101,7 +101,8 @@ divert_output(struct inpcb *inp, struct
/* Do basic sanity checks. */
if (m-m_pkthdr.len sizeof(struct ip))
goto fail;
- if ((m = m_pullup(m, sizeof(struct ip))) == NULL) {
+ if (m-m_len sizeof(struct ip)
+ (m = m_pullup(m, sizeof(struct ip))) == NULL) {
/* m_pullup() has freed the mbuf, so just return. */
divstat.divs_errors++;
return (ENOBUFS);
Index: netinet6/ip6_divert.c
===
RCS file: /cvs/src/sys/netinet6/ip6_divert.c,v
retrieving revision 1.31
diff -u -p -r1.31 ip6_divert.c
--- netinet6/ip6_divert.c 5 Dec 2014 15:50:04 - 1.31
+++ netinet6/ip6_divert.c 13 Dec 2014 04:32:24 -
@@ -104,7 +104,8 @@ divert6_output(struct inpcb *inp, struct
/* Do basic sanity checks. */
if (m-m_pkthdr.len sizeof(struct ip6_hdr))
goto fail;
- if ((m = m_pullup(m, sizeof(struct ip6_hdr))) == NULL) {
+ if (m-m_len sizeof(struct ip6_hdr)
+ (m = m_pullup(m, sizeof(struct ip6_hdr))) == NULL) {
/* m_pullup() has freed the mbuf, so just return. */
div6stat.divs_errors++;
return (ENOBUFS);
Re: pcap(3) manpage fixes
On Fri, Dec 12, 2014 at 03:32:31PM +0100, Ingo Schwarze wrote: Hi Kaspars, Kaspars Bankovskis wrote on Fri, Dec 12, 2014 at 03:22:16PM +0200: Function arguments in synopsis for pcap_inject and pcap_sendpacket are a bit messed up by comma. Types updated from actual code. And some .An and .In macro fixes while there. Committed, thanks. Some more argument names are missing, and i wouldn't be surprised if more argument types were wrong. If someone knowledgeable in this area could clean it up, that might be welcome. Here's my attempt to clean it up. This adds the missing argument names and ensures that the argument types and names are the same as those used in the code. ok? Index: pcap.3 === RCS file: /cvs/src/lib/libpcap/pcap.3,v retrieving revision 1.36 diff -u -p -u -p -r1.36 pcap.3 --- pcap.3 12 Dec 2014 14:23:17 - 1.36 +++ pcap.3 16 Dec 2014 05:07:38 - @@ -28,7 +28,7 @@ .Sh SYNOPSIS .In pcap.h .Ft pcap_t * -.Fn pcap_open_live char *device int snaplen int promisc int to_ms char *errbuf +.Fn pcap_open_live const char *source int snaplen int promisc int to_ms char *errbuf .Ft pcap_t * .Fn pcap_open_offline char *fname char *errbuf .Ft pcap_dumper_t * @@ -44,23 +44,23 @@ .Ft int .Fn pcap_loop pcap_t *p int cnt pcap_handler callback u_char *user .Ft void -.Fn pcap_dump u_char *user struct pcap_pkthdr *h u_char *sp +.Fn pcap_dump u_char *user const struct pcap_pkthdr *h const u_char *sp .Ft int .Fn pcap_inject pcap_t *p const void *buf size_t len .Ft int .Fn pcap_sendpacket pcap_t *p const u_char *buf int size .Ft int -.Fn pcap_compile pcap_t *p struct bpf_program *fp char *str int optimize bpf_u_int32 netmask +.Fn pcap_compile pcap_t *p struct bpf_program *program char *buf int optimize bpf_u_int32 netmask .Ft int .Fn pcap_setfilter pcap_t *p struct bpf_program *fp .Ft void -.Fn pcap_freecode struct bpf_program *fp +.Fn pcap_freecode struct bpf_program *program .Ft u_char * .Fn pcap_next pcap_t *p struct pcap_pkthdr *h .Ft int -.Fn pcap_next_ex pcap_t *p struct pcap_pkthdr **hp const u_char **pktp +.Fn pcap_next_ex pcap_t *p struct pcap_pkthdr **pkt_header const u_char **pkt_data .Ft int -.Fn pcap_setdirection pcap_t *p pcap_direction_t dir +.Fn pcap_setdirection pcap_t *p pcap_direction_t d .Ft int .Fn pcap_datalink pcap_t *p .Ft int @@ -78,13 +78,13 @@ .Ft int .Fn pcap_fileno pcap_t *p .Ft int -.Fn pcap_get_selectable_fd pcap_t * +.Fn pcap_get_selectable_fd pcap_t *p .Ft void .Fn pcap_perror pcap_t *p char *prefix .Ft char * .Fn pcap_geterr pcap_t *p .Ft char * -.Fn pcap_strerror int error +.Fn pcap_strerror int errnum .Ft void .Fn pcap_close pcap_t *p .Ft FILE * @@ -108,7 +108,7 @@ .Ft int .Fn pcap_set_datalink pcap_t * int dlt .Ft int -.Fn pcap_list_datalinks pcap_t *p int **dlts +.Fn pcap_list_datalinks pcap_t *p int **dlt_buffer .Ft pcap_t .Fn pcap_open_dead int linktype int snaplen .Ft pcap_t @@ -116,13 +116,13 @@ .Ft const char * .Fn pcap_lib_version void .Ft const char * -.Fn pcap_datalink_val_to_name int +.Fn pcap_datalink_val_to_name int dlt .Ft const char * -.Fn pcap_datalink_val_to_description int +.Fn pcap_datalink_val_to_description int dlt .Ft int .Fn pcap_datalink_name_to_val const char * .Ft pcap_t * -.Fn pcap_create const char *source char *errbuf +.Fn pcap_create const char *device char *errbuf .Ft int .Fn pcap_set_snaplen pcap_t *p int snaplen .Ft int @@ -132,13 +132,13 @@ .Ft int .Fn pcap_set_rfmon pcap_t *p int rfmon .Ft int -.Fn pcap_set_timeout pcap_t *p int timeout +.Fn pcap_set_timeout pcap_t *p int timeout_ms .Ft int .Fn pcap_set_buffer_size pcap_t *p int buffer_size .Ft int .Fn pcap_activate pcap_t *p .Ft const char * -.Fn pcap_statustostr int +.Fn pcap_statustostr int errnum .Sh DESCRIPTION .Nm provides a high level interface to packet capture systems. @@ -162,7 +162,7 @@ chars. .Fn pcap_open_live is used to obtain a packet capture descriptor to look at packets on the network. -.Fa device +.Fa source is a string that specifies the network device to open. .Fa snaplen specifies the maximum number of bytes to capture. @@ -305,9 +305,9 @@ It returns 0 on success or \-1 on failur .Pp .Fn pcap_compile is used to compile the string -.Fa str +.Fa buf into a filter program. -.Fa fp +.Fa program is a pointer to a .Fa bpf_program struct and is filled in by
Re: Dell R630 high interrupts on acpi0
On Sun, Dec 14, 2014 at 06:22:37PM +0100, Hrvoje Popovski wrote:
Hi all,
I have got two new Dell R630 and have current on them from Sun Dec
14 15:07:17. Installation went great and very fast.
The problem is that I see around 11k interrupts on acpi0. First I
thought that problem is similar to this thread
http://marc.info/?l=openbsd-miscm=140551906923931w=2
But if in dell bios system profile settings is set to performance or
to DAPC there are always interrupts on acpi0.
In links bellow you can find acpidump and dmesg from performance and
DAPC settings in dell bios.
We just got some r630s too, so I spent some time last week figuring out what's
going on here. Something in the AML wants to talk to the intel MEI device.
Normally this works, but on the new generation of dell machines (we've seen it
on r630s and r730s), it's been moved outside the pci memory range we currently
allow on amd64. You can see this in your dmesgs:
0:22:0: mem address conflict 0x3303000/0x10
0:22:1: mem address conflict 0x3302000/0x10
The interrupt will keep triggering until it manages to talk to the device,
which will never happen.
kettenis@ says we can get the pci memory range information we need to deal with
this from acpi. Until that happens, expanding the allowed pci memory range
makes things work properly.
ok?
Index: pci_machdep.c
===
RCS file: /cvs/src/sys/arch/amd64/pci/pci_machdep.c,v
retrieving revision 1.59
diff -u -p -u -p -r1.59 pci_machdep.c
--- pci_machdep.c 19 Apr 2014 11:53:42 - 1.59
+++ pci_machdep.c 16 Dec 2014 04:21:53 -
@@ -622,13 +622,17 @@ 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, 0x10UL,
- 0xfff0UL, EX_NOWAIT);
+ extent_alloc_region(pcimem_ex, 0x400UL,
+ 0xfc00UL, EX_NOWAIT);
for (bmp = bios_memmap; bmp-type != BIOS_MAP_END; bmp++) {
/*
Re: Dell R630 high interrupts on acpi0
On 16 Dec 2014, at 15:16, Jonathan Matthew jonat...@d14n.org wrote:
On Sun, Dec 14, 2014 at 06:22:37PM +0100, Hrvoje Popovski wrote:
Hi all,
I have got two new Dell R630 and have current on them from Sun Dec
14 15:07:17. Installation went great and very fast.
The problem is that I see around 11k interrupts on acpi0. First I
thought that problem is similar to this thread
http://marc.info/?l=openbsd-miscm=140551906923931w=2
But if in dell bios system profile settings is set to performance or
to DAPC there are always interrupts on acpi0.
In links bellow you can find acpidump and dmesg from performance and
DAPC settings in dell bios.
We just got some r630s too, so I spent some time last week figuring out what's
going on here. Something in the AML wants to talk to the intel MEI device.
Normally this works, but on the new generation of dell machines (we've seen it
on r630s and r730s), it's been moved outside the pci memory range we currently
allow on amd64. You can see this in your dmesgs:
0:22:0: mem address conflict 0x3303000/0x10
0:22:1: mem address conflict 0x3302000/0x10
The interrupt will keep triggering until it manages to talk to the device,
which will never happen.
we've also experienced this on r720s configured in Performance mode in the BIOS
too. others have hit this on r620s as well (look for Dell R620 high ACPI
Interrupt rate on misc@). the diff below fixes them too.
dlg
kettenis@ says we can get the pci memory range information we need to deal
with
this from acpi. Until that happens, expanding the allowed pci memory range
makes things work properly.
ok?
Index: pci_machdep.c
===
RCS file: /cvs/src/sys/arch/amd64/pci/pci_machdep.c,v
retrieving revision 1.59
diff -u -p -u -p -r1.59 pci_machdep.c
--- pci_machdep.c 19 Apr 2014 11:53:42 - 1.59
+++ pci_machdep.c 16 Dec 2014 04:21:53 -
@@ -622,13 +622,17 @@ 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, 0x10UL,
- 0xfff0UL, EX_NOWAIT);
+ extent_alloc_region(pcimem_ex, 0x400UL,
+ 0xfc00UL, EX_NOWAIT);
for (bmp = bios_memmap; bmp-type != BIOS_MAP_END; bmp++) {
/*
unnbound vs file descriptors
Hi, So i have started using unbound on a mailserver (running amd64 5.6-stable). First observation is that it uses (too?) many file descriptors in the default setup. Dec 15 22:38:00 mx1 unbound: [8713:0] error: can't create socket: Too many open files Dec 15 22:38:00 mx1 last message repeated 1366 times $ unbound-checkconf -o outgoing-range 4000 But even after settting this to 1500 and having a login.conf: unbound:\ :openfiles-cur=2048:\ :tc=daemon: I am still seeing these log messages. I'd like to make sure the settings out of the box are reasonable (setting outgoing-range any maybe other options in the default config and/or having a default entry in loging.conf, but so far unbound is not cooperating. Any clue on what setting I should fiddle with? -Otto
