Re: Hung kernel from sysv semaphore semu_list corruption
On Wed, Mar 07, 2007 at 06:07:31PM -0500, Ed Maste wrote:
Nightly tests on our 6.1-based installation using pgsql have resulted in
a number of kernel hangs, due to a corrupt semu_list (the list ended up
with a loop).
It seems there are a few holes in the locking in the semaphore code. The
issue we've encountered comes from semexit_myhook. It obtains a pointer
to a list element after acquiring SEMUNDO_LOCK, and after dropping the
lock manipulates the next pointer to remove the element from the list.
The fix below solves our current problem. Any comments?
--- RELENG_6/src/sys/kern/sysv_sem.cTue Jun 7 01:03:27 2005
+++ swbuild_plt_boson/src/sys/kern/sysv_sem.c Tue Mar 6 16:13:45 2007
@@ -1259,16 +1259,17 @@
struct proc *p;
{
struct sem_undo *suptr;
- struct sem_undo **supptr;
/*
* Go through the chain of undo vectors looking for one
* associated with this process.
*/
SEMUNDO_LOCK();
- SLIST_FOREACH_PREVPTR(suptr, supptr, semu_list, un_next) {
- if (suptr-un_proc == p)
+ SLIST_FOREACH(suptr, semu_list, un_next) {
+ if (suptr-un_proc == p) {
+ SLIST_REMOVE(semu_list, suptr, sem_undo, un_next);
this is wrong.. you cannot remove element from a *LIST when its iterated using
*LIST_FOREACH.
Use *LIST_FOREACH_SAFE instead...
thnx for the patch!
roman
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
harddrive no memory ---FreeBSD scenario
If I had say a 15k rpm drive, would it be possible to configure the FreeBSD kernel to not use system memory and ONLY the hard drive for caching instructions and executing operations? Can FreeBSD be built to run on a system memory free system (can we also circumvent the system cache for that matter), if not is it very difficult to make it run on such a systemme. regardz, ~Rudy _ [EMAIL PROTECTED]% ---_ http://www.[1]rudyrockstar.com -_-__--- -- - ---CELLY--678.984.3831: RiP 1997 -2004 -AIM:rudyrockstar- --- ---- -ICQ:6636643-- --- -- -- --- -YahoO:rudyrockstar- --- - -MSN:[EMAIL PROTECTED] ~~~!~!~!~~~!~~~~~~ _ [2]Find what you need at prices youll love. Compare products and save at MSN® Shopping. References 1. http://www.rudyrockstar.com/ 2. http://g.msn.com/8HMAENUS/2728??PS=47575 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: harddrive no memory ---FreeBSD scenario
2007/3/8, Rudy Rockstar [EMAIL PROTECTED]: If I had say a 15k rpm drive, would it be possible to configure the FreeBSD kernel to not use system memory and ONLY the hard drive for caching instructions and executing operations? No, probably not. Also, a 15K RPM drive still isn't very fast (compared to RAM) Can FreeBSD be built to run on a system memory free system (can we also circumvent the system cache for that matter), if not is it very difficult to make it run on such a systemme. Apart from wondering how you're getting the motherboard to get past POST without RAM, I'm wondering how you'd get the bootloader and kernel to load in a RAM-less system. You could probably do it for a system with a minimal amount of RAM and let (most) everything run in swap, but that's just going to be ridiculously slow. regardz, ~Rudy Any particular reason you're looking into doing this? Kind regards, Devon H. O'Dell _ [EMAIL PROTECTED]% ---_ http://www.[1]rudyrockstar.com -_-__--- -- - ---CELLY--678.984.3831: RiP 1997 -2004 -AIM:rudyrockstar- --- ---- -ICQ:6636643-- --- -- -- --- -YahoO:rudyrockstar- --- - -MSN:[EMAIL PROTECTED] ~~~!~!~!~~~!~~~~~~ _ [2]Find what you need at prices youll love. Compare products and save at MSN(r) Shopping. References 1. http://www.rudyrockstar.com/ 2. http://g.msn.com/8HMAENUS/2728??PS=47575 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any 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 based /usr prevents normal startup due to slow net init
Mike Meyer wrote: No, it will fail immediately (as seen above) if it can't resolve the server name. The only way to fix this is to modify mount_nfs to sleep and retry in such cases. The *current* sleep-and-retry code is in the NFS mount code in the kernel, which doesn't come into play until after DNS lookup. In that case, there's a bug in the mount_nfs man page, which just says that it keeps retrying until it succeeds. PR #110062 Given that it sounds like a potential workaround is to use the machines IP instead of name until this is fixed, thanks for the info guys. 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: Hung kernel from sysv semaphore semu_list corruption
On Thu, Mar 08, 2007 at 10:55:22AM +0100, Divacky Roman wrote:
this is wrong.. you cannot remove element from a *LIST when its iterated
using *LIST_FOREACH.
Use *LIST_FOREACH_SAFE instead...
We're not freeing the item in the loop so it would work unless
QUEUE_MACRO_DEBUG is turned on to intentionally trash the link
pointer on _REMOVE. You're right though it's not the correct approach.
There's an efficiency issue with the previous patch anyhow in that
SLIST_REMOVE walks the list again to find the element to remove.
How about the patch below instead:
Index: sysv_sem.c
===
RCS file: /usr/cvs/src/sys/kern/sysv_sem.c,v
retrieving revision 1.85
diff -u -r1.85 sysv_sem.c
--- sysv_sem.c 22 Oct 2006 11:52:13 - 1.85
+++ sysv_sem.c 8 Mar 2007 14:22:43 -
@@ -1301,8 +1301,10 @@
*/
SEMUNDO_LOCK();
SLIST_FOREACH_PREVPTR(suptr, supptr, semu_list, un_next) {
- if (suptr-un_proc == p)
+ if (suptr-un_proc == p) {
+ *supptr = SLIST_NEXT(suptr, un_next);
break;
+ }
}
SEMUNDO_UNLOCK();
@@ -1362,8 +1364,9 @@
* Deallocate the undo vector.
*/
DPRINTF((removing vector\n));
+ SEMUNDO_LOCK();
suptr-un_proc = NULL;
- *supptr = SLIST_NEXT(suptr, un_next);
+ SEMUNDO_UNLOCK();
}
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: harddrive no memory ---FreeBSD scenario
Hi! Apart from wondering how you're getting the motherboard to get past POST without RAM, I'm wondering how you'd get the bootloader and [...] The guys at Linux/OpenBIOS did some Cache-as-RAM stuff. Maybe you can also put (burn) the kernel directly into the BIOS chip and bott with that kernel. This is just an idea out of my head - nothing tested and no research done in this field. :-) Cheers Markus ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: harddrive no memory ---FreeBSD scenario
Markus Boelter wrote: Hi! Apart from wondering how you're getting the motherboard to get past POST without RAM, I'm wondering how you'd get the bootloader and [...] The guys at Linux/OpenBIOS did some Cache-as-RAM stuff. Maybe you can also put (burn) the kernel directly into the BIOS chip and bott with that kernel. This is just an idea out of my head - nothing tested and no research done in this field. :-) A modern CPU with 4Mb of cache and no ram has more ram than my first system. If you wanted to you might be able to get FreeBSD 1.1 up in such an environment. (Just no DMA capability, so no floppies). Cheers Markus ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any 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: harddrive no memory ---FreeBSD scenario
Marcus, Thanks! A chip level loading of the core kernel would be the only way. So its not possible todo without a completly new hardware infrastructre design. - I'm wanting todo this because computers are too slow. regardz, ~Rudy _ [EMAIL PROTECTED]% ---_ http://www.[1]rudyrockstar.com -_-__--- -- - ---CELLY--678.984.3831: RiP 1997 -2004 -AIM:rudyrockstar- --- ---- -ICQ:6636643-- --- -- -- --- -YahoO:rudyrockstar- --- - -MSN:[EMAIL PROTECTED] ~~~!~!~!~~~!~~~~~~ __ From: Markus Boelter [EMAIL PROTECTED] To: Devon H. O'Dell [EMAIL PROTECTED] CC: Rudy Rockstar [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: harddrive no memory ---FreeBSD scenario Date: Thu, 8 Mar 2007 15:53:18 +0100 Hi! Apart from wondering how you're getting the motherboard to get past POST without RAM, I'm wondering how you'd get the bootloader and [...] The guys at Linux/OpenBIOS did some Cache-as-RAM stuff. Maybe you can also put (burn) the kernel directly into the BIOS chip and bott with that kernel. This is just an idea out of my head - nothing tested and no research done in this field. :-) Cheers Markus _ [2]Win a Zunemake MSN® your homepage for your chance to win! References 1. http://www.rudyrockstar.com/ 2. http://g.msn.com/8HMBENUS/2743??PS=47575 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: harddrive no memory ---FreeBSD scenario
In [EMAIL PROTECTED], Rudy wrote: A chip level loading of the core kernel would be the only way. So its not possible todo without a completly new hardware infrastructre design. - I'm wanting todo this because computers are too slow. You need to learn a little more about the parts of a computer. Perhaps go to Google groups, and read comp.arch for a couple of months, making sure you understand all of the references. Disk drives are about 6 orders of magnitude (1,000,000x) slower than DDR memory. It takes a few tens of nanoseconds to read a random address from DDR, a few tens of milliseconds to read a random address from a disk. Note that DDR isn't the fastest memory in the system, either -- there are the L1 and L2 (and sometimes L3) caches as well. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.5 / 37N 20' 15.3 Internet: steve @ Watt.COM Whois: SW32-ARIN Free time? There's no such thing. It just comes in varying prices... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS based /usr prevents normal startup due to slow net init
Steven Hartland wrote: Given that it sounds like a potential workaround is to use the machines IP instead of name until this is fixed, thanks for the info guys. For as long as I can remember, it's been a Best Practice to have entries for critical NFS servers in /etc/hosts. Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS based /usr prevents normal startup due to slow net init
Doug Barton wrote: Steven Hartland wrote: Given that it sounds like a potential workaround is to use the machines IP instead of name until this is fixed, thanks for the info guys. For as long as I can remember, it's been a Best Practice to have entries for critical NFS servers in /etc/hosts. Hmm sounds more like a workaround for something thats not been fixed to me but thats just my opinion. 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]
