kern/167447: zfs rename with forced options to unmount.

2012-04-30 Thread Marcelo Araujo 

>Number: 167447
>Category:   kern
>Synopsis:   zfs rename with forced options to unmount.
>Confidential:   no
>Severity:   non-critical
>Priority:   low
>Responsible:freebsd-bugs
>State:  open
>Quarter:
>Keywords:   
>Date-Required:
>Class:  change-request
>Submitter-Id:   current-users
>Arrival-Date:   Mon Apr 30 07:50:19 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Marcelo Araujo
>Release:10.0-CURRENT
>Organization:
FreeBSD
>Environment:
FreeBSD hosta 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r233530M: Mon Apr 23 
11:51:58 UTC 2012 araujo@hosta:/usr/obj/usr/src/sys/HOSTA  i386
>Description:
Now is possible to use zfs rename -f to perform a force unmount.
Based on Illumos-gate commit: a0cbef703c12 by Matt Ahrens.

>How-To-Repeat:
hosta# zfs rename -fp tank/oi tank/araujo
hosta# zfs list
NAME  USED  AVAIL  REFER  MOUNTPOINT
tank 20.4M  39.1G  1.69M  /tank
tank/araujo31K  39.1G31K  /tank/araujo
tank/jail  31K  39.1G31K  /tank/jail
tank/tank1   9.73M  39.1G  1.68M  /tank/tank1

>Fix:


Patch attached with submission follows:

diff -r cfd524f8839b cddl/contrib/opensolaris/cmd/zfs/zfs.8
--- a/cddl/contrib/opensolaris/cmd/zfs/zfs.8Sat Apr 28 23:13:09 2012 +
+++ b/cddl/contrib/opensolaris/cmd/zfs/zfs.8Mon Apr 30 04:42:55 2012 +
@@ -18,9 +18,10 @@
 .\" information: Portions Copyright [] [name of copyright owner]
 .\"
 .\" Copyright (c) 2010, Sun Microsystems, Inc. All Rights Reserved.
-.\" Copyright (c) 2011 by Delphix. All rights reserved.
+.\" Copyright (c) 2012 by Delphix. All rights reserved.
 .\" Copyright (c) 2012 Nexenta Systems, Inc. All Rights Reserved.
 .\" Copyright (c) 2011, Pawel Jakub Dawidek 
+.\" Copyright (c) 2012, Marcelo Araujo 
 .\"
 .\" $FreeBSD$
 .\"
@@ -81,7 +82,7 @@
 .Ar filesystem Ns | Ns Ar volume Ns | Ns Ar snapshot
 .Nm
 .Cm rename
-.Fl p
+.Fl fp
 .Ar filesystem Ns | Ns Ar volume
 .Ar filesystem Ns | Ns Ar volume
 .Nm
@@ -1646,6 +1647,7 @@
 .It Xo
 .Nm
 .Cm rename
+.Fl fp
 .Ar filesystem Ns | Ns Ar volume Ns | Ns Ar snapshot
 .Ar filesystem Ns | Ns Ar volume Ns | Ns Ar snapshot
 .Xc
@@ -1677,6 +1679,10 @@
 are automatically mounted according to the
 .Sy mountpoint
 property inherited from their parent.
+.It Fl f
+Force
+.Sy unmount
+any filesystems that need to be unmounted in the process.
 .It Fl u
 Do not remount file systems during rename. If a file system's
 .Sy mountpoint
diff -r cfd524f8839b cddl/contrib/opensolaris/cmd/zfs/zfs_main.c
--- a/cddl/contrib/opensolaris/cmd/zfs/zfs_main.c   Sat Apr 28 23:13:09 
2012 +
+++ b/cddl/contrib/opensolaris/cmd/zfs/zfs_main.c   Mon Apr 30 04:42:55 
2012 +
@@ -22,10 +22,11 @@
 /*
  * Copyright (c) 2005, 2010, Oracle and/or its affiliates. All rights reserved.
  * Copyright 2012 Nexenta Systems, Inc. All rights reserved.
- * Copyright (c) 2011 by Delphix. All rights reserved.
+ * Copyright (c) 2012 by Delphix. All rights reserved.
  * Copyright (c) 2011-2012 Pawel Jakub Dawidek .
  * All rights reserved.
  * Copyright (c) 2011 Martin Matuska . All rights reserved.
+ * Copyright (c) 2012 Marcelo Araujo . All rights reserved.
  */
 
 #include 
