Re: Zero Copy, FreeBSD and Linus Torvalds opinion
On Mon, 2006-May-01 18:01:01 -0400, Allen wrote: Man I would LOVE to find a good sun box. Nothing huge, just a box I can use to toy with Solaris and oldschool stuff like early SunOS. This won't be one box. Sun hardware and software has undergone a lot of churn over the years and you will need to find a box to suit the SunOS or Solaris version that you want to run. Just want at least one UNIX box in the house. *BSD is Unix in all but branding. Or you can run Solaris 10 on a PC. Well.. Sun at some point took 4.1.3 and 4.1.4 into the Solaris naming scheme. Just confusing to a lot of people. Software naming has always been a pain ;) Especially when the marketing people get involved... -- Peter Jeremy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Boot manager beep (revisited)
Giorgos Keramidas wrote: On 2006-05-01 14:02, John Baldwin [EMAIL PROTECTED] wrote: How about the patch below. It restores the behavior of the beep only happening for invalid input by axeing the BSD/OS partition type from the lookup table. Much better, since this is the behavior we initially had, as you explained. Thanks :) Seconded! Thanks, --Alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gvinum start volume returns EBUSY
On Mon, May 01, 2006 at 03:27:11PM -0500, Rick C. Petty wrote: When rebuilding a degraded plex with gvinum start volume on a mounted filesystem, gvinum reports errno: 16 (EBUSY). In the CVS: src/sys/geom/vinum/geom_vinum_init.c, lines 363-364 (of MAIN, added 2005-Oct-09, rev 1.10.2.1) has the check: if (gv_is_open(p-geom)) return (EBUSY); Why is this the case? The log for that change suggests this is to prevent sync operations from starting when they are already in progress, but that really refers to lines 366-367: if (p-flags GV_PLEX_SYNCING) return (EINPROGRESS); It seems to me that lines 363-364 should be deleted. If you have a degraded volume but need to keep it mounted (such as /usr or /home, etc.), I can't see any reason why you should be forced to unmount the volume before rebuilding (if the volume is RAID5). Maybe this restriction is useful for non-RAID5 configurations, but gv_rebuild_plex is only called in the context of GV_PLEX_RAID5 on degraded plexes. Maybe I'm misunderstanding something. Feel free to enlighten me! :-) While regular vinum allowed rebuilding plexes that were mounted, I have seen resulting filesystem corruption afterwards. Unfortunately I don't know whether Lukas has implemented tested rebuilding online plexes for gvinum yet. --Stijn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Boot manager beep (revisited)
On Tuesday 02 May 2006 07:36 am, Alex Zbyslaw wrote: Giorgos Keramidas wrote: On 2006-05-01 14:02, John Baldwin [EMAIL PROTECTED] wrote: How about the patch below. It restores the behavior of the beep only happening for invalid input by axeing the BSD/OS partition type from the lookup table. Much better, since this is the behavior we initially had, as you explained. Thanks :) Seconded! Thanks, Does it work? :-) -- John Baldwin [EMAIL PROTECTED] http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Boot manager beep (revisited)
Alex Zbyslaw [EMAIL PROTECTED] writes: Since I'm on 5.4 I guess I just haven't got your changes yet. Thanks for doing it, though. Be nice not to have to remember to patch boot.S every time I rebuild. You don't have to, since installworld does not touch the MBR. 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: [PATCH] Fancy rc startup style RFC
Coleman Kane wrote: On Mon, May 01, 2006 at 12:29:20PM -0700, Brooks Davis wrote: On Mon, May 01, 2006 at 02:16:04PM -0500, Eric Anderson wrote: Brooks Davis wrote: On Mon, May 01, 2006 at 02:13:22PM -0500, Eric Anderson wrote: Brooks Davis wrote: On Sun, Apr 30, 2006 at 10:23:32PM -0500, Eric Anderson wrote: Coleman Kane wrote: On Mon, Apr 24, 2006 at 09:45:09AM -0500, Eric Anderson wrote: Eric Anderson wrote: Actually, some other things got changed somewhere in the history, that broke some things and assumptions I was making. This patch has them fixed, and I've tested it with all the different options: http://www.googlebit.com/freebsd/patches/rc_fancy.patch-9 It's missing the defaults/rc.conf diffs, but you should already know those. Eric I have a new patch (to 7-CURRENT) of the fancy_rc updates. This allows the use of: rc_fancy=YES--- Turns on fancy reporting (w/o color) rc_fancy_color=YES --- Turns on fancy reporting (w/ color), needs rc_fancy=YES rc_fancy_colour=YES --- Same as above for you on the other side of the pond. rc_fancy_verbose=YES -- Turn on more verbose activity messages. This will cause what appear to be false positives, where an unused service is OK instead of SKIP. You can also customize the colors, the widths of the message brackets (e.g. [ OK ] vs. [ OK ]), the screen width, and the contents of the message (OK versus GOOD versus BUENO). Also, we have the following message combinations: OK --- Universal good message SKIP,SKIPPED --- Two methods for conveying the same idea? ERROR,FAILED --- Ditto above, for failure cases Should we just have 3 different messages, rather than 5 messages in 3 categories? Yes, that's something that started with my first patch, and never got ironed out. I think it should be: OK SKIPPED FAILED and possibly also: ERROR The difference between FAILED and ERROR would be that FAILED means the service did not start at all, and ERROR means it started but had some kind of error response. FAILED vs ERROR seems confusing. I'd be inclined toward WARNING vs FAILED or ERROR. True, however I still see a difference between FAILED and WARNING. For instance, as an example: a FAILED RAID is different than a RAID with a WARNING. For that level of detail, the ability to provide additional output seems like the appropriate solution. Yes, true, but you'd still want to show something (I would think) in the [ ]'s to keep it consistent. My feeling is that anything short of complete success should report WARNING and a message unless it actually totally failed in which case FAILED or ERROR (I slightly perfer ERROR) should be used. -- Brooks What situations are we determining get flagged as ERROR versus FAILED? Is FAILED considered to be 'I was able to run the command, but it returned an error code', versus ERROR being 'I could not even run the command!' like bad path, file not found, etc... This point still kind of confuses me (and needs to be well defined). I am an advocate of having three distinct messages: OK, SKIPPED, ERROR. And not even bothering with the different types of ERROR/FAILED other than having extra reporting output. I'm ok with just OK, SKIPPED, ERROR.. If there's ever a need for more, it's easy to add it. Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: which running thread gests the external signal
Daniel Eischen wrote: POSIX states any thread that is in sigwait() (with the specified signal in the wait mask), or has the signal unmasked (in the threads signal mask) can receive the signal. If you want a certain thread to receive a process-wide signal, then the only sure way (POSIX) to do that is to block the signal in all the threads with the exception of the thread that is to receive the signal. OK, I was able to delegate a single thread for handling all the signals, by using sigprocmask to block all signals at the beggining, then using pthread_sigmask to unblock the needed signals inside the delegated thread. This seemed to be the cleanest way of doing it.. However, this is not fully clean: all the other threads should *ignore* the signals, not *block* them. Blocking a signal means the signal will be queued and the queue will eventually fill, and so on. In my scenario I get the result without running into problems (because each thread seems to have it's own signal queue), however it's not... clean. The other threads need to simply 'drop' the signals, not cause them to be queued forever (consider an uptime of 1 year?). I don't know the impact, however I want it to be clean.. So ... would it be a way to ignore the signals from all the other threads except the delegated one for handling them? (I'm sorry, I don't notice it, even if it's obvious) Thanks for the advices and the tips, it's been really usefull. PS: Without using sigprocmask and pthread_sigmask, one random thread is stopped in order for the signal handler to execute. Doesn't this mean that the other threads are not 'seeing' the signal? In order to force a thread to receive/see the signal, I need to block the signal inside all the other threads (either with sigprocmask in main, or with pthread_sigmask). On Linux, the signal gets delivered to all the running threads, unless specifically blocked :). And I think that conformes to your mentioning of POSIX standards. Sorry if I'm wrong. [..] I would recommend you also visit http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html I've read it, thanks. I added it to my bookmarks. Yours Sincerely, -- Alin-Adrian Anton GPG keyID 0x183087BA (B129 E8F4 7B34 15A9 0785 2F7C 5823 ABA0 1830 87BA) gpg --keyserver pgp.mit.edu --recv-keys 0x183087BA It is dangerous to be right when the government is wrong. - Voltaire ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: which running thread gests the external signal
On Tue, May 02, 2006 at 08:58:56PM +0300, Alin-Adrian Anton wrote: However, this is not fully clean: all the other threads should *ignore* the signals, not *block* them. Threads don't have signal queues. POSIX specifies that a process has a *global* list of pending signals and a *thread-local* list of currently blocked signals. A correct implementation could iterate over the list of all threads of a process, whenever either a new signal arrives or a thread mask is changed. This is not the behaviour Linux implemented for ages. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: which running thread gests the external signal
On Tue, 2 May 2006, Alin-Adrian Anton wrote: Daniel Eischen wrote: POSIX states any thread that is in sigwait() (with the specified signal in the wait mask), or has the signal unmasked (in the threads signal mask) can receive the signal. If you want a certain thread to receive a process-wide signal, then the only sure way (POSIX) to do that is to block the signal in all the threads with the exception of the thread that is to receive the signal. OK, I was able to delegate a single thread for handling all the signals, by using sigprocmask to block all signals at the beggining, then using pthread_sigmask to unblock the needed signals inside the delegated thread. This seemed to be the cleanest way of doing it.. However, this is not fully clean: all the other threads should *ignore* the signals, not *block* them. Blocking a signal means the signal will be queued and the queue will eventually fill, and so on. In my scenario I get the result without running into problems (because each thread seems to have it's own signal queue), however it's not... clean. The other threads need to simply 'drop' the signals, not cause them to be queued forever (consider an uptime of 1 year?). I don't know the impact, however I want it to be clean.. You are entirely confused. You should go back to the POSIX standard and get Dave Butenhof's Programming with POSIX Threads book. One and only one thread gets _a_ signal. Blocking a signal in a thread does not mean it is queued on that thread, unless the signal is sent specifically to that thread (using pthread_kill(tid, sig), not kill(pid, sig)). Read the part of the POSIX standard that talks about signals pending on the process. Signals pending on the process, stay pending (or queued if they are queued signals) until a thread either unblocks the signal, calls sigwait() selecting that signal, or ignores the signal (using sigaction()). A signal handler runs in the context of the thread that is receiving (handling) the signal. So ... would it be a way to ignore the signals from all the other threads except the delegated one for handling them? (I'm sorry, I don't notice it, even if it's obvious) Thanks for the advices and the tips, it's been really usefull. PS: Without using sigprocmask and pthread_sigmask, one random thread is stopped in order for the signal handler to execute. Doesn't this mean that the other threads are not 'seeing' the signal? In order to force a thread to receive/see the signal, I need to block the signal inside all the other threads (either with sigprocmask in main, or with pthread_sigmask). On Linux, the signal gets delivered to all the running threads, unless specifically blocked :). And I think that conformes to your mentioning of POSIX standards. No, if Linux delivers one signal to multiple threads, then it is entirely wrong and not compliant with POSIX behavior. I think Linux' NPT threads (or whatever they are called) have correct behavior. -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
memory allocation / deallocation within the kernel
I am trying to understand the impact of memory allocation / deallocation within the kernel. As I understand a) Kernel memory is not pageable ie the one you get from using kernel malloc(there may be exceptions) b) Does this imply that if I have 1 GB of RAM - then I cannot reserve more than 1 GB of kernel virtual address space? The reason is that if at any point of time, the kernel has to allocate all of its virtual address space i.e. if it needs to allocate more than 1 GB of address space, there won't be any physical RAM memory to allocate from and thus this scenario is not allowed as a configuration? c) Another scenario is that assume that the kernel has 512 MB of virtual address space with 1 GB of RAM. Now assume that the entire 1 GB of RAM is used up by the kernel and other userland process that are running - with the kernel taking 256 MB and the rest allocated to the processes. Now if the kernel needs to allocate more memory, will some of the processes be swapped out to make way for the kernel(since the kernel can take upto 512 MB) Thanks for any answers. Any URL / literature that explains this will also be appreciated. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: memory allocation / deallocation within the kernel
On Tue, 2 May 2006, Bharma Ji wrote: I am trying to understand the impact of memory allocation / deallocation within the kernel. As I understand I can't answer all your questions, but can point at a few examples in current kernel code. a) Kernel memory is not pageable ie the one you get from using kernel malloc(there may be exceptions) In general, we guarantee that kernel memory is accessible fault-free so that locks can be held over kernel memory use. In particular, both kernel malloc and the kernel slab allocator allocate both address space and locked memory that is non-pageable. Two canonical exceptions: - Kernel thread stacks, which may be swapped out. See PS_INMEM. - Pipe buffers, which use pageable kernel memory. b) Does this imply that if I have 1 GB of RAM - then I cannot reserve more than 1 GB of kernel virtual address space? The reason is that if at any point of time, the kernel has to allocate all of its virtual address space i.e. if it needs to allocate more than 1 GB of address space, there won't be any physical RAM memory to allocate from and thus this scenario is not allowed as a configuration? Address space and memory are separable. The kernel memory allocators ask for memory from the VM system as other consumers do, so the kernel address space can be much larger than available memory. On the other hand, you as long as you're dealing with kernel memory allocated using standard allocators, such as malloc and UMA, you are allocating both address space and memory, so you can't use more memory than address space. Some components, such as md disk devices, allocate using swap-backed memory that is pageable, so interfaces exist to use pageable memory in kernel, and are used. You do have to be pretty careful though, as if you fault in an address in kernel, you may have to wait for it to arrive, which involves long sleeps. Holding kernel locks, especially mutexes, across faults is not a good thing, and our invariants checkers will generate errors when that happens. c) Another scenario is that assume that the kernel has 512 MB of virtual address space with 1 GB of RAM. Now assume that the entire 1 GB of RAM is used up by the kernel and other userland process that are running - with the kernel taking 256 MB and the rest allocated to the processes. Now if the kernel needs to allocate more memory, will some of the processes be swapped out to make way for the kernel(since the kernel can take upto 512 MB) If we're talking about non-pageable kernel memory, then user space will be operating in a memory-starved environment, and likely thrash. If we're talking about pageable kernel memory, then the kernel threads and user threads will compete for physical memory. Robert N M Watson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 6.1-RC2 available
All, I'm foregoing the formal pretty announcement for 6.1-RC2 because the message needs to get out and I don't have an hour to spend on making it look nice. FreeBSD 6.1-RC2 is available for download. This is the last RC before the release. Please test it to make sure that there have been no regressions since the last RC, and to make sure that it there are no new problems with installation. Other than a few cosmetic tweaks, there will be no more changes before 6.1. The list of known issues: - Using UFS snapshots and quotas at the same time can cause system lockups. There is no work-around available at this time, so please avoid this configuration. This will be fixed in a future release. - Under rare and heavily loaded circumstances, there is a possibility to leak pty's. This can result in not being able to long into the system. The cause of this is not well understood, and it appears to be very difficult to trigger it. - DEVFS is known to have several problems with multiple processes doing directory listings at the same time, as well as with unmounting DEVFS directories at the same time. There is no known work-around for this at this time. This will be fixed in a future release. - A number of improvements and fixes for various drivers have come in at the last minute that still require much more testing and validation. This includes the 'if_nve' and 'if_bge' drivers in particular. These updates will be included in future releases. MD5 (6.1-RC1-amd64-bootonly.iso) = 93abe294e7678e00b7391f47a01074fe MD5 (6.1-RC1-amd64-disc1.iso) = c1b718b6752f0e48edb8b822ee9b0dc8 MD5 (6.1-RC1-amd64-disc2.iso) = 4a67ae8ed7a7852e08442205d6a5cd7c MD5 (6.1-RC1-i386-bootonly.iso) = b56aac9ca1a868daaf5673cd21bf78f5 MD5 (6.1-RC1-i386-disc1.iso) = 12521c3f9d40f637e4cdb40ea398d072 MD5 (6.1-RC1-i386-disc2.iso) = 53615f19889fe85c41e2bcea0b2be525 MD5 (6.1-RC2-ia64-bootonly.iso) = 481e6f1899c0ba632272e7853b8ef59e MD5 (6.1-RC2-ia64-disc1.iso) = f4601bb9089af1bcde5b751f5762f35a MD5 (6.1-RC2-ia64-disc2.iso) = b44d5a0538b784cbb5de0a8ec23e4256 MD5 (6.1-RC2-ia64-livefs.iso) = 0fe8b66a80edaa50ac353d5471930035 MD5 (6.1-RC2-pc98-disc1.iso) = 773a64a475596d586d0a1573d88310cc SHA256 (6.1-RC1-amd64-bootonly.iso) = 88e072b4898692813517aa254a33f1e7469de0e590c36bfb3e92cb120ac0ad16 SHA256 (6.1-RC1-amd64-disc1.iso) = 017e69c5461fe2c865a395830dde88c8a55e7ec83d9a195b3b619346b44f9cc6 SHA256 (6.1-RC1-amd64-disc2.iso) = 81624f3b8dfa67ceab1dc6ec0a94c4485ad85955321c39d13c9ab4a678f776ef SHA256 (6.1-RC1-i386-bootonly.iso) = ec1a3fbf53186b5bc44dbfcdc77872c847f3c55532bb62f2afb4133328e7994f SHA256 (6.1-RC1-i386-disc1.iso) = e0b83f2cbd27db20f330036d0a25b8366b9e45df4b9c09354f76e584a9eb3b83 SHA256 (6.1-RC1-i386-disc2.iso) = de1fe5009229efd44b25bb18c4e68b03027259171cd9e017fe5bffadaa3402bb SHA256 (6.1-RC2-ia64-bootonly.iso) = c044989257754fa17daa352f76c3e011dfc04b3b242c2153c7a1ec47a773d4d1 SHA256 (6.1-RC2-ia64-disc1.iso) = 60bec7c25b8f645a9d20d3240397c7a92f42d24ff5d01b4604ece5f9ee499ccc SHA256 (6.1-RC2-ia64-disc2.iso) = 854048d4ba4dcf00657501d36a5fb15a94ed4c20e646031960ebc3315c3a513e SHA256 (6.1-RC2-ia64-livefs.iso) = fb3fadb00c9ddb6233172a34a7d47ab80171b54410835954c20f50849359ee73 SHA256 (6.1-RC2-pc98-disc1.iso) = f2b5f17a3355465727613e33807964a0cf92d9c02868cd2c25440995b2c6ebfd ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Boot manager beep (revisited)
John Baldwin wrote: On Tuesday 02 May 2006 07:36 am, Alex Zbyslaw wrote: Giorgos Keramidas wrote: On 2006-05-01 14:02, John Baldwin [EMAIL PROTECTED] wrote: How about the patch below. It restores the behavior of the beep only happening for invalid input by axeing the BSD/OS partition type from the lookup table. Much better, since this is the behavior we initially had, as you explained. Thanks :) Seconded! Thanks, Does it work? :-) I downloaded the latest boot0.s from cvs, applied you patch and put it on all three disks in this box. On my tests it worked beautifully. Beeped when I selected a non-existent partition and didn't beep when I selected a legitimate one, or just let it time out to the default. (I tried both FreeBSD and WinXP/NTFS partitions for booting and auto-boot). I can't confirm what boot0sio does as I don't have anything set up with a serial console. You'll probably want some more confirmations, but I'd say this was the bees knees. --Alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Boot manager beep (revisited)
Alex Zbyslaw wrote: John Baldwin wrote: On Tuesday 02 May 2006 07:36 am, Alex Zbyslaw wrote: Giorgos Keramidas wrote: On 2006-05-01 14:02, John Baldwin [EMAIL PROTECTED] wrote: How about the patch below. It restores the behavior of the beep only happening for invalid input by axeing the BSD/OS partition type from the lookup table. Much better, since this is the behavior we initially had, as you explained. Thanks :) Seconded! Thanks, Does it work? :-) I downloaded the latest boot0.s from cvs, applied you patch and put it on all three disks in this box. On my tests it worked beautifully. Beeped when I selected a non-existent partition and didn't beep when I selected a legitimate one, or just let it time out to the default. (I tried both FreeBSD and WinXP/NTFS partitions for booting and auto-boot). I can't confirm what boot0sio does as I don't have anything set up with a serial console. You'll probably want some more confirmations, but I'd say this was the bees knees. Ditto.. My wife is very happy about the patch too. :) Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
