Re: kern/162181: [snd_emu10k1] [patch] The kernel sound driver module snd_emu10k1.ko hangs when loaded.
Old Synopsis: [patch] The kernel sound driver module snd_emu10k1.ko hangs when loaded. New Synopsis: [snd_emu10k1] [patch] The kernel sound driver module snd_emu10k1.ko hangs when loaded. Responsible-Changed-From-To: freebsd-bugs->freebsd-multimedia Responsible-Changed-By: linimon Responsible-Changed-When: Mon Oct 31 08:17:06 UTC 2011 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=162181 ___ 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/162187: /etc/localtime is never updated
>Number: 162187 >Category: conf >Synopsis: /etc/localtime is never updated >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 Oct 31 09:30:15 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Gleb Smirnoff >Release:FreeBSD 10.0-CURRENT i386 >Organization: >Environment: System: FreeBSD think 10.0-CURRENT FreeBSD 10.0-CURRENT #12 r226163M: Sun Oct 9 16:17:18 MSD 2011 glebius@think:/usr/obj/usr/src/head/sys/THINKPAD_T60 i386 >Description: By default, the /etc/localtime file isn't a symlink but a copy of timezone selected upon installation with tzsetup. As the system undergoes upgrades, runs installworld, mergemaster, etc, the file /etc/localtime is never touched. For example in my system it is dated year 2004. The problem pops up when the system doesn't change its timezone, but the timezone the system resides in is changed itself. For example new daylight saving policies are published by state. Administator expects that keeping system up to date, or installing a package upon /usr/share/zoneinfo would make his system configured to an updated timezone. >How-To-Repeat: 1) Update your system. 2) ls -l /etc/localtime. >Fix: 1) At job, our network installation process makes /etc/localtime a symlink. All these systems underwent the transition process to new 2011 daylight saving timezone in Russia correctly, unlike the systems installed by sysinstall. We have been running hundreds of installations with symlink for years, and we didn't notice any problems with this approach. 2) If having symlink to /usr/share/zoneinfo in /etc is not feasible for some reason, then some updating tool should check whether the /etc/localtime copy needs to be updated. Probably mergemaster? >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/162189: FreeBSD unzip does not restore file permissions properly
>Number: 162189 >Category: bin >Synopsis: FreeBSD unzip does not restore file permissions properly >Confidential: no >Severity: non-critical >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Oct 31 09:40:08 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Claude Buisson >Release:FreeBSD 9.0-BETA3, 9.0-CURRENT >Organization: >Environment: FreeBSD 9.0-BETA3 #0: Mon Sep 26 17:07:05 CEST 2011 toor@inspiron:/usr/obj/home/src/sys/INSPIRON9X i386 (r225744) FreeBSD zorglub 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Tue Aug 16 17:35:32 CEST 2011 toor@zorglub:/usr/obj/home/src/sys/ZORGLUB amd64 (r224294) >Description: When unzipping an archive, the file permissions are not restored properly (but they are by unzip from ports). More precisely the execute bit seems to be set unconditionnally for non executable files. >How-To-Repeat: create a zip archive, unzip it and compare. >Fix: use the following workarounds: 1- delete the /usr/sbin/unzip executable. or 2- create an alias and modify shells/perl/.. scripts to force use of port unzip. >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/162187: /etc/localtime is never updated
Synopsis: /etc/localtime is never updated State-Changed-From-To: open->closed State-Changed-By: glebius State-Changed-When: Mon Oct 31 10:08:21 UTC 2011 State-Changed-Why: I've found that some of my systems lacked /var/db/zoneinfo, which is required for correct update of /etc/localtime. http://www.freebsd.org/cgi/query-pr.cgi?pr=162187 ___ 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/162195: panic with soft updates journaling during umount -f
>Number: 162195
>Category: kern
>Synopsis: panic with soft updates journaling during umount -f
>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 Oct 31 11:30:11 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator: Kirk Russell
>Release:FreeBSD 9.0-RC1
>Organization:
bstg
>Environment:
FreeBSD kleenex 9.0-RC1 FreeBSD 9.0-RC1 #0: Sun Oct 30 15:34:30 GMT 2011
root@kleenex:/usr/obj/usr/src/sys/KLEENEX i386
>Description:
I have been testing a scratch filesystem, with soft updates journaling enabled.
During a test, if I run umount -f, I will see this panic:
panic: check_inode_unwritten: busy inode
Here is the source to the load test:
http://www.ba23.org/bstgbugs/bstg0004.sh
Here is the output from /var/crash/core.txt:
http://www.ba23.org/bstgbugs/bstg0004.core.txt.gz
kleenex# sh bstg0004.sh
/dev/ada0p4: 56320.0MB (115343360 sectors) block size 32768, fragment size 4096
using 77 cylinder groups of 740.00MB, 23680 blks, 47360 inodes.
with soft updates
super-block backups (for fsck -b #) at:
192, 1515712, 3031232, 4546752, 6062272, 7577792, 9093312, 10608832, 12124352,
13639872, 15155392, 16670912, 18186432, 19701952, 21217472, 22732992,
24248512, 25764032, 27279552, 28795072, 30310592, 31826112, 33341632,
34857152, 36372672, 37888192, 39403712, 40919232, 42434752, 43950272,
45465792, 46981312, 48496832, 50012352, 51527872, 53043392, 54558912,
56074432, 57589952, 59105472, 60620992, 62136512, 63652032, 65167552,
66683072, 68198592, 69714112, 71229632, 72745152, 74260672, 75776192,
77291712, 78807232, 80322752, 81838272, 83353792, 84869312, 86384832,
87900352, 89415872, 90931392, 92446912, 93962432, 95477952, 96993472,
98508992, 100024512, 101540032, 10302, 104571072, 106086592, 107602112,
109117632, 110633152, 112148672, 113664192, 115179712
Using inode 4 in cg 0 for 33554432 byte journal
newfs: soft updates journaling set
Test started [fstorture 2.1-pfh]: Mon Oct 31 11:24:34 GMT 2011
Running for 3 seconds
panic: check_inode_unwritten: busy inode
cpuid = 0
KDB: enter: panic
[ thread pid 1383 tid 100058 ]
Stopped at kdb_enter+0x3a: movl$0,kdb_why
db>
>How-To-Repeat:
Change the variables to match your installation. Then run the script.
#!/bin/sh
#
# Copyright 2011 Kirk J. Russell
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#
# Web page about FsTorture
# - http://fstools.macosforge.org/trac/wiki/FsTorture
#
# Port FsTorture to Freebsd
# - get source http://fstools.macosforge.org/trac/wiki/ToolsDevelopment
# - get membership.h http://www.ba23.org/~kirk/bstgbugs/membership.h
# - get patch http://www.ba23.org/~kirk/bstgbugs/fstorture.patch
# - gmake CFLAGS=-I. LDFLAGS="-lpthread -lm"
#
# Run this script and you will get a panic with FreeBSD 9.0-RC1
# panic: check_inode_unwritten: busy inode
#
# If you disable soft updates journaling, the panic will not happen.
#
fstorture=../fstorture/fstorture
# block special device used for testing
fsspec=/dev/ada0p4
# mount point used for filesystem testing
fsfile=/fubar
mkdir -p ${fsfile}
# run the test for less then 2 minutes
for tries in 1 2 3
do
for secs in 1 1 2 3 5 7 13
do
# Enable soft updates journaling
newfs -j ${fsspec}
mount ${fsspec} ${fsfile}
# run fstorture in the background
mkdir ${fsfile}/a ${fsfile}/b
timeout="$(printf "%d+2\n" ${secs} | bc)"
${fstorture} ${fsfile}/a ${fsfile}/b 25 -t ${timeout}s &
# block and then force the umount
sleep ${secs}
umount -f ${fsfile}
# clean up
killall fstorture fstorture fstorture
wait
done
done
>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"
misc/162201: [patch] multicast forwarding cache hash always allocated with size 0, resulting in buffer overrun
>Number: 162201
>Category: misc
>Synopsis: [patch] multicast forwarding cache hash always allocated with
>size 0, resulting in buffer overrun
>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 Oct 31 16:30:10 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator: Stevan Markovic
>Release:8.2.0 customized
>Organization:
McAfee inc
>Environment:
>Description:
Bug is observed as kernel panic shortly after stopping XORP (www.xorp.org)
configured for PIM/SM routing. Debugging discovered that at the time of MALLOC
for V_nexpire in ip_mroute.c::vnet_mroute_init() size variable mfchashsize
always has value 0.
Why: variable mfchashsize is initialized in module event handler which is
executed with SI_ORDER_ANY ordering tag which happens _after_ variable usage
in MALLOC in VNET_SYSINIT with SI_ORDER_MIDDLE.
Fix simply moves variable initialization before its usage in vnet_mroute_init.
This bug is discovered and fixed in McAfee Inc development.
>How-To-Repeat:
Hard to reproduce since system behavior after memory overwrite is
unpredictable. Multicast forwarding cashe hash overrun always happens after:
a) configuring xorp to use PIM/SM
b) starting xorp_rtrmgr
c) stopping xorp_rtrmgr.
>Fix:
Fix simply moves mfchashsize variable initialization before its usage in
vnet_mroute_init.
Patch attached with submission follows:
Index: ip_mroute.c
===
RCS file: /projects/freebsd/src_cvsup/src/sys/netinet/ip_mroute.c,v
retrieving revision 1.161
diff -u -r1.161 ip_mroute.c
--- ip_mroute.c 22 Nov 2010 19:32:54 - 1.161
+++ ip_mroute.c 31 Oct 2011 15:54:53 -
@@ -2814,7 +2814,13 @@
static void
vnet_mroute_init(const void *unused __unused)
{
-
+ mfchashsize = MFCHASHSIZE;
+ if (TUNABLE_ULONG_FETCH("net.inet.ip.mfchashsize", &mfchashsize) &&
+ !powerof2(mfchashsize)) {
+ printf("WARNING: %s not a power of 2; using default\n",
+ "net.inet.ip.mfchashsize");
+ mfchashsize = MFCHASHSIZE;
+ }
MALLOC(V_nexpire, u_char *, mfchashsize, M_MRTABLE, M_WAITOK|M_ZERO);
bzero(V_bw_meter_timers, sizeof(V_bw_meter_timers));
callout_init(&V_expire_upcalls_ch, CALLOUT_MPSAFE);
@@ -2855,13 +2861,6 @@
MFC_LOCK_INIT();
VIF_LOCK_INIT();
- mfchashsize = MFCHASHSIZE;
- if (TUNABLE_ULONG_FETCH("net.inet.ip.mfchashsize", &mfchashsize) &&
- !powerof2(mfchashsize)) {
- printf("WARNING: %s not a power of 2; using default\n",
- "net.inet.ip.mfchashsize");
- mfchashsize = MFCHASHSIZE;
- }
pim_squelch_wholepkt = 0;
TUNABLE_ULONG_FETCH("net.inet.pim.squelch_wholepkt",
>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/162201: [ip] [patch] multicast forwarding cache hash always allocated with size 0, resulting in buffer overrun
Old Synopsis: [patch] multicast forwarding cache hash always allocated with size 0, resulting in buffer overrun New Synopsis: [ip] [patch] multicast forwarding cache hash always allocated with size 0, resulting in buffer overrun Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Oct 31 16:46:16 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=162201 ___ 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/162211: regression bug in calendar 8.2, 8-stable & current, OK in 8.1 & 7.4 & 6.4
>Number: 162211 >Category: bin >Synopsis: regression bug in calendar 8.2, 8-stable & current, OK in 8.1 >& 7.4 & 6.4 >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 Nov 01 02:00:24 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Julian H. Stacey >Release:FreeBSD 8.2-RELEASE amd64 >Organization: http://berklix.com BSD Linux Unix Consultancy, Munich/Muenchen. >Environment: System: FreeBSD fire.js.berklix.net 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu Jun 2 23:10:13 CEST 2011 j...@blak.js.berklix.net:/ad6s4/release/8.2-RELEASE/src/sys/amd64/compile/FIRE64.small amd64 >Description: User groups rely on calendar meeting dates such as 1st Tuesday, 3rd Wednesday, Last Sunday each month. That broke in 8.2-RELEASE & 8-stable & current >How-To-Repeat: date # Tue Nov 1 ... echo > ~/tmp/calendar_test_data << EOF /* caution tabs in here so do not mouse copy */ Tuesday+1 first Tuesday in month Wednesday Midweek Thursday-1 last Thursday in month EOF 7.4 & 8.1-RELEASE: calendar -f ~/tmp/calendar_test_data Nov 1* first Tuesday in month Nov 2* Midweek 8.2-RELEASE & 8-stable & current Unprocessed: --- date: |Tuesday+1| flags: 10a - dayofweek modifierindex variable modifierindex: |+1| dayofweek: |Tuesday| (2) Ignored: Tuesday+1 first Tuesday in month Unprocessed: --- date: |Thursday-1| flags: 10a - dayofweek modifierindex variable modifierindex: |-1| dayofweek: |Thursday| (4) Ignored: Thursday-1 last Thursday in month Nov 2* Midweek PS Some other good & bad patterns I tried : /* 8.2 * /Friday testtestResult: Emits nothing*/ /* 8.2 * /Friday-1 testtestResult: Emits nothing */ /* 8.2 * FridaytesttestResult: OK Emits */ /* 8.2 * Friday-0 testtestResult: Emits nothing*/ /* 8.2 * Friday-1 testtestResult: Emits nothing*/ /* 8.2 * Friday-2 testtestResult: Emits nothing*/ /* 8.2 *''/Friday testtestResult: Emits nothing*/ /* 8.2 *''/Friday+1testtestResult: Emits nothing*/ /* 8.2 *''/Friday-0testtestResult: Emits nothing*/ /* 8.2 *''/Friday-1testtestResult: Emits nothing*/ /* 8.2 2011/10/27 testtestResult: OK Emits */ /* 8.2 Friday testtestResult: OK Emits */ /* 8.2 Friday +1 testtestResult: Emits nothing*/ /* 8.2 Friday+1testtestResult: Errors, and says Ignored*/ /* 6.4 Friday-1testtestResult: OK Emits */ /* 8.2 Friday-1testtestResult: Errors, and says Ignored*/ /* 8.2 Oct Friday -1 testtestResult: Emits nothing */ /* 8.2 Oct Friday-1testtestResult: Emits nothing*/ >Fix: http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.bin/calendar/calendar.c shows edwin@ was last person interested in calendar.c Mon Aug 23 22:09:25 2010 UTC ... r205821: Long awaited update to the calendar system: - Repeating events ... so FYI cc'd him as he's hopefully familiar with sources. >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/116722: ntpd(8): ntpd core dumps if hostnames are not specifed with "-4" option
Synopsis: ntpd(8): ntpd core dumps if hostnames are not specifed with "-4" option State-Changed-From-To: open->closed State-Changed-By: wblock State-Changed-When: Tue Nov 1 04:20:10 UTC 2011 State-Changed-Why: No longer applies. http://www.freebsd.org/cgi/query-pr.cgi?pr=116722 ___ 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"
