Re: Need to revert behavior of OpenSSH to the old key order ...
--- On Thu, 5/17/12, Jason Hellenthal wrote: > > That is not the standard "key mismatch" error that you > assumed it was. Look at it again - it is saying that > we do have a key for this server of type DSA, but the client > is receiving one of type RSA, etc. > > > > The keys are the same - they have not changed at all - > they are just being presented to clients in the reverse > order, which is confusing them and breaking automated, > key-based login. > > > > I need to take current ssh server behavior (rsa, then > dss) and change it back to the old order (dss, then rsa). > > Have you attempted to change that order via sshd_config and > placing the > DSA directive before the RSA one ? sshd_config has no such config directive. ssh_config does, but that's for clients, and I have no way to interact with the clients. It would indeed be very nice if this key order, which seems like a prime candidate for configuration, was a configurable option in sshd_config, but it is not. I am fairly certain that I need to hack up some source files, and I thought I had it with myproposal.h (see link in OP) but there must be more, because that small change does not fix things... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Need to revert behavior of OpenSSH to the old key order ...
--- On Thu, 5/17/12, Garrett Cooper wrote: > > ... but I'm afraid that changing that line in > myproposal.h BACK TO ssh-dss,ssh-rsa does not solve the > problem. I did indeed make that change to > myproposal.h, manually, and then build the openssh-portable > port, but the behavior persists. > > > > If I simply REMOVE the RSA keys, the error goes away, > and existing DSA-using clients no longer bomb out, but this > is NOT a good solution for two reasons: > > > > 1. anytime I HUP, or start sshd, it's going to create > new RSA keys for me > > > > 2. It's possible that some clients out there really > have been using RSA all along (who knows) and now they are > completely broken, since RSA is not there at all. > > > > I'm more than happy to muck around in the source with > further little edits, just like I did with myproposal.h, but > I have no idea what they would be. > > > > Can anyone help me "make new ssh behave like old one" > ? > > You can probably issue an option via -o with ssh to skip the > prompt (see ssh_config… maybe there's something in there > that can help you). No, I'm not referring to > StrictHostKeyChecking either :). That's on the client side. I don't have access to the clients. I have no way to interact with the clients at all. I need a way to configure (or patch) the OpenSSH server such that it presents keys in the same order (first DSS, then RSA) as it used to. Anyone ? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Need to revert behavior of OpenSSH to the old key order ...
--- On Thu, 5/17/12, Jason Hellenthal wrote: > On Thu, May 17, 2012 at 02:17:03PM -0700, Jason Usher > wrote: > > I have some old 6.x FreeBSD systems that need their > OpenSSH upgraded. > > > > Everything goes just fine, but when I am done, existing > clients are now presented with this message: > > > > > > WARNING: DSA key found for host hostname > > in /root/.ssh/known_hosts:12 > > DSA key fingerprint 4c:29:4b:6e:b8:6b:fa:49... > > > > The authenticity of host 'hostname (10.1.2.3)' can't be > established > > but keys of different type are already known for this > host. > > RSA key fingerprint is a3:22:3d:cf:f2:46:09:f2.. > > Are you sure you want to continue connecting (yes/no) > > > > You must be using different keys for your server than the > one that has > been generated before the upgrade. Just copy your keys over > to the new > location and restart the server daemon and you should be > fine. > > copy /etc/ssh/* -> /usr/local/etc/ssh/ You didn't read that error message. That is not the standard "key mismatch" error that you assumed it was. Look at it again - it is saying that we do have a key for this server of type DSA, but the client is receiving one of type RSA, etc. The keys are the same - they have not changed at all - they are just being presented to clients in the reverse order, which is confusing them and breaking automated, key-based login. I need to take current ssh server behavior (rsa, then dss) and change it back to the old order (dss, then rsa). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Need to revert behavior of OpenSSH to the old key order ...
On Thu, May 17, 2012 at 04:26:38PM -0700, Jason Usher wrote: > > > --- On Thu, 5/17/12, Jason Hellenthal wrote: > > > > That is not the standard "key mismatch" error that you > > assumed it was.? Look at it again - it is saying that > > we do have a key for this server of type DSA, but the client > > is receiving one of type RSA, etc. > > > > > > The keys are the same - they have not changed at all - > > they are just being presented to clients in the reverse > > order, which is confusing them and breaking automated, > > key-based login. > > > > > > I need to take current ssh server behavior (rsa, then > > dss) and change it back to the old order (dss, then rsa). > > > > Have you attempted to change that order via sshd_config and > > placing the > > DSA directive before the RSA one ? > > > sshd_config has no such config directive. ssh_config does, but that's for > clients, and I have no way to interact with the clients. > > It would indeed be very nice if this key order, which seems like a prime > candidate for configuration, was a configurable option in sshd_config, but it > is not. > > I am fairly certain that I need to hack up some source files, and I thought I > had it with myproposal.h (see link in OP) but there must be more, because > that small change does not fix things... You don't have any of this in your config ? # HostKey for protocol version 1 #HostKey /usr/local/etc/ssh/ssh_host_key # HostKeys for protocol version 2 HostKey /usr/local/etc/ssh/ssh_host_rsa_key #HostKey /usr/local/etc/ssh/ssh_host_dsa_key #HostKey /usr/local/etc/ssh/ssh_host_ecdsa_key -- - (2^(N-1)) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Need to revert behavior of OpenSSH to the old key order ...
On Thu, May 17, 2012 at 04:06:11PM -0700, Jason Usher wrote: > > > --- On Thu, 5/17/12, Jason Hellenthal wrote: > > > On Thu, May 17, 2012 at 02:17:03PM -0700, Jason Usher > > wrote: > > > I have some old 6.x FreeBSD systems that need their > > OpenSSH upgraded. > > > > > > Everything goes just fine, but when I am done, existing > > clients are now presented with this message: > > > > > > > > > WARNING: DSA key found for host hostname > > > in /root/.ssh/known_hosts:12 > > > DSA key fingerprint 4c:29:4b:6e:b8:6b:fa:49... > > > > > > The authenticity of host 'hostname (10.1.2.3)' can't be > > established > > > but keys of different type are already known for this > > host. > > > RSA key fingerprint is a3:22:3d:cf:f2:46:09:f2.. > > > Are you sure you want to continue connecting (yes/no) > > > > > > > You must be using different keys for your server than the > > one that has > > been generated before the upgrade. Just copy your keys over > > to the new > > location and restart the server daemon and you should be > > fine. > > > > copy /etc/ssh/* -> /usr/local/etc/ssh/ > > > You didn't read that error message. Sorry I misread that. Decieving message... > > That is not the standard "key mismatch" error that you assumed it was. Look > at it again - it is saying that we do have a key for this server of type DSA, > but the client is receiving one of type RSA, etc. > > The keys are the same - they have not changed at all - they are just being > presented to clients in the reverse order, which is confusing them and > breaking automated, key-based login. > > I need to take current ssh server behavior (rsa, then dss) and change it back > to the old order (dss, then rsa). Have you attempted to change that order via sshd_config and placing the DSA directive before the RSA one ? -- - (2^(N-1)) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Need to revert behavior of OpenSSH to the old key order ...
On Thu, May 17, 2012 at 02:17:03PM -0700, Jason Usher wrote: > I have some old 6.x FreeBSD systems that need their OpenSSH upgraded. > > Everything goes just fine, but when I am done, existing clients are now > presented with this message: > > > WARNING: DSA key found for host hostname > in /root/.ssh/known_hosts:12 > DSA key fingerprint 4c:29:4b:6e:b8:6b:fa:49... > > The authenticity of host 'hostname (10.1.2.3)' can't be established > but keys of different type are already known for this host. > RSA key fingerprint is a3:22:3d:cf:f2:46:09:f2.. > Are you sure you want to continue connecting (yes/no) > You must be using different keys for your server than the one that has been generated before the upgrade. Just copy your keys over to the new location and restart the server daemon and you should be fine. copy /etc/ssh/* -> /usr/local/etc/ssh/ > > And as you can imagine, existing automated jobs now all fail. > > I have no control over the clients.? Assume the clients cannot be touched at > all. > > So, the good news is, this appears to have been discussed/documented here: > > http://www.mail-archive.com/bugs@crater.dragonflybsd.org/msg04860.html > > ... but I'm afraid that changing that line in myproposal.h BACK TO > ssh-dss,ssh-rsa does not solve the problem.? I did indeed make that change to > myproposal.h, manually, and then build the openssh-portable port, but the > behavior persists. > > If I simply REMOVE the RSA keys, the error goes away, and existing DSA-using > clients no longer bomb out, but this is NOT a good solution for two reasons: > > 1. anytime I HUP, or start sshd, it's going to create new RSA keys for me > > 2. It's possible that some clients out there really have been using RSA all > along (who knows) and now they are completely broken, since RSA is not there > at all. > > I'm more than happy to muck around in the source with further little edits, > just like I did with myproposal.h, but I have no idea what they would be. > > Can anyone help me "make new ssh behave like old one" ? > > Thanks. > > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" -- - (2^(N-1)) pgphZW36vGlU7.pgp Description: PGP signature
Need to revert behavior of OpenSSH to the old key order ...
I have some old 6.x FreeBSD systems that need their OpenSSH upgraded. Everything goes just fine, but when I am done, existing clients are now presented with this message: WARNING: DSA key found for host hostname in /root/.ssh/known_hosts:12 DSA key fingerprint 4c:29:4b:6e:b8:6b:fa:49... The authenticity of host 'hostname (10.1.2.3)' can't be established but keys of different type are already known for this host. RSA key fingerprint is a3:22:3d:cf:f2:46:09:f2.. Are you sure you want to continue connecting (yes/no) And as you can imagine, existing automated jobs now all fail. I have no control over the clients. Assume the clients cannot be touched at all. So, the good news is, this appears to have been discussed/documented here: http://www.mail-archive.com/bugs@crater.dragonflybsd.org/msg04860.html ... but I'm afraid that changing that line in myproposal.h BACK TO ssh-dss,ssh-rsa does not solve the problem. I did indeed make that change to myproposal.h, manually, and then build the openssh-portable port, but the behavior persists. If I simply REMOVE the RSA keys, the error goes away, and existing DSA-using clients no longer bomb out, but this is NOT a good solution for two reasons: 1. anytime I HUP, or start sshd, it's going to create new RSA keys for me 2. It's possible that some clients out there really have been using RSA all along (who knows) and now they are completely broken, since RSA is not there at all. I'm more than happy to muck around in the source with further little edits, just like I did with myproposal.h, but I have no idea what they would be. Can anyone help me "make new ssh behave like old one" ? Thanks. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ARM + CACHE_LINE_SIZE + DMA
On Thu, 2012-05-17 at 15:20 +0200, Svatopluk Kraus wrote:
> Hi,
>
> I'm working on DMA bus implementation for ARM11mpcore platform. I've
> looked at implementation in ARM tree, but IMHO it only works with some
> assumptions. There is a problem with DMA on memory block which is not
> aligned on CACHE_LINE_SIZE (start and end) if memory is not coherent.
>
> Let's have a buffer for DMA which is no aligned on CACHE_LINE_SIZE.
> Then first cache line associated with the buffer can be divided into
> two parts, A and B, where A is a memory we know nothing about it and B
> is buffer memory. The same stands for last cache line associatted with
> the buffer. We have no problem if a memory is coherent. Otherwise it
> depends on memory attributes.
>
> 1. [no cache] attribute
> No problem as memory is coherent.
>
> 2. [write throught] attribute
> The part A can be invalidated without loss of any data. It's not problem too.
>
> 3. [write back] attribute
> In general, there is no way how to keep both parts consistent. At the
> start of DMA transaction, the cache line is written back and
> invalidated. However, as we know nothing about memory associated with
> part A of the cache line, the cache line can be filled again at any
> time and messing up DMA transaction if flushed. Even if the cache line
> is only filled but not flushed during DMA transaction, we must make it
> coherent with memory after that. There is a trick with saving part A
> of the line into temporary buffer, invalidating the line, and
> restoring part A in current ARM (MIPS) implementation. However, if
> somebody is writting to memory associated with part A of the line
> during this trick, the part A will be messed up. Moreover, the part A
> can be part of another DMA transaction.
>
> To safely use DMA with no coherent memory, a memory with [no cache] or
> [write throught] attributes can be used without problem. A memory with
> [write back] attribute must be aligned on CACHE_LINE_SIZE.
>
> However, for example mbuf, a buffer for DMA can be part of a structure
> which can be aligned on CACHE_LINE_SIZE, but not the buffer itself. We
> can know that nobody will write to the structure during DMA
> transaction, so it's safe to use the buffer event if it's not aligned
> on CACHE_LINE_SIZE.
>
> So, in practice, if DMA buffer is not aligned on CACHE_LINE_SIZE and
> we want to avoid bounce pages overhead, we must support additional
> information to DMA transaction. It should be easy to support the
> information about drivers data buffers. However, what about OS data
> buffers like mentioned mbufs?
>
> The question is following. Is or can be guaranteed for all or at least
> well-known OS data buffers which can be part of DMA access that the
> not CACHE_LINE_SIZE aligned buffers are surrounded by data which
> belongs to the same object as the buffer and the data is not written
> by OS when given to a driver?
>
> Any answer is appreciated. However, 'bounce pages' is not an answer.
>
> Thanks, Svata
I'm adding freebsd-arm@ to the CC list; that's where this has been
discussed before.
Your analysis is correct... to the degree that it works at all right
now, it's working by accident. At work we've been making the good
accident a bit more likely by setting the minimum allocation size to
arm_dcache_align in kern_malloc.c. This makes it somewhat less likely
that unrelated objects in the kernel are sharing a cache line, but it
also reduces the effectiveness of the cache somewhat.
Another factor, not mentioned in your analysis, is the size of the IO
operation. Even if the beginning of the DMA buffer is cache-aligned, if
the size isn't exactly a multiple of the cache line size you still have
the partial flush situation and all of its problems.
It's not guaranteed that data surrounding a DMA buffer will be untouched
during the DMA, even when that surrounding data is part of the same
conceptual object as the IO buffer. It's most often true, but certainly
not guaranteed. In addition, as Mark pointed out in a prior reply,
sometimes the DMA buffer is on the stack, and even returning from the
function that starts the IO operation affects the cacheline associated
with the DMA buffer. Consider something like this:
void do_io()
{
int buffer;
start_read(&buffer);
// maybe do other stuff here
wait_for_read_done();
}
start_read() gets some IO going, so before it returns a call has been
made to bus_dmamap_sync(..., BUS_DMASYNC_PREREAD) and an invalidate gets
done on the cacheline containing the variable 'buffer'. The act of
returning from the start_read() function causes that cacheline to get
reloaded, so now the stale pre-DMA value of the variable 'buffer' is in
cache again. Right after that, the DMA completes so that ram has a
newer value that belongs in the buffer variable and the copy in the
cacheline is stale.
Before control gets into the wait_for_read_done() routine that will
attempt to handle the POSTREAD parti
Re: ARM + CACHE_LINE_SIZE + DMA
On Thu, May 17, 2012 at 8:20 AM, Svatopluk Kraus wrote: > Hi, > > I'm working on DMA bus implementation for ARM11mpcore platform. I've > looked at implementation in ARM tree, but IMHO it only works with some > assumptions. There is a problem with DMA on memory block which is not > aligned on CACHE_LINE_SIZE (start and end) if memory is not coherent. > > Let's have a buffer for DMA which is no aligned on CACHE_LINE_SIZE. > Then first cache line associated with the buffer can be divided into > two parts, A and B, where A is a memory we know nothing about it and B > is buffer memory. The same stands for last cache line associatted with > the buffer. We have no problem if a memory is coherent. Otherwise it > depends on memory attributes. > > 1. [no cache] attribute > No problem as memory is coherent. > > 2. [write throught] attribute > The part A can be invalidated without loss of any data. It's not problem too. > > 3. [write back] attribute > In general, there is no way how to keep both parts consistent. At the > start of DMA transaction, the cache line is written back and > invalidated. However, as we know nothing about memory associated with > part A of the cache line, the cache line can be filled again at any > time and messing up DMA transaction if flushed. Even if the cache line > is only filled but not flushed during DMA transaction, we must make it > coherent with memory after that. There is a trick with saving part A > of the line into temporary buffer, invalidating the line, and > restoring part A in current ARM (MIPS) implementation. However, if > somebody is writting to memory associated with part A of the line > during this trick, the part A will be messed up. Moreover, the part A > can be part of another DMA transaction. > > To safely use DMA with no coherent memory, a memory with [no cache] or > [write throught] attributes can be used without problem. A memory with > [write back] attribute must be aligned on CACHE_LINE_SIZE. > > However, for example mbuf, a buffer for DMA can be part of a structure > which can be aligned on CACHE_LINE_SIZE, but not the buffer itself. We > can know that nobody will write to the structure during DMA > transaction, so it's safe to use the buffer event if it's not aligned > on CACHE_LINE_SIZE. > > So, in practice, if DMA buffer is not aligned on CACHE_LINE_SIZE and > we want to avoid bounce pages overhead, we must support additional > information to DMA transaction. It should be easy to support the > information about drivers data buffers. However, what about OS data > buffers like mentioned mbufs? > > The question is following. Is or can be guaranteed for all or at least > well-known OS data buffers which can be part of DMA access that the > not CACHE_LINE_SIZE aligned buffers are surrounded by data which > belongs to the same object as the buffer and the data is not written > by OS when given to a driver? > > Any answer is appreciated. However, 'bounce pages' is not an answer. > > Thanks, Svata Sigh. A several ideas by several people, but a good answer has not been created yet. SMP will make this worse. To make things worse, there are drivers that use memory from the stack as DMA buffers. I was hoping that mbufs are pretty well self-contained, unless you expect to modify them while DMA is happening. This is on my to-do list. --Mark. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: GSoC Project: EFI on amd64/i386
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/08/12 13:35, Eric McCorkle wrote: > Hello everyone, > > I'm going to be working on EFI boot support on the amd64/i386 > platforms as a GSoC project. The idea is to allow booting from > EFI (as opposed to legacy BIOS) on these platforms, so that FreeBSD > can continue to support a wide range of hardware as EFI begins to > replace BIOS. ... Just to bring this up, when was the last time anyone actually built the i386 EFI loader? There might be a bit of work to be done to bring it back into a buildable state. There most certainly *is* some work needed to be able to build on amd64. I spent last night poking around, and identified a few things, but I probably shouldn't go any farther until the 21st (or at least until I have a repository) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJPtSADAAoJENSCzbQ+koZ7ydYP/3g6pxpVfRxofDTtLH3MmElW TPMKuTJD4kZqbEjds0u7iXg2uweqUGajMQvOfHi6KXvmKriswrmortrLgMgJCI8P 5HoiS0WDrwRvdL38y5DpzpKZ1rc7RjWS0pEKpPYx3DQh0bps0sb1iAcI8gdPliNL /qRmeLNfiTcaYTOILgPcbWlLnIFYMmg5hmz7zjlIdZYWeBtVdKfrtw6hLCzJqoyz QfL4mzOrBNuXx4jw1yLk3qU7hxsrMkzN3Jm9HOJCb9D/4mDHvF3jmv/o0Jx9hacx Yt9gsYSd/Ot4hOQmB2d9KjOrZMrK5s+JhvknC1sMXz4UD7b6L/AItEpm0OiX1Ls6 2L1Fxob8V0VDZd4JJuZDFWAhqQ6dh9O5mQHrHxTCjEhYIDNPy367L9TdqLtggWN0 EMjVJqfg0XxLRP7vLopax/H6zpd0p8vXUGSxLiKXe4IHWIggPFgaWehslSzgTIu6 2xaETVkaBxt2JXo8ArAyfsvyW6JcZqYp2R2JAUXTNa/PX2Cn9iPFvnsqF7Ir3M5T /cabcrc69fARbRGCtL/vEY0ZHZ33b6K+ACJEmGuamZbDB0Xxe3dgRt+hSWFwjKfq 8+WP7xJ4dfkjICZ/+HXmO9n58myNd2hoBAWQwdG230p55YL2iuqGc2apqnZCsb5o KJVEWBn9VWYBxB/k7yoq =YxYV -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: GSoC Project: EFI on amd64/i386
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/17/12 10:36, John Baldwin wrote: >> Do the kernel and modules actually do anything that depends on >> being in a contiguous space in some way (ie some relocation >> trick)? Because it seems like it shouldn't really matter >> otherwise. > > They are statically linked at a fixed address. Modules can be > wherever, but the kernel has to be at the physical address it is > linked for (unless you make the kernel relocatable). > Hmm. That would definitely be an issue. Are there any reasons inherent to the way the kernel runs that would prevent that from being done? Alternately, it seems you could set up page tables in the EFI loader, though getting the handoff right would be trick to say the least. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJPtR6YAAoJENSCzbQ+koZ7JS4P+wfFfj4U/1OVy4cIyYc39XDt i+LDP1Eq/uSVnVB0Jj58yAMWR0ssrjA4/4DATN/59d5as42o4vN9alf6v+82o8CV mTIiaqynFvTGXaEdZE/tXz1TDshjt5zUMXjoBSMfkrVxHLhTvJNImmk6Zlc5lfQm GJ194X4rhiRK3BRyEWK0sHaGie88GYXcrZBr5iyLvi4MkqS6HnC5rV3ZaXQ4uqz3 po4eHbuIeU88INnL7qGULnGiZzGoTULaFdheDMxU7UtD++kGxpRfhqsCkJ3RbRb6 BxqI70CrKPBp/6CILSsaYqPKzn8Ew5xmG7qoxfBgmqLNOfoSyTsmybGXotRocxlO EQIG0BEcEu51OGAh5eDADBnfNw347cyGwdtr0HI7rPegK4CNedc5uf/OMoHlNz2F 9guzJLkG7Ruk6oIIyP5wn3m5uB1S5mJ0c5jow9Vxfie20TVzzHhZSNn6ipryt8iT FbN/sMReLudVlpEv5aQ2N1Y4YH2lt9Qqbg4h5qpQ6l89mGredGb4jOHJTKFchCLp N9B185r2O5emFV2jS6C/Nkcdqmp69hg/4jxn8aOVR2dmt//gBMy3KYlflLaBSIzQ r0Wzga+a/GOTX90ii1386q7HhQtAb0facBA3A0h0k9fb9BFra2LUO/vkXMLrxqUR +z8kQiLx8O0gFAanF7gN =sSDg -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: GSoC Project: Automated Kernel Crash Reporting System - Discussion
On Wednesday, May 16, 2012 10:00:33 am Mateusz Guzik wrote: > Are you going to support textdumps? > > I would like to note that some machines have swap space only for > textdumps, so I think you should support these. > > ddb is equiped with a lot of cool commands that show various important > debugging information(e.g. show alllocks). AFAIK kgdb doesn't have such > facilities so you will have to implement those first if you decide to > use it (btw I think these would be useful even without this project). > Take a look at tools/debugscripts. > > That being said, I would give a priority to support for textdumps (and > in case kgdb support cannot be finished in time, I would make sure that > the project is expendable enough to support information obtained from > kgdb and possibly other sources). Note that it is not hard to support these in kgdb. I have gdb scripts that already provide equivalents to 'show lockchain' and many other commands. However, the problem with textdumps (which are still worth reporting), is that for hard bugs a developer often wants to ask the submitter for specific information, and won't know what to ask for until looking at the general information. There simply isn't a way to grab all the possible information up front in textdumps. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: GSoC Project: Automated Kernel Crash Reporting System - Discussion
On Tuesday, May 15, 2012 5:30:20 pm tza...@it.teithe.gr wrote: > Hello Community, > > I have the project "Automated Kernel Crash Reporting System" for this > GSoC and I would like to discuss my plans about it before starting the > coding on May 21. > > I have created a page in the FreeBSD Wiki > (http://wiki.freebsd.org/SummerOfCode2012/AutomatedKernelCrashReportingSystem) > where I describe in details the architecture of the system. > > Here are some points that I would like to be discussed: > > * The implementation of the kcrashreporter is planned to be done in > two shell scripts. The first shell script is a rc.d script and the > second is the actual program. I choose to code it in shell because > kcrashreporter invokes the kgdb to collect the necessary debugging > information. I think that using the shell instead of traditional > programming language for this kind of job is more straightforward and > natural. Do you have a different opinion? Have you looked at /usr/sbin/crashinfo? -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: GSoC Project: EFI on amd64/i386
On Wednesday, May 16, 2012 9:24:54 am Eric McCorkle wrote: > On 05/15/12 11:44, John Baldwin wrote: > > The i386 kernel assumes it starts out with a flat 32-bit mode with > > the kernel loaded into a contiguous memory region at a fixed > > physical address. If we need a relocatable kernel (as Marcel > > hinted at I think), then that adds a fair bit of complication. > > > > The amd64 kernel assumes it starts in long mode (the bootinfo64.c > > bits in the loader setup initial page tables, etc.). I think the > > amd64 kernel also has to be loaded into contiguous memory at a > > fixed physical address currently. > > > > Seems like an initial workaround could be to allocate a space big > enough for all the necessary ELF segments, and split it up ourselves. > > Do the kernel and modules actually do anything that depends on being > in a contiguous space in some way (ie some relocation trick)? Because > it seems like it shouldn't really matter otherwise. They are statically linked at a fixed address. Modules can be wherever, but the kernel has to be at the physical address it is linked for (unless you make the kernel relocatable). -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: new panic in cpu_reset() with WITNESS
2012/5/17, Andriy Gapon : > on 25/01/2012 23:52 Andriy Gapon said the following: >> on 24/01/2012 14:32 Gleb Smirnoff said the following: >>> Yes, now: >>> >>> Rebooting... >>> lock order reversal: >>> 1st 0x80937140 smp rendezvous (smp rendezvous) @ >>> /usr/src/head/sys/kern/kern_shutdown.c:542 >>> 2nd 0xfe0001f5d838 uart_hwmtx (uart_hwmtx) @ >>> /usr/src/head/sys/dev/uart/uart_cpu.h:92 >>> panic: mtx_lock_spin: recursed on non-recursive mutex cnputs_mtx @ >>> /usr/src/head/sys/kern/kern_cons.c:500 >> >> OK, so it's just a plain LOR between smp rendezvous and uart_hwmtx, no >> new >> details... >> >> It's still intriguing to me why the LOR *doesn't* happen [*] with >> stop_scheduler_on_panic=0. But I don't see a productive way to pursue >> this >> investigation further. > > Salve Glebius! > After your recent nudging I took yet another look at this issue and it seems > that > I have some findings. > > For those who might get interested here is a convenience reference to the > whole > thread on gmane: http://thread.gmane.org/gmane.os.freebsd.current/139307 > > A short summary. > Prerequisites: an SMP x86 system, its kernel is configured with WITNESS && > !WITNESS_SKIPSPIN (this is important) and a system uses serial console via > uart. > Then, if stop_scheduler_on_panic is set to zero the system can be rebooted > without > a problem. On the other hand, if stop_scheduler_on_panic is enabled, then > the > system first runs into a LOR when calling printf() in cpu_reset() and then > it runs > into a panic when printf is recursively called from witness(9) to report the > LOR. > The panic happens because of the recursion on cnputs_mtx, which should > ensure > that cnputs() output is not intermingled and which is not flagged to > support > recursion. > > There are two things about this report that greatly confused and puzzled > me: > 1. stop_scheduler_on_panic variable is used _only_ in panic(9). So how > could it > be possible that changing its value affects behavior of the system when > panic(9) > is not called?! > > 2. The LOR in question happens between "smp rendezvous" (smp_ipi_mtx) and > "uart_hwmtx" (sc_hwmtx_s in uart core) spin locks. The order of these locks > is > actually predefined in witness order_lists[] such that uart_hwmtx must come > before > smp_ipi_mtx. But in the reboot path we first take smp_ipi_mtx in > shutdown_reset(), then we call cpu_reset, then it calls printf and from > there we > get to uart_hwmtx for serial console output. So the order between these > spinlocks > is always violated in the x86 SMP reboot path. > How come witness(9) doesn't _always_ detect this LOR? > How come it didn't detect this LOR before any "stop scheduler" commits?! > > [Spoiler alert :-)] > > Turns out that the two puzzles above are closely related. > Let's first list all the things that change when stop_scheduler_on_panic is > enabled and a panic happens: > - other CPUs are stopped (forced to spin) > - interrupts on current CPU are disabled > - by virtue of the above the current thread should be the only thread > running > (unless it executes a voluntary switch) > - all locks are "busted", they are completely ignored / bypassed > - by virtue of the above no lock invariants and witness checks are > performed, so > no lock order checking, no recursion checking, etc > > So, what I observe is this: when stop_scheduler_on_panic is disabled, the > LOR is > actually detected as it should be. witness(9) works properly here. Once > the LOR > is detected witness(9) wants to report it using printf(9). That's where we > run > into the cnputs_mtx recursion panic. It's all exactly as with > stop_scheduler_on_panic enabled. Then panic(9) wants to report the panic > using > printf(9), which goes to cnputs() again, where _mtx_lock_spin_flags() > detects > locks recursion again (this is independent of witness(9)) and calls > panic(9) > again. Then panic(9) wants to report the panic using printf(9)... > I assume that when the stack is exhausted we run into a double fault and > dblfault_handler wants to print something again... Likely we eventually run > into > a triple fault which resets the machine. Although, I recall some old > reports of > machines hanging during reboot in a place suspiciously close to where the > described ordeal happens... > But if the machine doesn't hang we get a full appearance of the reset > successfully > happening (modulo some last messages missing). > > With stop_scheduler_on_panic enabled and all the locks being ignored we, of > course, do not run into any secondary lock recursions and resulting panics. > So > the system is able to at least panic "gracefully" (still we should have > just > reported the LOR gracefully, no panic is required). > > Some obvious conclusions: > - the "smp rendezvous" and "uart_hwmtx" LOR is real and it is the true cause > of > the problem; it should be fixed one way or other - either by correcting > witness > order_lists[] or by avoiding the
Re: GSoC Project: EFI on amd64/i386
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/16/12 01:32, Andrey V. Elsukov wrote: > As i see we already have sys/boot/efi/libefi/efipart.c that uses > EFI BLOCK_IO_PROTOCOL to make "part" devsw. EFI BLOCK_IO_PROTOCOL > provides access to each disk and partition. AFAIK it supports only > GPT and MBR+EBR, so there might be some problems with ZFS support, > because we can use ZFS atop of BSD partition. > I'd need to take a look, but if the efi loaders are not directly calling the EFI_BLOCK_IO_PROTOCOL functions, then it should be easy to implement a layer that understands BSDlabels. IA64 might have a solution. Then again, is a BSDlabel really necessary on a GPT disk? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJPtPziAAoJENSCzbQ+koZ7WZwQAKPN80f/I3obnwSNgSeJ9RyJ q14FYshFuOyaiPPm+HsRdJsv82rdOx9AWi5uuBLTjGADHQ7FdVZTk7fIvhSakUHN d6s/FTcxpLopnibNApXXPNla2fHi25qz8c4axd/4XyxoJ1EGIWnXJ3pQ8R/GCNhK olXDocZ+vylO6IW0ta2C4yq2rYFLNCKoR5+Kdoo4B/S+NEguqBCUW/DXTvWqeJw5 GJGzCTDmCKGaOp9LrSQ5jws4XmnqsoBFeL7Zd1Yu40KvS3QyhHpeh1GCZklq3ncG xdGcK4P7/rwrfR3zSf0tHFCbt1o7BJ0XNHL4MrZflbGuQFGvIbdReXNmLi4QDvKS 7QzqsbbtgnL6NrWfJ/Z4UqEZt0dKAj9wZNX5AVP+p2KJomSoV2NPnuuFKAtoiGfe 282daJ4q3D60fxfdo/rExdpA6k2usnxZDCyFM15hhg4jJQDnl32Yj9ym5bbTeDDU Uqoh1Ka/Oj/RtRXHLFdAdL34Jm4RyFgeaRUtVD7o7f5ASCHx0EuFFAh1eZTqFCEi yN1V1+z8FE7va0fQDO7a5S+2O8Hph9K+W8Dxcuq1g/Rg8mBZ8Klny6etWghP6vvR ISiqdMvLkfqqF3eVcB/EY9rLahHr14kabMtSWLRVurVjEPxZ/ju0+9342z3vcY75 xIQe8JfKjuOjkclmpioa =flEs -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
ARM + CACHE_LINE_SIZE + DMA
Hi, I'm working on DMA bus implementation for ARM11mpcore platform. I've looked at implementation in ARM tree, but IMHO it only works with some assumptions. There is a problem with DMA on memory block which is not aligned on CACHE_LINE_SIZE (start and end) if memory is not coherent. Let's have a buffer for DMA which is no aligned on CACHE_LINE_SIZE. Then first cache line associated with the buffer can be divided into two parts, A and B, where A is a memory we know nothing about it and B is buffer memory. The same stands for last cache line associatted with the buffer. We have no problem if a memory is coherent. Otherwise it depends on memory attributes. 1. [no cache] attribute No problem as memory is coherent. 2. [write throught] attribute The part A can be invalidated without loss of any data. It's not problem too. 3. [write back] attribute In general, there is no way how to keep both parts consistent. At the start of DMA transaction, the cache line is written back and invalidated. However, as we know nothing about memory associated with part A of the cache line, the cache line can be filled again at any time and messing up DMA transaction if flushed. Even if the cache line is only filled but not flushed during DMA transaction, we must make it coherent with memory after that. There is a trick with saving part A of the line into temporary buffer, invalidating the line, and restoring part A in current ARM (MIPS) implementation. However, if somebody is writting to memory associated with part A of the line during this trick, the part A will be messed up. Moreover, the part A can be part of another DMA transaction. To safely use DMA with no coherent memory, a memory with [no cache] or [write throught] attributes can be used without problem. A memory with [write back] attribute must be aligned on CACHE_LINE_SIZE. However, for example mbuf, a buffer for DMA can be part of a structure which can be aligned on CACHE_LINE_SIZE, but not the buffer itself. We can know that nobody will write to the structure during DMA transaction, so it's safe to use the buffer event if it's not aligned on CACHE_LINE_SIZE. So, in practice, if DMA buffer is not aligned on CACHE_LINE_SIZE and we want to avoid bounce pages overhead, we must support additional information to DMA transaction. It should be easy to support the information about drivers data buffers. However, what about OS data buffers like mentioned mbufs? The question is following. Is or can be guaranteed for all or at least well-known OS data buffers which can be part of DMA access that the not CACHE_LINE_SIZE aligned buffers are surrounded by data which belongs to the same object as the buffer and the data is not written by OS when given to a driver? Any answer is appreciated. However, 'bounce pages' is not an answer. Thanks, Svata ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: GSoC Project: Automated Kernel Crash Reporting System - Discussion
On Wed, May 16, 2012 at 11:37:44PM +0300, tza...@it.teithe.gr wrote:
> Quoting Mateusz Guzik :
>
> >On Wed, May 16, 2012 at 12:30:20AM +0300, tza...@it.teithe.gr wrote:
> >>Hello Community,
> >>
> >>I have the project "Automated Kernel Crash Reporting System" for
> >>this GSoC and I would like to discuss my plans about it before
> >>starting the coding on May 21.
> >>
> >
> >Cogratulations. :)
> >
> >>I have created a page in the FreeBSD Wiki
> >>(http://wiki.freebsd.org/SummerOfCode2012/AutomatedKernelCrashReportingSystem)
> >>where I describe in details the architecture of the system.
> >>
> >>Here are some points that I would like to be discussed:
> >>
> >>* The implementation of the kcrashreporter is planned to be done in
> >>two shell scripts. The first shell script is a rc.d script and the
> >>second is the actual program. I choose to code it in shell because
> >>kcrashreporter invokes the kgdb to collect the necessary debugging
> >>information. I think that using the shell instead of traditional
> >>programming language for this kind of job is more straightforward
> >>and natural. Do you have a different opinion?
> >>
> >
> >Are you going to support textdumps?
> >
> >I would like to note that some machines have swap space only for
> >textdumps, so I think you should support these.
>
> Support for textdumps is already on the list.
>
> >ddb is equiped with a lot of cool commands that show various important
> >debugging information(e.g. show alllocks). AFAIK kgdb doesn't have such
> >facilities so you will have to implement those first if you decide to
> >use it (btw I think these would be useful even without this project).
> >Take a look at tools/debugscripts.
> >That being said, I would give a priority to support for textdumps (and
> >in case kgdb support cannot be finished in time, I would make sure that
> >the project is expendable enough to support information obtained from
> >kgdb and possibly other sources).
>
> Indeed, DDB is equipped with features that kgdb does not provide but
> only kgdb has access to the full debug information whenever we want
> because of its operation on the core dump. As far as I understand,
> if we want to use DDB to collect the debugging information, we have
> to do it *immediately* after the kernel panic and before the first
> reboot. Also consider that DDB is not included in the generic
> FreeBSD kernel of -STABLE and -RELEASE. You have to compile a custom
> kernel with the options KDB and DDB. I think that the nature of DDB
> as an on-line debugger is a restriction mainly for the manual
> behavior of kcrashreporter.
Maybe this is a gross misunderstanting on my side, but I'm pretty sure
that:
DDB supports simple form of scripting that allows series of commands to
be run on certain events, e.g. kernel panic. Output can be captured
("capture on").
textdump is a part of DDB that saves aforementioned output.
In other words, there are no textdumps without DDB and there is no
problem with running DDB commands automatically after panic. Also it
looks like you will have to actually add DDB to GENERIC in order to obtain
textdumps in default installations.
> I do not think that I could update the kgdb with the features that
> DDB provides, but if it is mandatory to collect these information
> and kgdb cannot, I will do my best.
>
> >I don't know if these are good ideas (no clue about cryptography), but I
> >would either:
> >- HTTP POST data over SSL
> >or
> >- HTTP POST data encrypted with some public key
>
> Nice. What about curl over the HTTPS protocol?
>
curl would be ok, except it's not in the base system.
Actually I just now checked for tools in base that support HTTP POST and
couldn't find any. Should've checked before proposing such solution,
sorry.
> >hardware information, dmesg, locks, locked vnodes, mount points, ps,
> >backtraces of all threads
> >
> >Basically if ddb can show something easly enough (or you will be able to
> >make it do so), the report should contain it.
>
> First I will try to search if and how we can obtain these
> information using kgdb.
>
>
> >I guess this site won't be very busy, so whatever popular httpd you will
> >choose it should be fine (although I would stick with either apache or
> >nginx). No clue about databases.
>
> One more vote for nginx.
>
> >Also it would be nice to have a way to contact the owner of machine that
> >submitted the report. One way I can think of is the ability to specify
> >e-mail address (say in rc.conf?) that will be included in the report.
>
> This is a feature that is included from the initial planning and
> with the way that you proposed :)
>
>
>
> This message was sent using IMP, the Internet Messaging Program.
>
>
--
Mateusz Guzik
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-
Re: new panic in cpu_reset() with WITNESS
on 25/01/2012 23:52 Andriy Gapon said the following: > on 24/01/2012 14:32 Gleb Smirnoff said the following: >> Yes, now: >> >> Rebooting... >> lock order reversal: >> 1st 0x80937140 smp rendezvous (smp rendezvous) @ >> /usr/src/head/sys/kern/kern_shutdown.c:542 >> 2nd 0xfe0001f5d838 uart_hwmtx (uart_hwmtx) @ >> /usr/src/head/sys/dev/uart/uart_cpu.h:92 >> panic: mtx_lock_spin: recursed on non-recursive mutex cnputs_mtx @ >> /usr/src/head/sys/kern/kern_cons.c:500 > > OK, so it's just a plain LOR between smp rendezvous and uart_hwmtx, no new > details... > > It's still intriguing to me why the LOR *doesn't* happen [*] with > stop_scheduler_on_panic=0. But I don't see a productive way to pursue this > investigation further. Salve Glebius! After your recent nudging I took yet another look at this issue and it seems that I have some findings. For those who might get interested here is a convenience reference to the whole thread on gmane: http://thread.gmane.org/gmane.os.freebsd.current/139307 A short summary. Prerequisites: an SMP x86 system, its kernel is configured with WITNESS && !WITNESS_SKIPSPIN (this is important) and a system uses serial console via uart. Then, if stop_scheduler_on_panic is set to zero the system can be rebooted without a problem. On the other hand, if stop_scheduler_on_panic is enabled, then the system first runs into a LOR when calling printf() in cpu_reset() and then it runs into a panic when printf is recursively called from witness(9) to report the LOR. The panic happens because of the recursion on cnputs_mtx, which should ensure that cnputs() output is not intermingled and which is not flagged to support recursion. There are two things about this report that greatly confused and puzzled me: 1. stop_scheduler_on_panic variable is used _only_ in panic(9). So how could it be possible that changing its value affects behavior of the system when panic(9) is not called?! 2. The LOR in question happens between "smp rendezvous" (smp_ipi_mtx) and "uart_hwmtx" (sc_hwmtx_s in uart core) spin locks. The order of these locks is actually predefined in witness order_lists[] such that uart_hwmtx must come before smp_ipi_mtx. But in the reboot path we first take smp_ipi_mtx in shutdown_reset(), then we call cpu_reset, then it calls printf and from there we get to uart_hwmtx for serial console output. So the order between these spinlocks is always violated in the x86 SMP reboot path. How come witness(9) doesn't _always_ detect this LOR? How come it didn't detect this LOR before any "stop scheduler" commits?! [Spoiler alert :-)] Turns out that the two puzzles above are closely related. Let's first list all the things that change when stop_scheduler_on_panic is enabled and a panic happens: - other CPUs are stopped (forced to spin) - interrupts on current CPU are disabled - by virtue of the above the current thread should be the only thread running (unless it executes a voluntary switch) - all locks are "busted", they are completely ignored / bypassed - by virtue of the above no lock invariants and witness checks are performed, so no lock order checking, no recursion checking, etc So, what I observe is this: when stop_scheduler_on_panic is disabled, the LOR is actually detected as it should be. witness(9) works properly here. Once the LOR is detected witness(9) wants to report it using printf(9). That's where we run into the cnputs_mtx recursion panic. It's all exactly as with stop_scheduler_on_panic enabled. Then panic(9) wants to report the panic using printf(9), which goes to cnputs() again, where _mtx_lock_spin_flags() detects locks recursion again (this is independent of witness(9)) and calls panic(9) again. Then panic(9) wants to report the panic using printf(9)... I assume that when the stack is exhausted we run into a double fault and dblfault_handler wants to print something again... Likely we eventually run into a triple fault which resets the machine. Although, I recall some old reports of machines hanging during reboot in a place suspiciously close to where the described ordeal happens... But if the machine doesn't hang we get a full appearance of the reset successfully happening (modulo some last messages missing). With stop_scheduler_on_panic enabled and all the locks being ignored we, of course, do not run into any secondary lock recursions and resulting panics. So the system is able to at least panic "gracefully" (still we should have just reported the LOR gracefully, no panic is required). Some obvious conclusions: - the "smp rendezvous" and "uart_hwmtx" LOR is real and it is the true cause of the problem; it should be fixed one way or other - either by correcting witness order_lists[] or by avoiding the LOR in shutdown_reset/cpu_reset; - because witness(9) uses printf(9) to report problems, it is very fragile to use witness with any locks that can be acquired under printf(9) - stop_scheduler_on_panic just uncovers the true bug The
Re: High-res Timers
On Wed, 16 May 2012, Jason Hellenthal wrote: Does anyone have a quick list of high-resolution timer functions? Both user-land and kernel-land? It would be greatly appreciated (doing some performance timing for applications). clocks(7) - various system timers getitimer(2), setitimer(2) - get/set value of interval timer see ( man -k timer ) list for some other references. I think the original poster wants timestamping functions. "Timer function" normally means a timer-interrupt-scheduling function. clocks(7) is bogus and more than 10 years out of date. It is mostly about hardware and virtual clock oscillators that may be used to build timestamping and timer functions (mostly the former). I am not sure what sort of high resolution you are refering to but maybe these will lead you in the right direction. Bruce Evans CCd - he may have quite a bit that could be added to this. I always find what he has to say very enlightening. Generally, some of the timestamping functions have high resolution, but are too slow to use if you make a lot of timestamps, and if you don't make a lot of timestamps then you don't need very high resolution. Bruce ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: GSoC Project: Automated Kernel Crash Reporting System - Discussion
On Wed, May 16, 2012 at 02:45:24PM +0300, tza...@it.teithe.gr wrote: > > In this case Apache is a good choice. I would however recommend using > > www/nginx and PHP in FastCGI mode (FPM option in lang/php5 port). This > > is a preffered setup for almost all Russian highloaded websites. > > At the beginning using Apache is a reasonable choice. > > I have never used nginx before. I have considered also the lighttpd. > Both with BSD licenses (nginx with a 2-clause BSD like license) and > FastCGI support. As I read from Wikipedia, PHP performance has > received special attention in lighttpd. I will test both Web servers > and then I will make up my mind. I think the HTTP server is not a big deal unless there is a really useful feature in one that the other doesn't provide. Most of the work will be done by the PHP backend anyway. >From an architectural point of view, best practices nowadays are leaning toward external PHP processes with FastCGI, as described by Ilya. There are alternatives to FPM, such as sysutils/py-supervisor. I don't know who will be administrating this server in the end, but I think it would be good to ask the FreeBSD webmaster team opinion though. -- Jeremie Le Hen Men are born free and equal. Later on, they're on their own. Jean Yanne ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
