[patch] usr.bin/elf2aout/elf2aout.1
hi there, just a small format correction. cheers. alex Index: usr.bin/elf2aout/elf2aout.1 === --- usr.bin/elf2aout/elf2aout.1 (revision 203786) +++ usr.bin/elf2aout/elf2aout.1 (working copy) @@ -24,7 +24,7 @@ .\" .\" $FreeBSD$ .\" -.Dd December 23, 2008 +.Dd February 10, 2010 .Dt ELF2AOUT 1 .Os .Sh NAME @@ -32,7 +32,7 @@ .Nd "Convert ELF binary to a.out format" .Sh SYNOPSIS .Nm -.Op Fl o outfile +.Op Fl o Ar outfile .Ar infile .Sh DESCRIPTION The ___ 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: Future CPUs - 128 threads
owner-freebsd-hack...@freebsd.org wrote: > Artem Belevich wrote: >>> Seriously, simply because of curiosity - are MIPS CPUs used in any >>> kind of "general purpose" machines? >> >> I'm not aware of any multi-core general-purpose MIPS box. >> Low-end MIPS CPUs are ubiquitous in low-end networking gear. >> High-end multicore MIPS chips are mostly going into mid-to-high end >> networking gear like firewalls. > > > However several companies are using FreeBSD as a base kernel for their > appliance, based on these chips. So they are of direct interest to us. >> >> They are probably not a very good fit for general purpose computing. >> >> --Artem I believe I know of one such company... :-) -- Andrew Duane Juniper Networks 978-589-0551 10 Technology Park Dr adu...@juniper.net Westford, MA 01886-3418 ___ 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: [patch] usr.bin/elf2aout/elf2aout.1
On Fri, Feb 12, 2010 at 02:32:44PM +0100, Alexander Best wrote: > hi there, > > just a small format correction. Committed to -CURRENT, except I didn't touch ".Dd" and fixed usage() as well. Cheers, -- Ruslan Ermilov r...@freebsd.org FreeBSD committer ___ 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: [patch] usr.bin/elf2aout/elf2aout.1
thanks. :) Ruslan Ermilov schrieb am 2010-02-12: > On Fri, Feb 12, 2010 at 02:32:44PM +0100, Alexander Best wrote: > > hi there, > > just a small format correction. > Committed to -CURRENT, except I didn't touch ".Dd" and fixed > usage() as well. > Cheers, ___ 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: KLD hello.ko: depends on kernel - not available or version mismatch
On Thu, Feb 11, 2010 at 08:06, Andrew Brampton wrote: > On Thu, Feb 11, 2010 at 2:25 AM, james toy wrote: >> Hello Hackers, >> >> I am working on learning to write FreeBSD drivers; however, I have >> some practice writing IOKit drivers for MacOSX (they are entirely >> different I know!). The code I am working with can be found here: >> >> http://pastebin.com/m2bbb393c >> >> and I am getting the error: >> >> dontpanic# kldload ./hello.ko >> kldload: can't load ./hello.ko: Exec format error >> >> dmesg reads: >> >> dontpanic# kldload ./hello.ko >> kldload: can't load ./hello.ko: Exec format error >> >> and finally uname -a: >> >> FreeBSD dontpanic.union.edu 9.0-CURRENT FreeBSD 9.0-CURRENT #1 >> r198859: Wed Feb 10 09:59:54 EST 2010 >> ja...@dontpanic.union.edu:/usr/obj/usr/src_klog/sys/DONTPANIC amd64 >> >> any information pointing me to being able to load this driver would be >> greatly appreciated. >> >> respectfully, >> >> james toy > > I just built your code on my FreeBSD 8 box and it compiles and loads > fine. How are you compiling your code? I used this makefile > http://pastebin.com/f3ab71917 and all I typed was this: > > make > sudo make install > sudo make load > > and I get the "hello, fail" message, and then I typed > sudo make unload > > and I got the "unload fail" message. > > Andrew > Andrey was correct, param.h and kern.osreldate were not the same. thanks very much for the prompt responses. =jt ___ 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"
[patch] contrib/gdtoa/hexnan.c
little patch to stop gcc from complaining about the implicit declaration of isalnum(). although this file comes from vendor contributed software (gdtoa) the cause for the warning is related to local freebsd specific changes in the file which are not part of the original file shipped by the vendor. so i guess this can be fixed directly in head. cheers. alex Index: contrib/gdtoa/hexnan.c === --- contrib/gdtoa/hexnan.c (revision 203786) +++ contrib/gdtoa/hexnan.c (working copy) @@ -31,6 +31,8 @@ /* $FreeBSD$ */ +#include + #include "gdtoaimp.h" static void ___ 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: NFS write corruption on 8.0-RELEASE
* Rick Macklem (rmack...@uoguelph.ca) wrote: > > Is it the hostname of the server or the client? > > My guess is that hades.panopticon (or something like that:-) is the Yes, that is the client. > As John said, it would be nice to try and narrow it down to client or > server side, too. I'm planning a massive testing for this weekend, including removing soft mount option and trying linux client/server. Btw, I forgot to mention that I'm experiencing other NFS problems from time to time, including "death" of a mount (that is, all processes that try to access it freeze; this cures itself in some time with a message "server is alive again"). Also I've seen another strange thing - not only the mount dies but the network is flooded with NFS traffic. Last time I've seen it quite a while ago, so I don't remember the circumstances and direction of the traffic. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ 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: NFS write corruption on 8.0-RELEASE
* Oliver Fromme (o...@lurza.secnetix.de) wrote: > This is an excerpt from Solaris' mount_nfs(1M) manpage: > > File systems that are mounted read-write or that con- > tain executable files should always be mounted with > the hard option. Applications using soft mounted file > systems may incur unexpected I/O errors, file corrup- > tion, and unexpected program core dumps. The soft > option is not recommended. > > FreeBSD's manual page doesn't contain such a warning, but > maybe it should. (It contains a warning not to use "soft" > with NFSv4, though, for different reasons.) Interesting, I'll try disabling it. However now I really wonder why is such dangerous option available (given it's the cause) at all, especially without a notice. Silent data corruption is possibly the worst thing to happen ever. However, without soft option NFS would be a strange thing to use - network problems is kinda inevitable thing, and having all processes locked in a unkillable state (with hard mounts) when it dies is not fun. Or am I wrong? > Also note that the "nolockd" option means that processes > on different clients won't see each other's locks. That > means that you will get corruption if they rely on > locking. I know - I have no processes that use locks on that filesystems. Also there's only a single client. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ 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: NFS write corruption on 8.0-RELEASE
On Thu, 11 Feb 2010, John Baldwin wrote: [good stuff snipped] Case1: single currupted block 3779CF88-3779 (12408 bytes). Data in block is shifted 68 bytes up, loosing first 68 bytes are filling last 68 bytes with garbage. Interestingly, among that garbage is my hostname. Is it the hostname of the server or the client? My guess is that hades.panopticon (or something like that:-) is the client. The garbage is 4 bytes (80 00 80 84) followed by the first part of the RPC header. (Bytes 5-8 vary because they are the xid and then the host name is part of the AUTH_SYS authenticator.) For Case2 and Case3, you see less of it, but it's the same stuff. Why? I have no idea, although it smells like some sort of corruption of the mbuf list. (It would be nice if you could switch to a different net interface/driver. Just a thought, since others don't seem to be seeing this?) As John said, it would be nice to try and narrow it down to client or server side, too. Don't know if this helps or is just noise, rick ___ 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: NFS write corruption on 8.0-RELEASE
On Fri, 12 Feb 2010, Dmitry Marakasov wrote: * Oliver Fromme (o...@lurza.secnetix.de) wrote: This is an excerpt from Solaris' mount_nfs(1M) manpage: File systems that are mounted read-write or that con- tain executable files should always be mounted with the hard option. Applications using soft mounted file systems may incur unexpected I/O errors, file corrup- tion, and unexpected program core dumps. The soft option is not recommended. FreeBSD's manual page doesn't contain such a warning, but maybe it should. (It contains a warning not to use "soft" with NFSv4, though, for different reasons.) Interesting, I'll try disabling it. However now I really wonder why is such dangerous option available (given it's the cause) at all, especially without a notice. Silent data corruption is possibly the worst thing to happen ever. Tell me about it. :) But in this case I'm not sure I understand. As I understand it, the difference between soft and hard is that in the case of soft, a timeout will result in the operation failing and returning EIO or the like (hence "unexpected I/O errors"). And if the operation is being done to fault in a mapped page, you'd have to notify the process asynchronously by sending a signal like SIGBUS which it may not be expecting (hence "unexpected core dumps"). But in what scenario would you see file corruption? Unless you have a buggy program that doesn't check return values from system calls or handles signals in a stupid way, I don't see how this can happen, and I'm not sure what the Sun man page is referring to. -- Nate Eldredge n...@thatsmathematics.com ___ 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: NFS write corruption on 8.0-RELEASE
Dmitry Marakasov wrote: > * Oliver Fromme (o...@lurza.secnetix.de) wrote: > > This is an excerpt from Solaris' mount_nfs(1M) manpage: > > > > File systems that are mounted read-write or that con- > > tain executable files should always be mounted with > > the hard option. Applications using soft mounted file > > systems may incur unexpected I/O errors, file corrup- > > tion, and unexpected program core dumps. The soft > > option is not recommended. > > > > FreeBSD's manual page doesn't contain such a warning, but > > maybe it should. (It contains a warning not to use "soft" > > with NFSv4, though, for different reasons.) > > Interesting, I'll try disabling it. However now I really wonder why > is such dangerous option available (given it's the cause) at all, > especially without a notice. Silent data corruption is possibly the > worst thing to happen ever. I'm sorry for the confusion ... I do not think that it's the cause for your data corruption, in this particular case. I just mentioned the potential problems with "soft" mounts because it could cause additional problems for you. (And it's important to know anyhow.) > However, without soft option NFS would be a strange thing to use - > network problems is kinda inevitable thing, and having all processes > locked in a unkillable state (with hard mounts) when it dies is not > fun. Or am I wrong? Well, this is what happens if the network hangs: 1. With "hard" mounts (the default), processes that access NFS shares are locked for as long as the network is down. 2. With "soft" mounts, binaries can coredump, and many programs won't notice that write access just failed which leads to file corruption. Personally I definitely prefer the first. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "I have stopped reading Stephen King novels. Now I just read C code instead." -- Richard A. O'Keefe ___ 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: NFS write corruption on 8.0-RELEASE
On Thu, 11 Feb 2010, John Baldwin wrote: Case1: single currupted block 3779CF88-3779 (12408 bytes). Data in block is shifted 68 bytes up, loosing first 68 bytes are filling last 68 bytes with garbage. Interestingly, among that garbage is my hostname. Is it the hostname of the server or the client? Oh, I realized the first 4 bytes of the garbage is the record mark that preceeds the RPC header for TCP, so the garbage is the first part of the RPC after the TCP/IP header. Can you reproduce this using a non-FreeBSD server with a FreeBSD client or a non-FreeBSD client with a FreeBSD server? That would narrow down the breakage to either the client or the server. If using a non-FreeBSD client/server isn't convenient, another way would be to do a binary packet capture (something like "tcpdump -s 0 -w ") and then looking at it in wireshark for a failed case and see if the data is corrupted on the wire. rick ___ 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: NFS write corruption on 8.0-RELEASE
On Fri, 12 Feb 2010, Dmitry Marakasov wrote: I'm planning a massive testing for this weekend, including removing soft mount option and trying linux client/server. Btw, I forgot to mention that I'm experiencing other NFS problems from time to time, including "death" of a mount (that is, all processes that try to access it freeze; this cures itself in some time with a message "server is alive again"). Also I've seen another strange thing - not only the mount dies but the network is flooded with NFS traffic. Last time I've seen it quite a while ago, so I don't remember the circumstances and direction of the traffic. There are some patches at: http://people.freebsd.org/~rmacklem that may be relevant if you are using vanilla FreeBSD-8.0. (They're all now in stable/8, but are post-release of 8.0.) rick ___ 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: NFS write corruption on 8.0-RELEASE
* Oliver Fromme (o...@lurza.secnetix.de) wrote: > I'm sorry for the confusion ... I do not think that it's > the cause for your data corruption, in this particular > case. I just mentioned the potential problems with "soft" > mounts because it could cause additional problems for you. > (And it's important to know anyhow.) Oh, then I really misunderstood. If the curruption implied is like when you copy a file via NFS and the net goes down, and in case of soft mount you have half of a file (read: corruption), while with hard mount the copy process will finish when the net is back up, that's definitely OK and expected. > Well, this is what happens if the network hangs: > > 1. With "hard" mounts (the default), processes that access > NFS shares are locked for as long as the network is down. > > 2. With "soft" mounts, binaries can coredump, and many > programs won't notice that write access just failed which > leads to file corruption. > > Personally I definitely prefer the first. Yeah, but I have mostly desktop<->(NAS w/torrents) setup so I prefer the second. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ 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: NFS write corruption on 8.0-RELEASE
On Fri, 12 Feb 2010, Dmitry Marakasov wrote: Interesting, I'll try disabling it. However now I really wonder why is such dangerous option available (given it's the cause) at all, especially without a notice. Silent data corruption is possibly the worst thing to happen ever. I doubt that the data corruption you are seeing would be because of "soft". "soft" will cause various problems w.r.t. consistency, but in the case of a write through the buffer cache, I think it will leave the buffer dirty and eventually it will get another write attempt. However, without soft option NFS would be a strange thing to use - network problems is kinda inevitable thing, and having all processes locked in a unkillable state (with hard mounts) when it dies is not fun. Or am I wrong? Well, using NFS over an unreliable network is going to cause grief sooner or later. The problem is that POSIX apps. don't expect I/O system calls to fail with EIO and generally don't handle that gracefully. For the future, I think "umount -F" (a forced dismount that accepts data loss) is the best compromise, since at least then a sysadmin knows that data corruption could have occurred when they do it and can choose to "wait" until the network is fixed as an alternative to the corruption? rick ___ 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: NFS write corruption on 8.0-RELEASE
Dmitry Marakasov wrote: > Oh, then I really misunderstood. If the curruption implied is > like when you copy a file via NFS and the net goes down, and in > case of soft mount you have half of a file (read: corruption), while > with hard mount the copy process will finish when the net is back up, > that's definitely OK and expected. Of course it depends what kinds of programs you run. If you run a database, it can become corrupted to the point that you can't start it anymore, so you have to restore it from the latest backup. Been there, done that. Another example, this happened to a friend of mine: After a network outage his Opera browser didn't work anymore. He had to remove his ~/.opera directory to get it working again (and he lost all his settings). His home directory was "soft"-mounted, but he removed the soft option after that incident. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "The last good thing written in C was Franz Schubert's Symphony number 9." -- Erwin Dieterich ___ 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: NFS write corruption on 8.0-RELEASE
On Fri, 12 Feb 2010, Dmitry Marakasov wrote: * Oliver Fromme (o...@lurza.secnetix.de) wrote: I'm sorry for the confusion ... I do not think that it's the cause for your data corruption, in this particular case. I just mentioned the potential problems with "soft" mounts because it could cause additional problems for you. (And it's important to know anyhow.) Oh, then I really misunderstood. If the curruption implied is like when you copy a file via NFS and the net goes down, and in case of soft mount you have half of a file (read: corruption), while with hard mount the copy process will finish when the net is back up, that's definitely OK and expected. The problem is that it can't distinguish between "slow network/server" and partitioned/failed network. In your case (one client) it may work out ok. (I can't remember how long it takes to timeout and give up for "soft".) For many clients talking to an NFS server, the NFS server's response time can degrade to the point where "soft" mounted clients start timing out and that can get ugly. rick ___ 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: NFS write corruption on 8.0-RELEASE
--- On Fri, 2/12/10, Rick Macklem wrote: > From: Rick Macklem > Subject: Re: NFS write corruption on 8.0-RELEASE > To: "Dmitry Marakasov" > Cc: freebsd-hackers@freebsd.org, freebsd-sta...@freebsd.org, "John Baldwin" > > Date: Friday, February 12, 2010, 11:12 AM > > > On Fri, 12 Feb 2010, Dmitry Marakasov wrote: > > > > > I'm planning a massive testing for this weekend, > including removing > > soft mount option and trying linux client/server. > > > > Btw, I forgot to mention that I'm experiencing other > NFS problems from > > time to time, including "death" of a mount (that is, > all processes that > > try to access it freeze; this cures itself in some > time with a message > > "server is alive again"). Also I've seen another > strange thing - not > > only the mount dies but the network is flooded with > NFS traffic. > > Last time I've seen it quite a while ago, so I don't > remember the > > circumstances and direction of the traffic. > > > There are some patches at: > http://people.freebsd.org/~rmacklem > that may be relevant if you are using vanilla FreeBSD-8.0. > (They're all > now in stable/8, but are post-release of 8.0.) > > rick > > ___ > freebsd-sta...@freebsd.org > mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > This is interesting: "I've seen another strange thing - not only the mount dies but the network is flooded with NFS traffic." Rick - this sounds very similar to the issues I was seeing (and reported in the thread on freebsd-stable "Zombie NFS writing from FreeBSD clients to FreeBSD 8.0 server with ZFS". For the record - I updated to the latest 8-Stable and that still didn't cure my issues. I was originally on hard mounts on udp, tried soft and TCP too, nothing solved it. So, a few days ago I switched to using samba and mount_smbfs instead and am now running 3 days without a crash or any network traffic/load issues. (same machine, same ZFS disks, etc...) Luckily it wasn't too painful to make the change. When I have more time I'd like to retry NFS. --Alan ___ 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"
