Re: Unable to shutdown
This sounds like a "create PR and make noise until it's fixed" issue. :-) green drives are only going to get more prevalent.. Adrian On 27 August 2011 12:51, Kevin Oberman wrote: > I've run into an odd problem with dismounting file systems on a > Seagate Expansion portable > USB drive. Running 8-stable on an amd64 system and with two FAT32 > (msdosfs) file systems > on the drive. > > The drive is "green" and spins down when idle. If an attempt is made > to shutdown the > system while the drive is spun down, the system goes through the usual > shutdown including > flushing all buffer out to disk, but when the final disk access to > mark the file systems as > clean, the drive never spins up and the system hangs until it is > powered down. I've found no > way to avoid this other then to remember to access the disk and cause > it to spin up before > shutting down. > > If I attempt to unmount the file systems when the drive is shut down. > the same thing > happens, but I can recover as the second file system is still mounted > and an ls(1) to that file > system will cause the disk to spin up and everything is fine. > > This looks like a bug, but I don't see why the unmounting of an > msdosfs system does not > spin up the drive. It's clearly hanging on some operation that is not > spinning up the drive, > but does block. > > Any ideas what is going on? Possible fix? > -- > R. Kevin Oberman, Network Engineer - Retired > E-mail: kob6...@gmail.com > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: sigwait return 4
On Thu, Aug 25, 2011 at 12:29:29AM +0300, Kostik Belousov wrote: > On Wed, Aug 24, 2011 at 10:56:09PM +0200, Jilles Tjoelker wrote: > > sigwait() was fixed not to return EINTR in 9-current in r212405 (fixed > > up in r219709). The discussion started at > > http://lists.freebsd.org/pipermail/freebsd-threads/2010-September/004892.html > > > > Solaris is simply wrong in the same way we were wrong. Although POSIX > > may not be as clear on this as one may like, its intention is clear and > > additionally not returning EINTR reduces subtle portability problems. > Can you, please, describe why do you consider the behaviour prohibiting > return of EINTR reasonable ? I do consider that the Solaris behaviour is > useful. Applications need to cope with EINTR returns (usually by retrying the call); if they do not do this, bugs arise in uncommon cases. In the case of sigwait(), applications do not really need EINTR: they can include the respective signal into the signal set and do the work inline that was originally in the signal handler. This might require additional pthread_sigmask() calls. This also fixes the race condition almost always associated with EINTR. Historically, this is because sigwait() came with POSIX threads, which also explains why it returns an error number rather than setting errno. The threads group considered EINTR errors not useful enough, given that they may lead to subtle bugs. This is fully standardized for functions like pthread_cond_wait() and pthread_mutex_lock(). In the case of sigwait(), it also plays a role that glibc has decided not to return EINTR, so that returning EINTR may lead to subtle bugs appearing on FreeBSD in software originally written for GNU/Linux. The functions sigwaitinfo() and sigtimedwait() came with POSIX realtime and therefore follow different conventions. -- Jilles Tjoelker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: sigwait return 4
On Sat, Aug 27, 2011 at 04:25:36PM +0200, Jilles Tjoelker wrote:
> On Thu, Aug 25, 2011 at 12:29:29AM +0300, Kostik Belousov wrote:
> > On Wed, Aug 24, 2011 at 10:56:09PM +0200, Jilles Tjoelker wrote:
> > > sigwait() was fixed not to return EINTR in 9-current in r212405 (fixed
> > > up in r219709). The discussion started at
> > > http://lists.freebsd.org/pipermail/freebsd-threads/2010-September/004892.html
> > >
> > > Solaris is simply wrong in the same way we were wrong. Although POSIX
> > > may not be as clear on this as one may like, its intention is clear and
> > > additionally not returning EINTR reduces subtle portability problems.
>
> > Can you, please, describe why do you consider the behaviour prohibiting
> > return of EINTR reasonable ? I do consider that the Solaris behaviour is
> > useful.
>
> Applications need to cope with EINTR returns (usually by retrying the
> call); if they do not do this, bugs arise in uncommon cases.
>
> In the case of sigwait(), applications do not really need EINTR: they
> can include the respective signal into the signal set and do the work
> inline that was originally in the signal handler. This might require
> additional pthread_sigmask() calls. This also fixes the race condition
> almost always associated with EINTR.
>
> Historically, this is because sigwait() came with POSIX threads, which
> also explains why it returns an error number rather than setting errno.
> The threads group considered EINTR errors not useful enough, given that
> they may lead to subtle bugs. This is fully standardized for functions
> like pthread_cond_wait() and pthread_mutex_lock().
>
> In the case of sigwait(), it also plays a role that glibc has decided
> not to return EINTR, so that returning EINTR may lead to subtle bugs
> appearing on FreeBSD in software originally written for GNU/Linux.
>
> The functions sigwaitinfo() and sigtimedwait() came with POSIX realtime
> and therefore follow different conventions.
I think I finally realized what was the problem Slawa searched the
fix for. The fix from r212405 indeed does not allow EINTR to be returned
from the sigwait() for new libc, but it still leaves the compat libc
and libthr with EINTR.
Below is the patch that I provided to Slawa to handle EINTR condition
in kernel. The meat is in kern_sig.c two lines, everything else is
the r212405 revert.
diff --git a/lib/libc/sys/Makefile.inc b/lib/libc/sys/Makefile.inc
index fe5061d..aa0959b 100644
--- a/lib/libc/sys/Makefile.inc
+++ b/lib/libc/sys/Makefile.inc
@@ -24,9 +24,6 @@ SRCS+=${SYSCALL_COMPAT_SRCS}
NOASM+=${SYSCALL_COMPAT_SRCS:S/.c/.o/}
PSEUDO+= _fcntl.o
.endif
-SRCS+= sigwait.c
-NOASM+= sigwait.o
-PSEUDO+= _sigwait.o
# Add machine dependent asm sources:
SRCS+=${MDASM}
diff --git a/lib/libc/sys/Symbol.map b/lib/libc/sys/Symbol.map
index 095751a..2ba1f8f 100644
--- a/lib/libc/sys/Symbol.map
+++ b/lib/libc/sys/Symbol.map
@@ -937,7 +937,6 @@ FBSDprivate_1.0 {
_sigtimedwait;
__sys_sigtimedwait;
_sigwait;
- __sigwait;
__sys_sigwait;
_sigwaitinfo;
__sys_sigwaitinfo;
diff --git a/lib/libc/sys/sigwait.c b/lib/libc/sys/sigwait.c
deleted file mode 100644
index 2fdffdd..000
--- a/lib/libc/sys/sigwait.c
+++ /dev/null
@@ -1,46 +0,0 @@
-/*-
- * Copyright (c) 2010 davi...@freebsd.org
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *notice, this list of conditions and the following disclaimer in the
- *documentation and/or other materials provided with the distribution.
- *
- * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-#include
-__FBSDID("$FreeBSD$");
-
-#include
-#include
-
-int __sys_sigwait(const sigset_t * restrict, int * restrict);
-
-__weak_reference(__sigwait, sigwait);
-
-int
-__sigwait(const sigset_t * restrict set, int * restrict sig)
-{
- int ret;
-
- /* POSIX does not allow EINTR to be returned */
- do {
- ret =
portsnap doesn't update INDEX-9?
Hi, I just upgraded to -CURRENT two weeks ago (and did a clean install at work last week). Is it normal if /usr/ports/INDEX-9 doesn't update after running portsnap? INDEX-7 and INDEX-8 are updated automatically. Ronald. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Unable to shutdown
This sounds like it may have the same underlying cause as an issue I've been experiencing. Steps to reproduce: 1) Mount filesystem (Seagate 2TB USB disk) 2) wait a while, so the drive spins down 3) cd to a directory off the root of the mount point (the thing we're looking for here is a directory that is already in the filesystem buffer cache because of the filesystem mount). We want a directory that is not empty. 4) ls 5) ls will hang for a while as the drive spins up (this is to be expected) 6) ls returns nothing We now have a problem. The kernel thinks the directory is empty, even when its not. The drive is spun up now, and the rest of the filesystem will function normally, but that one directory will be considered empty by the kernel until it has reason to interact with disk (which means writing to the directory). Once the directory is written, its now corrupt. My guess is that there is something in the USB subsystem that doesn't deal well with the longer times necessary for bigger drives to spin back up (this is not a problem on 1TB drives). A workaround is to have little script that does a dd from the raw device to /dev/null before attempting to access the drive - this will ensure that its spun up. Needless to say, this doesn't work at all well for some production operations (e.g. rsync backup to USB disk), where disk I/O can cease for long enough for the drive to spin down in the middle of the job. --eli On 8/26/11 9:51 PM, Kevin Oberman wrote: I've run into an odd problem with dismounting file systems on a Seagate Expansion portable USB drive. Running 8-stable on an amd64 system and with two FAT32 (msdosfs) file systems on the drive. The drive is "green" and spins down when idle. If an attempt is made to shutdown the system while the drive is spun down, the system goes through the usual shutdown including flushing all buffer out to disk, but when the final disk access to mark the file systems as clean, the drive never spins up and the system hangs until it is powered down. I've found no way to avoid this other then to remember to access the disk and cause it to spin up before shutting down. If I attempt to unmount the file systems when the drive is shut down. the same thing happens, but I can recover as the second file system is still mounted and an ls(1) to that file system will cause the disk to spin up and everything is fine. This looks like a bug, but I don't see why the unmounting of an msdosfs system does not spin up the drive. It's clearly hanging on some operation that is not spinning up the drive, but does block. Any ideas what is going on? Possible fix? -- Eli DartNOC: (510) 486-7600 ESnet Network Engineering Group (AS293) (800) 333-7638 Lawrence Berkeley National Laboratory PGP Key fingerprint = C970 F8D3 CFDD 8FFF 5486 343A 2D31 4478 5F82 B2B3 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: portsnap doesn't update INDEX-9?
On Sat, 27 Aug 2011 18:21:43 +0200, Ronald Klop wrote: Hi, I just upgraded to -CURRENT two weeks ago (and did a clean install at work last week). Is it normal if /usr/ports/INDEX-9 doesn't update after running portsnap? INDEX-7 and INDEX-8 are updated automatically. Ronald. http://www.freebsd.org/cgi/query-pr.cgi?pr=149232 --- Crap. First search, then search again, then post to the mailinglist. Not the other way around. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
usb question
This might sound stupid, but I want to be sure and not recompile again. To have usb keyboard working I had to add usb stack to the kernel. In a hurry I put all uhci, ohci and ehci, with ukbd also. What of this in necessary for kb? I suppose ehci and ukbd. Btw, after usb addage, I have strange 3 seconds freeze in X, once it's up. Not at the start, but some 2-5 minutes later. Branch 8. Best regrads Zoran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
