Re: packages, libfetch, and SSL
On Sun, Oct 21, 2007 at 08:28:19PM -0700, David E. Thiel wrote: >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. So would I. >Does anyone object to just using the ones currently provided by the >ca_root_nss port? I would like to have CAcert (www.cacert.org) included. It is not currently in the Mozilla root set but is included in various Linux and other BSD distributions. See http://wiki.cacert.org/wiki/InclusionStatus (which lists FreeBSD on the basis of the now-removed caroot port). I agree that the final decision should be up to the Security team. -- Peter pgpJdew8Ad1VM.pgp Description: PGP signature
Re: A more tenuously package-related question
On Sun, Oct 14, 2007 at 01:19:17PM -1000, Clifton Royston wrote: > On Sun, Oct 14, 2007 at 04:05:20PM -0700, [EMAIL PROTECTED] wrote: > > > I used to use pkg_update from the 'pkg_install-devel' toolset to > > > upgrade systems via replacement of binary packages. ... > > > Is there any better equivalent tool at the moment, or should I just > > > resuscitate the old "pkg_update"? > > > > Did you try ports-mgmt/portupgrade? You can run it as `portupgrade -P` > > for binary updates. Besides actual 'portupgrade', it has a set of > > useful tools, too. But be warned -- the utility is snail-slow. > > I did look at it, but it appeared that it needed to run off the > FreeBSD ports tree, whereas I'm building packages from a separate > instance of the ports tree in our own CVS, with local modifications, > and then deploying these packages on multiple servers. (This time > around, I'm planning to not even install the ports tree on servers > other than the build server.) I therefore need to use a utility which > can operate using only the dependency information in the pkgdb and > embedded in the package files themselves. > > After posting before, I decided to explore pkg_replace, and it > appears that it might be able to do what I want with the right options. I got a request to summarize my results to the list, so here's a quick write-up. Based on my preliminary testing last week, pkg_replace looks like the right tool for package-based server maintenance. One invaluable feature which was not immediately obvious from the description and man page is that if you give it a list of binary packages on the command line, it orders the updates correctly based on the dependencies between those packages. Thus updating my test server with the recently security-fixed versions of the packages for png and ImageMagick was just a matter of executing: sudo pkg_replace png-1.2.22.tbz ImageMagick-nox11-6.3.5.10_1.tbz in my package repository directory. Updating all of my locally written software packages from 1.99 to 2.00 was as simple as: sudo pkg_replace *-2.00.tbz Given this command line, pkg_replace ordered the dependencies properly, and then pkg_deleted each old package and replaced it with the updated version in correct dependency order, and fixed the requirements and dependency links in the package DB. This is much better than pkg_update could do in my experience; if you tried to pkg_update a package in which the newer version had a dependency which had not yet been satisfied, it would simply fail with the old version deleted and the new one not yet installed. (I have not yet checked how pkg_replace works if you are replacing a package with a newer version which has additional dependencies not present in the old one, so I don't know whether it will invoke pkg_add to recursively add the new requirements, but as long as all the packages you want to replace are in one command line it appears to DTRT.) I've confirmed you can also sudo pkg_replace -f foo-1.2.3.tbz to force version 1.2.3 of foo to replace some version x.y.z >= 1.2.3. Without the -f it will balk at replacing a package which has the same or higher version # than the one you're installing. (I had a interim version of a package where I had omitted an item from its packing list, and so wanted to replace it without revving the version.) All good behavior IMHO. Another interesting feature is that its default behavior is to use pkg_create to backup the package you're replacing, according to its packing list, before deleting it. This means by default you should find it trivially easy to roll back the change you just made. It would be really nice to have a tool with this capability in the base system some day (I'm just saying...) -- Clifton -- Clifton Royston -- [EMAIL PROTECTED] / [EMAIL PROTECTED] President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: auditpipe leak?
On Sun, Oct 21, 2007 at 01:47:21PM -0400, [EMAIL PROTECTED] wrote: [..] > > crw--- 1 root wheel0, 137 21 Oct 17:51 /dev/auditpipe0 > crw--- 1 root wheel0, 138 21 Oct 17:51 /dev/auditpipe1 > crw--- 1 root wheel0, 141 21 Oct 17:51 /dev/auditpipe2 > crw--- 1 root wheel0, 142 21 Oct 17:51 /dev/auditpipe3 > crw--- 1 root wheel0, 143 21 Oct 17:51 /dev/auditpipe4 > > The numbers seem to increment forever, in testing, I got up to > /dev/auditpipe50 before rebooting to clean them up (I expect > just restarting devfs would've been enough, in retrospect). > This is not a leak, this is a side effect of how device cloning works in devfs. IIRC these will be garbaged collected at some point, and faster if the system requires the resources. -- Christian S.J. Peron [EMAIL PROTECTED] FreeBSD Committer ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Segfault in praudit
I have fixed this issue in the vendor branch. We expect to do an vendor import soon. On Sun, Oct 21, 2007 at 01:42:12PM -0400, [EMAIL PROTECTED] wrote: > FreeBSD 6.2-RELEASE-p8 #2, i386 > > sudo auditreduce -m AUE_REBOOT /dev/auditpipe | praudit > auditreduce in free(): error: junk pointer, too high to make sense > Abort trap (core dumped) > > sudo auditreduce -m AUE_CONNECT /dev/auditpipe | praudit > auditreduce in free(): error: junk pointer, too high to make sense > Abort trap (core dumped) > > Not-exactly-helpful backtrace: > > #0 0x28146ecb in kill () from /lib/libc.so.6 > #1 0x28146e68 in raise () from /lib/libc.so.6 > #2 0x28145b78 in abort () from /lib/libc.so.6 > #3 0x280e2fdb in _UTF8_init () from /lib/libc.so.6 > #4 0xbfbfea28 in ?? () > #5 0x2814cdd3 in sys_nsig () from /lib/libc.so.6 > #6 0x2814ccd3 in sys_nsig () from /lib/libc.so.6 > #7 0x2814cdf0 in sys_nsig () from /lib/libc.so.6 > #8 0x in ?? () > #9 0x28157d80 in ?? () from /lib/libc.so.6 > #10 0xbfbfe6d8 in ?? () > #11 0x280e3009 in _UTF8_init () from /lib/libc.so.6 > #12 0x28157d80 in ?? () from /lib/libc.so.6 > #13 0x2816da24 in _nsyyin () from /lib/libc.so.6 > #14 0xbfbfe788 in ?? () > #15 0x280e3d69 in _UTF8_init () from /lib/libc.so.6 > #16 0x2808a6c0 in ?? () from /usr/lib/libbsm.so.1 > #17 0x2808a6da in ?? () from /usr/lib/libbsm.so.1 > #18 0x2806f558 in ?? () from /libexec/ld-elf.so.1 > #19 0x08048574 in ?? () > #20 0x0001 in ?? () > #21 0xbfbfe724 in ?? () > #22 0x28051863 in find_symdef () from /libexec/ld-elf.so.1 > Previous frame inner to this frame (corrupt stack?) > > Is this a known problem? It occurs when specifying any valid > event name. > > -- > dc > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Christian S.J. Peron [EMAIL PROTECTED] FreeBSD Committer ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB vs PAE
Bob Bishop wrote: > Hi, > > The whole USB kit and caboodle is nodevice'd out in the PAE config. Can > anyone give a succinct summary of what needs fixing? (EVERYTHING! is an > acceptable answer) Thanks I'm running USB keyboard and mouse under PAE without problems. Don't know about other USB devices. AFAIK everything that is 64-bit clean (i.e. works on AMD64 and other architectures) should work ok with PAE, so try compiling it in and see for yourself. signature.asc Description: OpenPGP digital signature
Re: USB vs PAE
Bob Bishop wrote: > Hi, > > The whole USB kit and caboodle is nodevice'd out in the PAE config. > Can anyone give a succinct summary of what needs fixing? (EVERYTHING! > is an acceptable answer) This may not be related but xorg had real difficulty findind cards with pae (e6850 4 gig)... amd64 fixed this ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Floating point in interrupt handler
On Tuesday 23 October 2007 07:52:41 Issei Suzuki wrote:
> 2007/10/23, Daan Vreeken [PA4DAN] <[EMAIL PROTECTED]>:
> > 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
>
> In FreeBSD, FPU context switch is delayed until FPU is used for the
> first time after user thread is switched. To achieve this, T_DNA
> (FPU device not available trap) is used as follows.
>
> (Before switching thread)
> 1. Save FPU state and enable DNA trap (npxsave() @ /sys/i386/isa/npx.c).
>After this, DNA trap occurs when you access FPU.
> (Switch to another user thread)
> 2. User thread accesses FPU.
> 3. T_DNA trap occurs, and npxdna() @ /sys/i386/isa/npx.c is called.
> 4. Initialize FPU state (1st time) or restore FPU state (2nd times or
> later). 5. Return to user mode, and user thread access FPU again.
>
> So, to use FPU in kernel, you must clear T_DNA trap and initialize FPU
> registers first.
>
> Reading these functions may help you, I think.
>
> /sys/i386/isa/npx.c
>start_emulating()
>stop_emulating()
>npxdna()
Thanks for the insights, this has helped a lot. If I understand the code
correctly, there are 2 options when the kernel arrives at hardclock() :
o The current process is using the FPU (fpcurthread != NULL)
o The current process hasn't used the FPU (yet) since it has been switched to
(fpcurthread == NULL)
In the first case, FPU instructions can be used and will not result in a trap,
but we should save/restore the FPU state before using them so userland
doesn't get confused. In the last case FPU instructions result in a trap, so
we need stop/start_emulating(), but as no one is using the FPU, there is no
need to save/restore it's state.
With this in mind I've come up with the following code :
At the start of the function :
// check FPU state on entry
if (PCPU_GET(fpcurthread) != NULL) {
// someone is using the FPU
// save it's state and remember to put it back later
restore = 1;
fpusave(&fpu_state);
} else {
// no one is using the FPU
// enable use of FPU instructions, no need to save it's state
restore = 0;
stop_emulating();
}
// init FPU state every time we get here, as we don't know who has
// been playing with it in between calls
fninit();
control = __INITIAL_NPXCW__;
fldcw(&control);
Then we do some floating point arithmetic.
And at the end of the function :
// restore FPU state before we leave
if (restore) {
// restore FPU registers to what they were
fpurstor(&fpu_state);
} else {
// no one was using the FPU, so re-enable the FPU trap
start_emulating();
}
With this code trap-22 has stopped to trigger within my function. The FPU
instructions still seem to be executed correctly in my function and when
adding a couple of printf()'s I can see it fpusave() and fpurstor() when
interrupting a userland process that uses the FPU.
Does this look reasonable to everyone?
Thanks,
--
Daan
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
USB vs PAE
Hi, The whole USB kit and caboodle is nodevice'd out in the PAE config. Can anyone give a succinct summary of what needs fixing? (EVERYTHING! is an acceptable answer) Thanks -- Bob Bishop +44 (0)118 940 1243 [EMAIL PROTECTED] fax +44 (0)118 940 1295 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Floating point in interrupt handler
2007/10/23, Daan Vreeken [PA4DAN] <[EMAIL PROTECTED]>: > 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 In FreeBSD, FPU context switch is delayed until FPU is used for the first time after user thread is switched. To achieve this, T_DNA (FPU device not available trap) is used as follows. (Before switching thread) 1. Save FPU state and enable DNA trap (npxsave() @ /sys/i386/isa/npx.c). After this, DNA trap occurs when you access FPU. (Switch to another user thread) 2. User thread accesses FPU. 3. T_DNA trap occurs, and npxdna() @ /sys/i386/isa/npx.c is called. 4. Initialize FPU state (1st time) or restore FPU state (2nd times or later). 5. Return to user mode, and user thread access FPU again. So, to use FPU in kernel, you must clear T_DNA trap and initialize FPU registers first. Reading these functions may help you, I think. /sys/i386/isa/npx.c start_emulating() stop_emulating() npxdna() Regards, -- Issei Suzuki <[EMAIL PROTECTED]> ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Floating point in interrupt handler
Hi SorAlx On Tuesday 23 October 2007 03:35:09 you wrote: > > 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 : > > why do you need floating point? Your ADCs and DACs are probably no more > than 16 bit anyway. Because of several reasons. The most important one being that it's a work related project. I'm the one developing the driver, not the one that's going to write the control loop. I need this driver to be usable by anyone with basic mathematical/programming skills. The second reason would be : "because I know it can be done". The code I currently have successfully uses floating point instructions in the kernel. Any modern CPU can execute extreme amounts of floating point instructions per second. Please lets not try to discuss the (dis)advantages of integer math vs. floating point. I know how to write integer math, but it's not what I'm looking for for this project. Thanks, -- Daan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
