From owner-freebsd-arch@FreeBSD.ORG Mon Aug 27 13:54:30 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F89416A418; Mon, 27 Aug 2007 13:54:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id E8BF213C461; Mon, 27 Aug 2007 13:54:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8k2) with ESMTP id 205598043-1834499 for multiple; Mon, 27 Aug 2007 09:54:42 -0400 Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l7RDsH9R027472; Mon, 27 Aug 2007 09:54:18 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Mon, 27 Aug 2007 09:14:59 -0400 User-Agent: KMail/1.9.7 References: <20070818120056.GA6498@garage.freebsd.pl> <20070824142952.GA24469@hub.freebsd.org> <20070825151913.S568@10.0.0.1> In-Reply-To: <20070825151913.S568@10.0.0.1> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708270915.00516.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [192.168.0.1]); Mon, 27 Aug 2007 09:54:19 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/4075/Mon Aug 27 08:49:55 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Attilio Rao , Alfred Perlstein , Pawel Jakub Dawidek Subject: Re: Lockless uidinfo. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2007 13:54:30 -0000 On Saturday 25 August 2007 06:23:10 pm Jeff Roberson wrote: > > On Fri, 24 Aug 2007, Kris Kennaway wrote: > > > On Fri, Aug 24, 2007 at 04:09:27PM +0200, Pawel Jakub Dawidek wrote: > >> On Wed, Aug 22, 2007 at 09:02:53PM +0200, Attilio Rao wrote: > >>> 2007/8/21, Pawel Jakub Dawidek : > >>>> > >>>> New patch is here: > >>>> > >>>> http://people.freebsd.org/~pjd/patches/uidinfo_waitfree.patch > >>> > >>> --- sys/ia64/include/atomic.h.orig > >>> +++ sys/ia64/include/atomic.h > >>> @@ -370,4 +370,15 @@ > >>> > >>> #define atomic_fetchadd_int atomic_fetchadd_32 > >>> > >>> +static __inline u_long > >>> +atomic_fetchadd_long(volatile u_long *p, u_long v) > >>> +{ > >>> + u_long value; > >>> + > >>> + do { > >>> + value = *p; > >>> + } while (!atomic_cmpset_64(p, value, value + v)); > >>> + return (value); > >>> +} > >>> + > >>> > >>> In cycles like those, as you get spinning, I would arrange things in > >>> order to do a cpu_spinwait(). Like this: > >>> > >>> for (;;) { > >>> value = *p; > >>> if (atomic_cmpset_64(p, value, value + v)) > >>> break; > >>> cpu_spinwait(); > >>> } > >> > >> In this case there is no difference as this is MI ia64 code and > >> cpu_spinwait() is defined as /* nothing */ there. As a general rule, > >> this might be a good idea. > > > I don't know that these kinds of loops really need cpu_spinwait(). If you > consider that the loop condition is only triggered if a single instruction > overlaps with another thread and one thread always wins, the number of > cases where we restart more than once is negligible. I believe pjd's test > that was artificially constructed to cause as much contention as possible > still only saw 30% loop once. > > This is contrasted with spin-wait code where no-one is making any progress > while a lock is held. I think this just adds complexity to the code > without any advantage. > > The cpu_spinwait() function is meant to stop one HTT core from starving > another that is holding a lock. In this case there is no lock and so > there is no starvation possible. Actually by spinwaiting you may increase > the chance for a second loop. Agreed. cpu_spinwait() is for when we know we will have to wait at least for a little while. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue Aug 28 02:13:05 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAAFD16A47A; Tue, 28 Aug 2007 02:13:05 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id D0E4B13C469; Tue, 28 Aug 2007 02:13:04 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l7S1lo1U084215; Tue, 28 Aug 2007 05:47:50 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l7S1lnqX084214; Tue, 28 Aug 2007 05:47:50 +0400 (MSD) (envelope-from yar) Date: Tue, 28 Aug 2007 05:47:49 +0400 From: Yar Tikhiy To: arch@freebsd.org Message-ID: <20070828014748.GV21352@comp.chem.msu.su> References: <20070824.172212.74696955.imp@bsdimp.com> <20070824.213615.146406398.imp@bsdimp.com> <20070828005654.GA50401@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070828005654.GA50401@dragon.NUXI.org> User-Agent: Mutt/1.5.9i Cc: deischen@freebsd.org Subject: ABI and install tools (was Re: cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 02:13:05 -0000 [Redirecting this branch to -arch] On Mon, Aug 27, 2007 at 05:56:54PM -0700, David O'Brien wrote: > On Fri, Aug 24, 2007 at 09:36:15PM -0600, M. Warner Losh wrote: > > In message: > > Daniel Eischen writes: > > : I guess the build system should be more tolerant of this, but > > : there are bound to be problems regardless. I don't see why > > : the install tools can't also either have their own set of > > : libraries (utilizing LD_LIBRARY_PATH) or be built static. > > > > There's much resistance to building everything that the build system > > might be used being build static. It adds too much time and > > complexity to the build system, the opponents say. > > I've never heard an argument against building these bits static. > What's the issue? FWIW, here's a patch implementing the opposite approach: If we're going to install world over this system (installworld with DESTDIR unset or empty), first install the new versions of necessary tools to a scratch directory and then switch to the new tools. The kernel must be capable of running the new tools with the new libraries, which is an already existing requirement. With the patch, the build system can tolerate ABI breakage in libc and, according to audit(4), it runs no binaries from the old system in the sensitive part of installworld. For easier and safer testing, INSTALL_TESTING can be set so that the new way is chosen even if DESTDIR is set. Of course, make sure that the new tools are for the same platform as the machine runs. Usually you cannot select a different platform w/o setting DESTDIR. Comments are welcome. Thanks! -- Yar Index: Makefile.inc1 =================================================================== RCS file: /home/ncvs/src/Makefile.inc1,v retrieving revision 1.584 diff -u -r1.584 Makefile.inc1 --- Makefile.inc1 10 Jul 2007 10:19:45 -0000 1.584 +++ Makefile.inc1 28 Aug 2007 01:15:28 -0000 @@ -159,7 +159,14 @@ STRICTTMPPATH= ${BPATH}:${XPATH} TMPPATH= ${STRICTTMPPATH}:${PATH} +# +# Avoid running mktemp(1) unless actually needed. +# It may not be functional, e.g., due to new ABI +# when in the middle of installing over this system. +# +.if make(installworld) || make(distributeworld) INSTALLTMP!= /usr/bin/mktemp -d -u -t install +.endif # # Building a world goes through the following stages @@ -265,12 +272,11 @@ .endif # install stage +IMAKEENV= ${CROSSENV} ${INSTALLENV} .if empty(.MAKEFLAGS:M-n) -IMAKEENV= ${CROSSENV} \ - PATH=${STRICTTMPPATH}:${INSTALLTMP} +IMAKEENV+= PATH=${STRICTTMPPATH}:${INSTALLTMPPATH} .else -IMAKEENV= ${CROSSENV} \ - PATH=${TMPPATH}:${INSTALLTMP} +IMAKEENV+= PATH=${TMPPATH}:${INSTALLTMPPATH} .endif IMAKE= ${IMAKEENV} ${MAKE} -f Makefile.inc1 @@ -567,6 +573,50 @@ .endfor # +# If installing over this system, use the newly built tools +# to avoid such complications as the requirement of ABI compatibility +# between the old tools and the new libraries. +# +.if make(installworld) && (empty(DESTDIR) || defined(INSTALL_TESTING)) +INSTALLPATH= /sbin:/bin:/usr/sbin:/usr/bin +INSTALLTMPPATH= ${INSTALLPATH:S/^/${INSTALLTMP}/:S/:/:${INSTALLTMP}/g} + +INSTALLENV= LD_LIBRARY_PATH=${WORLDTMP}/lib:${WORLDTMP}/usr/lib +INSTALLENV+= __MAKE_SHELL=${INSTALLTMP}/bin/sh + +INSTALLTOOLS= \ + bin/cat \ + bin/chflags \ + bin/chmod \ + bin/date \ + bin/echo \ + bin/ln \ + bin/mkdir \ + bin/mv \ + bin/rm \ + bin/sh \ + bin/test \ + gnu/usr.bin/grep \ + gnu/usr.bin/texinfo/install-info \ + sbin/sysctl \ + usr.bin/awk \ + usr.bin/cap_mkdb \ + usr.bin/find \ + usr.bin/lockf \ + usr.bin/make \ + usr.bin/sed \ + usr.bin/true \ + usr.bin/uname \ + usr.bin/wc \ + usr.sbin/chown \ + usr.sbin/mtree \ + usr.sbin/pwd_mkdb \ + usr.sbin/zic/zic +.else +INSTALLTMPPATH=${INSTALLTMP} +.endif + +# # distributeworld # # Distributes everything compiled by a `buildworld'. @@ -576,6 +626,15 @@ # Installs everything compiled by a 'buildworld'. # distributeworld installworld: installcheck +.if make(installworld) && (empty(DESTDIR) || defined(INSTALL_TESTING)) + mkdir -p ${INSTALLTMPPATH:S/:/ /g} +.for _tool in ${INSTALLTOOLS} + cd ${.CURDIR}/${_tool}; \ + ${MAKE} -DWITHOUT_INFO -DWITHOUT_MAN \ + DESTDIR=${INSTALLTMP} INSTALL="sh ${.CURDIR}/tools/install.sh" \ + install +.endfor +.else mkdir -p ${INSTALLTMP} for prog in [ awk cap_mkdb cat chflags chmod chown \ date echo egrep find grep install-info \ @@ -583,6 +642,7 @@ test true uname wc zic; do \ cp `which $$prog` ${INSTALLTMP}; \ done +.endif ${_+_}cd ${.CURDIR}; ${IMAKE} re${.TARGET:S/world$//} rm -rf ${INSTALLTMP} Index: share/mk/sys.mk =================================================================== RCS file: /home/ncvs/src/share/mk/sys.mk,v retrieving revision 1.92 diff -u -r1.92 sys.mk --- share/mk/sys.mk 14 Aug 2007 13:44:08 -0000 1.92 +++ share/mk/sys.mk 27 Aug 2007 16:29:08 -0000 @@ -256,6 +256,11 @@ .include "${__MAKE_CONF}" .endif +.if !empty(__MAKE_SHELL) +SHELL= ${__MAKE_SHELL} +.SHELL: path=${__MAKE_SHELL} +.endif + # Default executable format # XXX hint for bsd.port.mk OBJFORMAT?= elf From owner-freebsd-arch@FreeBSD.ORG Wed Aug 29 17:02:00 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E63E416A418 for ; Wed, 29 Aug 2007 17:02:00 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id A7FCB13C45E for ; Wed, 29 Aug 2007 17:02:00 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 8E0FA17104 for ; Wed, 29 Aug 2007 16:41:11 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id l7TGf7wU034338 for ; Wed, 29 Aug 2007 16:41:08 GMT (envelope-from phk@critter.freebsd.dk) To: arch@freebsd.org From: Poul-Henning Kamp Date: Wed, 29 Aug 2007 16:41:07 +0000 Message-ID: <34337.1188405667@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Subject: Please think architecture... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2007 17:02:01 -0000 My new laptop is a Fujitsu-Siemens and when I load the acpi_fujitsu, some new sysctls appear: hw.acpi.fujitsu.lcd_brightness: 4 hw.acpi.fujitsu.lcd_brightness_radix: 8 But these are named wrong, they should be: hw.backlight.brightness: 4 hw.backlight.brightness_radix: 8 or something like it. Backlighting is not a vendor specific feature, all laptops with LCD displays have it. If generic stuff like that end up under vendor-specific branches, we will never grow generic tools to handle backlightning but will instead have a tool for each vendor or a maddening list like the lists of SCSI controllers in devd.conf: set scsi-controller-regex "(aac|adv|adw|aha|ahb|ahc|ahd|aic|amd|amr|asr|bt|ciss|ct|dpt|\ esp|ida|iir|ips|isp|mlx|mly|mpt|ncr|ncv|nsp|stg|sym|trm|wds)\ [0-9]+"; Please don't turn FreeBSD into a nightmare of fragmented bits, just like Linux. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Fri Aug 31 10:42:31 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E708416A417 for ; Fri, 31 Aug 2007 10:42:30 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id F207913C428 for ; Fri, 31 Aug 2007 10:42:29 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.5]) by phk.freebsd.dk (Postfix) with ESMTP id 7B2A417105 for ; Fri, 31 Aug 2007 09:42:52 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id l7V9gpKg008413 for ; Fri, 31 Aug 2007 09:42:52 GMT (envelope-from phk@critter.freebsd.dk) To: arch@freebsd.org From: Poul-Henning Kamp Date: Fri, 31 Aug 2007 09:42:51 +0000 Message-ID: <8412.1188553371@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Subject: Proof of concept: soundcard as console device X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2007 10:42:31 -0000 Yesterday while I was futzing with my new laptop and ACPI suspend/resume, I once again found myself cursing the nutjob who took away our serial ports. Then my mind wandered around a bit and suddenly it struck me: all modern hardware have built in AC97 sound hardware, and it offers a channel with a pretty decent bandwidth. This morning I ran a simple experiment, from userland, but the result show clearly that the idea is workable. The transmission format I used: send a negative transient to start a character and after N samples, send a positive transient, where N is the ASCII value of the character + a small constant. I have attached my proof-of-concept code, which uses the two stereo channels as a differential wire (not sure if this is a actually good idea). In my first attempt, I was able to transmit around 320 characters per second with something that looks like 1% error rate. What's left to do: * optimize transmission schema. This can be done with two computers, a jack-jack cable and a bit of C-coding. The difference in sample rate between the two machines causes off-by-one errors. I don't know of a peak detector which interpolates can resolve this, of if we need use oversampling in the receiver. The two pulses can have two different polarities each, so we can transmit two bits just that way, this could speed up transmission by a factor of four, if we can find a way to synchronize properly. The two stereo channels can be used independently, offering a doubling in speed. * write a kernel console driver which talks to the sound hardware without using interrupts. I don't know what the hardware interface to a sound card looks like, but I suspect this might be fairly easy. Even if the connection is one-way, kernel-hackers like me will worship any person who completes this task. Have at it... Poul-Henning ----------------------------------------------------------------------- /* proof of concept transmission code */ #include #include #include #include #define OFF 5 static short int buf[2*128 + 2 * OFF]; int main(int argc __unused, char **argv __unused) { int fd_dsp; int i, j, k, c; fd_dsp = open("/dev/dsp0.1", O_RDWR); if (fd_dsp < 0) err(1, "open /dev/dsp"); i = ioctl(fd_dsp, SNDCTL_DSP_RESET, &j); assert(i == 0); j = 2; i = ioctl(fd_dsp, SNDCTL_DSP_CHANNELS, &j); assert(i == 0); j = 44100; i = ioctl(fd_dsp, SNDCTL_DSP_SPEED, &j); assert(i == 0); j = 16; i = ioctl(fd_dsp, SNDCTL_DSP_SETFMT, &j); assert(i == 0); while (1) { c = getchar(); if (c == EOF) break; buf[OFF] = 32000; buf[OFF + 1] = -32000; buf[OFF + 2 * c] = -32000; buf[OFF + 2 * c + 1] = 32000; i = write(fd_dsp, buf, sizeof buf); assert(i == sizeof buf); buf[OFF + 2 * c] = 0; buf[OFF + 1 + 2 * c] = 0; } exit (0); } ----------------------------------------------------------------------- /* proof of concept reception code */ #include #include static int sample(FILE *f, const char *p) { short l, r; int i, s; i = fread(&l, sizeof l, 1, stdin); assert(i == 1); i = fread(&r, sizeof l, 1, stdin); assert(i == 1); s = l; s -= r; if (0 && p != NULL) printf("%6d %s\n", s, p); return (s); } static void find_neg_peak(FILE *f) { int s, sl; while (1) { s = sample(stdin, "v"); if (s < -10000) break; } sl = s; while (1) { s = sample(stdin, "N"); if (s > sl) return; sl = s; } } static int find_pos_peak(FILE *f) { int s, sl, k; k = 0; while (1) { k++; s = sample(stdin, "^"); if (s > 10000) break; } sl = s; while (1) { k++; s = sample(stdin, "P"); if (s < sl) return (k); sl = s; } } int main(int argc __unused, char **argv) { short l, r; int i, k, p, s, sl; k = 0; p = 0; while (1) { find_neg_peak(stdin); k = find_pos_peak(stdin); if (k == 10) printf("\\n\n"); else if (k >= ' ' && k <= '~') printf("%c", k); else printf("\\x%02x", k); } exit (0); } ----------------------------------------------------------------------- -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Fri Aug 31 11:58:18 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33B4516A420; Fri, 31 Aug 2007 11:58:18 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe12.swip.net [212.247.155.97]) by mx1.freebsd.org (Postfix) with ESMTP id 7ADF513C45A; Fri, 31 Aug 2007 11:58:17 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.lan) by mailfe12.swip.net (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 425111561; Fri, 31 Aug 2007 12:57:21 +0200 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Fri, 31 Aug 2007 12:57:30 +0200 User-Agent: KMail/1.9.7 References: <8412.1188553371@critter.freebsd.dk> In-Reply-To: <8412.1188553371@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708311257.31627.hselasky@c2i.net> Cc: arch@freebsd.org, Poul-Henning Kamp Subject: Re: Proof of concept: soundcard as console device X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2007 11:58:18 -0000 Hi, This is really creative. Maybe you should add a simple N-tap FIR filter so that you limit the bandwidth used and don't destroy the soundcard :-) BTW: Why can't you use an USB serial adapter connected to the PC ? --HPS On Friday 31 August 2007, Poul-Henning Kamp wrote: > Yesterday while I was futzing with my new laptop and ACPI suspend/resume, > I once again found myself cursing the nutjob who took away our serial > ports. > > Then my mind wandered around a bit and suddenly it struck me: all > modern hardware have built in AC97 sound hardware, and it offers a > channel with a pretty decent bandwidth. > > This morning I ran a simple experiment, from userland, but the > result show clearly that the idea is workable. > > The transmission format I used: send a negative transient to start > a character and after N samples, send a positive transient, where > N is the ASCII value of the character + a small constant. > > I have attached my proof-of-concept code, which uses the two stereo > channels as a differential wire (not sure if this is a actually > good idea). > > In my first attempt, I was able to transmit around 320 characters > per second with something that looks like 1% error rate. > > What's left to do: > > * optimize transmission schema. > > This can be done with two computers, a jack-jack cable > and a bit of C-coding. > > The difference in sample rate between the two machines > causes off-by-one errors. I don't know of a peak detector > which interpolates can resolve this, of if we need use > oversampling in the receiver. > > The two pulses can have two different polarities each, > so we can transmit two bits just that way, this could speed > up transmission by a factor of four, if we can find a way > to synchronize properly. > > The two stereo channels can be used independently, offering > a doubling in speed. > > * write a kernel console driver which talks to the sound hardware > without using interrupts. > > I don't know what the hardware interface to a sound card > looks like, but I suspect this might be fairly easy. > > Even if the connection is one-way, kernel-hackers like me will worship > any person who completes this task. > > Have at it... > > Poul-Henning > > ----------------------------------------------------------------------- > /* proof of concept transmission code */ > #include > #include > #include > #include > > #define OFF 5 > > static short int buf[2*128 + 2 * OFF]; > > int > main(int argc __unused, char **argv __unused) > { > int fd_dsp; > int i, j, k, c; > > fd_dsp = open("/dev/dsp0.1", O_RDWR); > if (fd_dsp < 0) > err(1, "open /dev/dsp"); > > i = ioctl(fd_dsp, SNDCTL_DSP_RESET, &j); > assert(i == 0); > > j = 2; > i = ioctl(fd_dsp, SNDCTL_DSP_CHANNELS, &j); > assert(i == 0); > > j = 44100; > i = ioctl(fd_dsp, SNDCTL_DSP_SPEED, &j); > assert(i == 0); > > j = 16; > i = ioctl(fd_dsp, SNDCTL_DSP_SETFMT, &j); > assert(i == 0); > > > while (1) { > c = getchar(); > if (c == EOF) > break; > buf[OFF] = 32000; > buf[OFF + 1] = -32000; > > buf[OFF + 2 * c] = -32000; > buf[OFF + 2 * c + 1] = 32000; > > i = write(fd_dsp, buf, sizeof buf); > assert(i == sizeof buf); > > buf[OFF + 2 * c] = 0; > buf[OFF + 1 + 2 * c] = 0; > } > > exit (0); > } > ----------------------------------------------------------------------- > /* proof of concept reception code */ > #include > #include > > static int > sample(FILE *f, const char *p) > { > short l, r; > int i, s; > > i = fread(&l, sizeof l, 1, stdin); > assert(i == 1); > i = fread(&r, sizeof l, 1, stdin); > assert(i == 1); > s = l; > s -= r; > if (0 && p != NULL) > printf("%6d %s\n", s, p); > return (s); > } > > static void > find_neg_peak(FILE *f) > { > int s, sl; > > while (1) { > s = sample(stdin, "v"); > if (s < -10000) > break; > } > sl = s; > while (1) { > s = sample(stdin, "N"); > if (s > sl) > return; > sl = s; > } > } > > static int > find_pos_peak(FILE *f) > { > int s, sl, k; > > k = 0; > while (1) { > k++; > s = sample(stdin, "^"); > if (s > 10000) > break; > } > sl = s; > while (1) { > k++; > s = sample(stdin, "P"); > if (s < sl) > return (k); > sl = s; > } > } > > > int > main(int argc __unused, char **argv) > { > short l, r; > int i, k, p, s, sl; > > k = 0; > p = 0; > while (1) { > find_neg_peak(stdin); > k = find_pos_peak(stdin); > if (k == 10) > printf("\\n\n"); > else if (k >= ' ' && k <= '~') > printf("%c", k); > else > printf("\\x%02x", k); > } > exit (0); > } > ----------------------------------------------------------------------- From owner-freebsd-arch@FreeBSD.ORG Fri Aug 31 11:58:18 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33B4516A420; Fri, 31 Aug 2007 11:58:18 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe12.swip.net [212.247.155.97]) by mx1.freebsd.org (Postfix) with ESMTP id 7ADF513C45A; Fri, 31 Aug 2007 11:58:17 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.lan) by mailfe12.swip.net (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 425111561; Fri, 31 Aug 2007 12:57:21 +0200 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Fri, 31 Aug 2007 12:57:30 +0200 User-Agent: KMail/1.9.7 References: <8412.1188553371@critter.freebsd.dk> In-Reply-To: <8412.1188553371@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708311257.31627.hselasky@c2i.net> Cc: arch@freebsd.org, Poul-Henning Kamp Subject: Re: Proof of concept: soundcard as console device X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2007 11:58:18 -0000 Hi, This is really creative. Maybe you should add a simple N-tap FIR filter so that you limit the bandwidth used and don't destroy the soundcard :-) BTW: Why can't you use an USB serial adapter connected to the PC ? --HPS On Friday 31 August 2007, Poul-Henning Kamp wrote: > Yesterday while I was futzing with my new laptop and ACPI suspend/resume, > I once again found myself cursing the nutjob who took away our serial > ports. > > Then my mind wandered around a bit and suddenly it struck me: all > modern hardware have built in AC97 sound hardware, and it offers a > channel with a pretty decent bandwidth. > > This morning I ran a simple experiment, from userland, but the > result show clearly that the idea is workable. > > The transmission format I used: send a negative transient to start > a character and after N samples, send a positive transient, where > N is the ASCII value of the character + a small constant. > > I have attached my proof-of-concept code, which uses the two stereo > channels as a differential wire (not sure if this is a actually > good idea). > > In my first attempt, I was able to transmit around 320 characters > per second with something that looks like 1% error rate. > > What's left to do: > > * optimize transmission schema. > > This can be done with two computers, a jack-jack cable > and a bit of C-coding. > > The difference in sample rate between the two machines > causes off-by-one errors. I don't know of a peak detector > which interpolates can resolve this, of if we need use > oversampling in the receiver. > > The two pulses can have two different polarities each, > so we can transmit two bits just that way, this could speed > up transmission by a factor of four, if we can find a way > to synchronize properly. > > The two stereo channels can be used independently, offering > a doubling in speed. > > * write a kernel console driver which talks to the sound hardware > without using interrupts. > > I don't know what the hardware interface to a sound card > looks like, but I suspect this might be fairly easy. > > Even if the connection is one-way, kernel-hackers like me will worship > any person who completes this task. > > Have at it... > > Poul-Henning > > ----------------------------------------------------------------------- > /* proof of concept transmission code */ > #include > #include > #include > #include > > #define OFF 5 > > static short int buf[2*128 + 2 * OFF]; > > int > main(int argc __unused, char **argv __unused) > { > int fd_dsp; > int i, j, k, c; > > fd_dsp = open("/dev/dsp0.1", O_RDWR); > if (fd_dsp < 0) > err(1, "open /dev/dsp"); > > i = ioctl(fd_dsp, SNDCTL_DSP_RESET, &j); > assert(i == 0); > > j = 2; > i = ioctl(fd_dsp, SNDCTL_DSP_CHANNELS, &j); > assert(i == 0); > > j = 44100; > i = ioctl(fd_dsp, SNDCTL_DSP_SPEED, &j); > assert(i == 0); > > j = 16; > i = ioctl(fd_dsp, SNDCTL_DSP_SETFMT, &j); > assert(i == 0); > > > while (1) { > c = getchar(); > if (c == EOF) > break; > buf[OFF] = 32000; > buf[OFF + 1] = -32000; > > buf[OFF + 2 * c] = -32000; > buf[OFF + 2 * c + 1] = 32000; > > i = write(fd_dsp, buf, sizeof buf); > assert(i == sizeof buf); > > buf[OFF + 2 * c] = 0; > buf[OFF + 1 + 2 * c] = 0; > } > > exit (0); > } > ----------------------------------------------------------------------- > /* proof of concept reception code */ > #include > #include > > static int > sample(FILE *f, const char *p) > { > short l, r; > int i, s; > > i = fread(&l, sizeof l, 1, stdin); > assert(i == 1); > i = fread(&r, sizeof l, 1, stdin); > assert(i == 1); > s = l; > s -= r; > if (0 && p != NULL) > printf("%6d %s\n", s, p); > return (s); > } > > static void > find_neg_peak(FILE *f) > { > int s, sl; > > while (1) { > s = sample(stdin, "v"); > if (s < -10000) > break; > } > sl = s; > while (1) { > s = sample(stdin, "N"); > if (s > sl) > return; > sl = s; > } > } > > static int > find_pos_peak(FILE *f) > { > int s, sl, k; > > k = 0; > while (1) { > k++; > s = sample(stdin, "^"); > if (s > 10000) > break; > } > sl = s; > while (1) { > k++; > s = sample(stdin, "P"); > if (s < sl) > return (k); > sl = s; > } > } > > > int > main(int argc __unused, char **argv) > { > short l, r; > int i, k, p, s, sl; > > k = 0; > p = 0; > while (1) { > find_neg_peak(stdin); > k = find_pos_peak(stdin); > if (k == 10) > printf("\\n\n"); > else if (k >= ' ' && k <= '~') > printf("%c", k); > else > printf("\\x%02x", k); > } > exit (0); > } > ----------------------------------------------------------------------- From owner-freebsd-arch@FreeBSD.ORG Fri Aug 31 12:27:32 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 566D816A419 for ; Fri, 31 Aug 2007 12:27:32 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id CFEC513C469 for ; Fri, 31 Aug 2007 12:27:31 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A55A26.dip.t-dialin.net [84.165.90.38]) by redbull.bpaserver.net (Postfix) with ESMTP id 8CC682E332; Fri, 31 Aug 2007 14:01:03 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 15BF25B4996; Fri, 31 Aug 2007 14:01:01 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l7VC10wU060273; Fri, 31 Aug 2007 14:01:00 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from proxy.Leidinger.net (proxy.Leidinger.net [192.168.1.103]) by webmail.leidinger.net (Horde MIME library) with HTTP; Fri, 31 Aug 2007 14:01:00 +0200 Message-ID: <20070831140100.zphn2zsxzb408okc@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Fri, 31 Aug 2007 14:01:00 +0200 From: Alexander Leidinger To: Poul-Henning Kamp References: <8412.1188553371@critter.freebsd.dk> In-Reply-To: <8412.1188553371@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.9, required 8, BAYES_00 -15.00, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: arch@freebsd.org Subject: Re: Proof of concept: soundcard as console device X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2007 12:27:32 -0000 Quoting Poul-Henning Kamp (from Fri, 31 Aug 2007 =20 09:42:51 +0000): > > Yesterday while I was futzing with my new laptop and ACPI suspend/resume, > I once again found myself cursing the nutjob who took away our serial > ports. Lucky those people with a firewire interface... > Then my mind wandered around a bit and suddenly it struck me: all > modern hardware have built in AC97 sound hardware, and it offers a > channel with a pretty decent bandwidth. You are too late, Intel is moving to HDA and away of AC97. And it =20 seems everyone except Creative is following (there are companies with =20 their own interfaces (VIA envy24), but often they provide a HDA =20 chipset too). Creative doesn't really matter, as they don't provide =20 docs and everyone tries to avoid it. > This morning I ran a simple experiment, from userland, but the > result show clearly that the idea is workable. > > The transmission format I used: send a negative transient to start > a character and after N samples, send a positive transient, where > N is the ASCII value of the character + a small constant. Some cards have digital-out/in (SPDIF), maybe it's an option for you. Bye, Alexander. --=20 Never give an inch! http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-arch@FreeBSD.ORG Fri Aug 31 12:46:02 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 659CA16A418 for ; Fri, 31 Aug 2007 12:46:02 +0000 (UTC) (envelope-from tshadwick@oss-solutions.com) Received: from mail.hksilver.net (mail.hksilver.net [208.231.66.99]) by mx1.freebsd.org (Postfix) with ESMTP id A1FE913C459 for ; Fri, 31 Aug 2007 12:46:01 +0000 (UTC) (envelope-from tshadwick@oss-solutions.com) Received: from [172.16.30.8] (chibi.shadwick.home [172.16.30.8]) by mail.hksilver.net (8.14.0/8.13.4) with ESMTP id l7VC6nnS014537; Fri, 31 Aug 2007 07:06:49 -0500 (CDT) (envelope-from tshadwick@oss-solutions.com) Message-ID: <46D80456.5020301@oss-solutions.com> Date: Fri, 31 Aug 2007 07:06:46 -0500 From: Tony Shadwick User-Agent: Thunderbird 1.5.0.13 (Macintosh/20070809) MIME-Version: 1.0 To: Poul-Henning Kamp References: <8412.1188553371@critter.freebsd.dk> In-Reply-To: <8412.1188553371@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.90/4110/Thu Aug 30 18:49:40 2007 on moogle.hksilver.net X-Virus-Status: Clean Cc: arch@freebsd.org Subject: Re: Proof of concept: soundcard as console device X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2007 12:46:02 -0000 Brilliant! :D I don't care if it doesn't get committed to the main tree. Put it in the ports tree....that's one heck of a hack! I love it! :) Poul-Henning Kamp wrote: > Yesterday while I was futzing with my new laptop and ACPI suspend/resume, > I once again found myself cursing the nutjob who took away our serial > ports. > > Then my mind wandered around a bit and suddenly it struck me: all > modern hardware have built in AC97 sound hardware, and it offers a > channel with a pretty decent bandwidth. > > This morning I ran a simple experiment, from userland, but the > result show clearly that the idea is workable. > > The transmission format I used: send a negative transient to start > a character and after N samples, send a positive transient, where > N is the ASCII value of the character + a small constant. > > I have attached my proof-of-concept code, which uses the two stereo > channels as a differential wire (not sure if this is a actually > good idea). > > In my first attempt, I was able to transmit around 320 characters > per second with something that looks like 1% error rate. > > What's left to do: > > * optimize transmission schema. > > This can be done with two computers, a jack-jack cable > and a bit of C-coding. > > The difference in sample rate between the two machines > causes off-by-one errors. I don't know of a peak detector > which interpolates can resolve this, of if we need use > oversampling in the receiver. > > The two pulses can have two different polarities each, > so we can transmit two bits just that way, this could speed > up transmission by a factor of four, if we can find a way > to synchronize properly. > > The two stereo channels can be used independently, offering > a doubling in speed. > > * write a kernel console driver which talks to the sound hardware > without using interrupts. > > I don't know what the hardware interface to a sound card > looks like, but I suspect this might be fairly easy. > > Even if the connection is one-way, kernel-hackers like me will worship > any person who completes this task. > > Have at it... > > Poul-Henning > > ----------------------------------------------------------------------- > /* proof of concept transmission code */ > #include > #include > #include > #include > > #define OFF 5 > > static short int buf[2*128 + 2 * OFF]; > > int > main(int argc __unused, char **argv __unused) > { > int fd_dsp; > int i, j, k, c; > > fd_dsp = open("/dev/dsp0.1", O_RDWR); > if (fd_dsp < 0) > err(1, "open /dev/dsp"); > > i = ioctl(fd_dsp, SNDCTL_DSP_RESET, &j); > assert(i == 0); > > j = 2; > i = ioctl(fd_dsp, SNDCTL_DSP_CHANNELS, &j); > assert(i == 0); > > j = 44100; > i = ioctl(fd_dsp, SNDCTL_DSP_SPEED, &j); > assert(i == 0); > > j = 16; > i = ioctl(fd_dsp, SNDCTL_DSP_SETFMT, &j); > assert(i == 0); > > > while (1) { > c = getchar(); > if (c == EOF) > break; > buf[OFF] = 32000; > buf[OFF + 1] = -32000; > > buf[OFF + 2 * c] = -32000; > buf[OFF + 2 * c + 1] = 32000; > > i = write(fd_dsp, buf, sizeof buf); > assert(i == sizeof buf); > > buf[OFF + 2 * c] = 0; > buf[OFF + 1 + 2 * c] = 0; > } > > exit (0); > } > ----------------------------------------------------------------------- > /* proof of concept reception code */ > #include > #include > > static int > sample(FILE *f, const char *p) > { > short l, r; > int i, s; > > i = fread(&l, sizeof l, 1, stdin); > assert(i == 1); > i = fread(&r, sizeof l, 1, stdin); > assert(i == 1); > s = l; > s -= r; > if (0 && p != NULL) > printf("%6d %s\n", s, p); > return (s); > } > > static void > find_neg_peak(FILE *f) > { > int s, sl; > > while (1) { > s = sample(stdin, "v"); > if (s < -10000) > break; > } > sl = s; > while (1) { > s = sample(stdin, "N"); > if (s > sl) > return; > sl = s; > } > } > > static int > find_pos_peak(FILE *f) > { > int s, sl, k; > > k = 0; > while (1) { > k++; > s = sample(stdin, "^"); > if (s > 10000) > break; > } > sl = s; > while (1) { > k++; > s = sample(stdin, "P"); > if (s < sl) > return (k); > sl = s; > } > } > > > int > main(int argc __unused, char **argv) > { > short l, r; > int i, k, p, s, sl; > > k = 0; > p = 0; > while (1) { > find_neg_peak(stdin); > k = find_pos_peak(stdin); > if (k == 10) > printf("\\n\n"); > else if (k >= ' ' && k <= '~') > printf("%c", k); > else > printf("\\x%02x", k); > } > exit (0); > } > ----------------------------------------------------------------------- > > > > From owner-freebsd-arch@FreeBSD.ORG Fri Aug 31 13:18:40 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49E5216A419 for ; Fri, 31 Aug 2007 13:18:40 +0000 (UTC) (envelope-from rnsanchez@wait4.org) Received: from sumo.dreamhost.com (sumo.dreamhost.com [66.33.216.29]) by mx1.freebsd.org (Postfix) with ESMTP id 33EC213C465 for ; Fri, 31 Aug 2007 13:18:40 +0000 (UTC) (envelope-from rnsanchez@wait4.org) Received: from spunkymail-a16.dreamhost.com (sd-green-bigip-83.dreamhost.com [208.97.132.83]) by sumo.dreamhost.com (Postfix) with ESMTP id D43C717C0D6 for ; Fri, 31 Aug 2007 05:47:28 -0700 (PDT) Received: from sauron.lan.box (201-34-83-58.paemt701.dsl.brasiltelecom.net.br [201.34.83.58]) by spunkymail-a16.dreamhost.com (Postfix) with ESMTP id 2245E7CF5C; Fri, 31 Aug 2007 05:46:56 -0700 (PDT) Date: Fri, 31 Aug 2007 09:46:52 -0300 From: Ricardo Nabinger Sanchez To: Poul-Henning Kamp Message-Id: <20070831094652.0cf1f3a8.rnsanchez@wait4.org> In-Reply-To: <8412.1188553371@critter.freebsd.dk> References: <8412.1188553371@critter.freebsd.dk> Organization: SYS_WAIT4 X-Mailer: Sylpheed 2.4.4 (GTK+ 2.10.14; i386-unknown-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org Subject: Re: Proof of concept: soundcard as console device X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2007 13:18:40 -0000 On Fri, 31 Aug 2007 09:42:51 +0000 Poul-Henning Kamp wrote: > What's left to do: >=20 > * optimize transmission schema. >=20 > This can be done with two computers, a jack-jack cable > and a bit of C-coding. >=20 > The difference in sample rate between the two machines > causes off-by-one errors. I don't know of a peak > detector which interpolates can resolve this, of if we need use > oversampling in the receiver. >=20 > The two pulses can have two different polarities each, > so we can transmit two bits just that way, this could > speed up transmission by a factor of four, if we can find a way > to synchronize properly. >=20 > The two stereo channels can be used independently, > offering a doubling in speed. Sounds like a synchronization pattern could be used here, like the one used for E1 channels (resync at every 512 bits), or any other scheme for plesiochronous channels. Or taking one channel to signal when data is ready. This is simply =FCber-cool. :) --=20 Ricardo Nabinger Sanchez rnsanchez@wait4.org Powered by FreeBSD "Left to themselves, things tend to go from bad to worse." From owner-freebsd-arch@FreeBSD.ORG Fri Aug 31 13:20:48 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D275516A419 for ; Fri, 31 Aug 2007 13:20:48 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 910A413C457 for ; Fri, 31 Aug 2007 13:20:48 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.5]) by phk.freebsd.dk (Postfix) with ESMTP id DB80817104; Fri, 31 Aug 2007 13:20:10 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id l7VDKA9b010364; Fri, 31 Aug 2007 13:20:10 GMT (envelope-from phk@critter.freebsd.dk) To: Ricardo Nabinger Sanchez From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 31 Aug 2007 09:46:52 -0300." <20070831094652.0cf1f3a8.rnsanchez@wait4.org> Date: Fri, 31 Aug 2007 13:20:09 +0000 Message-ID: <10363.1188566409@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: arch@freebsd.org Subject: Re: Proof of concept: soundcard as console device X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2007 13:20:48 -0000 In message <20070831094652.0cf1f3a8.rnsanchez@wait4.org>, Ricardo Nabinger Sanchez writes: >On Fri, 31 Aug 2007 09:42:51 +0000 >> * optimize transmission schema. > >Sounds like a synchronization pattern could be used here, like the one >used for E1 channels (resync at every 512 bits), or any other scheme for >plesiochronous channels. Or taking one channel to signal when data is >ready. Don't loose sight of what the point is: It should "just work" and preferably no calibration should be necessary at all. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Fri Aug 31 14:22:23 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2EE8B16A46B; Fri, 31 Aug 2007 14:22:23 +0000 (UTC) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 0E06813C48D; Fri, 31 Aug 2007 14:22:22 +0000 (UTC) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.1/8.14.1) with ESMTP id l7VE3GNA079186; Fri, 31 Aug 2007 07:03:16 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.1/8.14.1/Submit) id l7VE3GV2079185; Fri, 31 Aug 2007 07:03:16 -0700 (PDT) (envelope-from obrien) Date: Fri, 31 Aug 2007 07:03:16 -0700 From: "David O'Brien" To: Hans Petter Selasky Message-ID: <20070831140316.GA79097@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Hans Petter Selasky , freebsd-arch@freebsd.org, arch@freebsd.org References: <8412.1188553371@critter.freebsd.dk> <200708311257.31627.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200708311257.31627.hselasky@c2i.net> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.11 Cc: arch@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Proof of concept: soundcard as console device X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2007 14:22:23 -0000 On Fri, Aug 31, 2007 at 12:57:30PM +0200, Hans Petter Selasky wrote: > BTW: Why can't you use an USB serial adapter connected to the PC ? That requires a USB stack that runs without using interrupts. That is the stumbling block. -- -- David (obrien@FreeBSD.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" From owner-freebsd-arch@FreeBSD.ORG Fri Aug 31 14:22:23 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2EE8B16A46B; Fri, 31 Aug 2007 14:22:23 +0000 (UTC) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 0E06813C48D; Fri, 31 Aug 2007 14:22:22 +0000 (UTC) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.1/8.14.1) with ESMTP id l7VE3GNA079186; Fri, 31 Aug 2007 07:03:16 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.1/8.14.1/Submit) id l7VE3GV2079185; Fri, 31 Aug 2007 07:03:16 -0700 (PDT) (envelope-from obrien) Date: Fri, 31 Aug 2007 07:03:16 -0700 From: "David O'Brien" To: Hans Petter Selasky Message-ID: <20070831140316.GA79097@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Hans Petter Selasky , freebsd-arch@freebsd.org, arch@freebsd.org References: <8412.1188553371@critter.freebsd.dk> <200708311257.31627.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200708311257.31627.hselasky@c2i.net> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.11 Cc: arch@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Proof of concept: soundcard as console device X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2007 14:22:23 -0000 On Fri, Aug 31, 2007 at 12:57:30PM +0200, Hans Petter Selasky wrote: > BTW: Why can't you use an USB serial adapter connected to the PC ? That requires a USB stack that runs without using interrupts. That is the stumbling block. -- -- David (obrien@FreeBSD.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" From owner-freebsd-arch@FreeBSD.ORG Fri Aug 31 17:12:17 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CE1D16A419; Fri, 31 Aug 2007 17:12:17 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe09.swip.net [212.247.155.1]) by mx1.freebsd.org (Postfix) with ESMTP id 72CAA13C481; Fri, 31 Aug 2007 17:12:16 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.lan) by mailfe09.swip.net (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 427690800; Fri, 31 Aug 2007 17:53:27 +0200 From: Hans Petter Selasky To: obrien@freebsd.org Date: Fri, 31 Aug 2007 17:53:39 +0200 User-Agent: KMail/1.9.7 References: <8412.1188553371@critter.freebsd.dk> <200708311257.31627.hselasky@c2i.net> <20070831140316.GA79097@dragon.NUXI.org> In-Reply-To: <20070831140316.GA79097@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708311753.40476.hselasky@c2i.net> Cc: arch@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Proof of concept: soundcard as console device X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2007 17:12:17 -0000 On Friday 31 August 2007, David O'Brien wrote: > On Fri, Aug 31, 2007 at 12:57:30PM +0200, Hans Petter Selasky wrote: > > BTW: Why can't you use an USB serial adapter connected to the PC ? > > That requires a USB stack that runs without using interrupts. > That is the stumbling block. That's not a problem. For a long time the USB stack has supported polling! --HPS From owner-freebsd-arch@FreeBSD.ORG Fri Aug 31 17:12:17 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CE1D16A419; Fri, 31 Aug 2007 17:12:17 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe09.swip.net [212.247.155.1]) by mx1.freebsd.org (Postfix) with ESMTP id 72CAA13C481; Fri, 31 Aug 2007 17:12:16 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.lan) by mailfe09.swip.net (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 427690800; Fri, 31 Aug 2007 17:53:27 +0200 From: Hans Petter Selasky To: obrien@freebsd.org Date: Fri, 31 Aug 2007 17:53:39 +0200 User-Agent: KMail/1.9.7 References: <8412.1188553371@critter.freebsd.dk> <200708311257.31627.hselasky@c2i.net> <20070831140316.GA79097@dragon.NUXI.org> In-Reply-To: <20070831140316.GA79097@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708311753.40476.hselasky@c2i.net> Cc: arch@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Proof of concept: soundcard as console device X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2007 17:12:17 -0000 On Friday 31 August 2007, David O'Brien wrote: > On Fri, Aug 31, 2007 at 12:57:30PM +0200, Hans Petter Selasky wrote: > > BTW: Why can't you use an USB serial adapter connected to the PC ? > > That requires a USB stack that runs without using interrupts. > That is the stumbling block. That's not a problem. For a long time the USB stack has supported polling! --HPS From owner-freebsd-arch@FreeBSD.ORG Fri Aug 31 22:02:04 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6401816A419 for ; Fri, 31 Aug 2007 22:02:04 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from gidgate.gid.co.uk (gid.co.uk [194.32.164.225]) by mx1.freebsd.org (Postfix) with ESMTP id 9BC5213C4D5 for ; Fri, 31 Aug 2007 22:02:03 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from [194.32.164.30] (host-83-146-60-88.bulldogdsl.com [83.146.60.88]) by gidgate.gid.co.uk (8.13.8/8.13.8) with ESMTP id l7VLmbJY028970; Fri, 31 Aug 2007 22:48:38 +0100 (BST) (envelope-from rb@gid.co.uk) In-Reply-To: <8412.1188553371@critter.freebsd.dk> References: <8412.1188553371@critter.freebsd.dk> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8CBA5466-FA65-4978-B963-B8CA8D76D1DA@gid.co.uk> Content-Transfer-Encoding: 7bit From: Bob Bishop Date: Fri, 31 Aug 2007 22:48:08 +0100 To: Poul-Henning Kamp X-Mailer: Apple Mail (2.752.3) Cc: arch@freebsd.org Subject: Re: Proof of concept: soundcard as console device X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2007 22:02:04 -0000 On 31 Aug 2007, at 10:42, Poul-Henning Kamp wrote: > [...] What's left to do: > > * optimize transmission schema. With a sound card, use (multi-level?) FSK. -- Bob Bishop +44 (0)118 940 1243 rb@gid.co.uk fax +44 (0)118 940 1295 From owner-freebsd-arch@FreeBSD.ORG Fri Aug 31 22:03:34 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 641B716A46D for ; Fri, 31 Aug 2007 22:03:34 +0000 (UTC) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 458D513C4D1 for ; Fri, 31 Aug 2007 22:03:34 +0000 (UTC) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.1/8.14.1) with ESMTP id l7VM3ILV007825; Fri, 31 Aug 2007 15:03:18 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.1/8.14.1/Submit) id l7VM3IXb007824; Fri, 31 Aug 2007 15:03:18 -0700 (PDT) (envelope-from obrien) Date: Fri, 31 Aug 2007 15:03:18 -0700 From: "David O'Brien" To: John Baldwin Message-ID: <20070831220318.GA4861@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, John Baldwin , Jeff Roberson , freebsd-arch@freebsd.org References: <20070815233852.X568@10.0.0.1> <200708161056.31494.jhb@freebsd.org> <20070816131327.J568@10.0.0.1> <200708161635.20935.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200708161635.20935.jhb@freebsd.org> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.11 Cc: freebsd-arch@freebsd.org Subject: Re: file locking. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2007 22:03:34 -0000 On Thu, Aug 16, 2007 at 04:35:20PM -0400, John Baldwin wrote: > On Thursday 16 August 2007 04:18:51 pm Jeff Roberson wrote: > > Do we have an official stance on libkvm? Now that we have sysctl for > > run-time it's only useful for crashdump debugging. Really in most cases > > it could be replaced with a reasonable set of gcc scripts. > > s/gcc/gdb/. At work we do mostly post-mortem analysis, so having working > libkvm is still very important for us. xref the way I just fixed netstat to > work again on coredumps recently. Breaking fstat on coredumps would probably > be very annoying. This applies at Juniper as well. I think post-mortem analysis is a Big Deal(tm) to those developing commercial products based on FreeBSD. -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Fri Aug 31 22:52:07 2007 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43C2C16A417 for ; Fri, 31 Aug 2007 22:52:07 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from creme-brulee.marcuscom.com (penna-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::1279]) by mx1.freebsd.org (Postfix) with ESMTP id D782013C461 for ; Fri, 31 Aug 2007 22:52:06 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from [IPv6:2001:470:1f00:2464::4] (shumai.marcuscom.com [IPv6:2001:470:1f00:2464::4]) by creme-brulee.marcuscom.com (8.14.1/8.14.1) with ESMTP id l7VMq2O3001524 for ; Fri, 31 Aug 2007 18:52:02 -0400 (EDT) (envelope-from marcus@FreeBSD.org) From: Joe Marcus Clarke To: freebsd-arch@FreeBSD.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-5VC5dfdhhdL4pmUdMfXX" Organization: FreeBSD, Inc. Date: Fri, 31 Aug 2007 18:52:01 -0400 Message-Id: <1188600721.1255.11.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on creme-brulee.marcuscom.com Cc: Subject: Understanding interrupted system calls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2007 22:52:07 -0000 --=-5VC5dfdhhdL4pmUdMfXX Content-Type: text/plain Content-Transfer-Encoding: quoted-printable In my attempts to debug the problems with ConsoleKit and the VT_WAITACTIVE ioctl, I delved into the tsleep/msleep code, and I think I have a pretty good idea when it returns EINTR vs. ERESTART. However, I'm curious as to why I have to do something like the following to allow a process waiting in tsleep() to die when it receives a termination signal (e.g. SIGTERM or SIGINT): struct sigaction sa; sa.sa_handler =3D SIG_DFL; ... sigaction (SIGTERM, &sa, NULL); Shouldn't the ps_sigintr set be initialized to the default set of termination signals by default (e.g. in init_main.c proc0_init())? That is, shouldn't the list of signals whose default action is to terminate the process (according to signal(3)) be allowed to interrupt a system call by default? If one then wants to restart the syscall, they can explicitly do: struct sigaction sa; sa.sa_flags =3D SA_RESTART; ... sigaction (SIGTERM, &sa, NULL); I'm just trying to get a better handle on why terminating a program that is running the VT_WAITACTIVE ioctl leaves an unkillable process on FreeBSD, but apparently just causes the program to terminate on Linux. Joe --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-5VC5dfdhhdL4pmUdMfXX Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBG2JuLb2iPiv4Uz4cRAuAMAJ90Mx4EM5avJpf8l39v3lD6qLGGEgCgkVas F7UWS+dPX84jJeec94h2hFU= =TFHe -----END PGP SIGNATURE----- --=-5VC5dfdhhdL4pmUdMfXX-- From owner-freebsd-arch@FreeBSD.ORG Sat Sep 1 11:26:03 2007 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AD2C16A47D; Sat, 1 Sep 2007 11:26:03 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (meestal-mk5.stack.nl [IPv6:2001:610:1108:5010::149]) by mx1.freebsd.org (Postfix) with ESMTP id D3A4E13C4FB; Sat, 1 Sep 2007 11:26:02 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 33B783F589; Sat, 1 Sep 2007 13:26:01 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 1DC97228C0; Sat, 1 Sep 2007 13:26:01 +0200 (CEST) Date: Sat, 1 Sep 2007 13:26:00 +0200 From: Jilles Tjoelker To: Joe Marcus Clarke Message-ID: <20070901112600.GA33832@stack.nl> References: <1188600721.1255.11.camel@shumai.marcuscom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1188600721.1255.11.camel@shumai.marcuscom.com> X-Operating-System: FreeBSD 6.2-STABLE i386 User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-arch@FreeBSD.org Subject: Re: Understanding interrupted system calls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2007 11:26:03 -0000 On Fri, Aug 31, 2007 at 06:52:01PM -0400, Joe Marcus Clarke wrote: > In my attempts to debug the problems with ConsoleKit and the > VT_WAITACTIVE ioctl, I delved into the tsleep/msleep code, and I think I > have a pretty good idea when it returns EINTR vs. ERESTART. However, > I'm curious as to why I have to do something like the following to allow > a process waiting in tsleep() to die when it receives a termination > signal (e.g. SIGTERM or SIGINT): > > struct sigaction sa; > > sa.sa_handler = SIG_DFL; > ... > sigaction (SIGTERM, &sa, NULL); > > Shouldn't the ps_sigintr set be initialized to the default set of > termination signals by default (e.g. in init_main.c proc0_init())? That > is, shouldn't the list of signals whose default action is to terminate > the process (according to signal(3)) be allowed to interrupt a system > call by default? If one then wants to restart the syscall, they can > explicitly do: > struct sigaction sa; > sa.sa_flags = SA_RESTART; > ... > sigaction (SIGTERM, &sa, NULL); > I'm just trying to get a better handle on why terminating a program that > is running the VT_WAITACTIVE ioctl leaves an unkillable process on > FreeBSD, but apparently just causes the program to terminate on Linux. The problem seems to be the following code in src/sys/dev/syscons/syscons.c, in case VT_WAITACTIVE in scioctl(): while ((error=tsleep(&scp->smode, PZERO|PCATCH, "waitvt", 0)) == ERESTART) ; If a signal is caught and system call restart is enabled for that signal, this makes it spin in a tight loop, waiting in vain for the signal to go away. The idea of ERESTART is that the syscall function returns it and then the signal handler is entered. If and when the signal handler returns, it will return to the system call instruction, restarting it (perhaps this is optimized to avoid the switch to userland and back). With EINTR, the signal handler would return to directly after the system call instruction. The fixed version would then be error = tsleep(&scp->smode, PZERO|PCATCH, "waitvt", 0); I have not tested this, however. The VT_WAITACTIVE implementation in pcvt (src/sys/i386/isa/pcvt/pcvt_ext.c) appears to have the same issue (in RELENG_6; pcvt has been removed from HEAD). -- Jilles Tjoelker From owner-freebsd-arch@FreeBSD.ORG Sat Sep 1 15:33:06 2007 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CEDF16A417 for ; Sat, 1 Sep 2007 15:33:06 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from creme-brulee.marcuscom.com (penna-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::1279]) by mx1.freebsd.org (Postfix) with ESMTP id E978413C45D for ; Sat, 1 Sep 2007 15:33:05 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from [IPv6:2001:470:1f00:2464::4] (shumai.marcuscom.com [IPv6:2001:470:1f00:2464::4]) by creme-brulee.marcuscom.com (8.14.1/8.14.1) with ESMTP id l81FX4PY008408; Sat, 1 Sep 2007 11:33:05 -0400 (EDT) (envelope-from marcus@FreeBSD.org) From: Joe Marcus Clarke To: Jilles Tjoelker In-Reply-To: <20070901112600.GA33832@stack.nl> References: <1188600721.1255.11.camel@shumai.marcuscom.com> <20070901112600.GA33832@stack.nl> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ZZaeLCSTA/pFm7KdVpbu" Organization: FreeBSD, Inc. Date: Sat, 01 Sep 2007 11:33:02 -0400 Message-Id: <1188660782.41727.5.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on creme-brulee.marcuscom.com Cc: freebsd-arch@FreeBSD.org Subject: Re: Understanding interrupted system calls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2007 15:33:06 -0000 --=-ZZaeLCSTA/pFm7KdVpbu Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2007-09-01 at 13:26 +0200, Jilles Tjoelker wrote: > On Fri, Aug 31, 2007 at 06:52:01PM -0400, Joe Marcus Clarke wrote: > > In my attempts to debug the problems with ConsoleKit and the > > VT_WAITACTIVE ioctl, I delved into the tsleep/msleep code, and I think = I > > have a pretty good idea when it returns EINTR vs. ERESTART. However, > > I'm curious as to why I have to do something like the following to allo= w > > a process waiting in tsleep() to die when it receives a termination > > signal (e.g. SIGTERM or SIGINT): > >=20 > > struct sigaction sa; > >=20 > > sa.sa_handler =3D SIG_DFL; > > ... > > sigaction (SIGTERM, &sa, NULL); > >=20 > > Shouldn't the ps_sigintr set be initialized to the default set of > > termination signals by default (e.g. in init_main.c proc0_init())? Tha= t > > is, shouldn't the list of signals whose default action is to terminate > > the process (according to signal(3)) be allowed to interrupt a system > > call by default? If one then wants to restart the syscall, they can > > explicitly do: >=20 > > struct sigaction sa; >=20 > > sa.sa_flags =3D SA_RESTART; > > ... > > sigaction (SIGTERM, &sa, NULL); >=20 > > I'm just trying to get a better handle on why terminating a program tha= t > > is running the VT_WAITACTIVE ioctl leaves an unkillable process on > > FreeBSD, but apparently just causes the program to terminate on Linux. >=20 > The problem seems to be the following code in > src/sys/dev/syscons/syscons.c, in case VT_WAITACTIVE in scioctl(): >=20 > while ((error=3Dtsleep(&scp->smode, PZERO|PCATCH, > "waitvt", 0)) =3D=3D ERESTART) ; >=20 > If a signal is caught and system call restart is enabled for that > signal, this makes it spin in a tight loop, waiting in vain for the > signal to go away. The idea of ERESTART is that the syscall function > returns it and then the signal handler is entered. If and when the > signal handler returns, it will return to the system call instruction, > restarting it (perhaps this is optimized to avoid the switch to userland > and back). With EINTR, the signal handler would return to directly > after the system call instruction. >=20 > The fixed version would then be >=20 > error =3D tsleep(&scp->smode, PZERO|PCATCH, "waitvt", 0); >=20 > I have not tested this, however. >=20 > The VT_WAITACTIVE implementation in pcvt > (src/sys/i386/isa/pcvt/pcvt_ext.c) appears to have the same issue (in > RELENG_6; pcvt has been removed from HEAD). I read the code the same way, but being naive in this area, assumed that's how the syscall would get restarted. The way you just described does make much more sense, and also seems to be the way other instances of tsleep() work. However, I'm curious as to my other point in this thread. Why should one need to re-register the default signal handlers to get a syscall to return EINTR? Or should ERESTART be caught and turned into EINTR then return to the caller (as in kern_connect())? Joe --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-ZZaeLCSTA/pFm7KdVpbu Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBG2YYqb2iPiv4Uz4cRAt6LAJ9DoqnwGa83onXMS3GMAsInc9Nq8wCeJnuB 7YL7sC0EE6pUkfAgPoi2v30= =vug/ -----END PGP SIGNATURE----- --=-ZZaeLCSTA/pFm7KdVpbu-- From owner-freebsd-arch@FreeBSD.ORG Sat Sep 1 22:40:27 2007 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF5AE16A420; Sat, 1 Sep 2007 22:40:27 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (meestal-mk5.stack.nl [IPv6:2001:610:1108:5010::149]) by mx1.freebsd.org (Postfix) with ESMTP id 67ECE13C4B0; Sat, 1 Sep 2007 22:40:27 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 1E79A3FDE9; Sun, 2 Sep 2007 00:40:26 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 0E650228C0; Sun, 2 Sep 2007 00:40:26 +0200 (CEST) Date: Sun, 2 Sep 2007 00:40:26 +0200 From: Jilles Tjoelker To: Joe Marcus Clarke Message-ID: <20070901224025.GA97796@stack.nl> References: <1188600721.1255.11.camel@shumai.marcuscom.com> <20070901112600.GA33832@stack.nl> <1188660782.41727.5.camel@shumai.marcuscom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1188660782.41727.5.camel@shumai.marcuscom.com> X-Operating-System: FreeBSD 6.2-STABLE i386 User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-arch@FreeBSD.org Subject: Re: Understanding interrupted system calls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2007 22:40:27 -0000 On Sat, Sep 01, 2007 at 11:33:02AM -0400, Joe Marcus Clarke wrote: > However, I'm curious as to my other point in this thread. Why should > one need to re-register the default signal handlers to get a syscall to > return EINTR? Or should ERESTART be caught and turned into EINTR then > return to the caller (as in kern_connect())? It is intended that most blocking system calls are not interrupted by signals. This saves the programmer some checks on EINTR. (Note that this is only really useful if the program uses signal handlers which do something meaningful other than setting a flag or doing some simple cleanup and terminating the process. Such signal handlers are rarely safe.) Some system calls, e.g. connect(), read/write/etc that have already committed some data and under BSD also select/poll/kqueue do not restart and always return EINTR or partial success. In the kernel code, this appears as changing ERESTART to EINTR. -- Jilles Tjoelker