Re: Segfault in _auditreduce_
Patch for the issue:
--- auditreduce.c.orig Mon Oct 22 21:32:07 2007
+++ auditreduce.c Mon Oct 22 21:30:13 2007
@@ -719,7 +719,6 @@
if (n == NULL)
usage("Incorrect event name");
p_evtype = *n;
- free(n);
}
SETOPT(opttochk, OPT_m);
break;
getauevnonam() returns a statically allocated event that the main
function then attempts to free() for some reason. This patch is against
6.2-RELEASE so it's probably already out of date.
--
dc
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Floating point in interrupt handler
Hi all, For a work related project I'm trying to create a sort of real-time control loop. I've written a driver for a PCI data acquisition card that features a number of digital-to-analog and analog-to-digital converters. The goal is to create a control loop that runs about 1 times a second and can be altered on the fly. The control loop should always run, running the rest of FreeBSD (kernel and userland) is less important. To achieve this I've been playing with some modifications to hardclock(). I have added hooks to hardclock() that will call my external loop function once attached. The loop function lives in a seperate kernel module that can be loaded and unloaded on the fly. After changing HZ to 1 I now have a function that gets called 1 times a second that can manipulate the outputs of the acquisition board. As a first test I've created a simple loop that uses integer arithmetic and a lookup table to create a sine wave on one of the DAC outputs. This works like a charm, but I really would like to be able to use floating point instructions to create more advanced control loops. So I've added asm inline functions to use the FPU's fsin and fcos operands. At the start of my loop function I (try to) save the FPU state with the following code : td = curthread; npxgetregs(td, &fpu_state); At the end of the function I restore the FPU state with : npxsetregs(td, &fpu_state); In between I currently have : // create a 500Hz sine wave, modulate it with a 2Hz sine wave and // let it have a 10.0 Volt amplitude t += 0.0001; set_dac_voltage(card, 0, fp_sin(500 * 2 * M_PI * t) * fp_sin(2 * 2 * M_PI * t) * 10.0); As uggly as the code may seem, it works and the output of the acquisition board shows the expected signal on a scope. While the code seems to do what it should, the kernel floods the console with the following message : kernel trap 22 with interrupts disabled As I'm completely new to saving/restoring the FPU state and working with it from within the kernel (and especially from within an interrupt handler) I'm not sure if all the above is the correct way to do things, so please correct me if I'm doing things wrong. I'm also not sure if the FPU state is correctly restored and I haven't done any tests (yet) to check this, but judging by the amount of trap-22 messages I'm getting, I must be doing something wrong ;-) I have done some Googling and found a couple of interresting threads to read : http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2007-03/msg00096.html http://lists.freebsd.org/pipermail/freebsd-emulation/2007-April/003448.html But what I haven't found is a description of exactly what the kernel is missing to allow floating point operations to be done there. Can anyone tell if I'm saving/restoring the FPU state the right way in the code snippets above and what I should do to correctly stop trap 22 from occuring? Thanks, -- Daan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Floating point in interrupt handler
Hi all, For a work related project I'm trying to create a sort of real-time control loop. I've written a driver for a PCI data acquisition card that features a number of digital-to-analog and analog-to-digital converters. The goal is to create a control loop that runs about 1 times a second and can be altered on the fly. The control loop should always run, running the rest of FreeBSD (kernel and userland) is less important. To achieve this I've been playing with some modifications to hardclock(). I have added hooks to hardclock() that will call my external loop function once attached. The loop function lives in a seperate kernel module that can be loaded and unloaded on the fly. After changing HZ to 1 I now have a function that gets called 1 times a second that can manipulate the outputs of the acquisition board. As a first test I've created a simple loop that uses integer arithmetic and a lookup table to create a sine wave on one of the DAC outputs. This works like a charm, but I really would like to be able to use floating point instructions to create more advanced control loops. So I've added asm inline functions to use the FPU's fsin and fcos operands. At the start of my loop function I (try to) save the FPU state with the following code : td = curthread; npxgetregs(td, &fpu_state); At the end of the function I restore the FPU state with : npxsetregs(td, &fpu_state); In between I currently have : // create a 500Hz sine wave, modulate it with a 2Hz sine wave and // let it have a 10.0 Volt amplitude t += 0.0001; set_dac_voltage(card, 0, fp_sin(500 * 2 * M_PI * t) * fp_sin(2 * 2 * M_PI * t) * 10.0); As uggly as the code may seem, it works and the output of the acquisition board shows the expected signal on a scope. While the code seems to do what it should, the kernel floods the console with the following message : kernel trap 22 with interrupts disabled As I'm completely new to saving/restoring the FPU state and working with it from within the kernel (and especially from within an interrupt handler) I'm not sure if all the above is the correct way to do things, so please correct me if I'm doing things wrong. I'm also not sure if the FPU state is correctly restored and I haven't done any tests (yet) to check this, but judging by the amount of trap-22 messages I'm getting, I must be doing something wrong ;-) I have done some Googling and found a couple of interresting threads to read : http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2007-03/msg00096.html http://lists.freebsd.org/pipermail/freebsd-emulation/2007-April/003448.html But what I haven't found is a description of exactly what the kernel is missing to allow floating point operations to be done there. Can anyone tell if I'm saving/restoring the FPU state the right way in the code snippets above and what I should do to correctly stop trap 22 from occuring? Thanks, -- Daan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: packages, libfetch, and SSL
On Sun, Oct 21, 2007 at 08:28:19PM -0700, David E. Thiel wrote: > On Mon, Oct 22, 2007 at 10:07:33AM +0800, Adrian Chadd wrote: > > You can't (easily) cache data over SSL. Well, you can't use a HTTP > > proxy that doesn't break the SSL conversation and cache the updates. > > > > As someone who occasionally makes sure that distribution updates > > through a Squid proxy actually caches said updates, I'd really prefer > > you didn't stick package contents behind SSL. > > Fair enough. > > > > Now, we could take another approach of PGP-signing packages instead, but > > > all the efforts I've seen to integrate PGP with the package management > > > system in the past haven't gone anywhere. The changes above seem to be > > > a bit more trivial than inventing a package-signing infrastructure and > > > putting gpg or a BSD-licensed clone into base. Perhaps using SSL to sign > > > packages and having a baked-in key would work as well. > > > > Considering its a solved problem (mostly!) in other distributions, and > > their updates are very cachable, why not do this? > > Sounds fine to me - I'll take a closer look at this. I'd still like > to see the root CA certs merged into base so libfetch can be fixed. > Does anyone object to just using the ones currently provided by the > ca_root_nss port? If we're going to have a default set, this is the right one since it's the one everyone already trusts. It would be useful to know what the security team thinks of the idea. -- Brooks pgpTcH8AFW4PB.pgp Description: PGP signature
Re: packages, libfetch, and SSL
On Mon, Oct 22, 2007 at 10:07:33AM +0800, Adrian Chadd wrote: > You can't (easily) cache data over SSL. Well, you can't use a HTTP > proxy that doesn't break the SSL conversation and cache the updates. > > As someone who occasionally makes sure that distribution updates > through a Squid proxy actually caches said updates, I'd really prefer > you didn't stick package contents behind SSL. Fair enough. > > Now, we could take another approach of PGP-signing packages instead, but > > all the efforts I've seen to integrate PGP with the package management > > system in the past haven't gone anywhere. The changes above seem to be > > a bit more trivial than inventing a package-signing infrastructure and > > putting gpg or a BSD-licensed clone into base. Perhaps using SSL to sign > > packages and having a baked-in key would work as well. > > Considering its a solved problem (mostly!) in other distributions, and > their updates are very cachable, why not do this? Sounds fine to me - I'll take a closer look at this. I'd still like to see the root CA certs merged into base so libfetch can be fixed. Does anyone object to just using the ones currently provided by the ca_root_nss port? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: packages, libfetch, and SSL
On 21/10/2007, David E. Thiel <[EMAIL PROTECTED]> wrote: > > The lowest-impact way to fix this, I think, is to use SSL for pkg_adds. > There are a couple of things that would need to change to make this > happen. You can't (easily) cache data over SSL. Well, you can't use a HTTP proxy that doesn't break the SSL conversation and cache the updates. As someone who occasionally makes sure that distribution updates through a Squid proxy actually caches said updates, I'd really prefer you didn't stick package contents behind SSL. > Now, we could take another approach of PGP-signing packages instead, but > all the efforts I've seen to integrate PGP with the package management > system in the past haven't gone anywhere. The changes above seem to be > a bit more trivial than inventing a package-signing infrastructure and > putting gpg or a BSD-licensed clone into base. Perhaps using SSL to sign > packages and having a baked-in key would work as well. Considering its a solved problem (mostly!) in other distributions, and their updates are very cachable, why not do this? Adrian -- Adrian Chadd - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
