Re: kern/167551: [vimage] Fatal trap 12 jails, vimage, ifconfig destroy epair*a
Old Synopsis: Fatal trap 12 jails, vimage, ifconfig destroy epair*a New Synopsis: [vimage] Fatal trap 12 jails, vimage, ifconfig destroy epair*a Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu May 3 07:47:53 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=167551 ___ 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/167555: libarchive fails to build WITHOUT_OPENSSH due to missing hash algorithm files
>Number: 167555 >Category: bin >Synopsis: libarchive fails to build WITHOUT_OPENSSH due to missing hash >algorithm files >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: Thu May 03 08:40:10 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Volodymyr Kostyrko >Release:RELENG_9 >Organization: None >Environment: FreeBSD green.tandem.local 9.0-STABLE FreeBSD 9.0-STABLE #0: Wed May 2 12:38:36 EEST 2012 arcade@green.tandem.local:/usr/obj/usr/src/sys/MINIMAL amd64 >Description: When trying to build world WITHOUT_OPENSSH I got: In file included from /usr/src/lib/libarchive/../../contrib/libarchive/libarchive/archive_read_support_format_xar.c:57: /usr/src/lib/libarchive/../../contrib/libarchive/libarchive/archive_hash.h:129:12: fatal error: 'sha1.h' file not found # include ^ 1 error generated. mkdep: compile failed *** Error code 1 It seems that file that should be part of CRYPTO is accounted to OPENSSH. >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/167527: bsdinstall fails with "Error while extracting base.txz: failed to sec access acl"
Hi, i have a typo in the Release that is used. It should be FreeBSD-9.0-RELEASE #5 instead of FreeBSD-9.0-RELEASE-p5. With further investigation i've seen the ACL flag for the build partition is activated. In this partition are the whole build directories. I think this could be the cause for my failure. Thorsten ___ 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/166340: commit references a PR
The following reply was made to PR kern/166340; it has been noted by GNATS. From: dfil...@freebsd.org (dfilter service) To: bug-follo...@freebsd.org Cc: Subject: Re: kern/166340: commit references a PR Date: Thu, 3 May 2012 10:38:14 + (UTC) Author: kib Date: Thu May 3 10:38:02 2012 New Revision: 234952 URL: http://svn.freebsd.org/changeset/base/234952 Log: When callout_reset_on() cannot immediately migrate a callout since it is running on other cpu, the CALLOUT_PENDING flag is temporarily cleared. Then, callout_stop() on this, in fact active, callout fails because CALLOUT_PENDING is not set, and callout_stop() returns 0. Now, in sleepq_check_timeout(), the failed callout_stop() causes the sleepq code to execute mi_switch() without even setting the wmesg, since the switch-out is supposed to be transient. In fact, the thread is put off the CPU for full timeout interval, instead of being put on runq immediately. Until timeout fires, the process is unkillable for obvious reasons. Fix this by marking the migrating callouts with CALLOUT_DFRMIGRATION flag. The flag is cleared by callout_stop_safe() when the function detects a migration, besides returning the success. The softclock() rechecks the flag for migrating callout and cancels its execution if the flag was cleared meantime. PR: misc/166340 Reported, debugging traces provided and tested by: Christian Esken Reviewed by: avg, jhb MFC after:1 week Modified: head/sys/kern/kern_timeout.c head/sys/sys/callout.h Modified: head/sys/kern/kern_timeout.c == --- head/sys/kern/kern_timeout.c Thu May 3 10:26:33 2012 (r234951) +++ head/sys/kern/kern_timeout.c Thu May 3 10:38:02 2012 (r234952) @@ -645,6 +645,32 @@ softclock(void *arg) cc_cme_cleanup(cc); /* + * Handle deferred callout stops + */ + if ((c->c_flags & CALLOUT_DFRMIGRATION) + == 0) { + CTR3(KTR_CALLOUT, + "deferred cancelled %p func %p arg %p", + c, new_func, new_arg); + if (cc->cc_next == c) { + cc->cc_next = + TAILQ_NEXT(c, + c_links.tqe); + } + if (c->c_flags & + CALLOUT_LOCAL_ALLOC) { + c->c_func = NULL; + SLIST_INSERT_HEAD( + &cc->cc_callfree, c, + c_links.sle); + } + goto nextc; + } else { + c->c_flags &= ~ + CALLOUT_DFRMIGRATION; + } + + /* * It should be assert here that the * callout is not destroyed but that * is not easy. @@ -659,6 +685,9 @@ softclock(void *arg) panic("migration should not happen"); #endif } +#ifdef SMP +nextc: +#endif steps = 0; c = cc->cc_next; } @@ -814,6 +843,7 @@ callout_reset_on(struct callout *c, int cc->cc_migration_ticks = to_ticks; cc->cc_migration_func = ftn; cc->cc_migration_arg = arg; + c->c_flags |= CALLOUT_DFRMIGRATION; CTR5(KTR_CALLOUT, "migration of %p func %p arg %p in %d to %u deferred", c, c->c_func, c->c_arg, to_ticks, cpu); @@ -984,6 +1014,12 @@ again: CC_UNLOCK(cc); KASSERT(!sq_locked, ("sleepqueue chain locked")); return (1); + } else if ((c->c_flags & CALLOUT_DFRMIGRATION) != 0) { + c->c_flags &= ~CALLOUT_DFRMIGRATION; + CTR3
misc/167562: geli cannot use gpt labels in loader.conf
>Number: 167562 >Category: misc >Synopsis: geli cannot use gpt labels in loader.conf >Confidential: no >Severity: non-critical >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Thu May 03 14:50:08 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Sayetsky Anton >Release:8.3-RELEASE >Organization: >Environment: FreeBSD jsn.local 8.3-RELEASE FreeBSD 8.3-RELEASE #0 r234490: Fri Apr 20 17:23:38 EEST 2012 root@jsn.local:/tmp/obj/mnt/garbage/build/src/sys/JASONW amd64 >Description: When I configuring boot-time attaching of geli device, i *must* write device name to loader.conf, e.g. geli_da0_keyfile0_load="YES". I prefer GEOM labels, but I cannot write to loader.conf something like geli_gpt/gptlabel_keyfile0_load nor geli_gptlabel_keyfile0_load. >How-To-Repeat: Set up GELI on any disk with any parameters, and try to attach it via GEOM label in loader.conf. >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: mac_mls (fwd)
Hi Richard, I committed this minute ago, will MFC the fix in a couple of days. Thanks! Chris On 5/2/12 5:59 , Richard Kojedzinszky wrote: Kojedzinszky Richard Euronet Magyarorszag Informatikai Zrt. -- Forwarded message -- Date: Sat, 28 Apr 2012 23:24:06 +0200 (CEST) From: Richard Kojedzinszky To: freebsd-secur...@freebsd.org Subject: mac_mls Dear fbsd team, I am using 9.0, and found that running atop, and exiting from it when the kernel is compiled with MAC_MLS (or the module is loaded), then a panic raises, I think the following patch could fix it (as in mac_biba); --- sys/security/mac_mls/mac_mls.c.orig 2012-04-28 23:19:45.0 +0200 +++ sys/security/mac_mls/mac_mls.c 2012-04-28 23:20:13.0 +0200 @@ -2028,6 +2028,9 @@ if (!mls_enabled) return (0); + if (vplabel == NULL) + return (0); + subj = SLOT(cred->cr_label); obj = SLOT(vplabel); Regards, Kojedzinszky Richard Euronet Magyarorszag Informatikai Zrt. ___ 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" ___ 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"
conf/167566: [rc.d] ipdivert module loading vs. ipfw rc.d order issue
>Number: 167566 >Category: conf >Synopsis: [rc.d] ipdivert module loading vs. ipfw rc.d order issue >Confidential: no >Severity: serious >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu May 03 19:30:12 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Dmitry Marakasov >Release:FreeBSD 9.0-RELEASE amd64 >Organization: >Environment: System: FreeBSD hades.panopticon 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 10 01:33:18 MSK 2012 root@hades.panopticon:/usr/obj/usr/src/sys/HADES amd64 >Description: 1) if ipfw divert rules are used, ipdivert module must be loaded before rules are added, or ipfw add'ing divert rule will fail 2) ipdivert module is loaded by rc.d/natd 3) there's nothing to make rc.d/natd executed before rc.d/ipfw, and in reality the order is incorrect: % rcorder /etc/rc.d/* | grep -Ee 'ipfw|natd' /etc/rc.d/ipfw /etc/rc.d/natd Thus, someone using natd will run into incomplete ruleset and will have to add ipdivert_load="YES" to /boot/loader.conf Attached patch makes rc.d/natd run before rc.d/ipfw, so the module is automatcally loaded in time. >How-To-Repeat: >Fix: --- rc.d-natd.patch begins here --- diff --git etc/rc.d/natd etc/rc.d/natd index 35f17bb..fcc8920 100755 --- etc/rc.d/natd +++ etc/rc.d/natd @@ -5,6 +5,7 @@ # PROVIDE: natd # KEYWORD: nostart nojail +# BEFORE: ipfw . /etc/rc.subr . /etc/network.subr --- rc.d-natd.patch 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"
bin/167567: gpart(8) -a alignment silently overrides -b beginning option
>Number: 167567 >Category: bin >Synopsis: gpart(8) -a alignment silently overrides -b beginning option >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: Thu May 03 21:50:05 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Warren Block >Release:9-STABLE >Organization: >Environment: FreeBSD lightning 9.0-STABLE FreeBSD 9.0-STABLE #0 r234953: Thu May 3 09:21:21 MDT 2012 root@lightning:/usr/obj/usr/src/sys/LIGHTNING amd64 >Description: When both the -a and -b options are given, -a overrides the value given by -b. gpart add -t freebsd-ufs -a4k -b1m -s2g ada0 adds a partition that starts at the next available even multiple of 4k rather than at 1M. If the -b value is an even multiple of the -a value, it should be used. Otherwise, an error should be shown. >How-To-Repeat: gpart create -s gpt ada0 gpart add -t freebsd-boot -a4k -s512k ada0 gpart add -t freebsd-ufs -a4k -b1m -s2g ada0 gpart show ada0 => 34 42680253 ada0 GPT (20G) 34 6- free - (3.0k) 40 1024 1 freebsd-boot (512k) 1064 4194304 2 freebsd-ufs (2.0G) 4195368 38484919- free - (18G) The freebsd-ufs partition should start at 2048, or 1M. >Fix: If a -b value is given, compare it to the alignment value. Use if it matches the alignment, otherwise error out. >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: conf/167566: [rc.d] [patch] ipdivert module loading vs. ipfw rc.d order issue
Old Synopsis: [rc.d] ipdivert module loading vs. ipfw rc.d order issue New Synopsis: [rc.d] [patch] ipdivert module loading vs. ipfw rc.d order issue Responsible-Changed-From-To: freebsd-bugs->freebsd-rc Responsible-Changed-By: linimon Responsible-Changed-When: Thu May 3 22:36:34 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=167566 ___ 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/167562: [geli] geli cannot use gpt labels in loader.conf
Old Synopsis: geli cannot use gpt labels in loader.conf New Synopsis: [geli] geli cannot use gpt labels in loader.conf Responsible-Changed-From-To: freebsd-bugs->freebsd-geom Responsible-Changed-By: linimon Responsible-Changed-When: Thu May 3 22:37:03 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=167562 ___ 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/167555: [build] libarchive fails to build WITHOUT_OPENSSH due to missing hash algorithm files
Old Synopsis: libarchive fails to build WITHOUT_OPENSSH due to missing hash algorithm files New Synopsis: [build] libarchive fails to build WITHOUT_OPENSSH due to missing hash algorithm files Responsible-Changed-From-To: freebsd-bugs->kientzle Responsible-Changed-By: linimon Responsible-Changed-When: Thu May 3 22:41:49 UTC 2012 Responsible-Changed-Why: Over to maintainer. Maybe be duplicate of 164206. http://www.freebsd.org/cgi/query-pr.cgi?pr=167555 ___ 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/164206: [build] [patch] buildworld WITHOUT_OPENSSL stops at lib/libarchive
Synopsis: [build] [patch] buildworld WITHOUT_OPENSSL stops at lib/libarchive Responsible-Changed-From-To: freebsd-bugs->kientzle Responsible-Changed-By: linimon Responsible-Changed-When: Thu May 3 22:42:52 UTC 2012 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=164206 ___ 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/167567: gpart(8) -a alignment silently overrides -b beginning option
Synopsis: gpart(8) -a alignment silently overrides -b beginning option Responsible-Changed-From-To: freebsd-bugs->eadler Responsible-Changed-By: eadler Responsible-Changed-When: Fri May 4 00:49:05 UTC 2012 Responsible-Changed-Why: I'll take it. http://www.freebsd.org/cgi/query-pr.cgi?pr=167567 ___ 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"