misc/149173: [patch] [zfs] make OpenSolaris installable
>Number: 149173
>Category: misc
>Synopsis: [patch] [zfs] make OpenSolaris installable
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Sun Aug 01 12:10:03 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: Robert Millan
>Release:
>Organization:
>Environment:
>Description:
This patch makes OpenSolaris buildable outside the compatibility
environment, so that it can be installed system-wide, along with ,
making it easier for third party apps to link with libnvpair.
It's been forwarded to OpenSolaris BTS already:
- https://defect.opensolaris.org/bz/show_bug.cgi?id=16697#c0
See also the discussion on GRUB list [1] about this problem:
- http://osdir.com/ml/grub-devel-gnu/2010-07/msg00263.html
[1] I'm in the process of adding support to GRUB for booting from ZFS
>How-To-Repeat:
>Fix:
Patch attached with submission follows:
--- sys/nvpair.h.old2010-07-31 12:03:02.038737593 -0400
+++ sys/nvpair.h2010-07-31 12:03:08.926873793 -0400
@@ -32,6 +32,18 @@
#include
#include
+/* for non-OpenSolaris systems */
+#if !defined(_KERNEL) && !defined(_BOOT)
+#include /* uintxx_t */
+#include /* va_list */
+typedef unsigned int uint_t;
+typedef unsigned char uchar_t;
+typedef enum { B_FALSE, B_TRUE } boolean_t;
+typedef long long hrtime_t;
+#else
+typedef __va_list va_list;
+#endif
+
#if defined(_KERNEL) && !defined(_BOOT)
#include
#endif
@@ -133,7 +145,7 @@
} nv_alloc_t;
struct nv_alloc_ops {
- int (*nv_ao_init)(nv_alloc_t *, __va_list);
+ int (*nv_ao_init)(nv_alloc_t *, va_list);
void (*nv_ao_fini)(nv_alloc_t *);
void *(*nv_ao_alloc)(nv_alloc_t *, size_t);
void (*nv_ao_free)(nv_alloc_t *, void *, size_t);
>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/148733: a potential buffer overflow in sh(1)
Synopsis: a potential buffer overflow in sh(1) Responsible-Changed-From-To: freebsd-bugs->jilles Responsible-Changed-By: jilles Responsible-Changed-When: Sun Aug 1 14:16:56 UTC 2010 Responsible-Changed-Why: I'm working on this. http://www.freebsd.org/cgi/query-pr.cgi?pr=148733 ___ 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/61810: mounts done within a chroot show up wrong and can't be unmounted from outside.
Synopsis: mounts done within a chroot show up wrong and can't be unmounted from outside. State-Changed-From-To: suspended->closed State-Changed-By: jilles State-Changed-When: Sun Aug 1 15:29:09 UTC 2010 State-Changed-Why: The umount problem was fixed, changing pathname display seems to require unlikely statfs rework. http://www.freebsd.org/cgi/query-pr.cgi?pr=61810 ___ 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/54683: commit references a PR
The following reply was made to PR bin/54683; it has been noted by GNATS. From: dfil...@freebsd.org (dfilter service) To: bug-follo...@freebsd.org Cc: Subject: Re: bin/54683: commit references a PR Date: Sun, 1 Aug 2010 16:38:00 + (UTC) Author: jilles Date: Sun Aug 1 16:37:51 2010 New Revision: 210736 URL: http://svn.freebsd.org/changeset/base/210736 Log: sh: Do not enter consecutive duplicates into the history. This simply sets a flag in libedit. It has a shortcoming in that it does not apply to multi-line commands. Note that a configuration option for this is not going to happen, but always having this seems better than not having it. NetBSD has done the same. PR: bin/54683 Obtained from: NetBSD MFC after: 1 month Modified: head/bin/sh/histedit.c Modified: head/bin/sh/histedit.c == --- head/bin/sh/histedit.c Sun Aug 1 15:55:49 2010(r210735) +++ head/bin/sh/histedit.c Sun Aug 1 16:37:51 2010(r210736) @@ -168,6 +168,7 @@ sethistsize(hs) (histsize = atoi(hs)) < 0) histsize = 100; history(hist, &he, H_SETSIZE, histsize); + history(hist, &he, H_SETUNIQUE, 1); } } ___ svn-src-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org" ___ 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/149173: [patch] [zfs] make OpenSolaris installable
Synopsis: [patch] [zfs] make OpenSolaris installable Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Sun Aug 1 16:41:53 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=149173 ___ 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/54683: sh(1) redundant history
Synopsis: sh(1) redundant history State-Changed-From-To: open->patched State-Changed-By: jilles State-Changed-When: Sun Aug 1 16:42:43 UTC 2010 State-Changed-Why: Fixed in 9-CURRENT. Responsible-Changed-From-To: freebsd-bugs->jilles Responsible-Changed-By: jilles Responsible-Changed-When: Sun Aug 1 16:42:43 UTC 2010 Responsible-Changed-Why: Take. http://www.freebsd.org/cgi/query-pr.cgi?pr=54683 ___ 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/43367: incorrect report from who(1) after 'shutdown now' from remote terminal
Synopsis: incorrect report from who(1) after 'shutdown now' from remote terminal State-Changed-From-To: open->feedback State-Changed-By: jilles State-Changed-When: Sun Aug 1 17:32:07 UTC 2010 State-Changed-Why: I cannot reproduce this on 7-stable or 9-current. Does this still happen for you? (I agree it would be a bug.) http://www.freebsd.org/cgi/query-pr.cgi?pr=43367 ___ 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/143271: [patch] whatis(1) should print error message to stderr
The following reply was made to PR bin/143271; it has been noted by GNATS. From: Alexander Best To: bug-follo...@freebsd.org Cc: Jan Schaumann Subject: Re: bin/143271: [patch] whatis(1) should print error message to stderr Date: Sun, 1 Aug 2010 21:33:48 + i agree with the stdout/sterr issue. however i don't see why whatis'es return values should be altered. it's common practice to return 0 on success. so returning 0 if whatis recognizes the keyword is just fine. cheers. alex -- a13x ___ 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/143271: [patch] whatis(1) should print error message to stderr
The following reply was made to PR bin/143271; it has been noted by GNATS. From: Jan Schaumann To: Alexander Best Cc: bug-follo...@freebsd.org Subject: Re: bin/143271: [patch] whatis(1) should print error message to stderr Date: Sun, 1 Aug 2010 18:30:28 -0400 --6v9BRtpmy+umdQlo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Alexander Best wrote: =20 > however i don't see why whatis'es return values should be altered. > it's common practice to return 0 on success. so returning 0 if whatis > recognizes the keyword is just fine. The problem is that whatis(1) returns 0 even if it does NOT find anything, which should be an error condition. $ whatis oink oink: nothing appropriate $ echo $? 0 $=20 -Jan --6v9BRtpmy+umdQlo Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (NetBSD) iD8DBQFMVfWEfFtkr68iakwRAgevAJ9afa0p/R2OZrPli98fUhtCyY771gCeL437 K2ujeDIlfMO6VOpUvN85N9s= =4bQX -END PGP SIGNATURE- --6v9BRtpmy+umdQlo-- ___ 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/143271: [patch] whatis(1) should print error message to stderr
The following reply was made to PR bin/143271; it has been noted by GNATS. From: Alexander Best To: Jan Schaumann Cc: bug-follo...@freebsd.org Subject: Re: bin/143271: [patch] whatis(1) should print error message to stderr Date: Sun, 1 Aug 2010 22:39:53 + On Sun Aug 1 10, Jan Schaumann wrote: > Alexander Best wrote: > > > however i don't see why whatis'es return values should be altered. > > it's common practice to return 0 on success. so returning 0 if whatis > > recognizes the keyword is just fine. oh i'm sorry. i think this was a misunderstanding then. indeed this is a bug. although the whatis(1) manual only talks about the return status of apropos i also checked apropos and it also returns 0 if nothing was found. so this is just plain wrong and apropos/whatis don't do what they're supposed to according to the manual. cheers. alex > > The problem is that whatis(1) returns 0 even if it does NOT find > anything, which should be an error condition. > > $ whatis oink > oink: nothing appropriate > $ echo $? > 0 > $ > > -Jan -- a13x ___ 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/149185: [rum] panic in rum(4) driver on 8.1-R
>Number: 149185 >Category: kern >Synopsis: [rum] panic in rum(4) driver on 8.1-R >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Aug 02 00:30:06 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Alex Kozlov >Release:8.1-RELEASE-i386 >Organization: private >Environment: >Description: The panic happens after random period of time. Fatal trap 18: integer divide fault while in kernel mode instruction pointer = 0x20:0xc087ce32 stack pointer = 0x28:0xc4e2d948 frame pointer = 0x28:0xc4e2d958 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 14 (usbus4) trap number = 18 panic: integer divide fault KDB: stack backtrace: db_trace_self_wrapper(c0669547,c06cb000,c0660c6a,c4e2d83c,c4e2d83c,...) at 0xc0436706 = db_trace_self_wrapper+0x26 panic(c0660c6a,c0680c94,c4e2d908,1,1,...) at 0xc04b898d = panic+0xed trap_fatal(c6a438ec,ae295ce6,5a1dc54c,adea5167,c50bf2a8,...) at 0xc06474bd = trap_fatal+0x23d trap(c4e2d908) at 0xc0647efe = trap+0xee calltrap() at 0xc062d4ac = calltrap+0x6 --- trap 0x12, eip = 0xc087ce32, esp = 0xc4e2d948, ebp = 0xc4e2d958 --- rum_setup_tx_desc(0,44,0,509,ff00,...) at 0xc087ce32 = rum_setup_tx_desc+0x72 rum_start(c531d800,8f82cefe,f5192700,6087b2a,c08babbb,...) at 0xc087ecec = rum_start+0x1d4 if_transmit(c531d800,caac7100,caac7100,a4,c53f80f4,...) at 0xc055f8f9 = if_transmit+0xc9 ieee80211_start(c53f8000,c4e2da2c,c04a5c7d,3,0,...) at 0xc08a2305 = ieee80211_start+0x316 if_transmit(c53f8000,caac7100,0) at 0xc055f8f9 = if_transmit+0xc9 ether_output_frame(c53f8000,caac7100,6,1,a000,...) at 0xc05645ac = ether_output_frame+0x2c ether_output(c53f8000,caac7100,c4e2db20,0,0,...) at 0xc0564f7d = ether_output+0x51d arpintr(caac7100,12,c08e67a3,c50be4c8,caac7100,...) at 0xc0570759 = arpintr+0x7a9 netisr_dispatch_src(7,0,caac7100,c4e2dbb0,c05644ea,...) at 0xc0567610 = netisr_dispatch_src+0x70 netisr_dispatch(7,caac7100,0) at 0xc05678d0 = netisr_dispatch+0x20 ether_demux(c53f8000,caac7100,3,0,3,...) at 0xc05644ea = ether_demux+0x19a ether_input(c53f8000,caac7100,caac7100,c659301c,5ed,...) at 0xc0564838 = ether_input+0x148 adhoc_input(c6593000,caac7100,37,ffa1,0,...) at 0xc08b0736 = adhoc_input+0x436 rum_bulk_read_callback(c535e988,0,c085c6ba,a85,c535e030,...) at 0xc087f169 = rum_bulk_read_callback+0xf6 usbd_callback_wrapper(c535e030,c5176ca4,c535e000,c4e2dcc8,c085867a,...) at 0xc085a9a7 = usbd_callback_wrapper+0xae usb_command_wrapper(c535e030,0,c085c6ba,7d2,c535e044,...) at 0xc0858383 = usb_command_wrapper+0x6e usb_callback_proc(c535e044,0,c085c609,6c,c5176cb4,...) at 0xc085867a = usb_callback_proc+0x98 usb_process(c5176ca4,c4e2dd38,8000,0,40,...) at 0xc085647a = usb_process+0xaa fork_exit(c08563d0,c5176ca4,c4e2dd38) at 0xc048e868 = fork_exit+0x88 fork_trampoline() at 0xc062d524 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc4e2dd70, ebp = 0 --- >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/149185: [rum] [panic] panic in rum(4) driver on 8.1-R
Old Synopsis: [rum] panic in rum(4) driver on 8.1-R New Synopsis: [rum] [panic] panic in rum(4) driver on 8.1-R Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Aug 2 02:23:08 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=149185 ___ 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/148862: [panic] page fault while in kernel mode at _mtx_lock_sleep
Synopsis: [panic] page fault while in kernel mode at _mtx_lock_sleep Responsible-Changed-From-To: freebsd-i386->freebsd-bugs Responsible-Changed-By: linimon Responsible-Changed-When: Mon Aug 2 02:51:09 UTC 2010 Responsible-Changed-Why: This does not sound i386-specific. http://www.freebsd.org/cgi/query-pr.cgi?pr=148862 ___ 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/148862: [panic] page fault while in kernel mode at _mtx_lock_sleep
Synopsis: [panic] page fault while in kernel mode at _mtx_lock_sleep Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Mon Aug 2 05:57:21 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=148862 ___ 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"
