Re: [help]strange problem about gethostbyname/getaddrinfo
On Wed, Dec 10, 2008 at 02:36:27PM +0800, Cheng Renquan wrote: On Wed, Dec 10, 2008 at 1:57 PM, ? [EMAIL PROTECTED] wrote: hi,all,we have a project which must resolv some domains in the server process our system in FreeBSD 6.2 or 6.3, the server process may open 7000+ sockets,not fork we have set the maxopensockets as 65536,as follows: Use strace to trace it, I personally found strace on fbsd to lie to me everytime. I'd avoid that and use ktrace/kdump instead... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with zfsboot loader if raidz present on any drive
On 9 Dec 2008, at 23:54, Paul Wootton wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pegasus Mc Cleaft Sent: 07 December 2008 12:17 To: Doug Rabson Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Problems with zfsboot loader if raidz present on any drive On Sunday 07 December 2008 09:22:16 Doug Rabson wrote: On 7 Dec 2008, at 03:19, Pegasus Mc Cleaft wrote: Hello Hackers, Recently and friend and I have been trying to get the new gptzfsboot working on our machines and ran into a interesting problem. Initially I was building the world without the environment variable LOADER_ZFS_SUPPORT=YES in the /etc/make.conf and this, of course, didnt work very well. Every time the machine booted, it would throw 2 lines after the pin-wheel and then reboot. I couldent read what the lines were it went so fast. My friend had a bit more luck and got his machine working OK with a single drive and later a mirror drive added. I added the environment variable and rebuilt everything and installed. This time, I could see the bios drives and a further 2 lines of ZFS something and a reboot... No matter what I tried, I couldent get the machine to boot up to a point where I could try and fix the problem, so I started pulling devices out and found the following: If there is a raidz pool on any drive (not necessarily the one that you are trying to boot from) the loader dies and reboots the machine. My friend, as an experiment created 3 gpt partitions (in addition to the single partition that he had been previously booted from) on his single drive and made a raidz pool for testing. His machine showed the same condition as mine, however he was able to capture the message before the machine rebooted: message ZFS: can only boot from disk or mirror vdevs ZFS: inconsistent nvlist contents The zfsboot code in current doesn't support raidz or raidz2. I have been working on adding that support but its not ready yet. The code works in my test harness but crashes instantly when I put it in the boot code :(. I should have time to finish debugging it soon. Hi Doug, In my haste to put a message to the group, I didnt do a very good job of explaining or give what platform I was working with. I set up a single disk pool with the gptzfsboot code on it as a boot drive. My idea was to have a single disk boot (and after it boots and I can kill the UFS drive I am currently booting from) convert it to a mirror. But I have 6 other drives in the machine that I have as a raidz for my /usr/home, et al. If the 6 raidz drives are present at boot time, the machine starts to cyclic reboot just after the pin-wheel. The machine I am working on is running FBSD8.0-Current as of midnight 7/12/2008 and the platform is AMD64. If I can help test in any way I would be more than happy to try, or provide any information necessary.. ~Peg Hi Doug, I was working with Peg on this over the weekend. I think I have a patch for this - see http://www.freebsd.org/cgi/query-pr.cgi?pr=129539 The problem was that we were not checking the return code from vdev_init_from_nvlist() on line 726 in /usr/src/sys/boot/zfs/zfsimpl.c Joao, Do you want to try the attached patch? It seems to have fixed the problem, at least on mine and Peg's machine. This looks like the right fix. I will commit something similar to this today. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MAXFILES in subr_param.c
Ivan Voras [EMAIL PROTECTED] writes: I'm looking at kern/subr_param.c: 72 #ifndef MAXFILES 73 #define MAXFILES (maxproc * 2) 74 #endif Shouldn't this be at least maxproc*3, for stdin,out,err for every proc? Even maxproc * 3 won't be enough, unless none of your processes actually do anything. It's just an arbitrary value, based on the assumption that you will never have maxproc concurrent processes anyway. Also, it looks like MAXFILES is used only once, and in a bit funny way: 238 maxfiles = MAXFILES; 239 TUNABLE_INT_FETCH(kern.maxfiles, maxfiles); 240 maxprocperuid = (maxproc * 9) / 10; 241 maxfilesperproc = (maxfiles * 9) / 10; What's funny about it? Historical reasons? To a certain degree, yes; MAXFILES used to be a static limit which you could only change in your kernel config. It is now a loader tunable (though you can still change the default in your kernel config), so the MAXFILES macro was replaced with a maxfiles variable wherever it is used, and the former is now only used to initialize the latter. DES -- Dag-Erling Smørgrav - [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: MAXFILES in subr_param.c
Dag-Erling Smørgrav wrote: Ivan Voras [EMAIL PROTECTED] writes: I'm looking at kern/subr_param.c: 72 #ifndef MAXFILES 73 #define MAXFILES (maxproc * 2) 74 #endif Shouldn't this be at least maxproc*3, for stdin,out,err for every proc? Even maxproc * 3 won't be enough, unless none of your processes actually do anything. It's just an arbitrary value, based on the assumption that you will never have maxproc concurrent processes anyway. Ok. Also, it looks like MAXFILES is used only once, and in a bit funny way: 238 maxfiles = MAXFILES; 239 TUNABLE_INT_FETCH(kern.maxfiles, maxfiles); 240 maxprocperuid = (maxproc * 9) / 10; 241 maxfilesperproc = (maxfiles * 9) / 10; What's funny about it? MAXFILES is a macro used only once, where it resolves to (maxproc*2). It's not technically incorrect, but it looks like it adds noise. Historical reasons? To a certain degree, yes; MAXFILES used to be a static limit which you could only change in your kernel config. It is now a loader tunable (though you can still change the default in your kernel config), so the MAXFILES macro was replaced with a maxfiles variable wherever it is used, and the former is now only used to initialize the latter. Ok. signature.asc Description: OpenPGP digital signature
FreeBSD
Hello dear command of developers of FreeBSD. I wish to take part in the project on developing out of FreeBSD and to subscribe for dispatch. Excuse me for my English. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MAXFILES in subr_param.c
On Mon, 08 Dec 2008 20:41:32 +0100, Ivan Voras [EMAIL PROTECTED] wrote: Hi, I'm looking at kern/subr_param.c: 72 #ifndef MAXFILES 73 #define MAXFILES (maxproc * 2) 74 #endif Shouldn't this be at least maxproc*3, for stdin,out,err for every proc? Also, it looks like MAXFILES is used only once, and in a bit funny way: 238 maxfiles = MAXFILES; 239 TUNABLE_INT_FETCH(kern.maxfiles, maxfiles); 240 maxprocperuid = (maxproc * 9) / 10; 241 maxfilesperproc = (maxfiles * 9) / 10; This is an attempt to limit a rogue process from grabbing the full maxfiles or maxproc value by opening too many files. There will still be (maxfiles / 10) file descriptors available and (maxproc / 10) process table entries, so that you can for example try to log into the system as root and try to fix things. You can still cause all sorts of trouble by *forking* and then going off into a file descriptor allocation spree, but as I said this is an _attempt_ at keeping things in a relatively sane state in the _default_ state. You can still use the loader to set the actual values of the `kern.maxprocperuid' and `kern.maxfilesperproc' tunables to something that is more robust for your particular application. The defaults are just a `best effort' guess to keep things working in the most common case. Nothing funny about them :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MAXFILES in subr_param.c
On Wed, 10 Dec 2008 14:30:24 +0100, Ivan Voras [EMAIL PROTECTED] wrote: Also, it looks like MAXFILES is used only once, and in a bit funny way: 238 maxfiles = MAXFILES; 239 TUNABLE_INT_FETCH(kern.maxfiles, maxfiles); 240 maxprocperuid = (maxproc * 9) / 10; 241 maxfilesperproc = (maxfiles * 9) / 10; What's funny about it? MAXFILES is a macro used only once, where it resolves to (maxproc*2). It's not technically incorrect, but it looks like it adds noise. It doesn't add noise :-) It's arguably a code quality and `documentation' feature. It provides a human-readable, useful name to the magic value (maxproc * 2). If we decide to bump the default to (maxproc * 10) sometime later, we won't have to grovel through the entire src/sys/tree and look for maxproc instances that need updating. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
7.0 unusual performance issue - vmdaemon hang?
Just had one of hour webservers flag as down here and on investigation the machine seems to be struggling due to a hung vmdaemon process. top is reporting vmdaemon as using a constant 55.57% CPU yet CPU time is not increasing:- last pid: 36492; load averages: 0.04, 0.05, .11 up 89+19:53:21 14:36:08 223 processes: 9 running, 201 sleeping, 13 waiting CPU states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle Mem: 644M Active, 2780M Inact, 480M Wired, 249M Cache, 214M Buf, 3759M Free Swap: 4096M Total, 537M Used, 3559M Free, 13% Inuse PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 11 root 1 171 ki31 0K16K CPU7 7 2116.4 100.00% idle: cpu7 12 root 1 171 ki31 0K16K CPU6 6 2059.5 100.00% idle: cpu6 13 root 1 171 ki31 0K16K CPU5 5 2029.3 100.00% idle: cpu5 14 root 1 171 ki31 0K16K CPU4 4 1977.8 100.00% idle: cpu4 15 root 1 171 ki31 0K16K CPU3 3 1912.0 100.00% idle: cpu3 16 root 1 171 ki31 0K16K CPU2 2 1835.2 100.00% idle: cpu2 17 root 1 171 ki31 0K16K CPU1 1 1763.1 100.00% idle: cpu1 18 root 1 171 ki31 0K16K RUN0 1727.6 100.00% idle: cpu0 37 root 1 20- 0K16K psleep 5 0:56 55.57% vmdaemon 60198 www1 4098M 13516K sbwait 2 35:21 1.46% httpd 60264 www1 40 133M 9248K sbwait 0 21:21 0.39% httpd 30 root 1 -68- 0K16K - 7 18.3H 0.00% em1 taskq 29 root 1 -68- 0K16K - 6 330:21 0.00% em0 taskq 41 root 1 20- 0K16K syncer 1 212:42 0.00% syncer 21 root 1 -44- 0K16K WAIT 0 201:02 0.00% swi1: net 19 root 1 -32- 0K16K WAIT 0 120:15 0.00% swi4: clock 22 root 1 44- 0K16K - 5 73:00 0.00% yarrow I've tried to ktrace the process and it produced nothing, also tried gdb and it failed to attach. Is there anything else I can try before we reboot the machine to help determine what the problem is? Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [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: NFS ( amd?) dysfunction descending a hierarchy
On Tue, Dec 09, 2008 at 02:20:05PM -0800, Julian Elischer wrote: Kostik Belousov wrote: On Tue, Dec 09, 2008 at 11:01:10AM -0800, David Wolfskill wrote: On Tue, Dec 02, 2008 at 04:15:38PM -0800, David Wolfskill wrote: I seem to have a fairly- (though not deterministly so) reproducible mode of failure with an NFS-mounted directory hierarchy: An attempt to traverse a sufficiently large hierarchy (e.g., via tar zcpf or rm -fr) will fail to visit some subdirectories, typically apparently acting as if the subdirectories in question do not actually exist (despite the names having been returned in the output of a previous readdir()). ... Did you saw me previous answer ? Supposed patch for your problem was committed to head as r185557, and MFCed to 7 in r185796, and to 7.1 in r185801. Please test with latest sources. did you notice that he tested with latest -current and releng 7? Yes, and failure mode on the HEAD looks like a different issue. pgpr8TYNabIWV.pgp Description: PGP signature
Re: MAXFILES in subr_param.c
2008/12/10 Giorgos Keramidas [EMAIL PROTECTED]: On Wed, 10 Dec 2008 14:30:24 +0100, Ivan Voras [EMAIL PROTECTED] wrote: Also, it looks like MAXFILES is used only once, and in a bit funny way: 238 maxfiles = MAXFILES; 239 TUNABLE_INT_FETCH(kern.maxfiles, maxfiles); 240 maxprocperuid = (maxproc * 9) / 10; 241 maxfilesperproc = (maxfiles * 9) / 10; What's funny about it? MAXFILES is a macro used only once, where it resolves to (maxproc*2). It's not technically incorrect, but it looks like it adds noise. It doesn't add noise :-) It's arguably a code quality and `documentation' feature. It provides a human-readable, useful name to the magic value (maxproc * 2). If we decide to bump the default to (maxproc * 10) sometime later, we won't have to grovel through the entire src/sys/tree and look for maxproc instances that need updating. The macro is defined and used exactly once, in this file. Other files probably use maxfiles. The problem is - since it's in an #ifdef block - is it defined anywhere else? A quick grep yields only this: conf/NOTES:options MAXFILES=999 conf/options:MAXFILES opt_param.h I don't know how config interacts with the source - does it shadow the subr_param.c value? This isn't a very important question as the system demonstratively works in any case, I see it more as a style curiosity. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
zfs panics
hi, from a solaris or linux client, doing a ls(1) of a nfs exported zfs file, for example: ls /net/zfs-server/h/.zfs/snapshot, panics the server. The server is running latest 7.1-prerelease. when client is freebsd, it mostly works, but in a few cases the server just goes into comma. btw, the server is running vanilla zfs, no tunning, and the server is 64bit with 8gb of memory and quad core (dell-pe2950) Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x168 fault code = supervisor write data, page not present instruction pointer = 0x8:0x804a9175 stack pointer = 0x10:0xb71fc550 frame pointer = 0x10:0xb71fc560 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 802 (nfsd) [thread pid 802 tid 100185 ] Stopped at _mtx_lock_flags+0x15: lock cmpxchgq %rsi,0x50(%rdi) db tr Tracing pid 802 tid 100185 td 0xff0004d576e0 _mtx_lock_flags() at _mtx_lock_flags+0x15 vput() at vput+0x45 nfsrv_readdirplus() at nfsrv_readdirplus+0x83e nfssvc() at nfssvc+0x400 syscall() at syscall+0x1bb Xfast_syscall() at Xfast_syscall+0xab --- syscall (155, FreeBSD ELF64, nfssvc), rip = 0x8006885cc, rsp = 0x7fffea2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD
Wed, Dec 10, 2008 at 04:17:48AM +0200, Юлия Смолик wrote:
Hello dear command of developers of FreeBSD. I wish to take part in the
project on developing out of FreeBSD and to subscribe for dispatch.
http://lists.freebsd.org/pipermail/freebsd-hackers/2008-November/026566.html
and especially http://www.freebsd.org/projects/index.html
http://wiki.freebsd.org/ will be good too.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpttDgtKl9rD.pgp
Description: PGP signature
Re: zfs panics
Hi, On 2008-12-10, Danny Braniss wrote: from a solaris or linux client, doing a ls(1) of a nfs exported zfs file, for example: ls /net/zfs-server/h/.zfs/snapshot, panics the server. The server is running latest 7.1-prerelease. This has been reported as PR kern/125149. I have described the problem in this message: http://lists.freebsd.org/pipermail/freebsd-fs/2008-October/005217.html See the PR for RELENG_7 patches. (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/125149) -- Jaakko ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MAXFILES in subr_param.c
Ivan Voras [EMAIL PROTECTED] writes: The macro is defined and used exactly once, in this file. Other files probably use maxfiles. maxfiles is the real value; it's a loader tunable, and more importantly, it can be modified at run time through the kern.maxfiles sysctl variable. MAXFILES is simply the default value to which maxfiles is initialized. The problem is - since it's in an #ifdef block - is it defined anywhere else? A quick grep yields only this: conf/NOTES:optionsMAXFILES=999 conf/options:MAXFILES opt_param.h I don't know how config interacts with the source - does it shadow the subr_param.c value? Yes. If you use the MAXFILES option in your kernel config, config(8) will add a corresponding #define MAXFILES to opt_param.h. I doubt anyone would complain (or even notice) if you removed it entirely. DES -- Dag-Erling Smørgrav - [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: NFS ( amd?) dysfunction descending a hierarchy
On Wed, Dec 10, 2008 at 11:30:26AM -0500, Rick Macklem wrote: ... The different behaviour for -CURRENT could be the newer RPC layer that was recently introduced, but that doesn't explain the basic problem. OK. All I can think of is to ask the obvious question. Are you using interruptible or soft mounts? If so, switch to hard mounts and see if the problem goes away. (imho, neither interruptible nor soft mounts are a good idea. You can use a forced dismount if there is a crashed NFS server that isn't coming back anytime soon.) From examination of /etc/amd* -- I don't see how to get mount(8) or amq(8) to report it -- it appears that we are using interruptible mounts, as we always have. The point is that the behavior has changed in an unexpected way. And I'm not so sure that the use of a forced dismount is generally available, as it would require logging in to the NFS client first, which may be difficult if the NFS server hosting non-root home directories is failing to respond and direct root login via ssh(1) is not permitted (as is the default). If you are getting this with hard mounts, I'm afraid I have no idea what the problem is, rick. What concerns me is that even if the attempted unmount gets EBUSY, the user-level process descending the directory hierarchy is getting ENOENT trying to issue fstatfs() against an open file descriptor. I'm having trouble figuring out any way that makes any sense. Peace, david -- David H. Wolfskill [EMAIL PROTECTED] Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpiNs29PfKCN.pgp Description: PGP signature
Re: NFS ( amd?) dysfunction descending a hierarchy
On Wed, Dec 10, 2008 at 08:50:22AM -0800, David Wolfskill wrote: On Wed, Dec 10, 2008 at 11:30:26AM -0500, Rick Macklem wrote: ... The different behaviour for -CURRENT could be the newer RPC layer that was recently introduced, but that doesn't explain the basic problem. OK. All I can think of is to ask the obvious question. Are you using interruptible or soft mounts? If so, switch to hard mounts and see if the problem goes away. (imho, neither interruptible nor soft mounts are a good idea. You can use a forced dismount if there is a crashed NFS server that isn't coming back anytime soon.) From examination of /etc/amd* -- I don't see how to get mount(8) or amq(8) to report it -- it appears that we are using interruptible mounts, as we always have. The point is that the behavior has changed in an unexpected way. And I'm not so sure that the use of a forced dismount is generally available, as it would require logging in to the NFS client first, which may be difficult if the NFS server hosting non-root home directories is failing to respond and direct root login via ssh(1) is not permitted (as is the default). If you are getting this with hard mounts, I'm afraid I have no idea what the problem is, rick. What concerns me is that even if the attempted unmount gets EBUSY, the user-level process descending the directory hierarchy is getting ENOENT trying to issue fstatfs() against an open file descriptor. I'm having trouble figuring out any way that makes any sense. Basically, the problem is that NFS uses shared lookup, and this allows for the bug where several negative namecache entries are created for non-existent node. Then this node gets created, removing only the first negative namecache entry. For some reasons, vnode is reclaimed; amd' tasting of unmount is a good reason for vnode to be reclaimed. Now, you have existing path and a negative cache entry. This was reported by Peter Holm first, I listed relevant revisions that should fix this in previous mail. pgpJTtEegr73d.pgp Description: PGP signature
Re: FreeBSD (russian)
Eygene Ryabinkin wrote: Wed, Dec 10, 2008 at 04:17:48AM +0200, Юлия Смолик wrote: Hello dear command of developers of FreeBSD. I wish to take part in the project on developing out of FreeBSD and to subscribe for dispatch. http://lists.freebsd.org/pipermail/freebsd-hackers/2008-November/026566.html and especially http://www.freebsd.org/projects/index.html http://wiki.freebsd.org/ will be good too. can we have a russian speaking developer contact him too? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD (russian)
2008/12/10 Julian Elischer [EMAIL PROTECTED]: Eygene Ryabinkin wrote: Wed, Dec 10, 2008 at 04:17:48AM +0200, Юлия Смолик wrote: Hello dear command of developers of FreeBSD. I wish to take part in the project on developing out of FreeBSD and to subscribe for dispatch. http://lists.freebsd.org/pipermail/freebsd-hackers/2008-November/026566.html and especially http://www.freebsd.org/projects/index.html http://wiki.freebsd.org/ will be good too. can we have a russian speaking developer contact him too? it's her :) -- wbr, pluknet ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Enhancing cdboot [patch for review]
On Monday 08 December 2008 06:51:19 pm Luigi Rizzo wrote: On Mon, Dec 08, 2008 at 02:40:41PM -0800, Maxim Sobolev wrote: Hi, Below please find patch that enhances cdboot with two compile-time options: ... Any comments/suggestions are appreciated. If there are no objections I would like to commit the change. The long-term goal is to make CDBOOT_PROMPT default mode for installation CD. http://sobomax.sippysoft.com/~sobomax/cdboot.diff Looks good. Some comments: 1. since there is plenty of space in the cdboot sector, why don't you make the two option always compiled in, controlling which one to activate through flags in the bootsector itself, to be set patching the binary sector itself using a mechanism similar to boot0cfg. Of course you cannot alter a cdrom after you burn it, but it makes it easier to build CDs with one or the other defaults, patching cdboot or the iso image itself before creating/burning it. I don't think this is very useful because CDs are read-only. You can just as easily build a different cdboot rather than having to write some custom cdbootcfg util to patch the binary. 2. in fact, the 'silent' option could be disabled at runtime by pressing some key (e.g. adding a short wait loop before proceeding; if this is meant for custom, unattended CDs the extra delay should not matter much); I don't imagine anyone will know to press a key to get verbose messages, and the CD boot process is quick enough you would have to add an artificial delay to it to allow for the keypress. 3. one nitpick -- in one of the first chunks you replace $start with $LOAD, but if i am not mistaken operation depends on $LOAD = $start, so why don't you always use the same ? No, because he relocates it, $start is now the relocated address, but the BIOS loads it at LOAD which is now != $start. Also in terms of relocation size, wouldn't it be the case of hardwiring the size of the cd boot sector: - mov $((end_init - start)/2),%cx + mov 1024,%cx I prefer the existing code to make sure and copy the full boot loader, whatever it's size is. Maxim, My only comment is to please make the new block comment match the style of the existing block comments by having '#\n' lines before and after. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD (russian)
pluknet wrote: 2008/12/10 Julian Elischer [EMAIL PROTECTED]: Eygene Ryabinkin wrote: Wed, Dec 10, 2008 at 04:17:48AM +0200, Юлия Смолик wrote: Hello dear command of developers of FreeBSD. I wish to take part in the project on developing out of FreeBSD and to subscribe for dispatch. http://lists.freebsd.org/pipermail/freebsd-hackers/2008-November/026566.html and especially http://www.freebsd.org/projects/index.html http://wiki.freebsd.org/ will be good too. can we have a russian speaking developer contact him too? it's her :) yeah you are the 3rd person to tell me it's Julia.. I should know better :-) (and I see more emails ahead in my list that will probably tell me too. :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS ( amd?) dysfunction descending a hierarchy
On Tue, 9 Dec 2008, David Wolfskill wrote: On Tue, Dec 02, 2008 at 04:15:38PM -0800, David Wolfskill wrote: I seem to have a fairly- (though not deterministly so) reproducible mode of failure with an NFS-mounted directory hierarchy: An attempt to traverse a sufficiently large hierarchy (e.g., via tar zcpf or rm -fr) will fail to visit some subdirectories, typically apparently acting as if the subdirectories in question do not actually exist (despite the names having been returned in the output of a previous readdir()). ... I was able to reproduce the external symptoms of the failure running CURRENT as of yesterday, using rm -fr of a copy of a recent /usr/ports hierachy on an NFS-mounted file system as a test case. However, I believe the mechanism may be a bit different -- while still being other than what I would expect. One aspect in which the externally-observable symptoms were different (under CURRENT, vs. RELENG_7) is that under CURRENT, once the error condition occurred, the NFS client machine was in a state where it merely kept repeating nfs server [EMAIL PROTECTED]:/volume: not responding until I logged in as root rebooted it. The different behaviour for -CURRENT could be the newer RPC layer that was recently introduced, but that doesn't explain the basic problem. All I can think of is to ask the obvious question. Are you using interruptible or soft mounts? If so, switch to hard mounts and see if the problem goes away. (imho, neither interruptible nor soft mounts are a good idea. You can use a forced dismount if there is a crashed NFS server that isn't coming back anytime soon.) If you are getting this with hard mounts, I'm afraid I have no idea what the problem is, rick. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: crypto(9) choose another driver if we cannot open a session on it
Le Mon, 8 Dec 2008 21:21:55 +0100, Philip Paeps [EMAIL PROTECTED] a écrit : Hello, On 2008-12-07 22:45:51 (+0100), Patrick Lamaizière [EMAIL PROTECTED] wrote: I wrote a small patch to allow the crypto framework to choose another cryptographic driver if we cannot open a session on the driver. Very cool. :-) I've been hacking on this too, mainly to get rid of the code duplication that currently exists. Which code exactly? Yes I'm curious :-) I'm thinking about how to remove the need for a device to support all the algorithms when we open a session. By using a fake crypto virtual device to open and dispatch crypto requests to real devices or to cryptosoft. But i don't have any code to show yet. There is one thing I'm asking about crypto(9): - I doubt that the migration of a session is safe and I think that would be far easier to prevent a driver to unregister when there are some pending sessions on it? glxsb and padlock do not allow to unregister in this case. I've looked quickly the code of geli or ipsec. If the crypto framework returns EAGAIN because the migration of the session, they restart a crypto_dispatch(crp) but the datas in crp-crp_buf can be corrupted by the previous crypto operation (IMHO, may be i've missed something)? Thanks, regards. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: crypto(9) choose another driver if we cannot open a session on it
Patrick Lamaizière wrote: Le Mon, 8 Dec 2008 21:21:55 +0100, Philip Paeps [EMAIL PROTECTED] a écrit : Hello, On 2008-12-07 22:45:51 (+0100), Patrick Lamaizière [EMAIL PROTECTED] wrote: I wrote a small patch to allow the crypto framework to choose another cryptographic driver if we cannot open a session on the driver. Very cool. :-) I've been hacking on this too, mainly to get rid of the code duplication that currently exists. Which code exactly? Yes I'm curious :-) I'm thinking about how to remove the need for a device to support all the algorithms when we open a session. By using a fake crypto virtual device to open and dispatch crypto requests to real devices or to cryptosoft. But i don't have any code to show yet. There is one thing I'm asking about crypto(9): - I doubt that the migration of a session is safe and I think that would be far easier to prevent a driver to unregister when there are some pending sessions on it? glxsb and padlock do not allow to unregister in this case. I've looked quickly the code of geli or ipsec. If the crypto framework returns EAGAIN because the migration of the session, they restart a crypto_dispatch(crp) but the datas in crp-crp_buf can be corrupted by the previous crypto operation (IMHO, may be i've missed something)? This sounds like the session management layer I wanted to insert a while back. It was a reason why I made the s/w driver into a pseudo device (so there'd be a handle). I want to look at your mods but haven't had time. As to unregister that was designed for devices like cardbus cards that might go away. About the only way to simulate it today is to unload a driver module. But it should work; if you see an issue we should try to fix it. OTOH the limitations of the existing crypto code are dramatic and the rationale for maintaining the obsd api's (both in kernel and user space) are no longer valid. It would be good to see someone take this stuff and overhaul it to do things like: o add a session management layer that falls back to s/w when a device is incapable and when operations are more efficiently done in s/w (e.g ops too small to incur the dma setup/overhead) o do load balancing over multiple devices o support cpu resources as pseudo drivers (e.g. pin a thread to a cpu) o replace the bogus fd session crud w/ device cloning The linux folks have done some of this and there may be lessons to be learned from their efforts. FWIW netbsd has some recent user api changes for doing async ops and batching to speedup openssl etc; if you're going to get into this stuff you might take a look. Sam ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Small Change to chpass.c
Hi guys,
When I was doing some user management today I noticed that chpass, and all
the utilities that use chpass.c, only give one attempt to authenticate to
make the change. After I messed this up once or twice (and after doing 4-5
minutes of editing only to have it lost when I typo'd the password) I wrote
this little change in to chpass.c.
When it needs the users password, it will enter into a for loop, increasing
itr until it hits max_retries (defined at top of main() declaration). If one
of these tries is successful (password given matches) then auth is set to
'1' and we break from the loop, and update info. If, after three tries, auth
is still '0' (the user didn't supply the proper password) we call baduser()
to handle it.
It's a pretty inconsequential change but it managed to relieve me of quite a
bit of stress :-)
Happy Holidays, everyone!
Sheldon Givens
---snip---
--- /usr/src/usr.bin/chpass.c 2008-12-11 01:55:27.0 -0800
+++ /usr/src/usr.bin/chpass.c 2008-12-11 01:57:09.0 -0800
@@ -80,10 +80,11 @@
{
enum { NEWSH, LOADENTRY, EDITENTRY, NEWPW, NEWEXP } op;
struct passwd lpw, *old_pw, *pw;
- int ch, pfd, tfd;
+ int ch, pfd, tfd, itr, auth;
const char *password;
char *arg = NULL;
uid_t uid;
+ int max_retries = 3;
#ifdef YP
struct ypclnt *ypclnt;
const char *yp_domain = NULL, *yp_host = NULL;
@@ -227,9 +228,16 @@
}
if (old_pw !master_mode) {
- password = getpass(Password: );
- if (strcmp(crypt(password, old_pw-pw_passwd),
- old_pw-pw_passwd) != 0)
+ auth = 0;
+ for(itr=0;itrmax_retries;itr++) {
+ password = getpass(Password:);
+ if(strcmp(crypt(password, old_pw-pw_passwd),
+ old_pw-pw_passwd) == 0) {
+ auth=1;
+ break;
+ }
+ }
+ if (!auth)
baduser();
} else {
password = ;
---snip---
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Watchdog for Boser (HS-7001)
Christoph Mallon wrote:
Won De Erick schrieb:
- Original Message
From: Rink Springer [EMAIL PROTECTED]
On Mon, Dec 01, 2008 at 09:38:51AM +0100, Christoph Mallon wrote:
Userland is not allowed to write to ports. That's the bus error you see.
Also without a call to the exit syscall at the end, it will segfault.
Note that you can write to ports from userland by opening /dev/io - if
you have it opened, you can write to the ports.
I've added the following at the end
mov eax, 1 ; SYS_exit
call doint
doint:
int 0x80
ret
Besides, I can see the following at /dev
crw--- 1 root wheel 0, 16 Nov 27 01:53 io
How should I make this open? do i need to %include this?
You're probably better of writing this in C. Here is a wrapper for the out
instruction:
static inline outb(unsigned short port, unsigned char data)
{
asm(outb %0, %1 : : a (data), dN (port));
}
As Rink mentioned, you have to open /dev/io. The process must have super-user
privileges, see io(4).
OK thanks for all the tips. I have now a working watchdog. :)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Small Change to chpass.c
On Wed, 10 Dec 2008 18:00:25 -0800, Sheldon Givens [EMAIL PROTECTED] wrote:
Hi guys,
When I was doing some user management today I noticed that chpass, and
all the utilities that use chpass.c, only give one attempt to
authenticate to make the change. After I messed this up once or twice
(and after doing 4-5 minutes of editing only to have it lost when I
typo'd the password) I wrote this little change in to chpass.c.
This seems useful, thanks for submitting the patch :)
---snip---
--- /usr/src/usr.bin/chpass.c 2008-12-11 01:55:27.0 -0800
+++ /usr/src/usr.bin/chpass.c 2008-12-11 01:57:09.0 -0800
@@ -80,10 +80,11 @@
{
enum { NEWSH, LOADENTRY, EDITENTRY, NEWPW, NEWEXP } op;
struct passwd lpw, *old_pw, *pw;
- int ch, pfd, tfd;
+ int ch, pfd, tfd, itr, auth;
const char *password;
char *arg = NULL;
uid_t uid;
+ int max_retries = 3;
#ifdef YP
struct ypclnt *ypclnt;
const char *yp_domain = NULL, *yp_host = NULL;
@@ -227,9 +228,16 @@
}
if (old_pw !master_mode) {
- password = getpass(Password: );
- if (strcmp(crypt(password, old_pw-pw_passwd),
- old_pw-pw_passwd) != 0)
+ auth = 0;
+ for(itr=0;itrmax_retries;itr++) {
+ password = getpass(Password:);
+ if(strcmp(crypt(password, old_pw-pw_passwd),
+ old_pw-pw_passwd) == 0) {
+ auth=1;
+ break;
+ }
+ }
+ if (!auth)
baduser();
} else {
password = ;
---snip---
You can probably do away with `auth' and reset password to NULL when
strcmp() fails (note that we also use whitespace in for statements to
separate everything more clearly):
if (old_pw !master_mode) {
for (itr = 0; itr max_retries; itr++) {
password = getpass(Password:);
if (strcmp(crypt(password, old_pw-pw_passwd),
old_pw-pw_passwd) != 0)
break;
password = NULL;
}
if (password == NULL)
baduser();
} else {
password = ;
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Enhancing cdboot [patch for review]
While you're enhancing cdboot anyway, can I ask how complicated it would be to make cdboot serial-console capable? (I'm not a C programmer, I'm a sysadmin - but I'd be prepared to try and look at this myself if no-one else is interested). As it stands, the only way I've found to do a serial-console CD-based installation is by enabling the serial console in /boot/loader.conf, by which time you've already missed several useful points, particularly the entry to BIOS settings (if you have a serial-capable BIOS). Jonathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Small Change to chpass.c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 11 Dec 2008 08:32+0200, Giorgos Keramidas wrote:
On Wed, 10 Dec 2008 18:00:25 -0800, Sheldon Givens [EMAIL PROTECTED]
wrote:
--- /usr/src/usr.bin/chpass.c 2008-12-11 01:55:27.0 -0800
+++ /usr/src/usr.bin/chpass.c 2008-12-11 01:57:09.0 -0800
@@ -80,10 +80,11 @@
{
enum { NEWSH, LOADENTRY, EDITENTRY, NEWPW, NEWEXP } op;
struct passwd lpw, *old_pw, *pw;
- int ch, pfd, tfd;
+ int ch, pfd, tfd, itr, auth;
const char *password;
char *arg = NULL;
uid_t uid;
+ int max_retries = 3;
#ifdef YP
struct ypclnt *ypclnt;
const char *yp_domain = NULL, *yp_host = NULL;
@@ -227,9 +228,16 @@
}
if (old_pw !master_mode) {
- password = getpass(Password: );
I'm sure you have noticed the trailing space in the string.
- if (strcmp(crypt(password, old_pw-pw_passwd),
- old_pw-pw_passwd) != 0)
+ auth = 0;
+ for(itr=0;itrmax_retries;itr++) {
+ password = getpass(Password:);
The space's missing in this string. It might be better to stay
consistent with the original code.
+ if(strcmp(crypt(password, old_pw-pw_passwd),
+ old_pw-pw_passwd) == 0) {
+ auth=1;
+ break;
+ }
+ }
+ if (!auth)
baduser();
} else {
password = ;
- --
- --
Trond Endrestøl | [EMAIL PROTECTED]
ACM, NAS, NUUG, SAGE, USENIX | FreeBSD 6.2-STABLE Pine 4.64
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (FreeBSD)
iD8DBQFJQL0dbYWZalUoElsRAolhAJoC4iTyrVY3xeoChg3iWRsDLpvonwCeP0yT
1kM28vaxZtNH9LGqyZzZCTA=
=0+CT
-END PGP SIGNATURE-___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
