Re: kern/165271: commit references a PR
The following reply was made to PR kern/165271; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/165271: commit references a PR
Date: Fri, 2 Mar 2012 08:49:22 + (UTC)
Author: mav
Date: Fri Mar 2 08:49:07 2012
New Revision: 232380
URL: http://svn.freebsd.org/changeset/base/232380
Log:
Fix names of some Marvell SATA chips. It looks like chips with proprietary
interface supported by mvs(4) are 88SX, while AHCI-like chips are 88SE.
PR: kern/165271
Submitted by:Jia-Shiun Li
MFC after: 1 week
Modified:
head/share/man/man4/ahci.4
head/share/man/man4/ata.4
head/sys/dev/ahci/ahci.c
head/sys/dev/ata/ata-pci.h
head/sys/dev/ata/chipsets/ata-ahci.c
head/sys/dev/ata/chipsets/ata-marvell.c
Modified: head/share/man/man4/ahci.4
==
--- head/share/man/man4/ahci.4 Fri Mar 2 07:23:28 2012(r232379)
+++ head/share/man/man4/ahci.4 Fri Mar 2 08:49:07 2012(r232380)
@@ -146,7 +146,7 @@ subclass 6 (SATA) and programming interf
.Pp
Also, in cooperation with atamarvell and atajmicron drivers of ata(4),
it supports AHCI part of legacy-PATA + AHCI-SATA combined controllers,
-such as JMicron JMB36x and Marvell 88SX61xx.
+such as JMicron JMB36x and Marvell 88SE61xx.
.Sh FILES
.Bl -tag -width /dev/led/ahcich*.locate
.It Pa /dev/led/ahcich*.act
Modified: head/share/man/man4/ata.4
==
--- head/share/man/man4/ata.4 Fri Mar 2 07:23:28 2012(r232379)
+++ head/share/man/man4/ata.4 Fri Mar 2 08:49:07 2012(r232380)
@@ -193,8 +193,8 @@ IT8211F, IT8212F, IT8213F.
.It JMicron:
JMB360, JMB361, JMB363, JMB365, JMB366, JMB368.
.It Marvell
-88SX5040, 88SX5041, 88SX5080, 88SX5081, 88SX6041, 88SX6042, 88SX6081,
88SX6101,
-88SX6102, 88SX6111, 88SX6121, 88SX6141, 88SX6145, 88SX7042.
+88SX5040, 88SX5041, 88SX5080, 88SX5081, 88SX6041, 88SX6042, 88SX6081,
88SE6101,
+88SE6102, 88SE6111, 88SE6121, 88SE6141, 88SE6145, 88SX7042.
.It National:
SC1100.
.It NetCell:
Modified: head/sys/dev/ahci/ahci.c
==
--- head/sys/dev/ahci/ahci.c Fri Mar 2 07:23:28 2012(r232379)
+++ head/sys/dev/ahci/ahci.c Fri Mar 2 08:49:07 2012(r232380)
@@ -186,13 +186,13 @@ static struct {
{0x2365197b, 0x00, "JMicron JMB365",AHCI_Q_NOFORCE},
{0x2366197b, 0x00, "JMicron JMB366",AHCI_Q_NOFORCE},
{0x2368197b, 0x00, "JMicron JMB368",AHCI_Q_NOFORCE},
- {0x61ab, 0x00, "Marvell 88SX6111", AHCI_Q_NOFORCE | AHCI_Q_1CH |
+ {0x61ab, 0x00, "Marvell 88SE6111", AHCI_Q_NOFORCE | AHCI_Q_1CH |
AHCI_Q_EDGEIS},
- {0x612111ab, 0x00, "Marvell 88SX6121", AHCI_Q_NOFORCE | AHCI_Q_2CH |
+ {0x612111ab, 0x00, "Marvell 88SE6121", AHCI_Q_NOFORCE | AHCI_Q_2CH |
AHCI_Q_EDGEIS | AHCI_Q_NONCQ | AHCI_Q_NOCOUNT},
- {0x614111ab, 0x00, "Marvell 88SX6141", AHCI_Q_NOFORCE | AHCI_Q_4CH |
+ {0x614111ab, 0x00, "Marvell 88SE6141", AHCI_Q_NOFORCE | AHCI_Q_4CH |
AHCI_Q_EDGEIS | AHCI_Q_NONCQ | AHCI_Q_NOCOUNT},
- {0x614511ab, 0x00, "Marvell 88SX6145", AHCI_Q_NOFORCE | AHCI_Q_4CH |
+ {0x614511ab, 0x00, "Marvell 88SE6145", AHCI_Q_NOFORCE | AHCI_Q_4CH |
AHCI_Q_EDGEIS | AHCI_Q_NONCQ | AHCI_Q_NOCOUNT},
{0x91201b4b, 0x00, "Marvell 88SE912x", AHCI_Q_EDGEIS|AHCI_Q_NOBSYRES},
{0x91231b4b, 0x11, "Marvell 88SE912x", AHCI_Q_NOBSYRES|AHCI_Q_ALTSIG},
Modified: head/sys/dev/ata/ata-pci.h
==
--- head/sys/dev/ata/ata-pci.h Fri Mar 2 07:23:28 2012(r232379)
+++ head/sys/dev/ata/ata-pci.h Fri Mar 2 08:49:07 2012(r232380)
@@ -278,12 +278,12 @@ struct ata_pci_controller {
#define ATA_M88SX6042 0x604211ab
#define ATA_M88SX6081 0x608111ab
#define ATA_M88SX7042 0x704211ab
-#define ATA_M88SX6101 0x610111ab
-#define ATA_M88SX6102 0x610211ab
-#define ATA_M88SX6111 0x61ab
-#define ATA_M88SX6121 0x612111ab
-#define ATA_M88SX6141 0x614111ab
-#define ATA_M88SX6145 0x614511ab
+#define ATA_M88SE6101 0x610111ab
+#define ATA_M88SE6102 0x610211ab
+#define ATA_M88SE6111 0x61ab
+#define ATA_M88SE6121 0x612111ab
+#define ATA_M88SE6141 0x614111ab
+#define ATA_M88SE6145 0x614511ab
#define ATA_MARVELL2_ID 0x1b4b
#define ATA_MICRON_ID 0x1042
Modified: head/sys/dev/ata/chipsets/ata-ahci.c
==
--- head/sys/dev/ata/chipsets/ata-ahci.c Fri Mar 2 07:23:28 2012
kern/165622: [ndis][panic][patch] Unregistered use of FPU in kernel on amd64
>Number: 165622
>Category: kern
>Synopsis: [ndis][panic][patch] Unregistered use of FPU in kernel on amd64
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Fri Mar 02 13:50:09 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Vladislav Movchan
>Release:FreeBSD 10.0-CURRENT
>Organization:
>Environment:
FreeBSD starlight 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r232379: Fri Mar 2
13:24:25 EET 2012 root@starlight:/usr/obj/usr/src/sys/Mephistopheles amd64
>Description:
Some miniport drivers (windows NIC drivers) could use FPU in kernel what cause
"Unregistered use of FPU in kernel" panic.
I've seen this only in amd64 case; i386 seems to be not affected.
Same is mentioned in this two messages:
http://lists.freebsd.org/pipermail/svn-src-all/2010-March/021770.html
http://lists.freebsd.org/pipermail/svn-src-all/2010-March/021773.html
Point when panic occurs depends on the driver. In my case it happening during
the first attempt to transmit a packet.
Panic message:
panic: Unregistered use of FPU in kernel
cpuid = 3
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
kdb_backtrace() at kdb_backtrace+0x37
panic() at panic+0x1cd
trap() at trap+0x71f
calltrap() at calltrap+0x8
--- trap 0x16, rip = 0x83c37e0e, rsp = 0xff80d116d7c0, rbp =
0xff80075df520 ---
__stop_set_sysinit_set() at __stop_set_sysinit_set+0xe6ee
dmapbase() at 0xfe0040fb5180
(null)() at 0xff80075df520
dmapbase() at 0xfe0040f83d00
dmapbase() at 0xfe0040f83e00
dmapbase() at 0xfe0040f8b080
dmapbase() at 0xfe0040f8b180
dmapbase() at 0xfe0040f8b280
..
dmapbase() at 0xfe0040fb4600
dmapbase() at 0xfe0040fb4700
dmapbase() at 0xfe0040fb4800
dmapbase() at 0xfe0040fb4900
dmapbase() at 0xfe0040fb4a00
Backtrace:
#0 doadump (textdump=-787033584) at /usr/src/sys/kern/kern_shutdown.c:268
268 if (textdump && textdump_pending) {
(kgdb) #0 doadump (textdump=-787033584) at
/usr/src/sys/kern/kern_shutdown.c:268
#1 0x802de36c in db_fncall (dummy1=Variable "dummy1" is not available.
)
at /usr/src/sys/ddb/db_command.c:573
#2 0x802de6a1 in db_command (last_cmdp=0x80dcd560,
cmd_table=Variable "cmd_table" is not available.
) at /usr/src/sys/ddb/db_command.c:449
#3 0x802de8f0 in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:502
#4 0x802e0ad4 in db_trap (type=Variable "type" is not available.
) at /usr/src/sys/ddb/db_main.c:229
#5 0x806d3bb1 in kdb_trap (type=3, code=0, tf=0xff80d116d440)
at /usr/src/sys/kern/subr_kdb.c:629
#6 0x80942f68 in trap (frame=0xff80d116d440)
at /usr/src/sys/amd64/amd64/trap.c:591
#7 0x8092c1cf in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:228
#8 0x806d36ab in kdb_enter (why=0x80a3fb16 "panic",
msg=0x80 ) at cpufunc.h:63
#9 0x8069aea6 in panic (fmt=Variable "fmt" is not available.
)
at /usr/src/sys/kern/kern_shutdown.c:633
#10 0x809434ef in trap (frame=Variable "frame" is not available.
) at /usr/src/sys/amd64/amd64/trap.c:478
#11 0x8092c1cf in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:228
#12 0x83c37e0e in ndis_Rtenic64_sys_drv_data_start ()
from /boot/modules/Rtenic64_sys.ko
#13 0x in ?? ()
#14 0x80a40a28 in __func__.17200 ()
#15 0x07420001 in ?? ()
#16 0x80a42b69 in link_elf_methods ()
#17 0xff80d116d800 in ?? ()
#18 0x in ?? ()
#19 0x in ?? ()
#20 0x in ?? ()
..
#79 0x in ?? ()
#80 0x in ?? ()
#81 0x in ?? ()
#82 0x in ?? ()
#83 0xff80d116dad0 in ?? ()
#84 0xfe007b2b1348 in ?? ()
#85 0xff80075de000 in ?? ()
#86 0xfe0008410800 in ?? ()
#87 0xff80075deff0 in ?? ()
#88 0xff80075de000 in ?? ()
#89 0xff80075de000 in ?? ()
#90 0xff80d116dad0 in ?? ()
#91 0x in ?? ()
#92 0x83c3d3ce in ndis_Rtenic64_sys_drv_data_start ()
from /boot/modules/Rtenic64_sys.ko
#93 0xff80d116 in ?? ()
#94 0xfe00 in ?? ()
#95 0xff80 in ?? ()
#96 0xff80d116d900 in ?? ()
#97 0x83c3d284 in ndis_Rtenic64_sys_drv_data_start ()
from /boot/modules/Rtenic64_sys.ko
#98 0x840e07b9 in x86_64_call1 ()
at /usr/src/sys/modules/ndis/../../compat/ndis/winx64_wrap.S:130
#99 0xfe007b2b1328 in ?? ()
#100 0xfe007b154000 in ?? ()
#101 0xff80075deff8 in ?? ()
#102 0xfe007b2b1328 in ?? ()
#103 0xff80d116dad0 in ?? ()
#104 0x840d3e87 in ndis_intrhand (dpc=Variable "dpc" is not available.
)
at /usr/src/sys/modules/ndis/../../compat/ndis/subr_ndis.c:2234
Previous frame inner to this fram
kern/165630: [ndis][panic][patch] IRQL_NOT_GREATER_THAN
>Number: 165630
>Category: kern
>Synopsis: [ndis][panic][patch] IRQL_NOT_GREATER_THAN
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Fri Mar 02 15:30:06 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Vladislav Movchan
>Release:FreeBSD 10.0-CURRENT
>Organization:
>Environment:
FreeBSD starlight 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r232379: Fri Mar 2
13:24:25 EET 2012 root@starlight:/usr/obj/usr/src/sys/Mephistopheles amd64
>Description:
There is a race condition inside of sys/compat/ndis/subr_hal.c:KfRaiseIrql()
function which could lead to "IRQL_NOT_GREATER_THAN" panic.
Race could happen if after execution of this line:
oldirql = KeGetCurrentIrql();
kthread got preempted and later appeared on another CPU core which has another
"irq level".
In this case "oldirql != DISPATCH_LEVEL" check will have no much sense as on
current CPU core "irq level" could be different. As result we will skip
sched_pin + mtx_lock lines when it was necessary execute them, or execute then
when it necessary to skip.
To fix this race we pin to current CPU core before obtaining "irq level", then
we made "oldirql != DISPATCH_LEVEL" check and later we "unpin" (if we find that
previous sched_pin() was not actually necessary).
Panic message:
panic: IRQL_NOT_GREATER_THAN
cpuid = 3
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
kdb_backtrace() at kdb_backtrace+0x37
panic() at panic+0x1cd
KfLowerIrql() at KfLowerIrql+0x62
ntoskrnl_workitem_thread() at ntoskrnl_workitem_thread+0xab
fork_exit() at fork_exit+0x189
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xff80d111acf0, rbp = 0 ---
KDB: enter: panic
Backtrace:
#0 doadump (textdump=-787372224) at /usr/src/sys/kern/kern_shutdown.c:268
268 if (textdump && textdump_pending) {
(kgdb) #0 doadump (textdump=-787372224) at
/usr/src/sys/kern/kern_shutdown.c:268
#1 0x802de36c in db_fncall (dummy1=Variable "dummy1" is not available.
)
at /usr/src/sys/ddb/db_command.c:573
#2 0x802de6a1 in db_command (last_cmdp=0x80dcd560,
cmd_table=Variable "cmd_table" is not available.
) at /usr/src/sys/ddb/db_command.c:449
#3 0x802de8f0 in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:502
#4 0x802e0ad4 in db_trap (type=Variable "type" is not available.
) at /usr/src/sys/ddb/db_main.c:229
#5 0x806d3bb1 in kdb_trap (type=3, code=0, tf=0xff80d111a970)
at /usr/src/sys/kern/subr_kdb.c:629
#6 0x80942f68 in trap (frame=0xff80d111a970)
at /usr/src/sys/amd64/amd64/trap.c:591
#7 0x8092c1cf in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:228
#8 0x806d36ab in kdb_enter (why=0x80a3fb16 "panic",
msg=0x80 ) at cpufunc.h:63
#9 0x8069aea6 in panic (fmt=Variable "fmt" is not available.
)
at /usr/src/sys/kern/kern_shutdown.c:633
#10 0x840d6ff2 in KfLowerIrql (oldirql=Variable "oldirql" is not
available.
)
at /usr/src/sys/modules/ndis/../../compat/ndis/subr_hal.c:417
#11 0x840dba5b in ntoskrnl_workitem_thread (arg=Variable "arg" is not
available.
)
at /usr/src/sys/modules/ndis/../../compat/ndis/subr_ntoskrnl.c:2766
#12 0x8066b039 in fork_exit (
callout=0x840db9b0 ,
arg=0xfe00206a9cc0, frame=0xff80d111ac40)
at /usr/src/sys/kern/kern_fork.c:992
#13 0x8092c6fe in fork_trampoline ()
at /usr/src/sys/amd64/amd64/exception.S:602
#14 0x in ?? ()
#15 0x in ?? ()
#16 0x0001 in ?? ()
#17 0x in ?? ()
#18 0x in ?? ()
#19 0x in ?? ()
#20 0x in ?? ()
#21 0x in ?? ()
#22 0x in ?? ()
#23 0x in ?? ()
#24 0x in ?? ()
#25 0x in ?? ()
#26 0x in ?? ()
#27 0x in ?? ()
#28 0x in ?? ()
#29 0x in ?? ()
#30 0x in ?? ()
#31 0x in ?? ()
#32 0x in ?? ()
#33 0x in ?? ()
#34 0x in ?? ()
#35 0x in ?? ()
#36 0x in ?? ()
#37 0x in ?? ()
#38 0x8240f200 in tdq_cpu ()
#39 0x in ?? ()
#40 0x8240f1c0 in affinity ()
#41 0xfe0020971900 in ?? ()
#42 0xff80d111a980 in ?? ()
#43 0xff80d111a928 in ?? ()
#44 0xfe00082bf900 in ?? ()
#45 0x806c64ac in sched_switch (td=0xfe00206a9cc0,
newtd=0x840db9b0, flags=Variable "flags" is not available.
) at /usr/src/sys/kern/sched_ule.c:1890
Previous frame inner to this frame (corrupt stack?)
(kgdb)
>How-To-Repeat:
There are no special conditions necessary to reprodu
dep-trace v. tsort (mac ports depends support)
Hi, BSD and Apple needs tsort(1) for portage still I believe. Topological sorting isn't quite right packaging. Please see: http://sourceforge.net/projects/dep-trace It is a "drop-in" replacement (operates like a /bin/tsort) but is right for pkg depends (ie, for portage: you need to dl source, order of compile may be required, sometimes gets missing message or "loop in depends" message when attempting to compile and install pkg) I'm a debian user but i wish I had a bsd machine :) So i do not know allot of BSD maintainer / mailing list specifics. Please give me a handicap there ! Thanks and thanks again, John p.s. (dep-trace itself has no depends (a /bin), has improvements, and is "more hackable" than tsort as to coding new ordering rules against lists - which in tsort "loop detected attempting to recover" is not as easy i feel. ___ 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/165642: kde4: keeps locking the screen.
>Number: 165642 >Category: misc >Synopsis: kde4: keeps locking the screen. >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: Sat Mar 03 00:10:06 UTC 2012 >Closed-Date: >Last-Modified: >Originator: adrian chadd >Release:FreeBSD-9.0 RELEASE >Organization: >Environment: >Description: I'm running this on both a Thinkpad T60 and T40. In both instances, I've installed kde4 via pkg_add -vr (so binary packages) after installing 9.0-RELEASE. The screen "locks" (as in asks for a password) very frequently. It's easily triggerable by using the function key. But i've seen it do it at odd moments too. I'll then be greeted by a large spam of notifications about power saving. (This is with AC plugged in.) I'd like to assist in debugging why this is occuring but I have no idea where to begin. :) >How-To-Repeat: Hit "fn" on said thinkpad models. >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"
kern/165643: Missing vnet restores in net/if_ethersubr.c
>Number: 165643
>Category: kern
>Synopsis: Missing vnet restores in net/if_ethersubr.c
>Confidential: no
>Severity: serious
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Sat Mar 03 01:10:08 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Vijay Singh
>Release:9/stable
>Organization:
>Environment:
>Description:
There are some missing vnet restore in net/if_ethersubr.c that can cause
networking code to execute in the wrong vnet context.
A patch is provided here:
[pc20 /u/vijay/bsd/CODE/9s/sys]# svn diff net/if_ethersubr.c
Index: net/if_ethersubr.c
===
--- net/if_ethersubr.c (revision 232242)
+++ net/if_ethersubr.c (working copy)
@@ -661,8 +661,10 @@
m = (*lagg_input_p)(ifp, m);
if (m != NULL)
ifp = m->m_pkthdr.rcvif;
- else
+ else {
+ CURVNET_RESTORE();
return;
+ }
}
/*
@@ -681,6 +683,7 @@
#endif
ifp->if_ierrors++;
m_freem(m);
+ CURVNET_RESTORE();
return;
}
>How-To-Repeat:
>Fix:
[pc20 /u/vijay/bsd/CODE/9s/sys]# svn diff net/if_ethersubr.c
Index: net/if_ethersubr.c
===
--- net/if_ethersubr.c (revision 232242)
+++ net/if_ethersubr.c (working copy)
@@ -661,8 +661,10 @@
m = (*lagg_input_p)(ifp, m);
if (m != NULL)
ifp = m->m_pkthdr.rcvif;
- else
+ else {
+ CURVNET_RESTORE();
return;
+ }
}
/*
@@ -681,6 +683,7 @@
#endif
ifp->if_ierrors++;
m_freem(m);
+ CURVNET_RESTORE();
return;
}
>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/165644: drtrace finds the syntax error in /usr/lib/dtrace/psinfo.d: syntax error near "uid_t"
>Number: 165644
>Category: misc
>Synopsis: drtrace finds the syntax error in /usr/lib/dtrace/psinfo.d:
>syntax error near "uid_t"
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Sat Mar 03 01:40:07 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Yuri
>Release:9.0
>Organization:
n/a
>Environment:
>Description:
Running this script:
dtrace -n 'proc:::signal-send /pid/ { printf("%s -%d
%d",execname,args[2],args[1]->pr_pid); }'
I get this error:
dtrace: invalid probe specifier proc:::signal-send /pid/ { printf("%s -%d
%d",execname,args[2],args[1]->pr_pid); }: "/usr/lib/dtrace/psinfo.d", line 37:
syntax error near "uid_t"
>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/161552: [rctl] [panic] kernel panic with RCTL option: racct_alloc_resource: usage < 0
Synopsis: [rctl] [panic] kernel panic with RCTL option: racct_alloc_resource: usage < 0 State-Changed-From-To: feedback->open State-Changed-By: jh State-Changed-When: Sat Mar 3 07:45:40 UTC 2012 State-Changed-Why: Feedback received. http://www.freebsd.org/cgi/query-pr.cgi?pr=161552 ___ 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"
