Re: Critical Sections for userland.
Alfred Perlstein <[EMAIL PROTECTED]> writes: > Hi guys, we need critical sections for userland here. > > This is basically to avoid a process being switched out while holding > a user level spinlock. Yeah, great idea, cooperative multitasking is the new black! 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: Critical Sections for userland.
Alfred Perlstein <[EMAIL PROTECTED]> writes: > Do you have: > > a) Evidence or a paper to prove that this is a bad idea? I need evidence or a paper to prove that it is a bad idea to allow a userland process to hold the CPU indefinitely? > b) A helpful suggestion? Why don't you tell us what you're actually trying to do, so we can tell you how to do it. > c) An obvious understanding of the problem? I'll show you mine if you show me yours. 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: Critical Sections for userland.
* Dag-Erling Sm??rgrav <[EMAIL PROTECTED]> [071004 02:05] wrote: > Alfred Perlstein <[EMAIL PROTECTED]> writes: > > Hi guys, we need critical sections for userland here. > > > > This is basically to avoid a process being switched out while holding > > a user level spinlock. > > Yeah, great idea, cooperative multitasking is the new black! Do you have: a) Evidence or a paper to prove that this is a bad idea? b) A helpful suggestion? c) An obvious understanding of the problem? If not then perhaps one ought to restrict snarky comments to private mail where they will be at least somewhat appreciated. -- - Alfred Perlstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
* Dag-Erling Sm??rgrav <[EMAIL PROTECTED]> [071004 03:01] wrote: > Alfred Perlstein <[EMAIL PROTECTED]> writes: > > Do you have: > > > > a) Evidence or a paper to prove that this is a bad idea? > > I need evidence or a paper to prove that it is a bad idea to allow a > userland process to hold the CPU indefinitely? > > > b) A helpful suggestion? > > Why don't you tell us what you're actually trying to do, so we can tell > you how to do it. > > > c) An obvious understanding of the problem? > > I'll show you mine if you show me yours. It's not worth my time to engage someone with your mind set, you posses neither the technical nor interpersonal skill to be useful to me. For context see my replies in this thread to Kip Macy which explains how one deals with the false-problems you mention. For evidence of existing, however suboptimal, run-to-completion systems see the RTPRIO scheduling knobs. -- - Alfred Perlstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
Alfred Perlstein <[EMAIL PROTECTED]> writes: > It's not worth my time to engage someone with your mind set, you > posses neither the technical nor interpersonal skill to be useful > to me. This could be the beginning of a wonderful friendship... > For context see my replies in this thread to Kip Macy which explains > how one deals with the false-problems you mention. I did read them, and I'm not convinced at all. You are asking for a large amount of complexity to be added to the system, but you refuse to tell us what you're actually trying to do. Are you worried that we might actually figure out a way to do it without raping the scheduler? 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]"
Recommended S-ATA controller?
What PCI 32/33 S-ATA controller is recommended for a x86/FreeBSD-6 system that is stable and reliable in terms of hardware design, and software drivers ? My current Promise card is said to abuse PCI burst mode, in essence it will exploit to tight timing margins. And the motherboard doesn't have any option to disable pci-burst. This gives intermittent errors. sos@ comments on SII chipsets isn't encourageing either. /P ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
Quoting Alfred Perlstein, who wrote on Thu, Oct 04, 2007 at 03:19:02AM -0700 .. > * Dag-Erling Sm??rgrav <[EMAIL PROTECTED]> [071004 03:01] wrote: > > Alfred Perlstein <[EMAIL PROTECTED]> writes: > > > Do you have: > > > > > > a) Evidence or a paper to prove that this is a bad idea? > > > > I need evidence or a paper to prove that it is a bad idea to allow a > > userland process to hold the CPU indefinitely? > > > > > b) A helpful suggestion? > > > > Why don't you tell us what you're actually trying to do, so we can tell > > you how to do it. > > > > > c) An obvious understanding of the problem? > > > > I'll show you mine if you show me yours. > > It's not worth my time to engage someone with your mind set, you > posses neither the technical nor interpersonal skill to be useful > to me. Gentlemen... please? -- Wilko Bulte [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
SCSI and SAN
Hello, How to distinguish if /dev/da* devices are internal scsi drivers or LUNs of external SAN? Is there any tool? Thanks for any advice. Sharad Chandra ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SCSI and SAN
Sharad Chandra wrote: Hello, How to distinguish if /dev/da* devices are internal scsi drivers or LUNs of external SAN? camcontrol devlist -v Might help you.. Eric ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
On Thu, 4 Oct 2007, Alfred Perlstein wrote: * Dag-Erling Sm??rgrav <[EMAIL PROTECTED]> [071004 03:01] wrote: Alfred Perlstein <[EMAIL PROTECTED]> writes: Do you have: a) Evidence or a paper to prove that this is a bad idea? I need evidence or a paper to prove that it is a bad idea to allow a userland process to hold the CPU indefinitely? b) A helpful suggestion? Why don't you tell us what you're actually trying to do, so we can tell you how to do it. c) An obvious understanding of the problem? I'll show you mine if you show me yours. It's not worth my time to engage someone with your mind set, you posses neither the technical nor interpersonal skill to be useful to me. For context see my replies in this thread to Kip Macy which explains how one deals with the false-problems you mention. For evidence of existing, however suboptimal, run-to-completion systems see the RTPRIO scheduling knobs. His point about telling us what you're really doing, so we might off other ways to do it is valid. We don't know why you are using homegrown user-level spinlocks instead of pthread mutexes. Priority ceiling mutexes and running in SCHED_RR or SCHED_FIFO is really what tries to address this problem, at least from the vague desciption you give. If you have tried this and they don't work correctly, then one solution is to fix them ;-) -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Recommended S-ATA controller?
Peter B wrote: What PCI 32/33 S-ATA controller is recommended for a x86/FreeBSD-6 system that is stable and reliable in terms of hardware design, and software drivers ? My current Promise card is said to abuse PCI burst mode, in essence it will exploit to tight timing margins. And the motherboard doesn't have any option to disable pci-burst. This gives intermittent errors. sos@ comments on SII chipsets isn't encourageing either. /P 3ware 7000 or 9000 series are working fine in my 5.4 box Cheers Richard ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SCSI and SAN
Quoting Sharad Chandra, who wrote on Thu, Oct 04, 2007 at 05:25:00PM +0530 .. > Hello, > > How to distinguish if /dev/da* devices are internal scsi drivers or > LUNs of > external SAN? > > Is there any tool? /var/run/dmesg.boot I would think. And then you would need to map things manually. -- Wilko Bulte [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: How to enable more than 256 pty's?
On 2007-10-02 15:41, Vlad GALU <[EMAIL PROTECTED]> wrote: > On 10/2/07, Dag-Erling Sm?rgrav <[EMAIL PROTECTED]> wrote: > > "Vlad GALU" <[EMAIL PROTECTED]> writes: > > > The symptoms were exhibited even with rev. 1.16. I've CC'ed him so > > > he can catch up with the thread. > > > > Which symptoms? I can no longer reproduce the hang-on-close bug. > > Strangely enough, me neither. In his case, allocated pts' wouldn't > get deallocated once the sessions ended. There was an old bug, which caused pts consumers to get stuck in "devdrn". This has been fixed, AFAICT, a long time ago. At least, I can't reproduce it any more with the usual tests: * Closing xterm windows. * Closing telnet sessions. * Exiting from screen(1) windows. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to enable more than 256 pty's?
On 10/4/07, Giorgos Keramidas <[EMAIL PROTECTED]> wrote: > On 2007-10-02 15:41, Vlad GALU <[EMAIL PROTECTED]> wrote: > > On 10/2/07, Dag-Erling Sm?rgrav <[EMAIL PROTECTED]> wrote: > > > "Vlad GALU" <[EMAIL PROTECTED]> writes: > > > > The symptoms were exhibited even with rev. 1.16. I've CC'ed him so > > > > he can catch up with the thread. > > > > > > Which symptoms? I can no longer reproduce the hang-on-close bug. > > > > Strangely enough, me neither. In his case, allocated pts' wouldn't > > get deallocated once the sessions ended. > > There was an old bug, which caused pts consumers to get stuck in > "devdrn". This has been fixed, AFAICT, a long time ago. At least, I > can't reproduce it any more with the usual tests: > > * Closing xterm windows. > > * Closing telnet sessions. > > * Exiting from screen(1) windows. > Weird. 3 people on this thread already saw the symptoms :( > -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to enable more than 256 pty's?
On 2007-10-04 18:05, Vlad GALU <[EMAIL PROTECTED]> wrote:
>On 10/4/07, Giorgos Keramidas <[EMAIL PROTECTED]> wrote:
>>On 2007-10-02 15:41, Vlad GALU <[EMAIL PROTECTED]> wrote:
>>>On 10/2/07, Dag-Erling Sm?rgrav <[EMAIL PROTECTED]> wrote:
"Vlad GALU" <[EMAIL PROTECTED]> writes:
> The symptoms were exhibited even with rev. 1.16. I've CC'ed him so
> he can catch up with the thread.
Which symptoms? I can no longer reproduce the hang-on-close bug.
>>>
>>> Strangely enough, me neither. In his case, allocated pts' wouldn't
>>> get deallocated once the sessions ended.
>>
>> There was an old bug, which caused pts consumers to get stuck in
>> "devdrn". This has been fixed, AFAICT, a long time ago. At least, I
>> can't reproduce it any more with the usual tests:
>>
>> * Closing xterm windows.
>>
>> * Closing telnet sessions.
>>
>> * Exiting from screen(1) windows.
>
> Weird. 3 people on this thread already saw the symptoms :(
It must be a different problem, then. I used to have a local patch
which reverted the devdrn wait in kern_conf.c:destroy_devl() near
the lines:
753 while (dev->si_threadcount != 0) {
754 /* Use unique dummy wait ident */
755 msleep(&csw, &devmtx, PRIBIO, "devdrn", hz / 10);
756 }
but the original problem I was seeing seems to have been fixed.
At least, I can't reproduce it was easily anymore...
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SCSI and SAN
Sharad Chandra wrote: Hello, How to distinguish if /dev/da* devices are internal scsi drivers or LUNs of external SAN? Is there any tool? Thanks for any advice. Sharad Chandra ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" Once you have identified the devices (using methods already suggested) you may want to take a look at geom_label to give friendly names to your partitions that are more descriptive than the da... names you have at the moment. Tom ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
* Wilko Bulte <[EMAIL PROTECTED]> [071004 04:15] wrote: > Quoting Alfred Perlstein, who wrote on Thu, Oct 04, 2007 at 03:19:02AM -0700 > .. > > * Dag-Erling Sm??rgrav <[EMAIL PROTECTED]> [071004 03:01] wrote: > > > Alfred Perlstein <[EMAIL PROTECTED]> writes: > > > > Do you have: > > > > > > > > a) Evidence or a paper to prove that this is a bad idea? > > > > > > I need evidence or a paper to prove that it is a bad idea to allow a > > > userland process to hold the CPU indefinitely? > > > > > > > b) A helpful suggestion? > > > > > > Why don't you tell us what you're actually trying to do, so we can tell > > > you how to do it. > > > > > > > c) An obvious understanding of the problem? > > > > > > I'll show you mine if you show me yours. > > > > It's not worth my time to engage someone with your mind set, you > > posses neither the technical nor interpersonal skill to be useful > > to me. > > Gentlemen... please? I think that it would behoove us to explain to developers that perhaps helping the users instead of talking down to them would probably catch more flies. I'm really tired of being told what I need by people that do not understand what environment I'm coming from. By not fielding these annoying responses I come across as clueless or perhaps even satiated by the non-help, conversely by answering I am forced to play this game with people that I'm quite certain will not help me even if they are somehow satisfied by the intellectual or sadistic things they are trying to extract. Even after making it clear with Kip what is needed, I have two more developers toying/trolling/etc with me rather than helping me. Here is how I handle the "holy crap your idea is hair-brained", I simply say, "well if you do that, you'll be worse off because of X, Y or Z and missing out on feature A, B or C, buuut, here's how you might accomplish that" So not only do I come across as smart, but also somewhat helpful. I think we should all know that too much of the former without the latter does not paint us in a good light. thank you, -- - Alfred Perlstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
* Daniel Eischen <[EMAIL PROTECTED]> [071004 06:05] wrote: > > His point about telling us what you're really doing, so we might > off other ways to do it is valid. > > We don't know why you are using homegrown user-level spinlocks > instead of pthread mutexes. Priority ceiling mutexes and running > in SCHED_RR or SCHED_FIFO is really what tries to address this > problem, at least from the vague desciption you give. If you > have tried this and they don't work correctly, then one solution > is to fix them ;-) First of all we're stuck on 6.x, how is threads on this platform? Second off we are contending against other devices in the system that do not run FreeBSD, How do we address that? -- - Alfred Perlstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
* Dag-Erling Sm??rgrav <[EMAIL PROTECTED]> [071004 03:28] wrote: > Alfred Perlstein <[EMAIL PROTECTED]> writes: > > It's not worth my time to engage someone with your mind set, you > > posses neither the technical nor interpersonal skill to be useful > > to me. > > This could be the beginning of a wonderful friendship... > > > For context see my replies in this thread to Kip Macy which explains > > how one deals with the false-problems you mention. > > I did read them, and I'm not convinced at all. You are asking for a > large amount of complexity to be added to the system, but you refuse to > tell us what you're actually trying to do. Are you worried that we > might actually figure out a way to do it without raping the scheduler? As already explained by Kip, the goal is to avoid switching out a lock owner due to quantum exhaustion at an inopportune time. We have needs that may wind up not being applicable to FreeBSD, however if we can accomplish this in a way that is not too awful we would likely be sharing the code, no matter how annoying you make it. :) -- - Alfred Perlstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
On Thu, 4 Oct 2007, Alfred Perlstein wrote: * Daniel Eischen <[EMAIL PROTECTED]> [071004 06:05] wrote: His point about telling us what you're really doing, so we might off other ways to do it is valid. We don't know why you are using homegrown user-level spinlocks instead of pthread mutexes. Priority ceiling mutexes and running in SCHED_RR or SCHED_FIFO is really what tries to address this problem, at least from the vague desciption you give. If you have tried this and they don't work correctly, then one solution is to fix them ;-) First of all we're stuck on 6.x, how is threads on this platform? I don't _think_ there is anything prohibitive of MFC'ing any libthr bug fixes into 6.x. I would have thought that you would have tried libthr on 6.x and possibly offered up "libthr performance sucks for me, and here's why" :-) You should probably ask David Xu about priority ceiling mutexes work on 6.x. Second off we are contending against other devices in the system that do not run FreeBSD, How do we address that? If you're running in real-time, then you are suppose to have priority over anything else except for ithreads. How much interrupt load is on your system and is ithread processing really going to impact you? If everything is working correctly and your thread that holds a priority ceiling mutex gets swapped out for an ithread, that thread should run again after the ithread. It shouldn't get swapped out for a different thread that doesn't also have its priority elevated (due to holding a similar mutex). I don't know if anyone other than possibly David Xu have tested SCHED_RR or SCHED_FIFO and priority ceiling mutexes, so they may not work as they're suppose to. -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
2007/10/3, Alfred Perlstein <[EMAIL PROTECTED]>: > * Daniel Eischen <[EMAIL PROTECTED]> [071002 19:46] wrote: > > On Tue, 2 Oct 2007, Alfred Perlstein wrote: > > > > >Hi guys, we need critical sections for userland here. > > > > > >This is basically to avoid a process being switched out while holding > > >a user level spinlock. > > > > Setting the scheduling class to real-time and using SCHED_FIFO > > and adjusting the thread priority around the lock doesn't work? > > Too heavy weight, we want to basically have this sort of code > in userland: > > /* assume single threaded process for now */ > static int is_critical; > > > > atomic_mutex_lock(); /* implies ++is_critical */ > ...do stuff... > atomic_mutex_unlock(); /* implies --is_critical */ > > We don't want two or more syscalls per lock operation. :) Basically, preemption in kernelspace is handled by using the td_critnest counter which should work in this way: - critical_enter() bumps td_critnest - if preemption is required or an ipi arrives and the operation is signalled with the td_owepreempt flag and will be deferred. - once critical_exit() is called the counter is decreased. If necessary (checking for td_critnest and td_owepreempt) the preemptive operation happens instantanely. It is all very fast and highly scalable as scope of operation is entirely per-thread so it doesn't require any lock. I think maybe you should use a very similar scheme to this. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
Attilio Rao wrote: 2007/10/3, Alfred Perlstein <[EMAIL PROTECTED]>: * Daniel Eischen <[EMAIL PROTECTED]> [071002 19:46] wrote: On Tue, 2 Oct 2007, Alfred Perlstein wrote: Hi guys, we need critical sections for userland here. This is basically to avoid a process being switched out while holding a user level spinlock. Setting the scheduling class to real-time and using SCHED_FIFO and adjusting the thread priority around the lock doesn't work? Too heavy weight, we want to basically have this sort of code in userland: /* assume single threaded process for now */ static int is_critical; atomic_mutex_lock(); /* implies ++is_critical */ ...do stuff... atomic_mutex_unlock(); /* implies --is_critical */ We don't want two or more syscalls per lock operation. :) Basically, preemption in kernelspace is handled by using the td_critnest counter which should work in this way: - critical_enter() bumps td_critnest - if preemption is required or an ipi arrives and the operation is signalled with the td_owepreempt flag and will be deferred. - once critical_exit() is called the counter is decreased. If necessary (checking for td_critnest and td_owepreempt) the preemptive operation happens instantanely. It is all very fast and highly scalable as scope of operation is entirely per-thread so it doesn't require any lock. I think maybe you should use a very similar scheme to this. Attilio I suggest that we map a per-thread page into the address space if it requests it. (and a per process page). The scheduler could look at it for behavioural hints when it is present. there are ways this could be done. it sort of dovetails into work other people have been considering.. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Critical Sections for userland.
On Oct 4, 2007, at 10:43 AM, Daniel Eischen wrote:
On Thu, 4 Oct 2007, Alfred Perlstein wrote:
* Daniel Eischen <[EMAIL PROTECTED]> [071004 06:05] wrote:
His point about telling us what you're really doing, so we might
off other ways to do it is valid.
We don't know why you are using homegrown user-level spinlocks
instead of pthread mutexes. Priority ceiling mutexes and running
in SCHED_RR or SCHED_FIFO is really what tries to address this
problem, at least from the vague desciption you give. If you
have tried this and they don't work correctly, then one solution
is to fix them ;-)
First of all we're stuck on 6.x, how is threads on this platform?
I don't _think_ there is anything prohibitive of MFC'ing
any libthr bug fixes into 6.x. I would have thought that
you would have tried libthr on 6.x and possibly offered up
"libthr performance sucks for me, and here's why" :-)
Alfred: The Hurricane team uses 1x1 threading on PowerPC
without problems.
The patch below fixes a NULL pointer dereference in the
POSIX priority cases:
diff -up /b/marcelm/freebsd/6.x/src/lib/libthr/thread/thr_mutex.c ./
thr_mutex.c
--- /b/marcelm/freebsd/6.x/src/lib/libthr/thread/thr_mutex.cSun
Jan 15 21:36:30 2006
+++ ./thr_mutex.c Sun Sep 9 20:58:20 2007
@@ -629,10 +629,14 @@ mutex_lock_common(struct pthread *curthr
/* Unlock the mutex structure: */
THR_LOCK_RELEASE(curthread, &(*m)-
>m_lock);
- clock_gettime(CLOCK_REALTIME, &ts);
- TIMESPEC_SUB(&ts2, abstime, &ts);
- ret = _thr_umtx_wait(&curthread-
>cycle, cycle,
-&ts2);
+ if (abstime != NULL) {
+ clock_gettime(CLOCK_REALTIME,
&ts);
+ TIMESPEC_SUB(&ts2, abstime,
&ts);
+ ret = _thr_umtx_wait
(&curthread->cycle,
+ cycle, &ts2);
+ } else
+ ret = _thr_umtx_wait
(&curthread->cycle,
+ cycle, NULL);
if (ret == EINTR)
ret = 0;
@@ -712,10 +716,14 @@ mutex_lock_common(struct pthread *curthr
/* Unlock the mutex structure: */
THR_LOCK_RELEASE(curthread, &(*m)-
>m_lock);
- clock_gettime(CLOCK_REALTIME, &ts);
- TIMESPEC_SUB(&ts2, abstime, &ts);
- ret = _thr_umtx_wait(&curthread-
>cycle, cycle,
- &ts2);
+ if (abstime != NULL) {
+ clock_gettime(CLOCK_REALTIME,
&ts);
+ TIMESPEC_SUB(&ts2, abstime,
&ts);
+ ret = _thr_umtx_wait
(&curthread->cycle,
+ cycle, &ts2);
+ } else
+ ret = _thr_umtx_wait
(&curthread->cycle,
+ cycle, NULL);
if (ret == EINTR)
ret = 0;
I don't know if anyone other than possibly David Xu have
tested SCHED_RR or SCHED_FIFO and priority ceiling mutexes,
so they may not work as they're suppose to.
We use it successfully with the above patch.
FYI,
--
Marcel Moolenaar
[EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FYI: 3Ware 9650 can cause data corruption
3ware 9650 in RAID6 mode with firmware version 3.08.00.004 seems to cause data corruption when rebuilding a single disc with raid6. http://www.webmasternetwork.se/f4t23551.html (Swedish) I thought this was serious enough for people to know. If another mailinglist is more appropiate for this kind of FYI then tell. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FYI: 3Ware 9650 can cause data corruption
Peter B wrote: 3ware 9650 in RAID6 mode with firmware version 3.08.00.004 seems to cause data corruption when rebuilding a single disc with raid6. http://www.webmasternetwork.se/f4t23551.html (Swedish) I thought this was serious enough for people to know. If another mailinglist is more appropiate for this kind of FYI then tell. This is a known issue with 3ware software v9.4.1.0 and 9.4.1.1 (firmware v3.08.00.004). 3ware released software v9.4.1.2 (firmware 3.08.02.005) that corrects the problem over three months ago and it has since been obsoleted by 9.4.1.3 and 9.5.0 (released earlier this week). In fact, the link you cite links to 3ware's advisory: http://www.3ware.com/support/UserDocs/RAID6-data-integrity-customer-notification_061907-FINAL.pdf While it is appreciated that you felt obligated to post this important bug notice, it would be even more appreciated if in the future, you would do a bit of research before clicking send. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
