Hi,
when using the current i386 snapshot kernel my system crashes during
boot, shortly after network initialization.
Messages from the latest snapshot kernel, extracted from /var/log/messages:
Apr 30 09:13:57 ml /bsd: OpenBSD 4.5-current (GENERIC.MP) #8: Tue Apr 28
17:40:03 MDT 2009
Apr 30 09:1
On 2009-04-30, Michael wrote:
> Hi,
>
> when using the current i386 snapshot kernel my system crashes during
> boot, shortly after network initialization.
sorry, this report is no use at all without details of the crash,
use pencil and paper if you have to.
- last line/s printed before it happen
On Thu, Apr 30, 2009 at 09:53:54AM +, Stuart Henderson wrote:
> On 2009-04-30, Michael wrote:
> > Hi,
> >
> > when using the current i386 snapshot kernel my system crashes during
> > boot, shortly after network initialization.
>
> sorry, this report is no use at all without details of the cra
what about making an NFS export, then the underlying file system wouldnt matter?
What about using sshfs?
mic
On Tue, Apr 28, 2009 at 2:02 PM, Coert Waagmeester
wrote:
> They will be the same, config wise, but what I want to do is have some
> kind of seamless failover, ie, box 1 will always be live, and if it goes
> down, I want Box 2 to take over its IP addresses, and continue providing
> all the service
Michael writes:
> my system crashes
[...]
> kqemu: kqemu version 0x00010300 loaded, max locked mem=519228kB
No shit?
//art
Hi,
Owain Ainsworth wrote:
> On Thu, Apr 30, 2009 at 09:53:54AM +, Stuart Henderson wrote:
>> On 2009-04-30, Michael wrote:
>>> Hi,
>>>
>>> when using the current i386 snapshot kernel my system crashes during
>>> boot, shortly after network initialization.
>> sorry, this report is no use at a
I missed it in ouput thanks to my eyes :-) But was too late as I send
response.
Dne 30. duben 2009 14:05 Michael napsal(a):
> Hi,
>
> TomC!E! BodE>C!r wrote:
>> What is a date of this snapshot? #8 looks old I think
>
> It is the latest available snapshot, compiled at Tue Apr 28 17:40:03 MDT
> 200
On Tue, Apr 28, 2009 at 10:18:35PM +0300, Timo Myyr?? wrote:
> I encrypted my $HOME with bioctl and just put the 'bioctl -c C -l
> /dev/sd0g softraid0' line to my /etc/rc. Simple and working solution
> although it needs a little bit tweaking as currently I get dropped to
> single user mode if I
On 30 Apr 2009, at 00:14, Daniel Ouellet wrote:
Joe S wrote:
What's really frustrating here are the network admins I work with
that
are trying to migrate from ipsec vpns to MPLS because it's "easier"
and "just as secure".
Well, I am not sure that it would be very convincing to them, but I
Can a softraid volume be shared between two different computers? Here's
my scenario:
I have two OpenBSD machines, A and B. Both are running OpenBSD 4.4.
Machine A is my primary computer, and I regularly back it up on an
external hard drive, encrypted with softraid. My plan is to copy the
backup
if you end up in ddb try boot crash. If your swap and /var/crash is big
enough you might get a code that you can use to extract the crash.
On Thu, Apr 30, 2009 at 02:12:58PM +0200, Michael wrote:
> Hi,
>
> Owain Ainsworth wrote:
> > On Thu, Apr 30, 2009 at 09:53:54AM +, Stuart Henderson wrot
This should work but there are a few caveats. It has to be same arch
(endiannes really), the softraid code has to be at the same level. Id'd
have to see your disklabel & dmesg to say more but I can assure you that
I do this with USB keys.
On Thu, Apr 30, 2009 at 01:21:16PM +, Matthew Szudzik
On Thu, Apr 30, 2009 at 08:30:25AM -0500, Marco Peereboom wrote:
> This should work but there are a few caveats. It has to be same arch
That's the problem. Machine A is i386 and machine B is macppc.
Won't ever work then.
On Thu, Apr 30, 2009 at 01:58:06PM +, Matthew Szudzik wrote:
> On Thu, Apr 30, 2009 at 08:30:25AM -0500, Marco Peereboom wrote:
> > This should work but there are a few caveats. It has to be same arch
>
> That's the problem. Machine A is i386 and machine B is macppc.
On Tue, 28.04.2009 at 07:12:34 +0200, Otto Moerbeek wrote:
> Caching only reduces load on the DNS system if the caches get used a
> lot. Lots of caches that are virtually unused increase the load.
>
> Imagine every laptop owner would do this, and the resulting load of
> root and other authorativ
Sorry,all. I didn't state what I needed very well. What I'm really looking
for is hardware data related to memory, swap, cpu, pci and scsi devices.
This would be similar to the data on Linux in /proc/meminfo, /proc/cpuinfo,
lspci -v and /proc/scsi/scsi respectively.
Thanks for all responses so
May 1, 2009.
We are pleased to announce the official release of OpenBSD 4.5.
This is our 25th release on CD-ROM (and 26th via FTP). We remain
proud of OpenBSD's record of more than ten years with only two remote
holes in the
Steve Fairhead wrote:
Second, you mentioned embedded work, which is my main work area. Yes,
embedded stuff needs to be stable long-term - but the Internet isn't:
threats change, and OpenBSD evolves. A classic solution to that (which I've
used) is to simply accept that the legacy embedded stuff
2009/4/30 Theo de Raadt :
>
> May 1, 2009.
>
> We are pleased to announce the official release of OpenBSD 4.5.
> This is our 25th release on CD-ROM (and 26th via FTP). We remain
> proud of OpenBSD's record of more than ten ye
* Michael Grigoni [2009-04-30 19:51]:
> I agree online threats change; my argument is for a stable core o/s, with
> patches made for threat mitigation and stable API and ABI and configuration
> within a major release number, to make life easier for small shops that
> can't afford to shoot at movin
I've been thinking of playing with improving the speed of OpenBSD's
cryptography primitives. My tentative plans:
- benchmark aes-ctr performance with current code vs. optimized
assembly code (e.g., just hacking sys/crypto/rijndael.c to use
optimized code); if no significant improvement, abort
On Thu, Apr 30, 2009 at 6:21 PM, Bob Beck wrote:
>The best place to get OpenBSD is from an official CD set, produced
in
> a secured location
Received my official CD set today, thank you all for your hard work!
Steph
2009/4/30 socknoggle :
> Sorry,all. B I didn't state what I needed very well. B What I'm really
looking
> for is hardware data related to memory, swap, cpu, pci and scsi devices.
> This would be similar to the data on Linux in /proc/meminfo, /proc/cpuinfo,
> lspci -v and /proc/scsi/scsi respective
On Thu, Apr 30, 2009 at 2:29 PM, Matthew Dempsky wrote:
> I've been thinking of playing with improving the speed of OpenBSD's
> cryptography primitives. My tentative plans:
> My long term goal/hope is to speed up IPsec, but in the interim I only
> have one machine to work with, so for now I'll p
Henning Brauer wrote:
* Michael Grigoni [2009-04-30 19:51]:
we do not tend to drop support for hardware. happens for really really
ancient stuff (>10years) from time to time, but even that seldom.
In the context of this discussion, the hardware is about 17 years old.
if you spent your
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mic J wrote:
> what about making an NFS export, then the underlying file system wouldnt
> matter?
>
> What about using sshfs?
First, remember I was talking about two partitions on the same machine, so
nothing like NFS (which requires processes on se
Hello,
on my just booted T60 pfctl reports
# pfctl -si
Status: Enabled for 49710 days 04:40:06 Debug: Urgent
State Table Total Rate
current entries 59
searches 15911
inserts
* Luca Corti [2009-04-30 21:51]:
> Hello,
>
> on my just booted T60 pfctl reports
>
> # pfctl -si
> Status: Enabled for 49710 days 04:40:06 Debug: Urgent
that really looks like userland and kernel out of sync or similiar. I
cannot reproduce that.
--
Henning Brauer, h...@bsws.de, henn...@o
On Thu, Apr 30, 2009 at 11:53 AM, Ted Unangst wrote:
> All your plans address making the crypto code faster, but I'm not sure
> that's actually the slow point.
That's possible, hence the first step of benchmarking to see if it
helps at all. If not, I'll take a stab at improving something else
fi
Nice!
I must confess I have a strong bias towards english language when
talking about programming, but as a spanish OpenBSD user I'll try to
support the group as far as possible.
!Mucha suerte en la singladura! ;)
Dani
Daniel Andersen escribis:
Well, I would like to announce that the Spani
* Michael Grigoni [2009-04-30 21:42]:
> Henning Brauer wrote:
>
>> * Michael Grigoni [2009-04-30 19:51]:
>
>
>>
>> we do not tend to drop support for hardware. happens for really really
>> ancient stuff (>10years) from time to time, but even that seldom.
>
> In the context of this discussion, th
And can I ask you Michael what any of this has to do with my original post?
Look at the subject.
Why not start your own thread instead of hi-jacking someone else's?
Bill
-
William J. Chivers
Lecturer in Information Technology
School of DCIT
Faculty of
socknoggle wrote:
> Sorry,all. I didn't state what I needed very well. What I'm really
> looking for is hardware data related to memory, swap, cpu, pci and scsi
> devices. This would be similar to the data on Linux in /proc/meminfo,
> /proc/cpuinfo, lspci -v and /proc/scsi/scsi respectively.
>
>
On Thu, Apr 30, 2009 at 09:34:09AM -0700, socknoggle wrote:
> Thanks for all responses so far!
How many more identical answers do you need?
--
Key ID: 493FB6AE
Key fingerprint: 3E96 7892 B56D AE27 02EF BBAA BAA6 6C78 493F B6AE
Keyserver:pgp.mit.edu
On Thu, Apr 30, 2009 at 03:01:27PM -0400, Chuck Robey wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Mic J wrote:
> > what about making an NFS export, then the underlying file system wouldnt
> > matter?
> >
> > What about using sshfs?
>
> First, remember I was talking about two pa
On Wed, Apr 29, 2009 at 9:44 AM, Daniel Gracia Garallar
wrote:
> Nice!
>
> I must confess I have a strong bias towards english language when talking
> about programming, but as a spanish OpenBSD user I'll try to support the
> group as far as possible.
>
> !Mucha suerte en la singladura! ;)
QuizC!
On Thu, Apr 30, 2009 at 11:29:13AM -0700, Matthew Dempsky wrote:
> I've been thinking of playing with improving the speed of OpenBSD's
> cryptography primitives. My tentative plans:
>
> - benchmark aes-ctr performance with current code vs. optimized
> assembly code (e.g., just hacking sys/crypt
On Thu, Apr 30, 2009 at 4:03 PM, Ariane van der Steldt
wrote:
>> - add new drivers that attach on specific CPUs and hook into the
>> crypto framework to provide optimized implementations
>
> Even if it isn't faster, it may allow the cpu to do something else in
> the meantime. That is a good thin
William Chivers wrote:
And can I ask you Michael what any of this has to do with my original
post? Look at the subject. Why not start your own thread instead of
hi-jacking someone else's?
I was replying to Steve Fairhead's post of 04/12...
Steve Fairhead wrote:
Slightly late in responding t
On 2009-04-30, Ariane van der Steldt wrote:
> On Thu, Apr 30, 2009 at 03:01:27PM -0400, Chuck Robey wrote:
>>
>> My problem is that the FreeBSD side of this match is a RAID1 mirror, using
>> FreeBSD's twa driver. So far, I can't find that driver for OpenBSD, but I'm
>> still looking (it's the AM
On Thu, Apr 30, 2009 at 04:52:59PM -0700, Matthew Dempsky wrote:
> On Thu, Apr 30, 2009 at 4:03 PM, Ariane van der Steldt
> wrote:
> >> ? - add new drivers that attach on specific CPUs and hook into the
> >> crypto framework to provide optimized implementations
> >
> > Even if it isn't faster, it
On Thu, Apr 30, 2009 at 5:24 PM, Ariane van der Steldt wrote:
> I think if you are going to differentiate on that level, you'll not get
> it in the kernel.
That's fine. This is a personal project primarily intended for my own
benefit in learning more about hacking on the kernel. If it actually
> > I think the crypto framework still
> > does too many context switches for small operations. IIRC It also
> > doesn't do much load balancing when you have multiple accelerators in
> > the system.
>
> I'm not too interested in accelerator cards at this point, just
> software implementations (i.
Hello Michael,
Apologies, I guess I was irritated that my original post, with the title above
and written a few weeks ago, was immediately hijacked back then and my original
point was lost. Even Theo responded, not to my point but to the hijack, which
was a rather ignorant question.
Such is li
On 2009-04-30, Matthew Dempsky wrote:
> On Thu, Apr 30, 2009 at 4:03 PM, Ariane van der Steldt
> wrote:
>>> - add new drivers that attach on specific CPUs and hook into the
>>> crypto framework to provide optimized implementations
>>
>> Even if it isn't faster, it may allow the cpu to do someth
listen to ted; he told you the real reason why it is slow.
On Thu, Apr 30, 2009 at 6:53 PM, Marco Peereboom wrote:
> listen to ted; he told you the real reason why it is slow.
Ted said it's slow because of the context switches, but Theo confirmed
that there are no context switches for the soft crypto code, which is
what I'm interested in.
On Thu, Apr 30, 2009 at 6:05 PM, Stuart Henderson wrote:
> I think you may need to update binutils before you can try these
> fastest implementations..
Why do you think that? I just successfully compiled Peter Schwabe's
record setting AES implementations for the Core 2, Athlon 64, and
Pentium 4
On Thu, Apr 30, 2009 at 11:49 PM, Matthew Dempsky wrote:
> On Thu, Apr 30, 2009 at 6:53 PM, Marco Peereboom wrote:
>> listen to ted; he told you the real reason why it is slow.
>
> Ted said it's slow because of the context switches, but Theo confirmed
> that there are no context switches for the
On Thu, Apr 30, 2009 at 9:42 PM, Ted Unangst wrote:
> If you turn on cryptodevallowsoft and run openssl speed -evp
> aes-128-cbc, you can watch the crypto thread in the kernel soaking up
> cpu. In order for the thread to be running, you're definitely context
> switching to it.
Oops, yeah, Marco
> On Thu, Apr 30, 2009 at 9:42 PM, Ted Unangst wrote:
> > If you turn on cryptodevallowsoft and run openssl speed -evp
> > aes-128-cbc, you can watch the crypto thread in the kernel soaking up
> > cpu. In order for the thread to be running, you're definitely context
> > switching to it.
>
> Oops
Shouldn't this go in the OPENBSD_4_5 branch?
Index: newvers.sh
===
RCS file: /cvs/src/sys/conf/newvers.sh,v
retrieving revision 1.94
diff -u -r1.94 newvers.sh
--- newvers.sh 26 Feb 2009 17:55:17 - 1.94
+++ newvers.sh 1 Ma
On Thu, Apr 30, 2009 at 10:18 PM, Theo de Raadt
wrote:
> Again, you have not said what you want to do.
Er, sorry, I thought that email applied regardless.
> Do you want the kernel to do crypto faster, or do you want userland to
> do crypto fast.
The kernel to do crypto faster, hence the email s
54 matches
Mail list logo
