httpd with cd9660 filesystem
I noticed that httpd will exit if it attempts to serve a file from a cd9660 filesystem. This is due to libevent's use of kqueue by default and kqueue's lack of support for cd9660 filesystems. I'm not sure if this is the most appropriate fix but the patch below restricts the server processes from using libevent/kqueue. I haven't encountered any issues with libevent/poll running with this for about a week on a low volume web server. Index: proc.c === RCS file: /cvs/src/usr.sbin/httpd/proc.c,v retrieving revision 1.8 diff -u -p -r1.8 proc.c --- proc.c 21 Jan 2015 22:21:05 - 1.8 +++ proc.c 30 May 2015 18:10:41 - @@ -395,6 +395,8 @@ proc_run(struct privsep *ps, struct priv ps-ps_instance + 1, ps-ps_instances[p-p_id], getpid()); #endif + if (strcmp(p-p_title, server) == 0) + setenv(EVENT_NOKQUEUE, yes, 0); event_init(); signal_set(ps-ps_evsigint, SIGINT, proc_sig_handler, p);
Re: httpd with cd9660 filesystem
I took a shot at fixing this the correct way by adding kqueue support
to cd9660. Hopefully I'm on the right track here with this diff based on
what I saw for ufs.
Index: cd9660_vnops.c
===
RCS file: /cvs/src/sys/isofs/cd9660/cd9660_vnops.c,v
retrieving revision 1.70
diff -u -p -r1.70 cd9660_vnops.c
--- cd9660_vnops.c 10 Feb 2015 21:56:09 - 1.70
+++ cd9660_vnops.c 31 May 2015 13:30:22 -
@@ -83,6 +83,10 @@ struct isoreaddir {
intiso_uiodir(struct isoreaddir *, struct dirent *, off_t);
intiso_shipdir(struct isoreaddir *);
+intcd9660_kqfilter(void *);
+void filt_cd9660detach(struct knote *);
+intfilt_cd9660read(struct knote *, long);
+intfilt_cd9660vnode(struct knote *, long);
/*
* Setattr call. Only allowed for block and character special devices.
@@ -808,6 +812,80 @@ cd9660_pathconf(void *v)
return (error);
}
+struct filterops cd9660read_filtops =
+ { 1, NULL, filt_cd9660detach, filt_cd9660read };
+struct filterops cd9660vnode_filtops =
+ { 1, NULL, filt_cd9660detach, filt_cd9660vnode };
+
+int
+cd9660_kqfilter(void *v)
+{
+ struct vop_kqfilter_args *ap = v;
+ struct vnode *vp = ap-a_vp;
+ struct knote *kn = ap-a_kn;
+
+ switch (kn-kn_filter) {
+ case EVFILT_READ:
+ kn-kn_fop = cd9660read_filtops;
+ break;
+ case EVFILT_VNODE:
+ kn-kn_fop = cd9660vnode_filtops;
+ break;
+ default:
+ return (EINVAL);
+ }
+
+ kn-kn_hook = (caddr_t)vp;
+
+ SLIST_INSERT_HEAD(vp-v_selectinfo.si_note, kn, kn_selnext);
+
+ return (0);
+}
+
+void
+filt_cd9660detach(struct knote *kn)
+{
+ struct vnode *vp = (struct vnode *)kn-kn_hook;
+
+ SLIST_REMOVE(vp-v_selectinfo.si_note, kn, knote, kn_selnext);
+}
+
+int
+filt_cd9660read(struct knote *kn, long hint)
+{
+ struct vnode *vp = (struct vnode *)kn-kn_hook;
+ struct iso_node *ip = VTOI(vp);
+
+ /*
+* filesystem is gone, so set the EOF flag and schedule
+* the knote for deletion.
+*/
+ if (hint == NOTE_REVOKE) {
+ kn-kn_flags |= (EV_EOF | EV_ONESHOT);
+ return (1);
+ }
+
+kn-kn_data = ip-i_size - kn-kn_fp-f_offset;
+ if (kn-kn_data == 0 kn-kn_sfflags NOTE_EOF) {
+ kn-kn_fflags |= NOTE_EOF;
+ return (1);
+ }
+
+return (kn-kn_data != 0);
+}
+
+int
+filt_cd9660vnode(struct knote *kn, long hint)
+{
+ if (kn-kn_sfflags hint)
+ kn-kn_fflags |= hint;
+ if (hint == NOTE_REVOKE) {
+ kn-kn_flags |= EV_EOF;
+ return (1);
+ }
+ return (kn-kn_fflags != 0);
+}
+
/*
* Global vfs data structures for isofs
*/
@@ -841,6 +919,7 @@ struct vops cd9660_vops = {
.vop_write = cd9660_write,
.vop_ioctl = cd9660_ioctl,
.vop_poll = cd9660_poll,
+ .vop_kqfilter = cd9660_kqfilter,
.vop_revoke = cd9660_revoke,
.vop_fsync = cd9660_fsync,
.vop_remove = cd9660_remove,
patch to add support for Intel 82567V-4 to pcidevs and em(4)
Hey all,
Here's a diff for adding the product ID for the Intel 82567V-4 NIC to
pcidevs and adding the card to em(4) (along with a corresponding man
update). The product ID came from the FreeBSD em. The information about
jumbo frames came from Intel's jumbo frame notes. This is my first
contribution, so please let me know where I can improve.
Index: share/man/man4/em.4
===
RCS file: /cvs/src/share/man/man4/em.4,v
retrieving revision 1.54
diff -u -p -u -p -r1.54 em.4
--- share/man/man4/em.419 Feb 2016 08:46:29 -1.54
+++ share/man/man4/em.49 Mar 2018 18:09:33 -
@@ -42,7 +42,7 @@ The
driver provides support for PCI, PCI-X and PCI Express Gigabit Ethernet
adapters
based on the Intel 82540EM, 82540EP, 82541EI, 82541ER, 82541GI, 82541PI,
82542,
82543GC, 82544EI, 82544GC, 82545EM, 82545GM, 82546EB, 82546GB, 82547EI,
82547GI,
-82562V, 82563EB, 82564EB, 82566DC, 82566DM, 82571EB, 82571GB, 82572EI,
82572GI,
+82562V, 82563EB, 82564EB, 82566DC, 82566DM, 82567V-3, 82567V-4, 82571EB,
82571GB, 82572EI, 82572GI,
82573E, 82573L, 82573V, 82574L, 82575EB, 82575GB, 82576EB, 82577LC,
82577LM,
82578DC, 82578DM, 82579LM, 82579V, 82580DB, 82580EB, 82583V, I210, I211,
I217,
I218, I219, I350, I354
@@ -166,7 +166,7 @@ The
.Nm
driver supports IPv4 receive IP/TCP/UDP checksum offload and transmit
TCP/UDP
checksum offload on all but 82542-based adapters, VLAN tag insertion and
-stripping, and jumbo frames on all but 82562V, 82566DC/82566DM and
+stripping, and jumbo frames on all but 82562V, 82566DC/82566DM,
82567V-3/82567V-4, and
82573E/82573L/82573V-based adapters.
The 82562V Ethernet controller chip only supports 10/100 media types.
.Pp
Index: sys/dev/pci/if_em.c
===
RCS file: /cvs/src/sys/dev/pci/if_em.c,v
retrieving revision 1.336
diff -u -p -u -p -r1.336 if_em.c
--- sys/dev/pci/if_em.c25 Jul 2017 20:45:18 -1.336
+++ sys/dev/pci/if_em.c9 Mar 2018 18:09:33 -
@@ -191,6 +191,7 @@ const struct pci_matchid em_devices[] =
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_ICH9_IGP_M_V },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_ICH10_D_BM_LF },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_ICH10_D_BM_LM },
+{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_ICH10_D_BM_V },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_ICH10_R_BM_LF },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_ICH10_R_BM_LM },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_ICH10_R_BM_V },
Index: sys/dev/pci/if_em_hw.c
===
RCS file: /cvs/src/sys/dev/pci/if_em_hw.c,v
retrieving revision 1.94
diff -u -p -u -p -r1.94 if_em_hw.c
--- sys/dev/pci/if_em_hw.c12 Aug 2017 16:40:54 -1.94
+++ sys/dev/pci/if_em_hw.c9 Mar 2018 18:09:34 -
@@ -590,6 +590,7 @@ em_set_mac_type(struct em_hw *hw)
break;
case E1000_DEV_ID_ICH10_D_BM_LF:
case E1000_DEV_ID_ICH10_D_BM_LM:
+case E1000_DEV_ID_ICH10_D_BM_V:
hw->mac_type = em_ich10lan;
break;
case E1000_DEV_ID_PCH_M_HV_LC:
Index: sys/dev/pci/if_em_hw.h
===
RCS file: /cvs/src/sys/dev/pci/if_em_hw.h,v
retrieving revision 1.70
diff -u -p -u -p -r1.70 if_em_hw.h
--- sys/dev/pci/if_em_hw.h12 Aug 2017 16:40:54 -1.70
+++ sys/dev/pci/if_em_hw.h9 Mar 2018 18:09:34 -
@@ -541,6 +541,7 @@ int32_t em_check_phy_reset_block(struct
#define E1000_DEV_ID_ICH10_R_BM_V0x10CE
#define E1000_DEV_ID_ICH10_D_BM_LM 0x10DE
#define E1000_DEV_ID_ICH10_D_BM_LF 0x10DF
+#define E1000_DEV_ID_ICH10_D_BM_V0x1525
#define E1000_DEV_ID_PCH_M_HV_LM 0x10EA
#define E1000_DEV_ID_PCH_M_HV_LC 0x10EB
#define E1000_DEV_ID_PCH_D_HV_DM 0x10EF
Index: sys/dev/pci/pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1837
diff -u -p -u -p -r1.1837 pcidevs
--- sys/dev/pci/pcidevs26 Feb 2018 06:46:10 -1.1837
+++ sys/dev/pci/pcidevs9 Mar 2018 18:09:35 -
@@ -3382,6 +3382,7 @@ product INTEL I350_COPPER0x1521I350
product INTEL I350_FIBER0x1522I350 Fiber
product INTEL I350_SERDES0x1523I350 SerDes
product INTEL I350_SGMII0x1524I350 SGMII
+product INTEL ICH10_D_BM_V0x1525ICH10 D BM V
product INTEL 82576_QUAD_CU_ET20x152682576
product INTEL 82580_QUAD_FIBER0x152782580 QF
product INTEL X540T0x1528X540T
Index: sys/dev/pci/pcidevs.h
===
RCS file: /cvs/src/sys/dev/pci/pcidevs.h,v
retrieving revision 1.1830
diff -u -p -u -p -r1.1830 pcidevs.h
--- sys/dev/pci/pcidevs.h26 Feb 2018 06:47:06 -1.1830
+++ sys/dev/pci/pcidevs.h9 Mar 2018 18:09:36 -
@@ -3387,6 +3387,7 @@
#definePCI_PRODUCT_INTEL_I350_FIBER0x1522/* I350 Fiber
Re: sparc64: fledgling QEMU support
Fantastic! Will be great for quick jobs without banshee fan wail and roasted office space in the long summers. Thank you. /jl
Re: Iso image integrity verification
On Wed, Sep 11, 2013 at 08:42:46PM +0300, Valentin Zagura wrote: The idea was to display a checksum of the files on such a https page. Like for example https://www.freebsd.org/releases/9.1R/announce.html at the bottom of the page. On Wed, Sep 11, 2013 at 7:18 PM, Stuart Henderson st...@openbsd.org wrote: On 2013/09/11 16:46, Janne Johansson wrote: So you publish something on a HTTPS page, which means that when the browser says green padlock, it only says: this site was using a key signed by someone who in turn was signed by someone out of a few hundred CAs in a list which include companies in scary countries*. That will help a lot. Add to that most of the top-level CAs are U.S. based and just as likely to bend over as Surprizon, USFest, Microslop, etc. the certificates they issue are probably not worth a damn much less those issued by intermediate CAs. Also it says nothing about the contents of the *files* on that site... You can PGP clearsign webpages. It's kind of cool but how many people are actually going to verify them? Maybe if there was a Firefox plugin grin
pthread_getspecific is too slow
Problem in a nutshell: pthread_getspecific serializes execution of threads using it. Without a better implementation my program doesn't work on OpenBSD. I am trying to port Cilk+ to OpenBSD (5.3). Cilk+ is a multithreaded extension to C/C++. It adds some bookkeeping operations in the prologue of some functions. In many Cilk programs most function calls do this bookkeeping (dynamic count, not static). The per-call bookkeeping calls pthread_getspecific. pthread_getspecific takes out a spinlock. The lock is apparently needed in case of a race with pthread_key_delete. This is unlikely to happen, but I suppose it is possible. Every function call in this multithreaded program serializes waiting on the lock. Also, the cache line with the lock is constantly moving between processors. This is worse than useless for Cilk. You're much better off with a single threaded program. An older version of Cilk used a thread local storage class (__thread). If memory serves, the switch to pthread_getspecific was driven by a few considerations: 1. Thread local variables don't get along well with shared libraries. 2. Thread local variables are less portable. OpenBSD doesn't really support them, for example. They are emulated with pthread_getspecific. 3. On Linux/x86 pthread_getspecific is very fast, essentially a move instruction with a segment override. It seems to me the implementation of pthread_getspecific doesn't need to be as slow as it is. It ought to be possible to have multiple readers be always nonblocking as long as the key list doesn't change, and possibly even if it does change. pthread_getspecific only needs a read lock rather than a mutex. The rwlock in librthread starts with a spinlock, so it's not the answer. Any thoughts?
Re: pthread_getspecific is too slow
I attached a program showing the slowdown. It spawns threads that call
pthread_getspecific in a tight loop. On Linux the wall clock time is
essentially constant for number of threads up to number of processors.
On OpenBSD 5.3 wall clock time increases approximately linearly with
number of processors.
First argument is number of threads. Second argument is number
of loop iterations. The default count on my system gives about
0.4 seconds per active thread. My system is:
cpu0: AMD Phenom(tm) II X4 955 Processor, 3211.18 MHz
cpu1: AMD Phenom(tm) II X4 955 Processor, 3210.78 MHz
cpu2: AMD Phenom(tm) II X4 955 Processor, 3210.78 MHz
cpu3: AMD Phenom(tm) II X4 955 Processor, 3210.78 MHz
We haven't done a lot of work to optimize performance except in
response to specific issues. Sounds like you found one. Would you
mind providing a test case? I just want to make sure we fix the
right thing.
#include stdio.h
#include stdlib.h
#include assert.h
#include pthread.h
const int verbose = 0;
struct data {
pthread_key_t key;
long count;
};
void fn(pthread_key_t key, long count)
{
long i;
pthread_setspecific(key, hi!);
for (i = 0; i count; i++) {
void *v = pthread_getspecific(key);
assert(v);
}
return;
}
void *tstart(void *x)
{
struct data *d = (struct data *)x;
if (verbose)
fputs(Starting thread\n, stdout);
fn(d-key, d-count);
if (verbose)
fputs(Stopping thread\n, stdout);
return 0;
}
#define MAXTHREAD 10
void spawn(pthread_key_t key, int nthreads, long count)
{
pthread_t *threads;
struct data d;
int i, rv;
threads = malloc(nthreads * sizeof (pthread_t));
assert(threads);
d.key = key;
d.count = count;
for (i = 0; i nthreads; i++) {
rv = pthread_create(threads[i], NULL, tstart, d);
assert(!rv);
}
for (i = 0; i nthreads; i++) {
void *rptr = ;
rv = pthread_join(threads[i], rptr);
assert(!rv);
assert(!rptr);
}
}
int main(int argc, char *argv[])
{
int nthreads = 3;
long niter = 2000;
pthread_key_t key;
int rv;
struct timeval t0, t1;
long dts;
int dtu;
if (argc 1) {
nthreads = atoi(argv[1]);
if (nthreads 1 || nthreads 100) {
fputs(Thread count must be integer in range 1..100\n, stderr);
return 1;
}
}
if (argc 2) {
niter = atol(argv[2]);
if (niter 1) {
fputs(Iteration count must be a positive integer\n, stderr);
return 1;
}
}
rv = pthread_key_create(key, 0);
assert(!rv);
rv = gettimeofday(t0, 0);
assert(!rv);
spawn(key, nthreads, niter);
rv = gettimeofday(t1, 0);
assert(!rv);
rv = pthread_key_delete(key);
assert(!rv);
dts = (long)t1.tv_sec - (long)t0.tv_sec;
dtu = (int)t1.tv_usec - (int)t0.tv_usec;
if (dtu 0) {
dtu += 100;
dts -= 1;
}
assert(dts = 0);
assert(dtu = 0);
printf(Time (%d threads, %ld iterations) = %ld.%03u\n,
nthreads, niter, dts, dtu / 1000);
return 0;
}
Re: pthread_getspecific is too slow
I think _spinlock is suboptimal, although that's not the real problem as far as my code is concerned. Spinlock is a loop: while (_atomic_lock(lock-ticket)) _sched_yield(); This causes a system call every time the lock is held by another thread. In many cases the spinlock protects a simple operation, e.g. setting a bit or inserting an item into a list. These operations will complete in less than 100 cycles (two atomics and a few memory references). Performance might be improved by polling the lock for a while before giving up and waiting: int i = 0; /* If the lock is held, wait a little for it to become free before doing expensive scheduling operations. */ while (i++ 50 lock-ticket) asm(pause); /* x86-specific instruction for use in polling loops */ while (_atomic_lock(lock-ticket)) _sched_yield() The pause instruction tells modern x86 processors not to get too aggressive unrolling the loop. Normal behavior hurts performance when the loop is polling memory waiting for a change.
Re: pthread_getspecific is too slow
Here is a diff relative of OpenBSD 5.3 to avoid taking a lock in
pthread_getspecific in the common case where storage for the key is
already allocated.
I have only tested this patch for my use case where a single key is
created once and used many times. In that case, the bottleneck I
observed is gone. My parallel program sees linear speedup.
This patch would be unsafe if elements were ever removed from the
per-thread list of allocated storage. In the 5.3 implementation the
list can only grow. Its size is bounded by PTHREAD_KEYS_MAX so I
do not consider this a leak. Possibly it should be an array instead
of a list.
Index: rthread_tls.c
===
RCS file: /cvs/src/lib/librthread/rthread_tls.c,v
retrieving revision 1.13
diff -c -r1.13 rthread_tls.c
*** rthread_tls.c 6 Nov 2011 11:48:59 - 1.13
--- rthread_tls.c 30 Sep 2013 14:27:13 -
***
*** 96,102
struct rthread_storage *rs;
pthread_t self;
! _spinlock(rkeyslock);
if (!rkeys[key].used) {
rs = NULL;
goto out;
--- 96,107
struct rthread_storage *rs;
pthread_t self;
! /* No lock is needed if
! (1) the key is not valid (undefined behavior)
! (2) storage is already allocated for the key (the linked
! list is only ever modified by adding to the head)
! */
!
if (!rkeys[key].used) {
rs = NULL;
goto out;
***
*** 109,125
break;
}
if (!rs) {
! rs = calloc(1, sizeof(*rs));
! if (!rs)
! goto out;
! rs-keyid = key;
! rs-data = NULL;
! rs-next = self-local_storage;
! self-local_storage = rs;
}
out:
- _spinunlock(rkeyslock);
return (rs);
}
--- 114,138
break;
}
if (!rs) {
! _spinlock(rkeyslock);
! /* Repeat search with lock held */
! for (rs = self-local_storage; rs; rs = rs-next) {
! if (rs-keyid == key)
! break;
! }
! if (!rs) {
! rs = calloc(1, sizeof(*rs));
! if (rs) {
! rs-keyid = key;
! rs-data = NULL;
! rs-next = self-local_storage;
! self-local_storage = rs;
! }
! }
! _spinunlock(rkeyslock);
}
out:
return (rs);
}
Problem in a nutshell: pthread_getspecific serializes execution of
threads using it. Without a better implementation my program doesn't
work on OpenBSD.
I am trying to port Cilk+ to OpenBSD (5.3).
Cilk+ is a multithreaded extension to C/C++. It adds some bookkeeping
operations in the prologue of some functions. In many Cilk programs
most function calls do this bookkeeping (dynamic count, not static).
The per-call bookkeeping calls pthread_getspecific. pthread_getspecific
takes out a spinlock. The lock is apparently needed in case of a race
with pthread_key_delete. This is unlikely to happen, but I suppose it
is possible. Every function call in this multithreaded program
serializes waiting on the lock. Also, the cache line with the lock is
constantly moving between processors.
This is worse than useless for Cilk. You're much better off with a
single threaded program.
An older version of Cilk used a thread local storage class (__thread).
If memory serves, the switch to pthread_getspecific was driven by a few
considerations:
1. Thread local variables don't get along well with shared libraries.
2. Thread local variables are less portable. OpenBSD doesn't really
support them, for example. They are emulated with pthread_getspecific.
3. On Linux/x86 pthread_getspecific is very fast, essentially a move
instruction with a segment override.
It seems to me the implementation of pthread_getspecific doesn't need to
be as slow as it is.
It ought to be possible to have multiple readers be always nonblocking
as long as the key list doesn't change, and possibly even if it does
change. pthread_getspecific only needs a read lock rather than a mutex.
The rwlock in librthread starts with a spinlock, so it's not the answer.
Any thoughts?
Re: pthread_getspecific is too slow
I got an email saying unified diff is preferred, so here's a resend
in that format.
Index: rthread_tls.c
===
RCS file: /cvs/src/lib/librthread/rthread_tls.c,v
retrieving revision 1.13
diff -u -r1.13 rthread_tls.c
--- rthread_tls.c 6 Nov 2011 11:48:59 - 1.13
+++ rthread_tls.c 30 Sep 2013 14:48:18 -
@@ -96,7 +96,12 @@
struct rthread_storage *rs;
pthread_t self;
- _spinlock(rkeyslock);
+ /* No lock is needed if
+ (1) the key is not valid (undefined behavior)
+ (2) storage is already allocated for the key (the linked
+ list is only ever modified by adding to the head)
+ */
+
if (!rkeys[key].used) {
rs = NULL;
goto out;
@@ -109,17 +114,25 @@
break;
}
if (!rs) {
- rs = calloc(1, sizeof(*rs));
- if (!rs)
- goto out;
- rs-keyid = key;
- rs-data = NULL;
- rs-next = self-local_storage;
- self-local_storage = rs;
+ _spinlock(rkeyslock);
+ /* Repeat search with lock held */
+ for (rs = self-local_storage; rs; rs = rs-next) {
+ if (rs-keyid == key)
+break;
+ }
+ if (!rs) {
+ rs = calloc(1, sizeof(*rs));
+ if (rs) {
+rs-keyid = key;
+rs-data = NULL;
+rs-next = self-local_storage;
+self-local_storage = rs;
+ }
+ }
+ _spinunlock(rkeyslock);
}
out:
- _spinunlock(rkeyslock);
return (rs);
}
Here is a diff relative of OpenBSD 5.3 to avoid taking a lock in
pthread_getspecific in the common case where storage for the key is
already allocated.
I have only tested this patch for my use case where a single key is
created once and used many times. In that case, the bottleneck I
observed is gone. My parallel program sees linear speedup.
This patch would be unsafe if elements were ever removed from the
per-thread list of allocated storage. In the 5.3 implementation the
list can only grow. Its size is bounded by PTHREAD_KEYS_MAX so I
do not consider this a leak. Possibly it should be an array instead
of a list.
Re: perlre(1) and substitution evaluations
On 30 November 2013 21:59, Lars Nooden lars.noo...@gmail.com wrote: perlre(1) seems to be missing information about substitution evaluations with the /e option. The functionality is present in perl: It is, however, already documented in perlop(1) John
Debugger for multithreaded OpenBSD programs?
gdb (gdb 6.3) knows about threads but core dumps half the time and is 10 years old. egdb (gdb 7.6) does not work right with multithreaded programs. It sees only one thread. Neither supports set scheduler-locking. Is there any good option for debugging a multithreaded program? I'm running OpenBSD 5.4 on amd64. What's the right mailing list for this, if not tech?
Re: hide kernel threads in ps?
On 1 September 2011 10:21, Uwe Stuehler u...@openbsd.org wrote: If -k would become free for other uses, just for consideration: - in FreeBSD and Solaris, -k is unused - in NetBSD, -k specifies the sort order - in Linux' procps, k specifies the sort order -k in AIX /usr/bin/ps is documented as Lists kernel processes in the manpage. This ps implementation has a split personality like Linux procps, in that SysVish and BSDish syntax both work. AIX /usr/sysv/ps doesn't have a -k option. Tru64 4.0 doesn't seem to support -k at all. AIX is the only commercial UNIX I'm seeing in job listings these days, for what that's worth. Solaris seems to be a corpse, and the flies are swarming. I guess people really don't need DTrace and ZFS after all ;-) John
CSRG history now available as an SVN repository
I recently converted CSRG's SCCS repository holding the original BSD history to a Subversion repository. As a derivative work of CSRG's code base, this repository is available under the terms of the original UC Berkeley license. You can browse the history at http://svnweb.freebsd.org/csrg/ The repository is also available via FTP or HTTP: - ftp://ftp.freebsd.org/pub/FreeBSD/development/CSRG/csrg_svn.tbz - http://freebsd.isc.org/pub/FreeBSD/development/CSRG/csrg_svn.tbz Thanks to Simon Neilsen for putting the repository up on FreeBSD.org and to Kirk McKusick for preserving this history. -- John Baldwin
Re: out of memory errors seen on several AnonCVS servers
On Sun, Mar 03, 2013 at 04:16:30PM +, Stuart Henderson wrote: Summary of off-list mail exchange: anoncvs.usa consistently has a realloc failure in xenocara/font/misc-misc/18x18ja.bdf, some other servers have a failure the first time checking this file out when it's part of the whole directory, but resuming or checking out individually does work. $ cvs -d anon...@anoncvs.spacehopper.org:/cvs get xenocara/font/misc-misc U xenocara/font/misc-misc/10x20.bdf U xenocara/font/misc-misc/12x13ja.bdf cvs [server aborted]: out of memory; can not reallocate 3833880 bytes I got this error consistently with anoncvs.openbsd.org as well, on both amd64 and mips64el. My use case is cvs -d$CVSROOT up -Pd for each of src, xenocara and ports (normal tracking of -stable). I believe I got the error on various other CVS servers until I started using spacehopper. I haven't seen the problem again. Thanks Stuart. /jl -- ASCII ribbon campaign ( ) Powered by Lemote Fuloong against HTML e-mail X Loongson MIPS and OpenBSD and proprietary/ \http://www.mutt.org attachments / \ Code Blue or Go Home! Encrypted email preferred PGP Key 2048R/DA65BC04
Hello8
Hello, What have you been up to ? Tell you a good news. At last few days,My friend Jack told me where was called the factory of world.All the things is very cheap. Register to be their members as soon as possible, during this time, they have discount sales, many surprises are waiting for you. what's more it is very convenient. The price of products is great low from there. But very perfect. Its incredible! For example: laptops, cell phone, digital cameras, LCD TV, GPS and so on. Remarkably,they have a very excellent after-sale service. You can log on their website yotops.com I would like you to have a pleasant shopping! Sincerely yours
Re: NTP
On Fri, Dec 19, 2014 at 06:22:47PM -0700, Theo de Raadt wrote: The ntp daemon included in OpenBSD is our own openntpd, written from scratch. openntpd is not vulnerable. Thank you OpenBSD people and project. I just shitcanned ntp on my Linux box and replaced it with openntpd. I plan to do the same on my Solaris boxes ASAP. It has become abundantly clear that it is very difficult to push lessons regarding better software practices into the greater open source community and the vendors who live off the teat. I'm tired of this kind of attitude where people who should know better write code that sort of works in some situations with all the options you never need. There is much to be said for something well defined that solves a problem and avoids others simply by paying attention and doing things right instead of trying to support every possible feature at the expense of safety and correctness. Thank you for knowing better and doing better. /jl -- ASCII ribbon campaign ( ) Powered by Lemote Fuloong against HTML e-mail X Loongson MIPS and OpenBSD and proprietary/ \http://www.mutt.org attachments / \ Code Blue or Go Home! Encrypted email preferred PGP Key 2048R/DA65BC04
Re: additional drm fixes from linux-stable 3.10.y
ATI EHCI root hub rev 2.00/1.00 addr 1 piixpm0 at pci0 dev 20 function 0 ATI SBx00 SMBus rev 0x13: SMI iic0 at piixpm0 spdmem0 at iic0 addr 0x50: 2GB DDR2 SDRAM non-parity PC2-5300CL5 spdmem1 at iic0 addr 0x51: 2GB DDR2 SDRAM non-parity PC2-5300CL5 pciide0 at pci0 dev 20 function 1 ATI SB600 IDE rev 0x00: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility azalia0 at pci0 dev 20 function 2 ATI SBx00 HD Audio rev 0x00: apic 8 int 16 azalia0: codecs: Analog Devices AD1983 audio0 at azalia0 pcib0 at pci0 dev 20 function 3 ATI SB600 ISA rev 0x00 ppb1 at pci0 dev 20 function 4 ATI SB600 PCI rev 0x00 pci2 at ppb1 bus 2 rl0 at pci2 dev 2 function 0 Realtek 8139 rev 0x10: apic 8 int 22, address 00:40:f4:6c:99:b2 rlphy0 at rl0 phy 0: RTL internal PHY bce0 at pci2 dev 9 function 0 Broadcom BCM4401B1 rev 0x02: apic 8 int 21, address 00:1d:09:16:ca:2e bmtphy0 at bce0 phy 1: BCM4401 10/100baseTX PHY, rev. 0 usb1 at ohci0: USB revision 1.0 uhub1 at usb1 ATI OHCI root hub rev 1.00/1.00 addr 1 usb2 at ohci1: USB revision 1.0 uhub2 at usb2 ATI OHCI root hub rev 1.00/1.00 addr 1 usb3 at ohci2: USB revision 1.0 uhub3 at usb3 ATI OHCI root hub rev 1.00/1.00 addr 1 usb4 at ohci3: USB revision 1.0 uhub4 at usb4 ATI OHCI root hub rev 1.00/1.00 addr 1 usb5 at ohci4: USB revision 1.0 uhub5 at usb5 ATI OHCI root hub rev 1.00/1.00 addr 1 isa0 at pcib0 isadma0 at isa0 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard pcppi0 at isa0 port 0x61 spkr0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 uhidev0 at uhub1 port 1 configuration 1 interface 0 Logitech Optical USB Mouse rev 2.00/3.40 addr 2 uhidev0: iclass 3/1 ums0 at uhidev0: 3 buttons, Z dir wsmouse0 at ums0 mux 0 uhub6 at uhub1 port 2 Dell Dell USB Keyboard Hub rev 1.10/48.01 addr 3 uhidev1 at uhub6 port 1 configuration 1 interface 0 Dell Dell USB Keyboard Hub rev 1.10/48.00 addr 4 uhidev1: iclass 3/1 ukbd0 at uhidev1: 8 variable keys, 6 key codes wskbd1 at ukbd0 mux 1 uhidev2 at uhub6 port 1 configuration 1 interface 1 Dell Dell USB Keyboard Hub rev 1.10/48.00 addr 4 uhidev2: iclass 3/0, 3 report ids uhid0 at uhidev2 reportid 1: input=1, output=0, feature=0 uhid1 at uhidev2 reportid 2: input=1, output=0, feature=0 uhid2 at uhidev2 reportid 3: input=3, output=0, feature=0 vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets root on sd0a (387205e18729d3cc.a) swap on sd0b dump on sd0b drm: initializing kernel modesetting (RS400 0x1002:0x5A61 0x1028:0x01E5). radeondrm0: VRAM: 32M 0xCE00 - 0xCFFF (32M used) radeondrm0: GTT: 512M 0xA000 - 0xBFFF drm: PCIE GART of 512M enabled (table at 0xCCD6D000). error: [drm:pid0:r100_ring_test] *ERROR* radeon: ring test failed (scratch(0x15E4)=0xCAFEDEAD) error: [drm:pid0:r100_cp_init] *ERROR* radeon: cp isn't working (-22). error: [drm:pid0:rs400_startup] *ERROR* failed initializing CP (-22). error: [drm:pid0:rs400_init] *ERROR* Disabling GPU acceleration error: [drm:pid0:r100_cp_fini] *ERROR* Wait for CP idle timeout, shutting down CP. error: [drm:pid0:r100_cp_disable] *ERROR* Failed to wait GUI idle while programming pipes. Bad things might happen. drm: radeon: cp finalized radeondrm0: 1280x1024 wsdisplay0 at radeondrm0 mux 1: console (std, vt100 emulation), using wskbd0 wskbd1: connecting to wsdisplay0 wsdisplay0: screen 1-5 added (std, vt100 emulation) -- John Merriam
Re: ksh version lies
On 2/17/2015 7:40 PM, Ted Unangst wrote: Jérémie Courrèges-Anglas wrote: Ted Unangst t...@tedunangst.com writes: [...] So let's return to the top. What does PD KSH in KSH_VERSION mean? What does one do differently if that string is present or missing? sigh pdksh is not the same thing as ksh88 or ksh93. And not the same thing as mksh, which has grew features since it was based on pdksh from the OpenBSD tree. And you may want to avoid known problems in some of those, or use known nice features in others, whether it is in scripts or your dotfiles. But for this obviously you have to know which shell you're using. Your proposal to remove the variable or to change significantly its content breaks other people's way to use ksh. I'm asking specifically what those features are. Well, good luck with that. As things stand, we need to make a list of features *not* to implement, lest people's version tests become incorrect. Are you genuinely afraid that people won't be able to use the features you plan to implement in ksh? Do you actually think that third-party shell developers out there have stopped implementing features just because ill-oriented users may make bad uses of $WHATEVERSH_VERSION? In short, I think KSH_VERSION encompasses all the badness of web pages that check USER_AGENT. We should not perpetuatate such silliness. Feel free to send this straight to the circular file, but I have been watching this discussion with some interest and figured I would add a couple cents to it. From what I can see the options are: 1) Leave OpenBSD ksh version string as it is which references only PD KSH. 2) Remove it completely as proposed by tedu. 3) Change it to something else not referencing PD KSH like OpenBSD ksh 5.7. 4) Change it to something else referencing PD KSH like OpenBSD ksh 5.7; based on PD KSH v5.2.14 as proposed by djm. 5) Change it to something that does not include version numbers like OpenBSD ksh or OpenBSD ksh based on PD KSH. I think option one is the least preferable if it isn't really PD KSH anymore. Options 2 and 5 are set and forget. Options 3 and 4 need to be bumped for each ksh/OpenBSD release. Personally I don't care what $???_VERSION is (or if it exists at all) in a shell I'm writing for. If I'm using #!/bin/sh, I'll stick to standard Bourne shell. If it's #!/bin/bash, it'll be Bash. If it's #!/bin/ksh, I'll try to stick with features common to all Korn shell variants. I definitely agree that the silliness of checking a version string to possibly use some exotic or non-standard feature of a particular flavor of a particular family of shells is not a good idea when writing a shell script. If you can't do what you want without relying on that particular feature then maybe what you're writing shouldn't be a shell script. If it's a bug in a particular flavor of a shell, then instead of checking for and working around it, report the bug to the author/maintainer. -- John Merriam
Re: ksh version lies
On Tue, 17 Feb 2015, Adam Thompson wrote: On 2015-02-17 08:06 PM, John Merriam wrote: I definitely agree that the silliness of checking a version string to possibly use some exotic or non-standard feature of a particular flavor of a particular family of shells is not a good idea when writing a shell script. If you can't do what you want without relying on that particular feature then maybe what you're writing shouldn't be a shell script. If it's a bug in a particular flavor of a shell, then instead of checking for and working around it, report the bug to the author/maintainer. Jumping in late in the conversation... This is not an academic point; as an ISV, I've had to do this sort of thing in the past, and will have to do so again in the future. There is no standard or universal way to detect what version of what shell happened to get invoked on what operating system, so an ISV must rely on tricks and silliness like checking the version string to make what amounts to an educated guess. For example, I have a customer that must run a specific (non-current) version of HP-UX due to hard dependencies in a mission-critical line-of-business app. Yes, that means there's a foundational problem, but it would cost ~$100M to fix now. Not going to happen. Report the bug to the author/maintainer is all very well, but HP isn't going to issue a patch for an old version of HP-UX just because one customer complains about /bin/ksh behaving badly. (Actually, they very well might, given sufficient financial incentive, but that's another story altogether...) Meanwhile, portable shell scripts must continue to run - portably - across multiple OSes. Array handling is the big bugbear I run into; if I can handle arrays inside the shell, I don't have to resort to using tmpfiles and fork/exec'ing multiple external utilities to simulate the functionality. Which means, firstly, determining if I'm inside something ksh-like or bash-like, or if I'm running in a simple POSIX shell. There are virtually no safe assumptions that can be made in portable shell scripting - how was the script invoked? Sourced? Hash-bang? Explicit /bin/sh script invocation? It's a mess, despite POSIX' attempt to unify things; the choice is to either code for lowest-common-denominator, which typically results in payloads up to 10x larger and that run up to 10x slower, or to probe for advanced features and exit cleanly and safely if they're absent. I definitely hear what you're saying. I also have seen issues dealing with arrays in shell scripts. What I do when I want an array in a shell script is to either switch to Perl5 or some other language, or insist that the shell be Bash. Say what you want about Bash but I have found it to be relatively consistent and available on many platforms. I would guess that option 5 in my original post in this thread (a version string with no version numbers with or without PD KSH in it) would probably keep the majority of shell script writers happy (especially if it does have PD KSH in it) and would involve no maintenance down the line. But maybe that's not the case. Are there large numbers of scripts keying off the version numbers out there? -- John Merriam
Re: libxfont errata
On 2015-03-18 04:06, Ted Unangst wrote: Patches are now available to fix buffer overflows in libXfont. This issue affects 5.5, 5.6, and the forthcoming 5.7 release. For more details, refer to the X.org advisory: http://www.x.org/wiki/Development/Security/Advisory-2015-03-17/ 5.5 patch: http://ftp.openbsd.org/pub/OpenBSD/patches/5.5/common/023_libxfont.patch.sig 5.6 patch: http://ftp.openbsd.org/pub/OpenBSD/patches/5.6/common/019_libxfont.patch.sig I'm sure most people could figure this out, but: --- 019_libxfont.patch.sig Wed Mar 18 01:25:07 2015 +++ 019_libxfont.patch.sig.fixedWed Mar 18 10:14:11 2015 @@ -17,7 +17,7 @@ Then build and install a new libXfont: -cd /usr/xenocara/lib/libXont +cd /usr/xenocara/lib/libXfont make -f Makefile.bsd-wrapper obj make -f Makefile.bsd-wrapper build Looks like the 5.5 patch has the same typo. Also wanted to pass along a BIG THANK YOU to all the OpenBSD developers for all the great work you do! -- John Merriam
Re: libxfont errata
On 2015-03-18 04:05, Ted Unangst wrote: Patches are now available to fix buffer overflows in libXfont. This issue affects 5.5, 5.6, and the forthcoming 5.7 release. For more details, refer to the X.org advisory: http://www.x.org/wiki/Development/Security/Advisory-2015-03-17/ 5.5 patch: http://ftp.openbsd.org/pub/OpenBSD/patches/5.5/common/023_libxfont.patch.sig 5.6 patch: http://ftp.openbsd.org/pub/OpenBSD/patches/5.6/common/019_libxfont.patch.sig I sent this earlier but I think it didn't go through for some reason so I am resending it. If it did go through the first time, sorry for the noise. Original message below... I'm sure most people could figure this out, but: --- 019_libxfont.patch.sig Wed Mar 18 01:25:07 2015 +++ 019_libxfont.patch.sig.fixedWed Mar 18 10:14:11 2015 @@ -17,7 +17,7 @@ Then build and install a new libXfont: -cd /usr/xenocara/lib/libXont +cd /usr/xenocara/lib/libXfont make -f Makefile.bsd-wrapper obj make -f Makefile.bsd-wrapper build Looks like the 5.5 patch has the same typo. Also wanted to pass along a BIG THANK YOU to all the OpenBSD developers for all the great work you do! -- John Merriam
Re: libre/openssl patches available
On Thu, 19 Mar 2015, John Merriam wrote: On Thu, 19 Mar 2015, Ted Unangst wrote: Ted Unangst wrote: Patches are now available to fix a variety of issues in libcrypto and libssl. 5.5 patch: http://ftp.openbsd.org/pub/OpenBSD/patches/5.5/common/024_openssl.patch.sig And I boned the instructions again. cd /usr/src/lib/libcrypto/crypto should be cd /usr/src/lib/libssl/crypto instead. Hmmm: # cd /usr/src/lib/libssl/crypto ksh: cd: /usr/src/lib/libssl/crypto - No such file or directory On 5.6-release amd64. I'll look back to see if I can find it but is there a different process to build all of libssl to be sure it's all patched? Nevermind. I see my failure. That change is for the 5.5 patch only I'm thinking. Sorry for the noise again. -- John Merriam
Re: Speedup sdhc(4)
On 4/28/16 2:30 PM, Mark Kettenis wrote: So here are just the bits that add DMA support. Since Theo likes this so much, I'd like to move forward with this. ok? Hi Mark, This diff seems to break things on my Lenovo Ideapad 100s. The 100s has an internal eMMC and a microSD card slot. As far as I can tell, reading from a microSD card breaks both eMMC and microSD. Reading from the eMMC, twice for good measure: # dd if=/dev/rsd0c of=/dev/null bs=1M count=1 1+0 records in 1+0 records out 1048576 bytes transferred in 0.191 secs (5486853 bytes/sec) # dd if=/dev/rsd0c of=/dev/null bs=1M count=1 1+0 records in 1+0 records out 1048576 bytes transferred in 0.190 secs (5506851 bytes/sec) Reading from the microSD: # dd if=/dev/rsd1c of=/dev/null bs=1M count=1 dd: /dev/rsd1c: Input/output error 0+0 records in 0+0 records out 0 bytes transferred in 3.019 secs (0 bytes/sec) Reading from the eMMC again: # dd if=/dev/rsd0c of=/dev/null bs=1M count=1 dd: /dev/rsd0c: Input/output error 0+0 records in 0+0 records out 0 bytes transferred in 0.004 secs (0 bytes/sec) At this point the system is unusable, and there's nothing else interesting in dmesg. I'm not sure how to troubleshoot this, but the dmesg after the commands above and an attempted shutdown is below. I'm running the 4/28 snapshot and applied the diff to kernel source synced a few hours ago. Let me know what else I can provide. Thanks, John OpenBSD 5.9-current (GENERIC.MP) #2: Fri Apr 29 10:55:36 EDT 2016 j...@ideapad.my.domain:/home/john/src/sys/arch/amd64/compile/GENERIC.MP RTC BIOS diagnostic error ff<clock_battery,ROM_cksum,config_unit,memory_size,fixed_disk,invalid_time> real mem = 2056638464 (1961MB) avail mem = 1990131712 (1897MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x7b2ae000 (38 entries) bios0: vendor LENOVO version "E2CN13WW" date 12/22/2015 bios0: LENOVO 80R2 acpi0 at bios0: rev 2 acpi0: sleep states S5 acpi0: tables DSDT FACP UEFI TCPA MSDM UEFI OEM0 DBG2 HPET LPIT APIC MCFG SLIC SSDT SSDT SSDT SSDT SSDT TPM2 SSDT SSDT SSDT FPDT WDAT CSRT BGRT acpi0: wakeup devices WLAN(S0) RTLW(S0) acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Atom(TM) CPU Z3735F @ 1.33GHz, 1333.58 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT cpu0: 1MB 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 83MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Atom(TM) CPU Z3735F @ 1.33GHz, 1333.34 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT cpu1: 1MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Atom(TM) CPU Z3735F @ 1.33GHz, 1333.34 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT cpu2: 1MB 64b/line 16-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Atom(TM) CPU Z3735F @ 1.33GHz, 1333.34 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT cpu3: 1MB 64b/line 16-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 87 pins ioapic0: misconfigured as apic 1, remapped to apid 2 acpimcfg0 at acpi0 addr 0xe000, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0 C3: state 7: substate 4 >= num 3: C2(10@500 mwait.1@0x51), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0 C3: state 7: substate 4 >= num 3: C2(10@500 mwait.1@0x51), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0 C3: state 7: substate 4 >= num 3: C2(10@500 mwait.1@0x51), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0 C3: state 7: substate 4 >= num 3: C2(10@500 mwait.1@0x51), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: WWPR, resource for HS03, MODM acpipwrres1 at acpi0: PLPE acpipwrres2 at acpi0: USBC, r
Re: Speedup sdhc(4)
On 5/1/16 3:09 PM, Mark Kettenis wrote: Date: Sat, 30 Apr 2016 13:31:21 +0200 (CEST) From: Mark Kettenis <mark.kette...@xs4all.nl> From: John Troy <j...@noxi.us> Date: Fri, 29 Apr 2016 11:56:24 -0400 On 4/28/16 2:30 PM, Mark Kettenis wrote: So here are just the bits that add DMA support. Since Theo likes this so much, I'd like to move forward with this. ok? Hi Mark, This diff seems to break things on my Lenovo Ideapad 100s. The 100s has an internal eMMC and a microSD card slot. As far as I can tell, reading from a microSD card breaks both eMMC and microSD. Reading from the eMMC, twice for good measure: # dd if=/dev/rsd0c of=/dev/null bs=1M count=1 1+0 records in 1+0 records out 1048576 bytes transferred in 0.191 secs (5486853 bytes/sec) # dd if=/dev/rsd0c of=/dev/null bs=1M count=1 1+0 records in 1+0 records out 1048576 bytes transferred in 0.190 secs (5506851 bytes/sec) Reading from the microSD: # dd if=/dev/rsd1c of=/dev/null bs=1M count=1 dd: /dev/rsd1c: Input/output error 0+0 records in 0+0 records out 0 bytes transferred in 3.019 secs (0 bytes/sec) Reading from the eMMC again: # dd if=/dev/rsd0c of=/dev/null bs=1M count=1 dd: /dev/rsd0c: Input/output error 0+0 records in 0+0 records out 0 bytes transferred in 0.004 secs (0 bytes/sec) At this point the system is unusable, and there's nothing else interesting in dmesg. Can reproduce this on the Lenovo stick, which is in many ways very similar to the 100s. So far I've not found a solution. Since the diff gives significant improvements and seems to be completely stable if I leave the SD card slot empty, I've committed it anyway. You may want to revert the changes to dev/acpi/sdhc_acpi.c for now if you intend to use the SD card slot on the 100s. Hopefully I'll figure out what the problem is soon. Otherwise I might selectively disable DMA support on this hardware. Found the problem. Should be fixed with: CVSROOT:/cvs Module name:src Changes by: kette...@cvs.openbsd.org2016/05/01 11:13:55 Modified files: sys/dev/sdmmc : sdhc.c Log message: Always write block count. This fixes the DMA issues on Bay Trail. Works like a charm. Raw eMMC reads went from ~3.5MB/s to ~35MB/s and microSD reads went from ~3MB/s to ~10MB/s. Writes to filesystems on these devices are a good deal quicker as well, about 4x and 2x, respectively. These changes make a big difference in terms of usability. Thanks for your work on this, Mark. -John
libressl-2.5.1 patches
libressl-2.5.1-medusade.tar.gz Description: GNU Zip compressed data
Password corruption in adduser
Hi all, I've noticed something strange in adduser -- when attempting to add a user completely though command line argument it seems to corrupt the entry in /etc/master.passwd. Example: $ echo "HorseBatteryStaple" | encrypt $2b$09$ssZSLC6laHsTS7O2FwJ4Mufw6mSS/FGXw.9oNjr3BLTS7DJp5n4M2 # adduser -silent -noconfig -uid_start 5000 -group USER -shell ksh \ -message no -batch some.user "" "Some User" \ $2b$09$ssZSLC6laHsTS7O2FwJ4Mufw6mSS/FGXw.9oNjr3BLTS7DJp5n4M2 Added user ``some.user'' # vipw ... some.user:b/bin/ksh9/9uoOrbTRaf//3ZprAb9k.hOpfe9vYVqjf1a:5000:5000:: \ 0:0:Some User:/home/some.user:/bin/ksh ... As you can see the password entry gets corrupted with a 'b/bin/ksh...' This behavior does not occur with -unencrypted. Behavior *is* present when hash is wrapped in " Take care, John
Re: Improve error message in rcctl(8)
Antoine,
I've been following this thread and noted that you did add _rc_check_name
to rc.subr and call it in rcctl. This looks clean and comprehensive. Two
thoughts, however:
1. I had to look at the pattern match in _rc_check_name for a while
before I understood it; the suggestion below makes it clearer for
someone like myself
2. The second suggestion handles the edge case where the argument to rcctl
matches the name of a subdirectory of rc.d. Note that ls_rcscripts()
earlier in the script has the same test
John
Index: etc/rc.d/rc.subr
===
RCS file: /cvs/src/etc/rc.d/rc.subr,v
retrieving revision 1.116
diff -u -p -r1.116 rc.subr
--- etc/rc.d/rc.subr7 Sep 2016 13:12:42 - 1.116
+++ etc/rc.d/rc.subr15 Sep 2016 15:58:29 -
@@ -61,7 +61,7 @@ _rc_rm_runfile() {
}
_rc_check_name() {
- [[ $1 == +([_[:alpha:]])+(|[_[:alnum:]]) ]]
+ [[ $1 == +([_[:alpha:]])*([_[:alnum:]]) ]]
}
_rc_do() {
Index: usr.sbin/rcctl/rcctl.sh
===
RCS file: /cvs/src/usr.sbin/rcctl/rcctl.sh,v
retrieving revision 1.105
diff -u -p -r1.105 rcctl.sh
--- usr.sbin/rcctl/rcctl.sh 7 Sep 2016 13:13:13 - 1.105
+++ usr.sbin/rcctl/rcctl.sh 15 Sep 2016 15:58:29 -
@@ -141,8 +141,8 @@ svc_is_avail()
local _svc=$1
_rc_check_name "${_svc}" || return
- [ -x "/etc/rc.d/${_svc}" ] && return
- svc_is_special ${_svc}
+ [[ -x "/etc/rc.d/${_svc}" && ! -d "/etc/rc.d/${_svc}" ]] \
+ || svc_is_special ${_svc}
}
svc_is_base()
Sent: Tuesday, September 06, 2016 at 2:13 PM
From: "Antoine Jacoutot" <ajacou...@bsdfrog.org>
To: "Anthony Coulter" <b...@anthonycoulter.name>
Cc: tech@openbsd.org
Subject: Re: Improve error message in rcctl(8)
On Tue, Sep 06, 2016 at 04:09:49PM -0400, Anthony Coulter wrote:
> Regarding Jiri's suggestion: Here is a diff that makes
> `rcctl ls all' only list executable files with valid service
> names.
>
> This diff also fixes two problems with my original submission:
> 1. The use of `[' instead of `[[' causes filename expansion to
> take place on the right-hand side of the comparison; you get
> different results depending on which directory you're sitting
> in when you test. I have switched to `[[' to fix that problem.
> 2. There was a stray closing brace that somehow did not cause
> problems in testing.
That's not enough. It cannot start with a digit either.
I'm working on a better diff.
> Index: usr.sbin/rcctl/rcctl.sh
> ===
> RCS file: /open/anoncvs/cvs/src/usr.sbin/rcctl/rcctl.sh,v
> retrieving revision 1.104
> diff -u -p -r1.104 rcctl.sh
> --- usr.sbin/rcctl/rcctl.sh 30 Jul 2016 06:25:21 - 1.104
> +++ usr.sbin/rcctl/rcctl.sh 6 Sep 2016 20:03:33 -
> @@ -53,8 +53,8 @@ ls_rcscripts()
>
> cd /etc/rc.d && set -- *
> for _s; do
> - [[ ${_s} = *.* ]] && continue
> - [ ! -d "${_s}" ] && echo "${_s}"
> + [[ "${_s}" != +([_0-9A-Za-z]) ]] && continue
> + [ -x "${_s}" ] && echo "${_s}"
> done
> }
>
> @@ -182,7 +182,7 @@ svc_is_meta()
> svc_is_special()
> {
> local _svc=$1
> - [ -n "${_svc}" ] || return
> + [[ "${_svc}" = +([_0-9A-Za-z]) ]] || return
>
> local _cached _ret
>
>
--
Antoine
TXIC TX382B UART controller support
I'm not an OpenBSD user, I'm not asking for help. I'm posting here because OpenBSD was the only mention of this device I found when searching the net. My device also identifies as 0x4651 0x3273, though marked as PCI 60806 instead of TX382B. I never found a data sheet for it, but after some trial and error reverse engineering, I discovered its quirks. a) As reported in the subject thread, MCR loopback is non functional. But the UART has a standard 16 byte FIFO, thus probing its depth is not necessary. b) In a normal UART, you see THRE interrupt after clearing higher priority interrupts (LINE and RECV). As the PC16550D data sheet says, THRE is reset by: "Reading the IIR Register (if source of interrupt) or Writing into the Transmitter Holding Register" The point of note is that reading the IIR will not clear THRE from the IIR unless it's the source of interrupt. Reading the IIR when LINE and RECV interrupts are active will leave the THRE indication intact, and you will see it as expected, after LINE and RECV interrupts are cleared. However, the 60806 / TX382B does not work that way. Any read of the IIR clears the THRE indication. So if you get a LINE or RECV indication when reading IIR, if THRE was there, it's now lost. You only see a THRE indication if it was the highest priority interrupt pending when reading the IIR. Losing THRE interrupts is a problem if your code assumes a standard UART and relies on THRE interrupts to keep transmission going. Once I understood that quirk, I was able to work around it. c) Unlike a normal UART, you cannot clear LSR error bits or LINE status interrupt by reading the LSR. This will cause havoc when you get a frame or break error, because you can't clear the interrupt, and that means trouble. I was able to crash linux by inducing a break / frame error when powering off my device attached to a null modem cable. This had me stumped at first, I thought it made the UART worthless. But after more testing, I discovered the LSR error bits and LINE status interrupt *auto* clear themselves, upon reception of the next good data byte. Until that happens, the error bits and LINE status interrupt are stuck on. Understanding that quirk, you can work around it too.
undocumented (?) test -e behaviour with symbolic links
Not sure if folks are interested in this or not, but it sure caused me some angst this morning. OSX has the same behaviour and also doesn't document it. I assume it has been that way for a long, long time. My first patch. Thanks for all the cool stuff :-) Index: bin/test/test.1 === RCS file: /cvs/src/bin/test/test.1,v retrieving revision 1.33 diff -u -p -r1.33 test.1 --- bin/test/test.1 16 Aug 2016 18:51:25 - 1.33 +++ bin/test/test.1 1 Oct 2016 03:37:23 - @@ -92,7 +92,9 @@ exists and is a directory. .It Fl e Ar file True if .Ar file -exists (regardless of type). +exists, unless +.Ar file +is a dangling symbolic link. .It Fl f Ar file True if .Ar file
Re: undocumented (?) test -e behaviour with symbolic links
So it does. Not sure how I missed that, but I did. Oh well. Thanks :-/ John On 1 October 2016 at 14:31, Theo Buehler <t...@math.ethz.ch> wrote: > On Sat, Oct 01, 2016 at 01:38:49PM +1000, john slee wrote: > > Not sure if folks are interested in this or not, but it sure caused me > some > > angst this morning. OSX has the same behaviour and also doesn't document > > it. I assume it has been that way for a long, long time. > > > > My first patch. Thanks for all the cool stuff :-) > > > > Index: bin/test/test.1 > > === > > RCS file: /cvs/src/bin/test/test.1,v > > retrieving revision 1.33 > > diff -u -p -r1.33 test.1 > > --- bin/test/test.1 16 Aug 2016 18:51:25 - 1.33 > > +++ bin/test/test.1 1 Oct 2016 03:37:23 - > > @@ -92,7 +92,9 @@ exists and is a directory. > > .It Fl e Ar file > > True if > > .Ar file > > -exists (regardless of type). > > +exists, unless > > +.Ar file > > +is a dangling symbolic link. > > Thanks, but I think that we document it. It seems unnecessary and > inconsistent to add that caveat only to -e. The manual says explicitly: > > Symbolic links are followed for all primaries except -h and -L. > > So if your file is a dangling symbolic link, it is followed, and since > the file it points to doesn't exist, the expression evaluates to false. > > POSIX is also unambiguous about this behavior: > >-e pathname > True if pathname resolves to an existing directory entry. > False if pathname cannot be resolved. > >[...] > >With the exception of the -h pathname and -L pathname primaries, if > a >pathname argument is a symbolic link, test shall evaluate the >expression by resolving the symbolic link and using the file > referenced >by the link. > > > .It Fl f Ar file > > True if > > .Ar file > >
Re: reloading pf through ansible easy hook
On Tue, Nov 22, 2016 at 10:46 AM, John Boeske wrote
> On Mon, Nov 21, 2016 at 3:48 PM, Antoine Jacoutet wrote
> > On Mon, Nov 21, 2016 at 05:34:35PM -0500, sven falempin wrote:
> > > Ansible is already managing pkg and service of openBSD , cool
> > >
> > > If one want to manage pf with it, and push or modify a few files,
> > > on must run - command: /sbin/pfctl -f {{ dank.config }}
> > >
> > > Yet - service could be use, if this glue was in the rc.d directory :
> >
> > You can easily create an ansible role|module to do that natively.
> > The rc.d framework is only meant to handle real daemons.
> > We don't want it to manage pf, quota, network, mounts...
>
> I don't understand this philosophical point - why wouldn't you want
> the rc.d framework to manage pf, quota, etc. whenever it's natural.
> With pf, for example, it surely is.
>
> One of the reasons I loved AIX's System Resource Controller (SRC)
> was that it did present a unified management interface to all
> system resources whether daemon or built in.
> Using a consistent rc.d/rcctl framework to manage system services
> and daemons - even pkg_add daemons - seems a good idea. Consistent
> interfaces, fewer interfaces, less special-casing all simplify
> management, thus minimize the chance of error and enhance security.
>
> This is true whether management is local or through a remote tool
> like ansible. Or?
Oops. Meant "pkg_script daemons" above...
John
Re: reloading pf through ansible easy hook
On Mon, Nov 21, 2016 at 3:48 PM, Antoine Jacoutet wrote
> On Mon, Nov 21, 2016 at 05:34:35PM -0500, sven falempin wrote:
> > Ansible is already managing pkg and service of openBSD , cool
> >
> > If one want to manage pf with it, and push or modify a few files,
> > on must run - command: /sbin/pfctl -f {{ dank.config }}
> >
> > Yet - service could be use, if this glue was in the rc.d directory :
>
> You can easily create an ansible role|module to do that natively.
> The rc.d framework is only meant to handle real daemons.
> We don't want it to manage pf, quota, network, mounts...
I don't understand this philosophical point - why wouldn't you want
the rc.d framework to manage pf, quota, etc. whenever it's natural.
With pf, for example, it surely is.
One of the reasons I loved AIX's System Resource Controller (SRC)
was that it did present a unified management interface to all
system resources whether daemon or built in.
Using a consistent rc.d/rcctl framework to manage system services
and daemons - even pkg_add daemons - seems a good idea. Consistent
interfaces, fewer interfaces, less special-casing all simplify
management, thus minimize the chance of error and enhance security.
This is true whether management is local or through a remote tool
like ansible. Or?
John
Re: Sync calendars.judaic with reality
On Mon, 2018-11-12 at 06:57 +, Jason McIntyre wrote: > On Sun, Nov 11, 2018 at 07:36:55PM -0500, Brian Callahan wrote: > > Hi tech -- > > > > Reminded by the recent email to tech@ about calendar.christian, I > > took a look at syncing calendar.judaic. > > > > This diff does the following: > > 1. Sync the holiday days that are not connected to Pesach, which > > on > > our calendar is Chanukah, Fast of 10 Tevet, and Yom Yerushalayim. I am not sure what this means. All of the Jewish holidays move on the civil calendar year to year. However, since every time the calendar includes an additional month (a second Adar) the month is inserted before Pesach; therefore the holidays which fall after that time do not move *relative to Pesach* but they do move on the civil calendar. > > 2. Add the holidays that are explicitly mentioned on the Wikipedia > > page of Jewish holidays, which adds Tu B'Shevat to our calendar. > > 3. Replace the year marker on Rosh Hashana with the current Jewish > > year (5741 => 5779). This calendar has to be updated yearly as it > > is anyway, so it seems odd to me not to put the current year if > > we're going to list a year in connection with Rosh Hashanah. > > > > It looks like mickey@ removed Yom HaAtzmaut some years ago due to > > the understanding that this be a religious and not secular > > calendar. Which is a perfectly legitimate stance, as there is no > > universal yes or no as to whether or not the Israeli rememberance > > holidays are religious holidays, both in Israel and in the > > dispora. There is. Yom Hatzmaut, Yom HaShoah, Yom Hazikaron, Yom Yerushalayim are all Israeli (civil) holidays not connected to the Jewish religion. > > So we either need to remove Yom Yerushalayim for the same reason, > > or add back Yom HaAtzmaut, and add Yom HaShoah and Yom Hazikaron. > > Doesn't matter to me either way. It might be nice to include Yom > > HaShoah in either event, as it is likely to become a universal > > Jewish religious holiday within our lifetimes. That is absolutely not true. No major religious authority has ever recognized any of the Israeli civil holidays. > > Whatever is decided > > having Yom Yerushalayim by itself is the strangest of all worlds. > > > > And I'll volunteer to keep this calendar synced since I might be > > the only one who cares about it. > > > > OK? > > > > ~Brian > > > > morning. > > if you're willing to do the work, i say go for it. i don;t have > enough > knowledge about dates/holidays to provide any useful feedback. > > if you have any opinion on the .christian diff, please do reply. i'm > about to as well, but again i just don;t have the knowledge to deal > with this. I can help with this. Contact me offline with any questions. In the diff below I see some conflicts in terms of transliteration. There are two main communities of Jews and the transliterations below do not align with either one in all cases. /jl > > jmc > > > Index: calendar.judaic > > == > > = > > RCS file: /cvs/src/usr.bin/calendar/calendars/calendar.judaic,v > > retrieving revision 1.5 > > diff -u -p -r1.5 calendar.judaic > > --- calendar.judaic 6 Sep 2005 23:42:59 - 1.5 > > +++ calendar.judaic 12 Nov 2018 00:11:04 - > > @@ -7,7 +7,7 @@ > > #ifndef _calendar_judaic_ > > #define _calendar_judaic_ > > > > -Pesach+163 First Day of Rosh Hashanah (Jewish Lunar New Year; > > 5741 == 1980; > > +Pesach+163 First Day of Rosh Hashanah (Jewish Lunar New Year; > > 5779 == 2018; > > sabbatical) > > Pesach+164 Rosh Hashanah (sabbatical) > > Pesach+166 Fast of Gedalya (Murder of Gedalya and subsequent > > Exile; fast day) > > @@ -17,8 +17,9 @@ Pesach+179Succot (sabbatical) > > Pesach+184 Hoshanah Rabba (7th day of Succos) > > Pesach+185 Shmini Atzeres (8th Day of Gathering; sabbatical) > > Pesach+186 Shmini Atzeres/Simchas Torah (Rejoicing of the Law; > > sabbatical) > > -12/12* First Day of Chanukah > > -12/27* Fast of Asara B'Tevet (Babylonians put siege on > > Jerusalem; fast day) > > +12/03* First Day of Chanukah > > +12/18* Fast of Asara B'Tevet (Babylonians put siege on > > Jerusalem; fast day) > > +01/20* Tu B'Shevat (New Year of the Trees) > > Pesach-31 Fast of Esther (Battle of Purim; fast day) > > Pesach-30 Purim (Feast of Lots) > > Pesach-29 Purim (Feast of Lots) > > @@ -27,10 +28,10 @@ Pesach+1Pesach (sabbatical) > > Pesach+6 Pesach (sabbatical) > > Pesach+7 Pesach (Last Day of Passover; 8th day of Pesach; > > sabbatical) > > Pesach+34 Lag Ba`omer (Commemoration of the Great Rebellion) > > -05/22* Yom Yerushalayim (Reunification of Jerusalem) > > +06/01* Yom Yerushalayim (Reunification of Jerusalem) > > Pesach+50 Shavuot (Festival of Weeks; sabbatical) > > Pesach+51 Shavuot (Festival of Weeks; sabbatical) > > -07/10* Fast of Shiv'a Asar B'Tammuz (Romans breach Wall of > > Jerusalem; fast day) > > +07/21*
Re: Sync calendars.judaic with reality
On Mon, 2018-11-12 at 12:38 -0500, Brian Callahan wrote: > > On 11/12/18 11:20 AM, John Long wrote: > > On Mon, 2018-11-12 at 06:57 +, Jason McIntyre wrote: > > > On Sun, Nov 11, 2018 at 07:36:55PM -0500, Brian Callahan wrote: > > > > Hi tech -- > > > > > > > > Reminded by the recent email to tech@ about > > > > calendar.christian, I > > > > took a look at syncing calendar.judaic. > > > > > > > > This diff does the following: > > > > 1. Sync the holiday days that are not connected to Pesach, > > > > which > > > > on > > > > our calendar is Chanukah, Fast of 10 Tevet, and Yom > > > > Yerushalayim. > > > > I am not sure what this means. All of the Jewish holidays move on > > the > > civil calendar year to year. However, since every time the > > calendar > > includes an additional month (a second Adar) the month is inserted > > before Pesach; therefore the holidays which fall after that time > > do > > not move *relative to Pesach* but they do move on the civil > > calendar. > > What are you talking about? This is in reference to the code in > calendar(1) that sets the dates for the Judaic calendar. If you > think > there's something wrong there, I await your patch to > usr.bin/calendar/pesach.c > I haven't seen the code. I responded to the comment that "days are not connected to Pesach." All Jewish holidays are connected to Pesach, it is one of the points from which years are calculated. And my statement above and the explanation how it works is correct as I wrote it. So what are you talking about? Exactly what did I write that you are disputing here? > Yes, I know how the Hebrew calendar works. mickey@'s calculation is > actually quite nice IMO. > > > > 2. Add the holidays that are explicitly mentioned on the > > > > Wikipedia > > > > page of Jewish holidays, which adds Tu B'Shevat to our > > > > calendar. > > > > 3. Replace the year marker on Rosh Hashana with the current > > > > Jewish > > > > year (5741 => 5779). This calendar has to be updated yearly as > > > > it > > > > is anyway, so it seems odd to me not to put the current year > > > > if > > > > we're going to list a year in connection with Rosh Hashanah. > > > > > > > > It looks like mickey@ removed Yom HaAtzmaut some years ago due > > > > to > > > > the understanding that this be a religious and not secular > > > > calendar. Which is a perfectly legitimate stance, as there is > > > > no > > > > universal yes or no as to whether or not the Israeli > > > > rememberance > > > > holidays are religious holidays, both in Israel and in the > > > > dispora. > > > > There is. Yom Hatzmaut, Yom HaShoah, Yom Hazikaron, Yom > > Yerushalayim > > are all Israeli (civil) holidays not connected to the Jewish > > religion. > > > > Reform Judaism and Conservative Judaism (in the US, at least) both > treat > Yom HaShoah as a religious holiday, with both crafting prayers > specifically for the holiday and with Conservative Judaism writing a > new > liturgy for the day. If the calendar we are talking about is supposed to be representative of mainstream Jewish belief and practice which has remained the same for the past 3,500 years then those demominations will need their own calendars. > > This is considered so "common knowledge" that Wikipedia has a whole > section on it: > https://en.wikipedia.org/wiki/Yom_HaShoah#Religious_observances_and_liturgy This is no proof of anything except activism which isn't representative of the Jewish religion. > > Additionally, there is no reason that calendar.judaic cannot be both > a > religious and secular calendar. mickey@ clearly had reasons for > preferring to it to be religious only but I can't go ask him his > reasoning for it. So my question is whether or not people prefer > one > over the other. I slightly prefer it to be both religious and > secular > but I care more about the dates being maintained so am willing to > go > either way. I have no preference either, since I don't use it, rather I use calendars from reliable sources and I have also written my own which aligns with those. Again, I was responding to what Jason wrote. Regardless, some of the holidays mentioned are Jewish, some are Israeli. There is no overlap. > > > > > So we either need to remove Yom Yerushalayim for the same > > > > reason, > > > > or ad
Re: Sync calendars.judaic with reality
On Mon, 2018-11-12 at 15:01 -0500, Brian Callahan wrote: > > On 11/12/18 1:13 PM, John Long wrote: > > On Mon, 2018-11-12 at 12:38 -0500, Brian Callahan wrote: > > > On 11/12/18 11:20 AM, John Long wrote: > > > > On Mon, 2018-11-12 at 06:57 +, Jason McIntyre wrote: > > > > > On Sun, Nov 11, 2018 at 07:36:55PM -0500, Brian Callahan > > > > > wrote: > > > > > > Hi tech -- > > > > > > > > > > > > Reminded by the recent email to tech@ about > > > > > > calendar.christian, I > > > > > > took a look at syncing calendar.judaic. > > > > > > > > > > > > This diff does the following: > > > > > > 1. Sync the holiday days that are not connected to Pesach, > > > > > > which > > > > > > on > > > > > > our calendar is Chanukah, Fast of 10 Tevet, and Yom > > > > > > Yerushalayim. > > > > > > > > I am not sure what this means. All of the Jewish holidays move > > > > on > > > > the > > > > civil calendar year to year. However, since every time the > > > > calendar > > > > includes an additional month (a second Adar) the month is > > > > inserted > > > > before Pesach; therefore the holidays which fall after that > > > > time > > > > do > > > > not move *relative to Pesach* but they do move on the civil > > > > calendar. > > > > > > What are you talking about? This is in reference to the code in > > > calendar(1) that sets the dates for the Judaic calendar. If you > > > think > > > there's something wrong there, I await your patch to > > > usr.bin/calendar/pesach.c > > > > > > > I haven't seen the code. I responded to the comment that "days are > > not > > connected to Pesach." All Jewish holidays are connected to Pesach, > > it > > is one of the points from which years are calculated. And my > > statement > > above and the explanation how it works is correct as I wrote it. > > > > So what are you talking about? Exactly what did I write that you > > are > > disputing here? > > If you haven't read pesach.c or the calendar.judaic code, then you > can't > be helped because it is obvious from a quick glance at the code > that > some of the dates on calendar.judaic are listed as Westernized > dates > (aka the ones my diff changes) and others are dates in the form of > Pesach+/-n. I looked at it and there is no revelation there, the code is just an implementation of Gauss's Pesach algorithm, as it says. From that, with an understanding of how the years are laid out along with some basic math and in some cases specific rules for various fasts that can't fall on Shabbes, etc. it's possible to write code that works forever i.e. does not need to be changed every year. You said the calendar has to be changed every year and is based on western [civil] dates, so it's clear whoever is maintaing it doesn't understand our calendar. > I'll be moving forward with the oks I have and without your > opinion on everything else below because you can go be a shanda > somewhere else and not on this list, as this list is no place for > your > nonsense diatribe as to what counts as Judaism or not. I'm qualified to correct issues with the transliterations and I pointed out several inconsistencies earlier, and also to differentiate between Jewish and civil holidays. When you translate these holidays into English and if you want to include both major communities (Ashkenaz and Sephard) you will have to have two sets of transliterations. There is a third significant community (Yemenite) but an English transliteration according to the Sephardi community would be acceptable to them. We use our calendar daily. In addition to info about when holidays occur, we also have to know how the various times work out each day of the year for religious observances during the day. So any useful Jewish calendar necessarily includes things like astronomical sunrise/sunset by geographic location and based on legal rulings over history in each place where there was a Jewish community. We also need to know about other times of the day derived from the length of the daylight period as the days get longer and shorter. We have many obligations and prohibitions based on the day of the year and time of day. So we have a vital interest in understanding the calendar as it was calculated and ratified thousands of years ago and it is in use until now because to us it is actually relevant in our lives day by day, hour by hour. If you would like to see an example of what a Jewish calendar looks like I can send you a couple of snapshots of the one I use. It is really excellent and has a section explaining the various legal opinions as well as providing the times based on those calculations. /jl
Typo in bsd.port.mk(5)
While studying bsd.port.mk I ran across a reference to PACKAGES_REPOSITORY that seems like a typo. My assumption is that it is supposed to be PACKAGE_REPOSITORY as in the rest of the document (and in the FAQ, etc.). Index: bsd.port.mk.5 === RCS file: /cvs/src/share/man/man5/bsd.port.mk.5,v retrieving revision 1.567 diff -u -p -u -p -r1.567 bsd.port.mk.5 --- bsd.port.mk.528 Jul 2022 09:09:43 -1.567 +++ bsd.port.mk.510 Sep 2022 01:57:58 - @@ -364,7 +364,7 @@ owned by .Ev FETCH_USER , and creates directories .Ev LOCKDIR , -.Ev PACKAGES_REPOSITORY , +.Ev PACKAGE_REPOSITORY , .Ev PLIST_REPOSITORY and .Ev WRKOBJDIR
azalia module fix for 7.2-stable and some Intel 500 HDA Chips
Hi, I noticed I did not have sound on my new thinkpad which has a newer Intel 500 HDA chipset. bsd$ doas pcidump -vvv 0:31:3 0:31:3: Intel 500 Series HD Audio 0x: Vendor ID: 8086, Product ID: 43c8 0x0004: Command: 0006, Status: 0010 0x0008:Class: 04 Multimedia, Subclass: 01 Audio, Interface: 00, Revision: 11 0x000c: BIST: 00, Header Type: 00, Latency Timer: 00, Cache Line Size: 00 0x0010: BAR mem 64bit addr: 0x00603d1c/0x4000 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR mem 64bit addr: 0x00603d00/0x0010 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 17aa Product ID: 22e4 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 01 Line: ff Min Gnt: 00 Max Lat: 00 0x0050: Capability 0x01: Power Management State: D0 0x0080: Capability 0x09: Vendor Specific 0x0060: Capability 0x05: Message Signalled Interrupts (MSI) Enabled: yes Looking at src/sys/dev/pci/azalia.c I noticed making the change in the below diff corrects the issue with a new kernel build. It seems the pci subsystem match inclusion may not be needed, but hopefully someone smarter than I can figure that out (or help me figure that out). Index: sys/dev/pci/azalia.c === RCS file: /cvs/src/sys/dev/pci/azalia.c,v retrieving revision 1.276 diff -u -p -u -p -r1.276 azalia.c --- sys/dev/pci/azalia.c8 Sep 2022 01:28:46 -1.276 +++ sys/dev/pci/azalia.c4 Nov 2022 14:02:31 - @@ -511,8 +511,7 @@ azalia_pci_match(struct device *parent, struct pci_attach_args *pa; pa = aux; -if (PCI_CLASS(pa->pa_class) == PCI_CLASS_MULTIMEDIA -&& PCI_SUBCLASS(pa->pa_class) == PCI_SUBCLASS_MULTIMEDIA_HDAUDIO) +if (PCI_CLASS(pa->pa_class) == PCI_CLASS_MULTIMEDIA) return 1; return pci_matchbyid((struct pci_attach_args *)aux, azalia_pci_devices, nitems(azalia_pci_devices)); I hope this helps some folks! I apologize that I am using 7.2-stable and not -current. Thanks, John Browning
Re: azalia module fix for 7.2-stable and some Intel 500 HDA Chips
Hey,
It's: hw.vendor=LENOVO
hw.product=20Y4S1QE00
hw.version=ThinkPad P1 Gen 4i
That patch seems to be a better method.
Thanks!
On Fri, Nov 4, 2022 at 10:06 AM Jonathan Gray wrote:
>
> On Fri, Nov 04, 2022 at 09:10:52AM -0500, John Browning wrote:
> > Hi,
> > I noticed I did not have sound on my new thinkpad which has a newer
> > Intel 500 HDA chipset.
> >
> > bsd$ doas pcidump -vvv 0:31:3
> > 0:31:3: Intel 500 Series HD Audio
> > 0x: Vendor ID: 8086, Product ID: 43c8
> > 0x0004: Command: 0006, Status: 0010
> > 0x0008:Class: 04 Multimedia, Subclass: 01 Audio,
> > Interface: 00, Revision: 11
> > 0x000c: BIST: 00, Header Type: 00, Latency Timer: 00,
> > Cache Line Size: 00
> > 0x0010: BAR mem 64bit addr: 0x00603d1c/0x4000
> > 0x0018: BAR empty ()
> > 0x001c: BAR empty ()
> > 0x0020: BAR mem 64bit addr: 0x00603d00/0x0010
> > 0x0028: Cardbus CIS:
> > 0x002c: Subsystem Vendor ID: 17aa Product ID: 22e4
> > 0x0030: Expansion ROM Base Address:
> > 0x0038:
> > 0x003c: Interrupt Pin: 01 Line: ff Min Gnt: 00 Max Lat: 00
> > 0x0050: Capability 0x01: Power Management
> > State: D0
> > 0x0080: Capability 0x09: Vendor Specific
> > 0x0060: Capability 0x05: Message Signalled Interrupts (MSI)
> > Enabled: yes
> >
> >
> > Looking at src/sys/dev/pci/azalia.c I noticed making the change in the
> > below diff corrects the issue with a new kernel build. It seems the
> > pci subsystem match inclusion may not be needed, but hopefully someone
> > smarter than I can figure that out (or help me figure that out).
>
> When the subclass is not hd-audio, we match with azalia_pci_devices[].
>
> Which model thinkpad is this?
>
> Index: sys/dev/pci/azalia.c
> ===
> RCS file: /cvs/src/sys/dev/pci/azalia.c,v
> retrieving revision 1.280
> diff -u -p -r1.280 azalia.c
> --- sys/dev/pci/azalia.c26 Oct 2022 20:19:08 - 1.280
> +++ sys/dev/pci/azalia.c4 Nov 2022 14:10:59 -
> @@ -488,6 +488,7 @@ const struct pci_matchid azalia_pci_devi
> { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_300SERIES_U_HDA },
> { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_400SERIES_CAVS },
> { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_400SERIES_LP_HDA },
> + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_500SERIES_HDA },
> { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_500SERIES_LP_HDA },
> { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_600SERIES_LP_HDA },
> { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_GLK_HDA },
[PATCH] workaround buggy ACPI tables in some Intel boards
There was some discussion of this on misc@ recently. Some Baytrail boards are setting local APIC flags to 0b11, which is a reserved value. The acpidump and other info related to the problem is capture over there, as well. Ref: http://marc.info/?l=openbsd-miscm=140043989412703w=2 Instead of panicking, make like Linux and FreeBSD and assume level trigger and low polarity. Ref: http://www.freebsd.org/cgi/query-pr.cgi?pr=187966 This same system panics later when the Local APIC LINT Pin is set to strange values for all four CPUs. I'm still thinking about that one, but it will probably involve mpbios fixups. This workaround separates the notion of a reserved value and a totally unexpected value. Anyway, just sharing this idea while I work away at this one. Index: arch/amd64/include/mpbiosreg.h === RCS file: /cvs/src/sys/arch/amd64/include/mpbiosreg.h,v retrieving revision 1.4 diff -u -p -r1.4 mpbiosreg.h --- arch/amd64/include/mpbiosreg.h 23 Mar 2011 16:54:34 - 1.4 +++ arch/amd64/include/mpbiosreg.h 22 May 2014 04:39:59 - @@ -63,12 +63,14 @@ #define MPS_INTPO_DEF 0 #define MPS_INTPO_ACTHI1 #define MPS_INTPO_ACTLO3 +#define MPS_INTPO_RESERVED 2 #define MPS_INTPO_SHIFT0 #define MPS_INTPO_MASK 3 #define MPS_INTTR_DEF 0 #define MPS_INTTR_EDGE 1 #define MPS_INTTR_LEVEL3 +#define MPS_INTTR_RESERVED 2 #define MPS_INTTR_SHIFT2 #define MPS_INTTR_MASK 3 Index: arch/i386/include/mpbiosreg.h === RCS file: /cvs/src/sys/arch/i386/include/mpbiosreg.h,v retrieving revision 1.5 diff -u -p -r1.5 mpbiosreg.h --- arch/i386/include/mpbiosreg.h 23 Mar 2011 16:54:35 - 1.5 +++ arch/i386/include/mpbiosreg.h 22 May 2014 04:52:29 - @@ -63,12 +63,14 @@ #define MPS_INTPO_DEF 0 #define MPS_INTPO_ACTHI1 #define MPS_INTPO_ACTLO3 +#define MPS_INTPO_RESERVED 2 #define MPS_INTPO_SHIFT0 #define MPS_INTPO_MASK 3 #define MPS_INTTR_DEF 0 #define MPS_INTTR_EDGE 1 #define MPS_INTTR_LEVEL3 +#define MPS_INTTR_RESERVED 2 #define MPS_INTTR_SHIFT2 #define MPS_INTTR_MASK 3 Index: dev/acpi/acpimadt.c === RCS file: /cvs/src/sys/dev/acpi/acpimadt.c,v retrieving revision 1.27 diff -u -p -r1.27 acpimadt.c --- dev/acpi/acpimadt.c 18 May 2014 20:16:29 - 1.27 +++ dev/acpi/acpimadt.c 22 May 2014 23:02:55 - @@ -165,6 +165,10 @@ acpimadt_cfg_intr(int flags, u_int32_t * case MPS_INTPO_ACTLO: *redir |= IOAPIC_REDLO_ACTLO; break; + case MPS_INTPO_RESERVED: + printf(reserved MPS interrupt polarity %d, using low polarity\n, mpspo); + *redir |= IOAPIC_REDLO_ACTLO; + break; default: panic(unknown MPS interrupt polarity %d, mpspo); } @@ -178,6 +182,10 @@ acpimadt_cfg_intr(int flags, u_int32_t * case MPS_INTTR_DEF: case MPS_INTTR_EDGE: *redir = ~IOAPIC_REDLO_LEVEL; + break; + case MPS_INTTR_RESERVED: + printf(reserved MPS interrupt trigger %d, using level trigger\n, mpspo); + *redir |= IOAPIC_REDLO_LEVEL; break; default: panic(unknown MPS interrupt trigger %d, mpstrig);
Re: [PATCH] workaround buggy ACPI tables in some Intel boards
On Thu, May 22, 2014 at 08:27:40PM -0400, John D. Verne wrote:
There was some discussion of this on misc@ recently. Some Baytrail
boards are setting local APIC flags to 0b11, which is a reserved value.
The acpidump and other info related to the problem is capture over
there, as well. Ref:
http://marc.info/?l=openbsd-miscm=140043989412703w=2
Instead of panicking, make like Linux and FreeBSD and assume level
trigger and low polarity.
Ref: http://www.freebsd.org/cgi/query-pr.cgi?pr=187966
This same system panics later when the Local APIC LINT Pin is set to
strange values for all four CPUs. I'm still thinking about that one, but
it will probably involve mpbios fixups.
This workaround separates the notion of a reserved value and a totally
unexpected value.
Anyway, just sharing this idea while I work away at this one.
My last diff was terrible. This is less terrible.
The change to lapic.c is just wrong, but it allows -current to boot with
acpi enabled so I can dig into this more.
The AML info at
http://www.clevermonkey.org/OpenBSD/ACPI_ASRock_IMB-150.txt.gz is still
valid. I also have a dmesg from this kernel with MBVERBOSE enabled, if
it matters.
Index: arch/amd64/amd64/lapic.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/lapic.c,v
retrieving revision 1.31
diff -u -p -r1.31 lapic.c
--- arch/amd64/amd64/lapic.c29 Mar 2014 18:09:28 - 1.31
+++ arch/amd64/amd64/lapic.c27 May 2014 00:20:03 -
@@ -195,7 +195,7 @@ lapic_set_lvt(void)
|| mpi-cpu_id == ci-ci_apicid)) {
#ifdef DIAGNOSTIC
if (mpi-ioapic_pin 1)
- panic(lapic_set_lvt: bad pin value %d,
+ printf(lapic_set_lvt: bad pin value %d\n,
mpi-ioapic_pin);
#endif
if (mpi-ioapic_pin == 0)
Index: arch/amd64/include/mpbiosreg.h
===
RCS file: /cvs/src/sys/arch/amd64/include/mpbiosreg.h,v
retrieving revision 1.4
diff -u -p -r1.4 mpbiosreg.h
--- arch/amd64/include/mpbiosreg.h 23 Mar 2011 16:54:34 - 1.4
+++ arch/amd64/include/mpbiosreg.h 26 May 2014 01:06:05 -
@@ -62,12 +62,14 @@
#define MPS_INTPO_DEF 0
#define MPS_INTPO_ACTHI1
+#define MPS_INTPO_RESERVED 2
#define MPS_INTPO_ACTLO3
#define MPS_INTPO_SHIFT0
#define MPS_INTPO_MASK 3
#define MPS_INTTR_DEF 0
#define MPS_INTTR_EDGE 1
+#define MPS_INTTR_RESERVED 2
#define MPS_INTTR_LEVEL3
#define MPS_INTTR_SHIFT2
#define MPS_INTTR_MASK 3
Index: arch/i386/include/mpbiosreg.h
===
RCS file: /cvs/src/sys/arch/i386/include/mpbiosreg.h,v
retrieving revision 1.5
diff -u -p -r1.5 mpbiosreg.h
--- arch/i386/include/mpbiosreg.h 23 Mar 2011 16:54:35 - 1.5
+++ arch/i386/include/mpbiosreg.h 26 May 2014 01:06:44 -
@@ -62,12 +62,14 @@
#define MPS_INTPO_DEF 0
#define MPS_INTPO_ACTHI1
+#define MPS_INTPO_RESERVED 2
#define MPS_INTPO_ACTLO3
#define MPS_INTPO_SHIFT0
#define MPS_INTPO_MASK 3
#define MPS_INTTR_DEF 0
#define MPS_INTTR_EDGE 1
+#define MPS_INTTR_RESERVED 2
#define MPS_INTTR_LEVEL3
#define MPS_INTTR_SHIFT2
#define MPS_INTTR_MASK 3
Index: dev/acpi/acpimadt.c
===
RCS file: /cvs/src/sys/dev/acpi/acpimadt.c,v
retrieving revision 1.27
diff -u -p -r1.27 acpimadt.c
--- dev/acpi/acpimadt.c 18 May 2014 20:16:29 - 1.27
+++ dev/acpi/acpimadt.c 26 May 2014 01:41:19 -
@@ -162,6 +162,9 @@ acpimadt_cfg_intr(int flags, u_int32_t *
case MPS_INTPO_ACTHI:
*redir = ~IOAPIC_REDLO_ACTLO;
break;
+ case MPS_INTPO_RESERVED:
+ printf(reserved MPS interrupt polarity %d, assuming low
polarity\n, mpspo);
+ /* Fall-through */
case MPS_INTPO_ACTLO:
*redir |= IOAPIC_REDLO_ACTLO;
break;
@@ -172,6 +175,9 @@ acpimadt_cfg_intr(int flags, u_int32_t *
*redir |= (IOAPIC_REDLO_DEL_LOPRI IOAPIC_REDLO_DEL_SHIFT);
switch (mpstrig) {
+ case MPS_INTTR_RESERVED:
+ printf(reserved MPS interrupt trigger %d, assuming level
trigger\n, mpstrig);
+ /* Fall-through */
case MPS_INTTR_LEVEL:
*redir |= IOAPIC_REDLO_LEVEL;
break;
clean/portable crypto code...
Hello, I've been doing some work recently on crypto code, and noticed that there aren't many/any good clean implementations of performant crypto code out there (or maybe I just don't know of them). Both OpenSSL's and NSS's code has issues w/ portability and/or cleanliness. But, I prefer to reuse code so that hopefully, when one bug is found, derivatives can be fixed. Is there any interest in collaberation? My current interest is in AES-GCM and AES-XTS. I'm looking at taking a version of the AES-GCM code from NSS (heavily modified as it is unportable) for import into FreeBSD. Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not.
increase netcat's buffer...
So, I was using nc (on FreeBSD) to image an HD over the network and
it was consuming much cpu. It turns out that the buffer used by netcat
is only 2k in size, though the buffer on the stack is 16k.
This patch increased plan to use the entire buffer:
--- netcat.obsd.c.orig 2014-05-19 18:25:23.0 -0700
+++ netcat.obsd.c 2014-06-09 20:07:31.0 -0700
@@ -738,7 +738,7 @@
int lfd = fileno(stdout);
int plen;
- plen = 2048;
+ plen = sizeof buf;
/* Setup Network FD */
pfd[0].fd = nfd;
A better patch is probably the following which also increases the size
of the buffer to at least 64k:
--- netcat.obsd.c.orig 2014-05-19 18:25:23.0 -0700
+++ netcat.obsd.c 2014-06-09 20:11:56.0 -0700
@@ -733,12 +733,12 @@
readwrite(int nfd)
{
struct pollfd pfd[2];
- unsigned char buf[16384];
+ unsigned char buf[64*1024];
int n, wfd = fileno(stdin);
int lfd = fileno(stdout);
int plen;
- plen = 2048;
+ plen = sizeof buf;
/* Setup Network FD */
pfd[0].fd = nfd;
I would like to apply the following patch to FreeBSD, but it'd be nice
to keep these changes to a minimum between the two.
Thanks.
--
John-Mark Gurney Voice: +1 415 225 5579
All that I will do, has been done, All that I have, has not.
Re: sys/msdosfs: off by one
Tobias Stoeckmann wrote this message on Tue, Jun 17, 2014 at 00:05 +0200: there is a potential off by one in function fillinusemap() leading to possible out of boundary access (32 bytes after allocated area). pmp-pm_inusemap is allocated in msdosfs_vfsops.c like this: bmapsiz = (pmp-pm_maxcluster + N_INUSEBITS - 1) / N_INUSEBITS; pmp-pm_inusemap = malloc(bmapsiz * sizeof(*pmp-pm_inusemap), M_MSDOSFSFAT, M_WAITOK | M_CANFAIL); and accessed in msdosfs_fat.c like this: for (cn = 0; cn (pmp-pm_maxcluster + N_INUSEBITS) / N_INUSEBITS; cn++) Assignment of bmapsiz and for-condition should be equal, and actually resemble a resolved version of howmany macro (hint to my howmany mail ;)). Unfortunately - 1 is missing in for-loop. This _can_ lead to out of boundary access, depending on actual pmp-pm_maxcluster value. FreeBSD fixed this by increasing the malloc size: https://svnweb.freebsd.org/changeset/base/r126086 -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not.
Re: increase netcat's buffer...
) {
+ write_space_network =
event.data;
+ }
+ else if (event.filter ==
EVFILT_READ) {
+ available = MIN(event.data,
write_space_stdout);
+ available = MIN(available,
plen);
+ if (available 0) {
+ n = read(nfd, buf,
available);
+ if (n != available)
{
You should probably raise this as an error like the other cases...
+ return;
+ } else {
+ n =
write(lfd, buf, available);
+ if (n !=
available) {
+
return;
+ }
+ }
+ write_space_stdout
-= available;
+ /* Break to ignore
EVFILT_WRITE that could
+* be in current
keventlist, after this event
+* and which is now
invalid, because we just
+* write in the fd.
+*/
+ break;
+ }
+ }
+ }
}
- }
-
- if (!dflag pfd[1].revents POLLIN) {
- if ((n = read(wfd, buf, plen)) 0)
- return;
- else if (n == 0) {
- if (Nflag)
- shutdown(nfd, SHUT_WR);
- pfd[1].fd = -1;
- pfd[1].events = 0;
- } else {
- if (atomicio(vwrite, nfd, buf, n) != n)
+ else if (event.ident == lfd) {
+ if (event.filter == EVFILT_WRITE) {
+ write_space_stdout = event.data;
+ }
+ }
+ else if (event.ident == wfd) {
+ if (event.flags EV_EOF) {
+ if (Nflag)
+ shutdown(nfd, SHUT_WR);
return;
+ } else {
+ if (event.filter == EVFILT_READ) {
+ available = MIN(event.data,
write_space_network);
+ available = MIN(available,
plen);
+ if (available 0) {
+ n = read(wfd, buf,
available);
+ if (n != available)
{
+ return;
+ } else {
+ n =
write(nfd, buf, available);
+ if (n !=
available) {
+
return;
+ }
+ }
+ write_space_network
-= available;
+ /* Break to ignore
EVFILT_WRITE that could
+* be in current
keventlist, after this event
+* and which is now
invalid, because we just
+* write in the fd.
+*/
+ break;
+ }
+ }
+ }
As this second half of the path is the same as the first, my previous
comments also apply...
--
John-Mark Gurney Voice: +1 415 225 5579
All that I will do, has been done, All that I have, has not.
improving OpenBSD's gmac.c...
So, as I was working on FreeBSD's implementation of gmac.c, I noticed that I was able to get a significant speed up by using a mask instead of an if branch in ghash_gfmul in gmac.c from OpenBSD... Add a mask var and replace the code between the comments update Z and update V w/: mask = !!(x[i 3] (1 (~i 7))); mask = ~(mask - 1); z[0] ^= v[0] mask; z[1] ^= v[1] mask; z[2] ^= v[2] mask; z[3] ^= v[3] mask; And you should see a nice performance increase... I also have an implementation of ghash that does a 4 bit lookup table version with the table split between cache lines in p4 at: https://p4db.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/opencrypto/sys/opencrypto/gfmult.cREV=4 This also has a version with does 4 blocks at a time getting a further speed up... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not.
Re: improving OpenBSD's gmac.c...
Christian Weisgerber wrote this message on Tue, Oct 07, 2014 at 23:08 +0200: John-Mark Gurney: So, as I was working on FreeBSD's implementation of gmac.c, I noticed that I was able to get a significant speed up by using a mask instead of an if branch in ghash_gfmul in gmac.c from OpenBSD... Add a mask var and replace the code between the comments update Z and update V w/: mask = !!(x[i 3] (1 (~i 7))); mask = ~(mask - 1); z[0] ^= v[0] mask; z[1] ^= v[1] mask; z[2] ^= v[2] mask; z[3] ^= v[3] mask; And you should see a nice performance increase... I tried this on a Soekris net6501-50 and the performance increase was around 1.3%. (I set up an ESP transport association with AES-128-GMAC and pushed UDP traffic with tcpbench over it.) Yeh, I benchmarked the raw algo in userland, not part of IPsec. I forget the resulting perf increase, but it was well more than 10-20%. A look at the generated amd64 assembly code shows that the change indeed removes a branch. What's pretty shocking is that this code mul = v[3] 1; ... v[0] = (v[0] 1) ^ (0xe100 * mul); is turned into an actual imul instruction by GCC. I used the same masking approach to get rid of the multiplication, but the improvement was minuscule (1%). Hmm. interesting... In my code I switched both to using the and operator... I also have code which switches the registers to 64bits so that on amd64, we make better uses of registers, and on i386, the compilers are good at breaking down the 64bit registers to 32bit w/o extra work... I also have an implementation of ghash that does a 4 bit lookup table version with the table split between cache lines in p4 at: https://p4db.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/opencrypto/sys/opencrypto/gfmult.cREV=4 I'll have to look at this, but haven't there been increasing misgivings about table implementations for GHASH because of timing attacks? Well, the code avoids one issue but introduces another issue... Each table lookup accesses all four lines (assuming 64 byte cache lines), so there isn't a problem there... The issue intrroduded is that the first 64 bits of a cache line are faster to access than the remaining bits... For more info, look at the NSS bug: https://bugzilla.mozilla.org/show_bug.cgi?id=868948 Though considering that the AES implementation that FreeBSD is still using is the standard table based AES, there are also timing issues there too... Yes, no excuse for opening up additional windows... I have thought about introducing an option of slow but secure and fast but insecure against local attackers... Since we are already on the fast but insecure against local attackers path, I figured I'll take the extra performance... As with all things, there is a trade off between speed and security... As most IPsec gateways don't have a local user trying to target the key, this is less of an issue... And even if they did, it'd probably be easier to use a local root exploit to get the key than try to mount a timing attack to extract a key that might change in an hour or a day... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not.
Re: improving OpenBSD's gmac.c...
Mike Belopuhov wrote this message on Wed, Oct 08, 2014 at 14:32 +0200: On 8 October 2014 00:48, John-Mark Gurney j...@funkthat.com wrote: Christian Weisgerber wrote this message on Tue, Oct 07, 2014 at 23:08 +0200: John-Mark Gurney: So, as I was working on FreeBSD's implementation of gmac.c, I noticed that I was able to get a significant speed up by using a mask instead of an if branch in ghash_gfmul in gmac.c from OpenBSD... Add a mask var and replace the code between the comments update Z and update V w/: mask = !!(x[i 3] (1 (~i 7))); mask = ~(mask - 1); z[0] ^= v[0] mask; z[1] ^= v[1] mask; z[2] ^= v[2] mask; z[3] ^= v[3] mask; And you should see a nice performance increase... I tried this on a Soekris net6501-50 and the performance increase was around 1.3%. (I set up an ESP transport association with AES-128-GMAC and pushed UDP traffic with tcpbench over it.) Yeh, I benchmarked the raw algo in userland, not part of IPsec. I forget the resulting perf increase, but it was well more than 10-20%. A look at the generated amd64 assembly code shows that the change indeed removes a branch. What's pretty shocking is that this code mul = v[3] 1; ... v[0] = (v[0] 1) ^ (0xe100 * mul); is turned into an actual imul instruction by GCC. I used the same masking approach to get rid of the multiplication, but the improvement was minuscule (1%). Hmm. interesting... In my code I switched both to using the and operator... I also have code which switches the registers to 64bits so that on amd64, we make better uses of registers, and on i386, the compilers are good at breaking down the 64bit registers to 32bit w/o extra work... I also have an implementation of ghash that does a 4 bit lookup table version with the table split between cache lines in p4 at: https://p4db.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/opencrypto/sys/opencrypto/gfmult.cREV=4 I'll have to look at this, but haven't there been increasing misgivings about table implementations for GHASH because of timing attacks? Well, the code avoids one issue but introduces another issue... Each table lookup accesses all four lines (assuming 64 byte cache lines), so there isn't a problem there... The issue intrroduded is that the first 64 bits of a cache line are faster to access than the remaining bits... For more info, look at the NSS bug: https://bugzilla.mozilla.org/show_bug.cgi?id=868948 Though considering that the AES implementation that FreeBSD is still using is the standard table based AES, there are also timing issues there too... Yes, no excuse for opening up additional windows... I have thought about introducing an option of slow but secure and fast but insecure against local attackers... Since we are already on the fast but insecure against local attackers path, I figured I'll take the extra performance... As with all things, there is a trade off between speed and security... As most IPsec gateways don't have a local user trying to target the key, this is less of an issue... And even if they did, it'd probably be easier to use a local root exploit to get the key than try to mount a timing attack to extract a key that might change in an hour or a day... I've talked to Theo and it looks like we'll be importing your GF2 multiplication library as is. I think we should concentrate on making table version of gmac.c work better. Sounds good... Let me know of any issues you have... I'll want to try to keep the source in sync... As for making the table version work better? do you mean closer to constant time? or? Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not.
Re: increase netcat's buffer...
Ted Unangst wrote this message on Thu, Oct 30, 2014 at 12:09 -0400: On Mon, Oct 13, 2014 at 15:02, Arne Becker wrote: OK, no more fiddling with O_NONBLOCK. New diff below, tested with tcpbench and file transfers. I think this is good. Thanks, committed. We'll let it sit for a while and then see what if any changes need to take place on the buffer side. Maybe we can revisit the original impetus and try 64k again. I can't compile test this, but I think the vwrite cast could go away if you changed the atomicio's f type from ssize_t (*f) (int, void *, size_t) to ssize_t (*f) (int, const void *, size_t)... There isn't any reason why atomicio needs to have a non-const pointer to the buffer... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not.
slight prettying of acpicpu output
This changes the dmesg on one acpi enabled machine:
acpiprt3 at acpi0: bus -1 (MPCI)
-acpicpu0 at acpi0acpicpu0: struck PSS entry, core frequency equals last
-acpicpu0: struck PSS entry, core frequency equals last
+acpicpu0 at acpi0
+acpicpu0: struck PSS entry, core frequency equals last
+acpicpu0: struck PSS entry, core frequency equals last
acpicpu0: invalid _PSS length
-: C2
+acpicpu0: C2
acpipwrres0 at acpi0: PADA
Index: acpicpu.c
===
RCS file: /cvs/src/sys/dev/acpi/acpicpu.c,v
retrieving revision 1.56
diff -N -u -p acpicpu.c
--- acpicpu.c 29 Aug 2009 11:01:15 - 1.56
+++ acpicpu.c 26 Jun 2010 17:49:05 -
@@ -348,6 +348,8 @@ acpicpu_attach(struct device *parent, struct device *s
sc-sc_pblk_addr, sc-sc_pblk_len, sc-sc_duty_off,
sc-sc_duty_wid, sc-sc_acpi-sc_fadt-pstate_cnt,
CPU_MAXSTATE(sc));
+#else
+ printf(\n);
#endif
/* Get C-States from _CST or FADT */
@@ -423,7 +425,7 @@ acpicpu_attach(struct device *parent, struct device *s
* ACPI CPU provides.
*/
if (!SLIST_EMPTY(sc-sc_cstates)) {
- printf(:);
+ printf(%s:, DEVNAME(sc));
i = 0;
SLIST_FOREACH(cx, sc-sc_cstates, link) {
@@ -448,7 +450,10 @@ acpicpu_attach(struct device *parent, struct device *s
if (!(sc-sc_flags (FLAGS_NOPSS | FLAGS_NOPCT)) ||
!(sc-sc_flags FLAGS_NOPSS)) {
- printf(%c , SLIST_EMPTY(sc-sc_cstates) ? ':' : ',');
+ if (SLIST_EMPTY(sc-sc_cstates))
+ printf(%s: , DEVNAME(sc));
+ else
+ printf(, );
/*
* If acpicpu is itself providing the capability to transition
@@ -584,7 +589,7 @@ acpicpu_getpss(struct acpicpu_softc *sc)
*/
if (cf == sc-sc_pss[c].pss_core_freq) {
printf(%s: struck PSS entry, core frequency equals
-last\n, sc-sc_dev.dv_xname);
+ last\n, sc-sc_dev.dv_xname);
continue;
}
patch to owctr
- just use a buffer and make onewire_crc16() operate like onewire_crc()
- some style cleanups
- build for i386 GENERIC (only arch tested)
Index: onewire_subr.c
===
RCS file: /cvs/src/sys/dev/onewire/onewire_subr.c,v
retrieving revision 1.3
diff -N -u -p onewire_subr.c
--- onewire_subr.c 6 Jul 2010 19:59:59 - 1.3
+++ onewire_subr.c 17 Jul 2010 19:09:16 -
@@ -150,15 +150,21 @@ onewire_crc(const void *buf, int len)
}
u_int16_t
-onewire_crc16(u_int16_t crc16, u_int8_t data)
+onewire_crc16(const void *buf, int len)
{
+ const u_int8_t *p = buf;
+ u_int16_t crc = 0;
+ u_int16_t tmpcrc;
int idx;
- u_int16_t newcrc16;
- idx = (crc16 0xff) ^ data;
- newcrc16 = crc16_table_high[idx] 8;
- newcrc16 |= crc16_table_low[idx] ^ (crc16 8);
- return (newcrc16);
+ while (len--) {
+ idx = (crc 0xff) ^ *p++;
+ tmpcrc = crc16_table_high[idx] 8;
+ tmpcrc |= crc16_table_low[idx] ^ (crc 8);
+ crc = tmpcrc;
+ }
+
+ return (crc);
}
const char *
Index: onewirevar.h
===
RCS file: /cvs/src/sys/dev/onewire/onewirevar.h,v
retrieving revision 1.6
diff -N -u -p onewirevar.h
--- onewirevar.h6 Jul 2010 19:59:59 - 1.6
+++ onewirevar.h17 Jul 2010 19:09:16 -
@@ -77,7 +77,7 @@ struct onewire_matchfam {
/* Miscellaneous routines */
intonewire_crc(const void *, int);
-u_int16_t onewire_crc16(u_int16_t, u_int8_t);
+u_int16_t onewire_crc16(const void *, int);
const char * onewire_famname(int);
intonewire_matchbyfam(struct onewire_attach_args *,
const struct onewire_matchfam *, int);
Index: owctr.c
===
RCS file: /cvs/src/sys/dev/onewire/owctr.c,v
retrieving revision 1.3
diff -N -u -p owctr.c
--- owctr.c 8 Jul 2010 07:19:54 - 1.3
+++ owctr.c 17 Jul 2010 19:09:16 -
@@ -26,6 +26,7 @@
#include sys/systm.h
#include sys/device.h
#include sys/kernel.h
+#include sys/malloc.h
#include sys/proc.h
#include sys/rwlock.h
#include sys/sensors.h
@@ -41,6 +42,12 @@
#define DS2423_COUNTER_BANK_A 0x1c0
#define DS2423_COUNTER_BANK_B 0x1e0
+/* Buffer offsets */
+#define DS2423_COUNTER_BUF_COUNTER 35
+#define DS2423_COUNTER_BUF_CRC 43
+
+#define DS2423_COUNTER_BUFSZ 45
+
struct owctr_softc {
struct device sc_dev;
@@ -153,78 +160,60 @@ owctr_update_counter(void *arg, int bank)
struct owctr_softc *sc = arg;
u_int32_t counter;
u_int16_t crc;
- int data;
- int i;
+ u_int8_t *buf;
rw_enter_write(sc-sc_lock);
onewire_lock(sc-sc_onewire, 0);
if (onewire_reset(sc-sc_onewire) != 0)
goto done;
- onewire_matchrom(sc-sc_onewire, sc-sc_rom);
- onewire_write_byte(sc-sc_onewire, DSCTR_CMD_READ_MEMCOUNTER);
- crc = onewire_crc16(0, DSCTR_CMD_READ_MEMCOUNTER);
- onewire_write_byte(sc-sc_onewire, bank);
- crc = onewire_crc16(crc, bank);
- onewire_write_byte(sc-sc_onewire, bank 8);
- crc = onewire_crc16(crc, bank 8);
- for (i=0; i32; ++i)
- {
- data = onewire_read_byte(sc-sc_onewire);
- crc = onewire_crc16(crc, data);
+ buf = malloc(DS2423_COUNTER_BUFSZ, M_DEVBUF, M_NOWAIT);
+ if (buf == NULL) {
+ printf(%s: malloc() failed\n, sc-sc_dev.dv_xname);
+ goto done;
}
- data = onewire_read_byte(sc-sc_onewire);
- crc = onewire_crc16(crc, data);
- counter = data;
- data = onewire_read_byte(sc-sc_onewire);
- crc = onewire_crc16(crc, data);
- counter |= data 8;
- data = onewire_read_byte(sc-sc_onewire);
- crc = onewire_crc16(crc, data);
- counter |= data 16;
- data = onewire_read_byte(sc-sc_onewire);
- crc = onewire_crc16(crc, data);
- counter |= data 24;
- for (i=0; i4; ++i)
- {
- onewire_read_byte(sc-sc_onewire);
- crc = onewire_crc16(crc, data);
- }
- data = onewire_read_byte(sc-sc_onewire);
- crc ^= data;
- data = onewire_read_byte(sc-sc_onewire);
- crc ^= data 8;
- if ( crc != 0x)
- {
+
+ onewire_matchrom(sc-sc_onewire, sc-sc_rom);
+ buf[0] = DSCTR_CMD_READ_MEMCOUNTER;
+ buf[1] = bank;
+ buf[2] = bank 8;
+ onewire_write_byte(sc-sc_onewire, buf[0]);
+ onewire_write_byte(sc-sc_onewire, buf[1]);
+ onewire_write_byte(sc-sc_onewire, buf[2]);
+ onewire_read_block(sc-sc_onewire, buf[3], DS2423_COUNTER_BUFSZ-3);
+
+ crc = onewire_crc16(buf, DS2423_COUNTER_BUFSZ-2);
+ crc ^= buf[DS2423_COUNTER_BUF_CRC]
+ |
openbsd install on toshiba laptop
Greetings, I'm trying to install OpenBSD 4.6 onto a Toshiba L505D-S5965 Laptop and am running into a problem. Just after booting from the kernel from the install CD, the screen turns white and I am unable to proceed with the install. Any ideas as to what is causing this and or a workaround would be greatly appreciated. Toshiba L505D-S5965 AMD Athlon Dual Core QL-65 3GB SDRAM, 250GB HDD 15.6 TruBrite Wide screen DVD drive. ATI Radeon graphics thanks John
Re: improving OpenBSD's gmac.c...
Mike Belopuhov wrote this message on Wed, Nov 12, 2014 at 19:05 +0100: On 10 October 2014 02:39, Damien Miller d...@mindrot.org wrote: On Thu, 9 Oct 2014, Christian Weisgerber wrote: John-Mark Gurney: I also have an implementation of ghash that does a 4 bit lookup table version with the table split between cache lines in p4 at: https://p4db.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/opencrypto/sys/opencrypto/gfmult.cREV=4 This also has a version with does 4 blocks at a time getting a further speed up... FWIW, I did a quick dirty merge of this into the OpenBSD tree and the speed of my test (net6501-50, tcpbench -u over esp aes-128-gmac) almost doubled. isn't this likely to make it more likely to be subject to timing attacks? then how is this different to our table based aes implementation? My gfmul code spreads the table out over 4 64-byte arrays (common cache line size), and to read an entry, it must access all four... This doesn't mitigate entirely the cache timing attacks due to the fact that the first 64-bits of a cache line are faster: https://bugzilla.mozilla.org/show_bug.cgi?id=868948#c5 and it's the same C code as in openssl which also uses table based gcm implementation. what countermeasures can be applied to the table lookup code to fight these attacks? If you mean for AES, there is a version of AES that uses SSE instructions to bit slice the AES S-box and caclulate the S-box as if it were a set of logic gates... See: Faster and Timing-Attack Resistant AES-GCM by Emilia Kasper and Peter Schwabe... But obviously that requires FPU context saving... One of the issues today is that most of the research for implementations of algorithms assume you have access to SSE operations, there isn't much research going into making safe implementations that aren't using SSE... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not.
uow patch
fixes panic on attach/detach due to free list corruption, also use
after usbd_free_xfer(), tested on i386
~~~
Index: uow.c
===
RCS file: /cvs/src/sys/dev/usb/uow.c,v
retrieving revision 1.33
diff -u -p -s -r1.33 uow.c
--- uow.c 15 Apr 2013 09:23:02 - 1.33
+++ uow.c 29 Aug 2015 20:06:02 -
@@ -226,8 +226,10 @@ fail:
usbd_close_pipe(sc-sc_ph_obulk);
if (sc-sc_ph_intr != NULL)
usbd_close_pipe(sc-sc_ph_intr);
- if (sc-sc_xfer != NULL)
+ if (sc-sc_xfer != NULL) {
usbd_free_xfer(sc-sc_xfer);
+ sc-sc_xfer = NULL;
+ }
}
int
@@ -251,8 +253,10 @@ uow_detach(struct device *self, int flag
usbd_close_pipe(sc-sc_ph_intr);
}
- if (sc-sc_xfer != NULL)
+ if (sc-sc_xfer != NULL) {
usbd_free_xfer(sc-sc_xfer);
+ sc-sc_xfer = NULL;
+ }
if (sc-sc_ow_dev != NULL)
rv = config_detach(sc-sc_ow_dev, flags);
@@ -464,15 +468,18 @@ uow_read(struct uow_softc *sc, void *buf
usbd_setup_xfer(sc-sc_xfer, sc-sc_ph_ibulk, sc, buf, len,
USBD_SHORT_XFER_OK | USBD_SYNCHRONOUS, UOW_TIMEOUT, NULL);
error = usbd_transfer(sc-sc_xfer);
- usbd_free_xfer(sc-sc_xfer);
if (error != 0) {
printf(%s: read failed, len %d: %s\n,
sc-sc_dev.dv_xname, len, usbd_errstr(error));
uow_reset(sc);
+ usbd_free_xfer(sc-sc_xfer);
+ sc-sc_xfer = NULL;
return (-1);
}
usbd_get_xfer_status(sc-sc_xfer, NULL, NULL, count, error);
+ usbd_free_xfer(sc-sc_xfer);
+ sc-sc_xfer = NULL;
return (count);
}
@@ -496,6 +503,7 @@ uow_write(struct uow_softc *sc, const vo
USBD_SYNCHRONOUS, UOW_TIMEOUT, NULL);
error = usbd_transfer(sc-sc_xfer);
usbd_free_xfer(sc-sc_xfer);
+ sc-sc_xfer = NULL;
if (error != 0) {
printf(%s: write failed, len %d: %s\n,
sc-sc_dev.dv_xname, len, usbd_errstr(error));
Re: Feature request: Use the PCIe devices on Thunderbolt (aka PCIe hotplug?)
Joseph Mayer wrote this message on Sat, Mar 21, 2020 at 02:57 +: > Thunderbolt support would be awesome. Especially it would allow the use > of additional M.2 NVMe SSD:s on a laptop at full performance. > > Thunderbolt support would also allow the use of an AMDGPU via a PCIe > chassi, as well as enable the use of 10gbps Ethernet on laptops [1]. > > > While I like to use Thunderbolt for this pragmatic reason, also Intel > apparently promises license etc. generosity to computer makers, which > certainly does not hurt. [2] > > > FreeBSD has Thunderbolt support. It appears to me that they call it > "PCIe Hot plug". [3] >From my understanding, Thunderbolt is different from PCIe Hot Plug... PCIe the spec itself has hot plug capabilities, and this is what is used for laptops w/ ExpressCards and some servers... Thunderbolt from my understanding is more complicated due to display routing and other related features and FreeBSD does NOT yet have support for it. > It was implemented 2015 by John-Mark Gurney . John Baldwin, j...@freebsd.org ended up implementing it differently and not using the code I had written, so he is probably a better person to ask on the current state of the code.. This was done via: https://reviews.freebsd.org/D6136?id=15683 I have heard that there may be a proper ThunderBolt support coming to FreeBSD in the near future, but not sure exactly when... > Not sure if a TB device must be attached on boot and cannot be > detached, anyhow if that is the case then still totally fine. The devctl command can detach a device. This allows ejecting devices w/o crashing the system for removal, or allowing you to detach a device and pass it through to a bhyve vm, etc. Not all drivers are written to allow detaching... > NetBSD appears to have support also but I don't find details. > > Security-wise Thunderbolt without IOMMU is correlated with physical > break-in attack vectors, anyhow that is commonly fine. [4] >From my understanding, all PCIe switches have a built in IOMMU, so this shouldn't be a major security issue. I have not done indepth analysis to verify this though. and this also depends upon the PCIe switch not having bugs... There is a relatively inexpensive USB3 to PCIe bridge that lets you issue arbitrary PCIe commands that could be used to verify the security of implementations... > One Thunderbolt 3 controller provides 22gbps of PCIe data bandwidth to > all the one or two Thunderbolt ports it exports, which is fine. [5] > Many Thunderbolt devices allow daisy chaining. An "eGFX" certified [6] > Thunderbolt PCIe chassi (such as [7]) has absolutely no performance > advantage over a normal Thunderbolt PCIe chassi (such as [8]), > including for eGPU (e.g. AMDGPU) use. Good luck! > [1] The lowest cost and most common 10gbps Ethernet Thunderbolt chip > is Aquantia AQC107S. There are also some adapters based on a normal > PCIe 10gbps chip and a separate Thunderbolt to PCIe controller. > > [2] https://www.theregister.co.uk/2017/05/24/intel_thunderbolt_3forall/ > > [3] > https://www.freebsd.org/news/status/report-2015-01-2015-03.html#Adding-PCIe-Hot-plug-Support > https://www.freebsd.org/news/status/report-2015-07-2015-09.html#Adding-PCIe-Hot-plug-Support > > [4] > https://www.osnews.com/story/129501/thunderbolt-enables-severe-security-threats/ > > [5] And not 40gbps as common marketing makes it sound like. > > [6] https://thunderbolttechnology.net/egfx > https://thunderbolttechnology.net/blog/the-difference-between-egfx-and-egpu > = marketing mumbo jumbo. > > [7] https://www.asus.com/Graphics-Cards-Accessories/XG-STATION-PRO/ > > [8] https://www.akitio.com/expansion/node-pro -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."
