Re: Turbo on i7
On Sun, Jun 22, 2014 at 08:04:27PM -0700, Philip Guenther wrote: On Tue, Jun 17, 2014 at 3:45 PM, Gustav Fransson Nyvell gus...@nyvell.se wrote: I want to alert you to this strange observation. $ sysctl -a ... hw.cpuspeed=3101 hw.setperf=100 ... This on an Intel i7 3920XM. Rated for 3.8GHz when running 100%. 3101 would mean 3.1GHz and hw.setperf=100 means it should/must run at 100%. I want to alert you to the fact that your message didn't include the system dmesg, and will therefore be ignored as insufficient data for analysis. Indeed, *NO ONE* has sent in a dmesg to dm...@openbsd.org for that CPU. Clearly it doesn't exist... It is also worth pointing out that the highest speedstep speed that is 1 MHz higher than the next is the turbo mode. sysctl will not reflect the actual speed when in turbo mode, we'd have to do a bunch of msrs on a periodic timer or something similiar.
Re: diff: Fix udp_usrreq.c to compile without IPSEC.
YASUOKA Masahiko yasu...@yasuoka.net writes: ok? ok Fix compile without IPSEC. Pointed out by Ivan Solonin. Index: sys/netinet/udp_usrreq.c === RCS file: /disk/cvs/openbsd/src/sys/netinet/udp_usrreq.c,v retrieving revision 1.184 diff -u -p -r1.184 udp_usrreq.c --- sys/netinet/udp_usrreq.c 23 Apr 2014 12:25:35 - 1.184 +++ sys/netinet/udp_usrreq.c 23 Jun 2014 02:17:06 - @@ -186,9 +186,9 @@ udp_input(struct mbuf *m, ...) struct m_tag *mtag; struct tdb_ident *tdbi; struct tdb *tdb; +#endif /* IPSEC */ int error; u_int32_t ipsecflowinfo = 0; -#endif /* IPSEC */ va_start(ap, m); iphlen = va_arg(ap, int); -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: Turbo on i7
On 06/23/14 05:04, Philip Guenther wrote: On Tue, Jun 17, 2014 at 3:45 PM, Gustav Fransson Nyvell gus...@nyvell.se mailto:gus...@nyvell.se wrote: I want to alert you to this strange observation. $ sysctl -a ... hw.cpuspeed=3101 hw.setperf=100 ... This on an Intel i7 3920XM. Rated for 3.8GHz when running 100%. 3101 would mean 3.1GHz and hw.setperf=100 means it should/must run at 100%. I want to alert you to the fact that your message didn't include the system dmesg, and will therefore be ignored as insufficient data for analysis. Indeed, *NO ONE* has sent in a dmesg to dm...@openbsd.org mailto:dm...@openbsd.org for that CPU. Clearly it doesn't exist... Philip Guenther Oh but it does! OpenBSD 5.5-current (GENERIC.MP) #5: Sat Jun 21 19:55:55 CEST 2014 gus...@uncouth.nyvell.se:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 34226692096 (32641MB) avail mem = 33306812416 (31763MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb420 (33 entries) bios0: vendor American Megatrends Inc. version 4.6.5 date 08/22/2012 bios0: CLEVO P15xEMx acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT ASF! MCFG HPET SSDT SSDT SSDT DMAR SSDT SSDT acpi0: wakeup devices P0P1(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) USB6(S3) USB7(S3) PXSX(S4) RP01(S3) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(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) i7-3920XM CPU @ 2.90GHz, 2794.02 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS 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 cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-3920XM CPU @ 2.90GHz, 2793.67 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-3920XM CPU @ 2.90GHz, 2793.67 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-3920XM CPU @ 2.90GHz, 2793.67 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 1 (application processor) cpu4: Intel(R) Core(TM) i7-3920XM CPU @ 2.90GHz, 2793.67 MHz cpu4: 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu4: 256KB 64b/line 8-way L2 cache cpu4: smt 1, core 0, package 0 cpu5 at mainbus0: apid 3 (application processor) cpu5: Intel(R) Core(TM) i7-3920XM CPU @ 2.90GHz, 2793.67 MHz cpu5: 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu5: 256KB 64b/line 8-way L2 cache cpu5: smt 1, core 1, package 0 cpu6 at mainbus0: apid 5 (application processor) cpu6: Intel(R) Core(TM) i7-3920XM CPU @ 2.90GHz, 2793.67 MHz cpu6:
PATCH: ftp: allow @ in username for Basic Auth
Hi,
Using ftp(1) with HTTP(S) scheme and Basic auth, it is currently not
possible to have username (or password) with a '@' inner.
For example, this URI is badly parsed:
ftp https://mym...@example.com:my-passw...@another-domain.example.com/blabla
According to RFC2617, '@' is a valid character in user-id or password:
user-pass = userid : password
userid = *TEXT excluding :
password= *TEXT
Here a patch to search the last '@' in the string (which don't contains
the path at this time).
--
Sébastien Marie
Index: fetch.c
===
RCS file: /cvs/src/usr.bin/ftp/fetch.c,v
retrieving revision 1.122
diff -u -p -r1.122 fetch.c
--- fetch.c 20 May 2014 01:25:23 - 1.122
+++ fetch.c 23 Jun 2014 07:46:33 -
@@ -474,7 +474,7 @@ noslash:
*/
if (proxyenv == NULL
(!strcmp(scheme, HTTP_URL) || !strcmp(scheme, HTTPS_URL))) {
- if ((p = strchr(host, '@')) != NULL) {
+ if ((p = strrchr(host, '@')) != NULL) {
size_t authlen = (strlen(host) + 5) * 4 / 3;
*p = 0; /* Kill @ */
if ((auth = malloc(authlen)) == NULL)
ddb: ELF line decoding in stack traces
Diff below implements file/line number decoding in ddb for ELF; e.g.,
ddb{2} trace
Debugger() at Debugger+0x9 [../../../../arch/amd64/amd64/db_interface.c:406]
ddb_sysctl() at ddb_sysctl+0x1b4 [../../../../ddb/db_usrreq.c:104]
sys___sysctl() at sys___sysctl+0x214 [../../../../kern/kern_sysctl.c:229]
syscall() at syscall+0x297 [../../../../sys/syscall_mi.h:84]
--- syscall (number 202) ---
end of kernel
end trace frame: 0x7f7e1def, count: -4
acpi_pdirpa+0x41195a:
ddb{2}
It works by modifying boot(8) to copy the .debug_line DWARF section
into memory when present (same as it does currently for symbol and
string table sections), and then ddb's ELF symbol format handler code
makes use of it to translate program counters into file/line pairs
just like addr2line would.
For line decoding to work, the kernel must have been compiled with -g.
Normal and/or stripped kernels continue to work as they do now, just
won't produce file/line information.
Only lightly tested on amd64 so far, but might work on other platforms
too. If you're brave, you can try it out thusly:
1. Apply patch.
2. Build boot(8), copy to /boot, and run installboot(8).
3. Configure kernel with 'makeoptions DEBUG=-g'.
4. Build kernel and install bsd.gdb (not bsd!).
5. Reboot.
I did this mostly for fun / personal enlightenment, so I haven't put
too much effort into polishing it yet.
Index: ddb/db_elf.c
===
RCS file: /home/matthew/anoncvs/cvs/src/sys/ddb/db_elf.c,v
retrieving revision 1.10
diff -u -p -r1.10 db_elf.c
--- ddb/db_elf.c16 Mar 2014 20:31:46 - 1.10
+++ ddb/db_elf.c23 Jun 2014 12:27:26 -
@@ -46,6 +46,7 @@
#include sys/exec_elf.h
static char *db_elf_find_strtab(db_symtab_t *);
+static char *db_elf_find_linetab(db_symtab_t *, size_t *);
#defineSTAB_TO_SYMSTART(stab) ((Elf_Sym *)((stab)-start))
#defineSTAB_TO_SYMEND(stab)((Elf_Sym *)((stab)-end))
@@ -111,10 +112,10 @@ db_elf_sym_init(int symsize, void *symta
* . . .
* . . .
* last section header
-* first symbol or string table section
+* first symbol, string, or line table section
* . . .
* . . .
-* last symbol or string table section
+* last symbol, string, or line table section
*/
/*
@@ -233,6 +234,29 @@ db_elf_find_strtab(db_symtab_t *stab)
}
/*
+ * Internal helper function - return a pointer to the line table
+ * for the current symbol table.
+ */
+static char *
+db_elf_find_linetab(db_symtab_t *stab, size_t *size)
+{
+ Elf_Ehdr *elf = STAB_TO_EHDR(stab);
+ Elf_Shdr *shp = STAB_TO_SHDR(stab, elf);
+ char *shstrtab;
+ int i;
+
+ shstrtab = (char *)elf + shp[elf-e_shstrndx].sh_offset;
+ for (i = 0; i elf-e_shnum; i++) {
+ if (strcmp(.debug_line, shstrtab+shp[i].sh_name) == 0) {
+ *size = shp[i].sh_size;
+ return ((char *)elf + shp[i].sh_offset);
+ }
+ }
+
+ return (NULL);
+}
+
+/*
* Lookup the symbol with the given name.
*/
db_sym_t
@@ -343,6 +367,8 @@ db_elf_symbol_values(db_symtab_t *symtab
*valuep = symp-st_value;
}
+#include db_elf_dwarf.c
+
/*
* Return the file and line number of the current program counter
* if we can find the appropriate debugging symbol.
@@ -351,11 +377,15 @@ boolean_t
db_elf_line_at_pc(db_symtab_t *symtab, db_sym_t cursym, char **filename,
int *linenum, db_expr_t off)
{
+ const char *linetab;
+ size_t linetab_size;
- /*
-* XXX We don't support this (yet).
-*/
- return (FALSE);
+ linetab = db_elf_find_linetab(symtab, linetab_size);
+ if (linetab == NULL)
+ return (FALSE);
+
+ return (db_elf_dwarf_line_at_pc(linetab, linetab_size, off,
+ filename, linenum));
}
/*
Index: ddb/db_elf_dwarf.c
===
RCS file: ddb/db_elf_dwarf.c
diff -N ddb/db_elf_dwarf.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ ddb/db_elf_dwarf.c 23 Jun 2014 13:37:34 -
@@ -0,0 +1,404 @@
+/* $OpenBSD$*/
+/*
+ * Copyright (c) 2014 Matthew Dempsky matt...@dempsky.org
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
ksh file completion with quotes
Hi,
This patch adds some intelligence to emacs mode filename completion when dealing
with quotes in ksh.
Example:
$ ls '/booTAB
$ ls 'boot point
becomes:
$ ls 'boot' point
Index: emacs.c
===
RCS file: /cvs/src/bin/ksh/emacs.c,v
retrieving revision 1.48
diff -u -p -r1.48 emacs.c
--- emacs.c 17 Dec 2013 16:37:05 - 1.48
+++ emacs.c 23 Jun 2014 15:00:41 -
@@ -1799,12 +1799,31 @@ do_complete(int flags, /* XCF_{COMMAND,F
nlen = x_longest_prefix(nwords, words);
/* complete */
if (nwords == 1 || nlen olen) {
+ int isdir;
+
x_goto(xbuf + start);
x_delete(olen, false);
x_escape(words[0], nlen, x_emacs_putbuf);
x_adjust();
completed = 1;
+
+ isdir = words[0][nlen - 1] == '/';
+
+ /* add matching quote if we began with one */
+ if (start 0 xbuf[start - 1] == '\'') {
+ if (xbuf[start + nlen] != '\'' !isdir)
+ x_ins(');
+ if (!isdir)
+ x_mv_forw(0);
+ }
+ if (start 0 xbuf[start - 1] == '') {
+ if (xbuf[start + nlen] != '' !isdir)
+ x_ins(\);
+ if (!isdir)
+ x_mv_forw(0);
+ }
}
+
/* add space if single non-dir match */
if (nwords == 1 words[0][nlen - 1] != '/') {
x_ins(space);
pgpqTFCCq500X.pgp
Description: PGP signature
Re: gcc: warn about overly aligned stack variables
GCC supports an aligned attribute to specify a minimum alignment for
types/objects. However, if an object is allocated on the stack and
its alignment exceeds the preferred stack boundary, then GCC 4.2
silently ignores the alignment.
[...]
Since newer GCC properly support overly aligned stack allocations, it
seems prudent to at least make base GCC emit a warning if its going to
ignore an alignment request.
[...]
I verified this doesn't break an amd64 kernel build, but I haven't had
time to look beyond that. Sharing in case anyone's interested and/or
wants to test further themselves.
I love this. I have verified that kernels for all our gcc4 platforms
still build with this diff.
Miod
Index: gcc/cfgexpand.c
===
RCS file: /home/matthew/cvs-mirror/cvs/src/gnu/gcc/gcc/cfgexpand.c,v
retrieving revision 1.4
diff -u -p -r1.4 cfgexpand.c
--- gcc/cfgexpand.c 6 May 2014 23:32:34 - 1.4
+++ gcc/cfgexpand.c 20 Jun 2014 22:55:53 -
@@ -159,8 +159,10 @@ get_decl_align_unit (tree decl)
align = DECL_ALIGN (decl);
align = LOCAL_ALIGNMENT (TREE_TYPE (decl), align);
- if (align PREFERRED_STACK_BOUNDARY)
+ if (align PREFERRED_STACK_BOUNDARY) {
+warning (0, ignoring alignment for stack allocated %q+D, decl);
align = PREFERRED_STACK_BOUNDARY;
+ }
if (cfun-stack_alignment_needed align)
cfun-stack_alignment_needed = align;
fsck_msdos: validate basic information
Hi,
there should be some more validations in boot.c. Not just to validate
the filesystem, but to make sure that the program won't crash later on
because it assumes some values...
First chunk: The sectors per cluster have to be a power of 2, otherwise
it's possible to send fsck_msdos over the edge at for-loop comparison
with values that could go up to SIZE_MAX. If it's not power of 2, it
can iterate above, overflow, and continue the loop. By specifications
and our kernel implementation, the value has to be power of 2 anyway.
Second chunk is a merge from Android. A FAT filesystem without a FAT
doesn't make sense.
Third chunk: A FAT without any sectors is invalid. We would allocate
memory based on that, yet the memory will be accessed because the code
assumes that offsets in first sector is available.
Fourth and last chunk: The offset into the partition must not be
larger than the filesystem. If that's not checked, the previously
assigned value could overflow due to negative numbers.
Tobias
Index: boot.c
===
RCS file: /cvs/src/sbin/fsck_msdos/boot.c,v
retrieving revision 1.20
diff -u -p -r1.20 boot.c
--- boot.c 16 Jun 2014 18:33:33 - 1.20
+++ boot.c 16 Jun 2014 19:01:51 -
@@ -88,12 +88,16 @@ readboot(int dosfs, struct bootblock *bo
goto fail;
}
boot-SecPerClust = block[13];
- if (boot-SecPerClust == 0) {
+ if (boot-SecPerClust == 0 || !powerof2(boot-SecPerClust)) {
pfatal(Invalid cluster size: %u\n, boot-SecPerClust);
goto fail;
}
boot-ResSectors = block[14] + (block[15] 8);
boot-FATs = block[16];
+ if (boot-FATs == 0) {
+ pfatal(Invalid number of FATs: %u\n, boot-FATs);
+ goto fail;
+ }
boot-RootDirEnts = block[17] + (block[18] 8);
boot-Sectors = block[19] + (block[20] 8);
boot-Media = block[21];
@@ -227,6 +231,11 @@ readboot(int dosfs, struct bootblock *bo
/* Check backup FSInfo? XXX */
}
+ if (boot-FATsecs == 0) {
+ pfatal(Invalid number of FAT sectors: %u\n, boot-FATsecs);
+ goto fail;
+ }
+
boot-ClusterOffset = (boot-RootDirEnts * 32 + secsize - 1)
/ secsize
+ boot-ResSectors
@@ -239,6 +248,12 @@ readboot(int dosfs, struct bootblock *bo
} else
boot-NumSectors = boot-HugeSectors;
boot-NumClusters = (boot-NumSectors - boot-ClusterOffset) /
boot-SecPerClust;
+
+ if (boot-ClusterOffset boot-NumSectors) {
+ pfatal(Cluster offset too large (%u clusters)\n,
+ boot-ClusterOffset);
+ goto fail;
+ }
if (boot-flagsFAT32)
boot-ClustMask = CLUST32_MASK;
Re: sys/msdosfs: possible kernel crash
And again...
Could have saved myself time by checking FreeBSD in detail first.
They fixed the issue by adding a simple check:
According to FAT specs, the size of a cluster shall not exceed 64 KB.
That is even a rare case, 32 KB shouldn't be crossed for compatibility
reasons.
Therefore, it's enough to check if we would have more than 128
physical blocks around. If that is the case, the filesystem is
invalid and we won't overflow or crash.
FreeBSD's commit message:
mountmsdosfs: reject too high value of bytes per cluster
Bytes per cluster are calcuated as bytes per sector times sectors per
cluster. Too high value can overflow an internal variable with type
that can hold only values in valid range. Trying to use a wider type
results in an attempt to read more than MAXBSIZE at once, a panic.
Unfortunately, it is FreeBSD newfs_msdos that produces filesystems
with invalid parameters for certain types of media.
Basically their version from revision 206098, adjusted to fit into our
style of the if-block.
Tobias
Index: msdosfs_vfsops.c
===
RCS file: /cvs/src/sys/msdosfs/msdosfs_vfsops.c,v
retrieving revision 1.66
diff -u -p -u -p -r1.66 msdosfs_vfsops.c
--- msdosfs_vfsops.c18 Jun 2014 17:24:46 - 1.66
+++ msdosfs_vfsops.c23 Jun 2014 17:51:37 -
@@ -385,7 +385,8 @@ msdosfs_mountfs(struct vnode *devvp, str
if ((SecPerClust == 0) || (SecPerClust (SecPerClust - 1)) ||
(pmp-pm_BytesPerSec DEV_BSIZE) ||
(pmp-pm_BytesPerSec (pmp-pm_BytesPerSec - 1)) ||
- (pmp-pm_HugeSectors == 0) || (pmp-pm_FATsecs == 0)) {
+ (pmp-pm_HugeSectors == 0) || (pmp-pm_FATsecs == 0) ||
+ (SecPerClust * pmp-pm_BlkPerSec MAXBSIZE / DEV_BSIZE)) {
error = EINVAL;
goto error_exit;
}
Re: NOINET6 by default
Henning Brauer lists-openbsdt...@bsws.de writes: since no consensus could be found yet for a new command line option to ifconfig, heck, not even about wether it is needed, I propose this for now. I didn't reply to your proposal but since you've just committed the ifconfig part, I think I should chime in. Our IPv6 support is far from perfect, from a usability point of view. For example people can't use RA on an uplink interface while having forwarding turned on. I've looked at the changes that would be needed, they are neither small nor huge, they just need a bit of thinking. Properly enabling or disabling IPv6 / link-local addressing on an interface would be part of those changes. FreeBSD has already made similar changes, and I think there are interesting bits that we should copy. More information here: http://www.freebsd.org/cgi/man.cgi?query=ifconfigapropos=0sektion=0manpath=FreeBSD+10.0-RELEASEarch=defaultformat=html (Search for ICMPv6 Neighbor Discovery Protocol) https://www.freebsd.org/releases/9.0R/relnotes-detailed.html#AEN1395 I'm volunteering for this job. I know that other people have already expressed interest in such a task. Can we please postpone ifp-if_xflags |= IFXF_NOINET6; until the situation is more clear? I think 5.6 is a safe bet. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: NOINET6 by default
j...@wxcvbn.org (Jérémie Courrèges-Anglas) writes: Henning Brauer lists-openbsdt...@bsws.de writes: since no consensus could be found yet for a new command line option to ifconfig, heck, not even about wether it is needed, I propose this for now. I didn't reply to your proposal but since you've just committed the ifconfig part and the kernel part. nevermind. [...] -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: gcc: warn about overly aligned stack variables
On Mon, Jun 23, 2014 at 9:59 AM, Miod Vallat m...@online.fr wrote: I love this. I have verified that kernels for all our gcc4 platforms still build with this diff. Awesome! I also heard back from guenther@ that he completed an i386 base build without warnings too. Do we want to test this any further (e.g., ports), or should I go ahead and commit? If the latter, anyone want to step up to ok it? :)
Re: diff: Fix udp_usrreq.c to compile without IPSEC.
If you really want to be pedantic, it should be if defined(PIPEX) || defined(IPSEC) YASUOKA Masahiko [yasu...@yasuoka.net] wrote: ok? Fix compile without IPSEC. Pointed out by Ivan Solonin. Index: sys/netinet/udp_usrreq.c === RCS file: /disk/cvs/openbsd/src/sys/netinet/udp_usrreq.c,v retrieving revision 1.184 diff -u -p -r1.184 udp_usrreq.c --- sys/netinet/udp_usrreq.c 23 Apr 2014 12:25:35 - 1.184 +++ sys/netinet/udp_usrreq.c 23 Jun 2014 02:17:06 - @@ -186,9 +186,9 @@ udp_input(struct mbuf *m, ...) struct m_tag *mtag; struct tdb_ident *tdbi; struct tdb *tdb; +#endif /* IPSEC */ int error; u_int32_t ipsecflowinfo = 0; -#endif /* IPSEC */ va_start(ap, m); iphlen = va_arg(ap, int); -- If you see fraud and don't shout fraud, you are a fraud -- Nassim Taleb
audio(9) manual page
So I have been trying to write a new audio driver (for Xonar DS if anyone interested) and therefore reading audio(9). I was confused for a while by the use of will here. I think it's not clear enough that these functions should be called by the driver code. I'm not a native speaker, so may be it's just my lack of familiarity with english idioms. Sorry for the noise if that's the case. Index: audio.9 === RCS file: /cvs/src/share/man/man9/audio.9,v retrieving revision 1.23 diff -u -r1.23 audio.9 --- audio.9 21 Jan 2014 03:15:46 - 1.23 +++ audio.9 23 Jun 2014 19:42:42 - @@ -284,7 +284,7 @@ has been initiated (normally with DMA). When the hardware is ready to accept more samples the function .Fa intr -will be called with the argument +shall be called with the argument .Fa intrarg . Calling .Fa intr @@ -302,7 +302,7 @@ has been initiated (normally with DMA). When the hardware is ready to deliver more samples the function .Fa intr -will be called with the argument +shall be called with the argument .Fa intrarg . Calling .Fa intr @@ -437,7 +437,7 @@ .Fa blksize sized block, the function .Fa intr -will be called with the argument +shall be called with the argument .Fa intrarg (typically from the audio hardware interrupt service routine). Once started, the transfer may be stopped using @@ -459,7 +459,7 @@ .Fa blksize sized block, the function .Fa intr -will be called with the argument +shall be called with the argument .Fa intrarg (typically from the audio hardware interrupt service routine). Once started, the transfer may be stopped using
Re: NOINET6 by default
I'm volunteering for this job. I know that other people have already expressed interest in such a task. Can we please postpone ifp-if_xflags |= IFXF_NOINET6; until the situation is more clear? I think 5.6 is a safe bet. No. Apparently you are the only one who keeps postponing action, month after month, so NO.
Re: diff: Fix udp_usrreq.c to compile without IPSEC.
On Sun, Jun 22, 2014 at 11:47 PM, Jérémie Courrèges-Anglas j...@wxcvbn.org wrote: YASUOKA Masahiko yasu...@yasuoka.net writes: ok? ok
Re: diff: Fix udp_usrreq.c to compile without IPSEC.
On Sun, Jun 22, 2014 at 7:28 PM, YASUOKA Masahiko yasu...@yasuoka.net wrote: ok? Fix compile without IPSEC. Pointed out by Ivan Solonin. ...and Theo just reverted this because it broke RAMDISK compiles! Messing with kernel options #ifdefs without testing by building a release is unwise. People messing with changing kernel options are wasting their own time; when they post to the list about it they waste EVERYONE'S time. To Mr Solonin: go read http://www.openbsd.org/faq/faq5.html#Why and then just use a GENERIC kernel and concentrate on getting useful work done. Philip Guenther
Re: diff: Fix udp_usrreq.c to compile without IPSEC.
On Mon, 23 Jun 2014 16:33:46 -0700 Philip Guenther guent...@gmail.com wrote: On Sun, Jun 22, 2014 at 7:28 PM, YASUOKA Masahiko yasu...@yasuoka.net wrote: ok? Fix compile without IPSEC. Pointed out by Ivan Solonin. ...and Theo just reverted this because it broke RAMDISK compiles! Messing with kernel options #ifdefs without testing by building a release is unwise. People messing with changing kernel options are wasting their own time; when they post to the list about it they waste EVERYONE'S time. I'm sorry. --yasuoka
Re: diff: Fix udp_usrreq.c to compile without IPSEC.
On Mon, Jun 23, 2014 at 10:14 PM, YASUOKA Masahiko yasu...@yasuoka.net wrote: On Mon, 23 Jun 2014 16:33:46 -0700 Philip Guenther guent...@gmail.com wrote: ... Messing with kernel options #ifdefs without testing by building a release is unwise. People messing with changing kernel options are wasting their own time; when they post to the list about it they waste EVERYONE'S time. I'm sorry. You're forgiven: go forth and do great ppp hacks!