@@ -256,9 +257,9 @@
"snapshot>\n"
"\treceive [-vnFu] [-d | -e] \n"));
case HELP_RENAME:
-   return (gettext("\trename  "
+   return (gettext("\trename [-f]  "
"\n"
-   "\trename -p  \n"
+   "\trename [-f] -p  \n"
"\trename -r  \n"
"\trename -u [-p]  "));
case HELP_ROLLBACK:
@@ -3091,8 +3092,8 @@
 }
 
 /*
- * zfs rename  
- * zfs rename -p  
+ * zfs rename [-f]  
+ * zfs rename [-f] -p  
  * zfs rename -r  
  * zfs rename -u [-p]  
  *
@@ -3110,9 +3111,10 @@
int ret = 0;
int types;
boolean_t parents = B_FALSE;
+   boolean_t force_unmount = B_FALSE;
 
/* check options */
-   while ((c = getopt(argc, argv, "pru")) != -1) {
+   while ((c = getopt(argc, argv, "pruf")) != -1) {
switch (c) {
case 'p':
parents = B_TRUE;
@@ -3123,6 +3125,9 @@
case 'u':
flags.nounmount = B_TRUE;
break;
+   case 'f':
+   force_unmount = B_TRUE;
+   break;
case '?':
default:
(void) fprintf(stderr, gettext("invalid option '%c'\n"),
@@ -3185,7 +3190,7 @@
return (1);
}
 
-   ret = (zfs_rename(zhp, argv[1], flags) != 0);
+   ret = (zfs_rename(zhp, argv[1], flags, force_unmount) != 0);
 
zfs_close(zhp);
return (ret);
diff -r cfd524f8839b cddl/contrib/opensolaris/lib/libzfs/common/libzfs.h
--- a/cddl/contrib/opensolaris/lib/libzfs/common/libzfs.h   Sat Apr 28 
23:13:09 2012 +
+++ b/cddl/contrib/opensolaris/lib/libzfs/co

Re: kern/167447: zfs rename with forced options to unmount.

2012-04-30 Thread araujo 
Synopsis: zfs rename with forced options to unmount.

Responsible-Changed-From-To: freebsd-bugs->freebsd-fs
Responsible-Changed-By: araujo
Responsible-Changed-When: Mon Apr 30 07:51:29 UTC 2012
Responsible-Changed-Why: 
Over to maintainer.

http://www.freebsd.org/cgi/query-pr.cgi?pr=167447
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/19402: Signals 127 and 128 cannot be detected in wait4() interface

2012-04-30 Thread Bruce Evans 
The following reply was made to PR kern/19402; it has been noted by GNATS.

From: Bruce Evans 
To: Jilles Tjoelker 
Cc: bug-follo...@freebsd.org, ne...@segfault.kiev.ua, b...@freebsd.org
Subject: Re: kern/19402: Signals 127 and 128 cannot be detected in wait4()
 interface
Date: Mon, 30 Apr 2012 18:24:51 +1000 (EST)

 On Mon, 30 Apr 2012, Jilles Tjoelker wrote:
 
 >> [problems with signals 127 and 128]
 >
 > First, note that "clean" programs cannot use signals 127 and 128 because
 > they do neither have a SIG* constant nor are in the range SIGRTMIN to
 > SIGRTMAX. Therefore, I think it is inappropriate to make large changes
 > to make them work. It suffices if wait4() and other interfaces cannot
 > cause confusion.
 
 I agree with not making large changes, of course.
 
 I wonder if there is a technical reason why 127 and and 128 were left out
 of SIGRTMAX.  In 4.4BSD, NSIG was only 32, with a comment saying that 33
 is possible (since NSIG counts signal 0).  Signal 32 would have caused
 fewer problems than signal 128 does now, but was left out.  In Linux
 (2.6.10 for x86-64, i386 and many others), NSIG is 32 and _NSIG is 64;
 apparently NSIG counts signal 0 but _NSIG doesn't, similarly to
 FreeBSD except for the spelling and value of _NSIG and all signals up
 to and including _NSIG being supported (SIGRTMIN is NSIG = 32 and
 SIGRTMAX is _NSIG = 64; FreeBSD uses the better spelling _SIG_MAXSIG
 for _NSIG); a max of 64 causes fewer technical problems and less bloat.
 
 > Because sh returns exit status 128+sig for signal sig, signal 128 cannot
 > be represented in an 8-bit exit status and would have to be aliased to
 > another signal if it is kept.
 >
 > The suggestion to modify wait4() ABI seems inappropriate for that
 > reason.
 >
 > Another option is to modify the highest signal number accepted by
 > interfaces (while leaving the size of sigset_t and the like unchanged).
 > This effectively removes signals 127 and 128 from the system. One
 > problem results when having posix_spawn() from an old libc reset all
 > signals to default (by passing posix_spawnattr_setsigdefault() a
 > sigfillset()'ed sigset_t and enabling the POSIX_SPAWN_SETSIGDEF flag in
 > the posix_spawnattr_t). It will then attempt to set all signals from 1
 > to 128 to the default action and fail the entire spawn if sigaction()
 > fails. This could be allowed by having certain calls (such as
 > sigaction() with SIG_DFL) return success without doing anything for
 > signals 127 and 128. This is likely to get messy.
 >
 > Alternatively, the default action for signals 127 and 128 could be
 > changed to ignore (like SIGCHLD, SIGURG and SIGINFO), so that no process
 > may terminate because of them. Processes can still send the signals and
 > set handlers for them. Apart from the obvious effect that the process
 > will not terminate when it receives such a signal without handling or
 > masking it, FreeBSD also discards ignored signals even when they are
 > masked (POSIX permits this). This could lead to unexpected results if a
 > process is using sigwait() or a similar function.
 > 
 > Yet another approach would modify the wait4() system call, changing
 > signals 127 and 128 to something that does not cause confusion. This
 > seems ugly.
 
 I think I prefer disallowing signal 128 and not worry about unportable
 programs using it, and not changing anything for signal 127 and not worry
 about the ambiguous wait status from this.
 
 Emulators give interesting problems with signal ranges.  FreeBSD seems
 to handle these problems mostly correctly in the Linux emulator.  First,
 it needs a host signal range larger than the target signal range.
 [0..126], [0..127] and [0..128] all exceed the Linux range of [0..64],
 so there is no problem yet.  However, for mips under Linux, _NSIG is 128,
 so the full FreeBSD range might be needed, depending on how Linux handles
 the problem with wait statuses.   FreeBSD mostly uses the Linux _NSIG
 correctly, so it gets target limits.  It also translates signal numbers
 below NSIG, so it knows a little about NSIG counting signal 0.  However,
 in linux_ioctl.c, it still uses the old FreeBSD signal number NSIG in a
 private ISSIGVALID() macro instead of using its standard macro
 LINUX_SIG_VALID() which uses _NSIG correctly.  ISSIGVALID() is only used
 for the VT_SETMODE ioctl, and FreeBSD's signal handling for this differs
 in other ways than Linux's (FreeBSD fixes up mode.frsig (but only if it
 and mode.acqsig are invalid according to the private macro), while Linux
 ignores mode.frsig.  The private macro might even be correct, with making
 it look like a standard macro just obfuscating any magic for NSIG here.
 
 Bruce
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/19402: Signals 127 and 128 cannot be detected in wait4() interface

2012-04-30 Thread Valentin Nechayev 
The following reply was made to PR kern/19402; it has been noted by GNATS.

From: Valentin Nechayev 
To: Jilles Tjoelker 
Cc: bug-follo...@freebsd.org, b...@freebsd.org
Subject: Re: kern/19402: Signals 127 and 128 cannot be detected in wait4()
 interface
Date: Mon, 30 Apr 2012 12:04:54 +0300

 Hi,
 
  Mon, Apr 30, 2012 at 00:46:19, jilles wrote about "Re: kern/19402: Signals 
127 and 128 cannot be detected in wait4() interface": 
 
 > > [problems with signals 127 and 128]
 > 
 > First, note that "clean" programs cannot use signals 127 and 128 because
 > they do neither have a SIG* constant nor are in the range SIGRTMIN to
 > SIGRTMAX.
 
 You are correct here now, but not at the time I have issued the original
 request. Values for SIGRTMIN, SIGRTMAX initially appeared only in
 version 1.47 (Oct 2005) and was incorrect. Revision 1.53 reduced
 SIGRTMAX from 128 to 126 exactly concerning this my PR. So, if we stick
 on treating 126 as maximal possible signal number which doesn't break
 existing ABI, all seems satisfied and I suggest simply to close it as
 fixed. No need to change any more.
 
 
 -netch-
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

misc/167449: slice re-partitioning cause invalid partition for boot2, boot.config not recognized

2012-04-30 Thread hans 

>Number: 167449
>Category:   misc
>Synopsis:   slice re-partitioning cause invalid partition for boot2, 
>boot.config not recognized
>Confidential:   no
>Severity:   serious
>Priority:   low
>Responsible:freebsd-bugs
>State:  open
>Quarter:
>Keywords:   
>Date-Required:
>Class:  sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Apr 30 09:10:07 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: hans
>Release:Satable-9
>Organization:
>Environment:
FreeBSD pop1.hm.net.br 9.0-STABLE FreeBSD 9.0-STABLE #5: Wed Apr 25 02:18:05 
BRT 2012 h...@pop1.hm.net.br:/usr/obj/usr/src/sys/WIPMINI  i386

>Description:
After deleting the d and e partition and creating a new d partition with the 
available free space, boot hangs at boot2 

However, entering 0:ad(0,3,a)/boot/loader, I can boot and system works normal

bsdlabel is ok

# /dev/ada0s3:
8 partitions:
#  size offsetfstype   [fsize bsize bps/cpg]
  a:4194304  04.2BSD0 0 0
  b:41902084194304  swap
  c:   96255999  0unused0 0 # "raw" part, don't edit
  d:   8787148783845124.2BSD0 0 0


so I created /boot.config with the above settings but it seems not beeing read, 
still hangs at boot2

Editing the label with bsdlabel -e was not permitted

using gpart for bootstrapping
gpart bootcode -b /boot/boot ada0s3

also no success, still hangs at boot2

having currdev and/or rootdev in boot.loader makes no difference either

I am n ot very familare to mbr/disk manipulation, so I do not know what else to 
do now

My boot loader is grub2 installed on this ada0s3a partition, all other systems 
are coming up fine, since it is coming until boot2 on ada0s3a I believe the 
problem is not the boot manager

my partitions are glabeled, some also gjournal, I have two disks, this system 
should boot from ada0s3a which is label/rootfs

/dev/label/rootfs  2G394M1.4G21%/
devfs1.0k1.0k  0B   100%/dev
/dev/label/varfs  57G1.4G 51G 3%/var
/dev/label/usrfs 134G 12G111G10%/usr
/dev/label/dados  39G 29G7.4G80%/dados
procfs   4.0k4.0k  0B   100%/proc
linprocfs4.0k4.0k  0B   100%/compat/linux/proc


glabel status
  Name  Status  Components
 ext2fs/F16_rootfs N/A  ada0s1
  label/rootfs N/A  ada0s3a
   label/swap0 N/A  ada0s3b
 ntfs/Win7 N/A  ada1s2
   label/usrfs N/A  ada0s2b.journal
   label/varfs N/A  ada0s2d.journal
   label/dados N/A  ada0s3d.journal
   label/swap1 N/A  ada1s3b
ext2fs/_Fedora-16-i686 N/A  ada1s6
   label/root0 N/A  ada1s3a.journal
ufsid/4f97986cf50ff2b4 N/A  ada1s3a.journal
 ufs/root0 N/A  ada1s3a.journal

journal status
   Name  Status  Components
ada0s2b.journal N/A  ada0s2b
ada0s2d.journal N/A  ada0s2d
ada0s3d.journal N/A  ada0s3d
ada1s3a.journal N/A  ada1s3a










>How-To-Repeat:

>Fix:


>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/19402: Signals 127 and 128 cannot be detected in wait4() interface

2012-04-30 Thread Valentin Nechayev 
The following reply was made to PR kern/19402; it has been noted by GNATS.

From: Valentin Nechayev 
To: Bruce Evans 
Cc: Jilles Tjoelker , bug-follo...@freebsd.org,
b...@freebsd.org
Subject: Re: kern/19402: Signals 127 and 128 cannot be detected in wait4()
 interface
Date: Mon, 30 Apr 2012 12:22:54 +0300

  Mon, Apr 30, 2012 at 18:24:51, brde wrote about "Re: kern/19402: Signals 127 
and 128 cannot be detected in wait4() interface": 
 
 > I think I prefer disallowing signal 128 and not worry about unportable
 > programs using it, and not changing anything for signal 127 and not worry
 > about the ambiguous wait status from this.
 
 As soon as realtime signals are already kind of feature very limited in
 use, and correct program doesn't allocate them in manner linear
 dependent on checked descriptor count, I guess it's too improbable to
 see a program which uses more than 10-16 realtime signals. Our current
 limit 62 is much more.
 
 > However, for mips under Linux, _NSIG is 128,
 
 If they didn't change the wait*() exitstatus ABI under MIPS (and as far
 as I see at the code, this ABI is platform independent), Linux have the
 same problems with signals 127 and 128 and their usage is incorrect.
 I guess it's better to discuss the issue in LKML and wait for Linux reaction.
 
 
 -netch-
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/157397: [ada] ahci/ada/cam NCQ timeouts on Samsung and non-disable-ability

2012-04-30 Thread Matthias Andree 
The following reply was made to PR kern/157397; it has been noted by GNATS.

From: Matthias Andree 
To: bug-follo...@freebsd.org
Cc:  
Subject: Re: kern/157397: [ada] ahci/ada/cam NCQ timeouts on Samsung and 
non-disable-ability
Date: Mon, 30 Apr 2012 21:08:42 +0200

 Also affects: 9-stable as of mid April 2012.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

misc/167460: devel/libytnef: bad handling of PT_CLSID in TNEFFillMapi

2012-04-30 Thread Sean Bruno 

>Number: 167460
>Category:   misc
>Synopsis:   devel/libytnef: bad handling of PT_CLSID in TNEFFillMapi
>Confidential:   no
>Severity:   serious
>Priority:   medium
>Responsible:freebsd-bugs
>State:  open
>Quarter:
>Keywords:   
>Date-Required:
>Class:  sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Apr 30 19:30:09 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Sean Bruno
>Release:9-stable
>Organization:
FreeBSD 
>Environment:
FreeBSD powernoodle-l7 9.0-STABLE FreeBSD 9.0-STABLE #0 r233925: Thu Apr  5 
11:34:25 PDT 2012 
root@pcbsd-4855:/usr/obj/usr/home/sbruno/bsd/9/sys/GENERIC  amd64

>Description:
devel/libytnef/ytnef.c has incomplete handling of the PT_CLSID type and will 
spin off and crash applications attempting to use it.

Patch attached properly handles the GUID data structure via hardcoded magic 
values.

Fix ideas were liberally stolen from the MSDN docs and wine.org handling code.
>How-To-Repeat:

>Fix:


>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: misc/167460: devel/libytnef: bad handling of PT_CLSID in TNEFFillMapi

2012-04-30 Thread Sean Bruno 
The following reply was made to PR misc/167460; it has been noted by GNATS.

From: Sean Bruno 
To: bug-follo...@freebsd.org, sbr...@freebsd.org
Cc:  
Subject: Re: misc/167460: devel/libytnef: bad handling of PT_CLSID in
 TNEFFillMapi
Date: Mon, 30 Apr 2012 12:56:37 -0700

 Patch located at:
 
 http://people.freebsd.org/~sbruno/libytnef_ytnef_c.txt
 
 Sean
 
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

bin/167463: [PATCH] (src/HEAD) sbin/md5 - Add "-c string" to usage

2012-04-30 Thread Bryan Drewery 

>Number: 167463
>Category:   bin
>Synopsis:   [PATCH] (src/HEAD) sbin/md5 - Add "-c string" to usage
>Confidential:   no
>Severity:   non-critical
>Priority:   low
>Responsible:freebsd-bugs
>State:  open
>Quarter:
>Keywords:   
>Date-Required:
>Class:  change-request
>Submitter-Id:   current-users
>Arrival-Date:   Mon Apr 30 20:30:09 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Bryan Drewery
>Release:FreeBSD 10-CURRENT i386
>Organization:
>Environment:



>Description:
`md5 --help` does not document '-c string'. man.1 does document this. 
Patch adds to `md5 --help`.
>How-To-Repeat:

>Fix:



--- sbin-md5.patch.txt begins here ---
diff --git sbin/md5/md5.c sbin/md5/md5.c
index 2e0a0d0..29d50bb 100644
--- sbin/md5/md5.c
+++ sbin/md5/md5.c
@@ -372,6 +372,6 @@ static void
 usage(Algorithm_t *alg)
 {
 
-   fprintf(stderr, "usage: %s [-pqrtx] [-s string] [files ...]\n", 
alg->progname);
+   fprintf(stderr, "usage: %s [-pqrtx] [-c string] [-s string] [files 
...]\n", alg->progname);
exit(1);
 }
--- sbin-md5.patch.txt ends here ---


>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: bin/167463: [PATCH] (src/HEAD) sbin/md5 - Add "-c string" to usage

2012-04-30 Thread eadler 
Synopsis: [PATCH] (src/HEAD) sbin/md5 - Add "-c string" to usage

Responsible-Changed-From-To: freebsd-bugs->eadler
Responsible-Changed-By: eadler
Responsible-Changed-When: Mon Apr 30 20:31:38 UTC 2012
Responsible-Changed-Why: 
I'll take it.

http://www.freebsd.org/cgi/query-pr.cgi?pr=167463
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/166806: Inability to reboot system

2012-04-30 Thread RX 
The following reply was made to PR kern/166806; it has been noted by GNATS.

From: RX 
To: Attilio Rao 
Cc: bug-follo...@freebsd.org
Subject: Re: kern/166806: Inability to reboot system
Date: Mon, 30 Apr 2012 17:30:47 -0700

 On Apr 20, 2012, at 6:17 PM, Attilio Rao wrote:
 
 > Are you eventually able to make some tests on that machine if I send
 > you some instruction/patches? Is the problem 100% reproducible?
 > Can you try by starting with showing "sysctl hw.acpi.handle_reboot"
 > and force it to 0 (and see what happens)?
 
 
 Hello Attillio,
 
 I have hardware dedicated to resolving this problem.
 
 The problem is 100% reproducible.
 
 The sysctl you asked for is already set to zero.
 
 sysctl -a |grep handle_reboot
 hw.acpi.handle_reboot: 0
 
 --RX
 
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: ports/167460: devel/libytnef: bad handling of PT_CLSID in TNEFFillMapi

2012-04-30 Thread linimon 
Synopsis: devel/libytnef: bad handling of PT_CLSID in TNEFFillMapi

Responsible-Changed-From-To: freebsd-bugs->freebsd-ports-bugs
Responsible-Changed-By: linimon
Responsible-Changed-When: Tue May 1 01:07:52 UTC 2012
Responsible-Changed-Why: 
ports PR.

http://www.freebsd.org/cgi/query-pr.cgi?pr=167460
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/161454: [i18n] [patch] because i18n/csmapper/Makefile.part bug, some mps files are not found

2012-04-30 Thread Yamaya Takashi 
The following reply was made to PR kern/161454; it has been noted by GNATS.

From: Yamaya Takashi 
To: bug-follo...@freebsd.org, yama...@kbh.biglobe.ne.jp
Cc:  
Subject: Re: kern/161454: [i18n] [patch] because i18n/csmapper/Makefile.part
 bug, some mps files are not found
Date: Tue, 01 May 2012 10:40:47 +0900

 I forgot CC: bug-follo...@freebsd.org.
 
 This PR is /usr/src/share/i18n/csmapper.
 
 Who's committer?
 
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/166805: Winbond W83627DHG-P serial console hang

2012-04-30 Thread Marcin Wiśnicki 
The following reply was made to PR kern/166805; it has been noted by GNATS.

From: =?UTF-8?Q?Marcin_Wi=C5=9Bnicki?= 
To: bug-follo...@freebsd.org, yoitsmeremem...@gmail.com
Cc:  
Subject: Re: kern/166805: Winbond W83627DHG-P serial console hang
Date: Tue, 1 May 2012 04:46:11 +0200

 I have this same problem in pfSense 2.0.1 (FreeBSD 8.1-RELEASE-p6). It
 seems that if I enter ddb using real (usb) keyboard, I can control it
 via serial console. Resuming execution will print more characters and
 stop. This can be repeated couple of times until entering ddb will
 cause what looks like a freeze where not even numlock works but
 repeatedly breaking will get me back to usable ddb.
 
 I have disabled all non-essential devices in bios (everything except
 usb and serial) and tried booting into single user mode.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

kern/167467: [ZFS] improve zdb(8) manpage and help.

2012-04-30 Thread Marcelo Araujo 

>Number: 167467
>Category:   kern
>Synopsis:   [ZFS] improve zdb(8) manpage and help.
>Confidential:   no
>Severity:   non-critical
>Priority:   low
>Responsible:freebsd-bugs
>State:  open
>Quarter:
>Keywords:   
>Date-Required:
>Class:  change-request
>Submitter-Id:   current-users
>Arrival-Date:   Tue May 01 04:10:06 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Marcelo Araujo
>Release:10.0-CURRENT
>Organization:
FreeBSD
>Environment:
FreeBSD hosta 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r233530M: Mon Apr 23 
11:51:58 UTC 2012 araujo@hosta:/usr/obj/usr/src/sys/HOSTA  i386
>Description:
Improve zdb man page as well as the output help provided by zdb command.
>How-To-Repeat:

>Fix:


Patch attached with submission follows:

diff -r b470a5db430e cddl/contrib/opensolaris/cmd/zdb/zdb.8
--- a/cddl/contrib/opensolaris/cmd/zdb/zdb.8Mon Apr 30 06:02:00 2012 +
+++ b/cddl/contrib/opensolaris/cmd/zdb/zdb.8Mon Apr 30 11:28:04 2012 +
@@ -18,55 +18,451 @@
 .\" information: Portions Copyright [] [name of copyright owner]
 .\"
 .\" Copyright (c) 2004, Sun Microsystems, Inc. All Rights Reserved.
+.\" Copyright 2012, Richard Lowe.
+.\" Copyright (c) 2012, Marcelo Araujo .
+.\" All Rights Reserved.
 .\"
 .\" $FreeBSD$
 .\"
-.Dd November 26, 2011
+.Dd May 1, 2012
 .Dt ZDB 8
 .Os
 .Sh NAME
 .Nm zdb
-.Nd ZFS debugger
+.Nd Display zpool debugging and consistency information
 .Sh SYNOPSIS
-.Nm
-.Ar pool
+\fBzdb\fR [-CumdibcsDvhLXFPA] [-e [-p \fIpath\fR...]] [-t \fItxg\fR]
+\fIpoolname\fR [\fIobject\fR ...]
+
+.P
+\fBzdb\fR [-divPA] [-e [-p \fIpath\fR...]] 
+\fIdataset\fR [\fIobject\fR ...]
+
+.P
+\fBzdb\fR -m [-LXFPA] [-t \fItxg\fR] [-e [-p \fIpath\fR...]] \fIpoolname\fR
+[\fIvdev\fR [\fImetaslab\fR ...]]
+
+.P
+\fBzdb\fR -R [-A] [-e [-p \fIpath\fR...]] \fIpoolname\fR
+\fIvdev\fR:\fIoffset\fR:\fIsize\fR[:\fIflags\fR]
+
+.P
+\fBzdb\fR -S [-AP] [-e [-p \fIpath\fR...]] \fIpoolname\fR
+
+.P
+\fBzdb\fR -l [-uA] \fIdevice\fR
+
+.P
+\fBzdb\fR -C [-A] [-U \fIcache\fR]
+
 .Sh DESCRIPTION
 The
-.Nm
-command is used by support engineers to diagnose failures and
-gather statistics. Since the
-.Tn ZFS
-file system is always consistent on disk and is self-repairing,
-.Nm
-should only be run under the direction by a support engineer.
-.Pp
-If no arguments are specified,
-.Nm
-performs basic consistency checks on the pool and associated datasets, and
-report any problems detected.
-.Nm
-Any options supported by this command are internal to Sun and subject to change
-at any time.
-.Sh EXIT STATUS
-The following exit values are returned:
-.Bl -tag -offset 2n -width 2n
-.It 0
-The pool is consistent.
-.It 1
-An error was detected.
-.It 2
-Invalid command line options were specified.
-.El
+.Nm 
+utility displays information about a ZFS pool useful for
+debugging and performs some amount of consistency checking. It is a not a
+general purpose tool and options (and facilities) may change. This is neither
+a fsck(1M) nor an fsdb(1M) utility.
+.p
+The output of this command in general reflects the on-disk structure of a ZFS
+pool, and is inherently unstable. The precise output of most invocations is
+not documented, a knowledge of ZFS internals is assumed.
+.p
+When operating on an imported and active pool it is possible, though unlikely,
+that zdb may interpret inconsistent pool data and behave erratically.
+.Sh OPTIONS
+Display options:
+.sp
+.ne 2
+.na
+\fB-b\fR
+.ad
+.sp .6
+.RS 4n
+Display statistics regarding the number, size (logical, physical and
+allocated) and deduplication of blocks.
+.RE
+.sp
+.ne 2
+.na
+\fB-c\fR
+.ad
+.sp .6
+.RS 4n
+Verify the checksum of all metadata blocks while printing block statistics
+(see \fB-b\fR).
+.sp
+If specified multiple times, verify the checksums of all blocks.
+.RE
+.sp
+.ne 2
+.na
+\fB-C\fR
+.ad
+.sp .6
+.RS 4n
+Display information about the configuration. If specified with no other
+options, instead display information about the cache file
+(\fB/etc/zfs/zpool.cache\fR). To specify the cache file to display, see
+\fB-U\fR.
+.P
+If specified multiple times, and a pool name is also specified display both
+the cached configuration and the on-disk configuration.  If specified multiple
+times with \fB-e\fR also display the configuration that would be used were the
+pool to be imported.
+.RE
+.sp
+.ne 2
+.na
+\fB-d\fR
+.ad
+.sp .6
+.RS 4n
+Display information about datasets. Specified once, displays basic dataset
+information: ID, create transaction, size, and object count.
+.sp
+If specified multiple times provides greater and greater verbosity.
+.sp
+If object IDs are specified, display information about those specific objects 
only.
+.RE
+.sp
+.ne 2
+.na
+\fB-D\fR
+.ad
+.sp .6
+.RS 4n
+Display deduplication statistics, including the deduplication ratio (dedup),
+compression ratio (compress), inflation due to the zfs copies property
+(copies), and an overall effective ratio (dedup * compress / copi

Re: kern/167467: [ZFS] improve zdb(8) manpage and help.

2012-04-30 Thread araujo 
Synopsis: [ZFS] improve zdb(8) manpage and help.

Responsible-Changed-From-To: freebsd-bugs->freebsd-fs
Responsible-Changed-By: araujo
Responsible-Changed-When: Tue May 1 04:11:17 UTC 2012
Responsible-Changed-Why: 
Over to maintainer.

http://www.freebsd.org/cgi/query-pr.cgi?pr=167467
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

kern/167468: drm locking Xorg in loop

2012-04-30 Thread Andrew 

>Number: 167468
>Category:   kern
>Synopsis:   drm locking Xorg in loop
>Confidential:   no
>Severity:   serious
>Priority:   medium
>Responsible:freebsd-bugs
>State:  open
>Quarter:
>Keywords:   
>Date-Required:
>Class:  sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue May 01 05:00:25 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Andrew
>Release:8.3-STABLE
>Organization:
>Environment:
FreeBSD certhas 8.3-STABLE FreeBSD 8.3-STABLE #0: Fri Apr 27 02:00:05 EST 2012  
   root@certhas:/usr/obj/usr/src/sys/GENERIC  amd64
>Description:
After rebuild in April using a Radeon HD4200 chip with DRI/DR2/GLX enabled 
would soon result in Xorg freezing, you then have to ssh in to kill Xorg and/or 
reboot. See below segment of dmesg. Am using KDE on this workstation. The 
problem seems to have become more frequent which leads to horrible suspicion 
it's overheating the GPU each time.

Now only able to use this workstation by disabling DRI/DRI2/GLX.

drm0:  on vgapci0
info: [drm] MSI enabled 1 message(s)
info: [drm] Initialized radeon 1.31.0 20080613
info: [drm] Setting GART location based on new memory map
info: [drm] Loading RS780/RS880 Microcode
info: [drm] Resetting GPU
info: [drm] writeback test succeeded in 1 usecs
drm0: [ITHREAD]
wlan1: link state changed to UP
info: [drm] Resetting GPU
info: [drm] Loading RS780/RS880 Microcode
info: [drm] Resetting GPU
info: [drm] Resetting GPU
info: [drm] Loading RS780/RS880 Microcode
info: [drm] Resetting GPU
info: [drm] Resetting GPU
info: [drm] Loading RS780/RS880 Microcode
info: [drm] Resetting GPU
info: [drm] wait idle failed status : 0xA0003030 0x0003
info: [drm] wait idle failed status : 0xA0003030 0x0003
info: [drm] wait idle failed status : 0xA0003030 0x0003
info: [drm] wait idle failed status : 0xA0003030 0x0003
info: [drm] wait idle failed status : 0xA0003030 0x0003
info: [drm] wait idle failed status : 0xA0003030 0x0003
info: [drm] wait idle failed status : 0xA0003030 0x0003
info: [drm] wait idle failed status : 0xA0003030 0x0003
info: [drm] wait idle failed status : 0xA0003030 0x0003
info: [drm] wait idle failed status : 0xA0003030 0x0003
info: [drm] wait idle failed status : 0xA0003030 0x0003
info: [drm] wait idle failed status : 0xA0003030 0x0003
info: [drm] wait idle failed status : 0xA0003030 0x0003
info: [drm] wait idle failed status : 0xA0003030 0x0003
info: [drm] wait idle failed status : 0xA0003030 0x0003
info: [drm] wait idle failed status : 0xA0003030 0x0003
info: [drm] wait idle failed status : 0xA0003030 0x0003
info: [drm] wait idle failed status : 0xA0003030 0x0003
info: [drm] wait idle failed status : 0xA0003030 0x0003
info: [drm] wait idle failed status : 0xA0003030 0x0003
info: [drm] wait idle failed status : 0xA0003030 0x0003
info: [drm] wait idle failed status : 0xA0003030 0x0003
info: [drm] wait idle failed status : 0xA0003030 0x0003
info: [drm] wait idle failed status : 0xA0003030 0x0003
info: [drm] wait idle failed status : 0xA0003030 0x0003
info: [drm] wait idle failed status : 0xA0003030 0x0003
info: [drm] wait idle failed status : 0xA0003030 0x0003
info: [drm] wait idle failed status : 0xA0003030 0x0003
info: [drm] wait idle failed status : 0xA0003030 0x0003
>How-To-Repeat:

>Fix:


>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"