From nobody@FreeBSD.org  Thu Apr 10 05:14:06 2008
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 47D7D106566B
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 10 Apr 2008 05:14:06 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id 3854C8FC12
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 10 Apr 2008 05:14:06 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.2/8.14.2) with ESMTP id m3A5DkbX069825
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 10 Apr 2008 05:13:46 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.2/8.14.1/Submit) id m3A5DkRv069820;
	Thu, 10 Apr 2008 05:13:46 GMT
	(envelope-from nobody)
Message-Id: <200804100513.m3A5DkRv069820@www.freebsd.org>
Date: Thu, 10 Apr 2008 05:13:46 GMT
From: bob frazier <bobf@mrp3.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: occasional crash/boot while running Xorg
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         122615
>Category:       kern
>Synopsis:       [devfs] [panic] occasional crash/boot while running Xorg
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    jh
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Apr 10 05:20:00 UTC 2008
>Closed-Date:    Wed Apr 14 15:59:17 UTC 2010
>Last-Modified:  Wed Apr 14 15:59:17 UTC 2010
>Originator:     bob frazier
>Release:        FreeBSD 7.0-STABLE
>Organization:
SFT inc.
>Environment:
FreeBSD hack.SFT.local 7.0-STABLE FreeBSD 7.0-STABLE #0: Tue Apr  1 01:11:09 PDT 2008     root@hack.SFT.local:/usr/obj/usr/src/sys/GENERIC  i386
>Description:
While Xorg is running and a reasonably large number of resources are in use, the system will occasionally reboot itself.  Sometimes Xorg crashes on its own a signal 11, but often enough the entire system will crash (panic) and reboot.  I have saved the most recent crash dump files and will upload them here if possible (otherwise I'll send by e-mail if you ask me).

pciconf output
hostb0@pci0:0:0:0:	class=0x060000 card=0x1b291019 chip=0x07411039 rev=0x03 hdr=0x00
pcib1@pci0:0:1:0:	class=0x060400 card=0x00000000 chip=0x00031039 rev=0x00 hdr=0x01
isab0@pci0:0:2:0:	class=0x060100 card=0x00000000 chip=0x09641039 rev=0x36 hdr=0x00
atapci0@pci0:0:2:5:	class=0x01018a card=0x1b291019 chip=0x55131039 rev=0x01 hdr=0x00
pcm0@pci0:0:2:7:	class=0x040100 card=0x1b291019 chip=0x70121039 rev=0xa0 hdr=0x00
ohci0@pci0:0:3:0:	class=0x0c0310 card=0x1b291019 chip=0x70011039 rev=0x0f hdr=0x00
ohci1@pci0:0:3:1:	class=0x0c0310 card=0x1b291019 chip=0x70011039 rev=0x0f hdr=0x00
ohci2@pci0:0:3:2:	class=0x0c0310 card=0x1b291019 chip=0x70011039 rev=0x0f hdr=0x00
ehci0@pci0:0:3:3:	class=0x0c0320 card=0x1b291019 chip=0x70021039 rev=0x00 hdr=0x00
re0@pci0:0:9:0:	class=0x020000 card=0x816910ec chip=0x816910ec rev=0x10 hdr=0x00
ath0@pci0:0:10:0:	class=0x020000 card=0x3ab91948 chip=0x0013168c rev=0x01 hdr=0x00
atapci1@pci0:0:11:0:	class=0x018000 card=0x31121095 chip=0x31121095 rev=0x02 hdr=0x00
vgapci0@pci0:1:0:0:	class=0x030000 card=0x1b291019 chip=0x63301039 rev=0x00 hdr=0x00

kldstat
Id Refs Address    Size     Name
 1    9 0xc0400000 911c50   kernel
 2    1 0xc0d12000 6f88     snd_ich.ko
 3    2 0xc0d19000 4a5ac    sound.ko
 4    1 0xc0d64000 6a2c4    acpi.ko
 5    1 0xc29ce000 22000    linux.ko

X.Org X Server 1.4.0
Release Date: 5 September 2007
X Protocol Version 11, Revision 0
Build Operating System: FreeBSD 7.0-STABLE i386 
Current Operating System: FreeBSD hack.SFT.local 7.0-STABLE FreeBSD 7.0-STABLE #0: Tue Apr  1 01:11:09 PDT 2008     root@hack.SFT.local:/usr/obj/usr/src/sys/GENERIC i386
Build Date: 24 March 2008  12:37:49PM

using 'sis' driver for Xorg in 1280x1024 mode (24bit color) with DRI enabled



>How-To-Repeat:
this problem usually appears when Xorg has been left running for several days.  Actually making it happen is difficult.  However, the following conditions are nearly always present:  a) firefox is open with several tabs, and graphics intensive web pages.  b) several gnome-terminal sessions are running on multiple desktops.  c) thunderbird or some other resource-intensive application is running.  d) dnetc is running in the background.  Occasionally, heavy disk access is also in progress, particularly with respect to the SATA drive on my system.
>Fix:
NOT running the screen savers reduces the frequency of the crashes.

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: remko 
State-Changed-When: Thu Apr 10 06:46:59 UTC 2008 
State-Changed-Why:  
Can you please add information regarding the kernel dump? please use 
http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html 
to obtain the information we need. Thanks! 

http://www.freebsd.org/cgi/query-pr.cgi?pr=122615 

From: Bob Frazier <bobf@mrp3.com>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/122615: occasional crash/boot while running Xorg
Date: Thu, 10 Apr 2008 06:42:04 -0700

 the information is in a 55Mb zip and I read the warning about containing 
 passwords, etc. - How can I get this file to you?
 
 

From: Volker <volker@vwsoft.com>
To: bug-followup@FreeBSD.org, bobf@mrp3.com
Cc:  
Subject: Re: kern/122615: occasional crash/boot while running Xorg
Date: Fri, 11 Apr 2008 22:06:41 +0200

 Bob,
 
 please check the information pointed to by the URL Remko was giving.
 There you'll find detailed instructions on how to get kgdb output. We
 need the backtrace and as much information as possible.
 
 A (55 MiB) dump file is of no use for us as it can only be analyzed with
 access to the binaries.
 
 Please check the instructions and file all requested information in a
 followup.
 
 Thanks!
 
 Volker

From: Bob Frazier <bobf@mrp3.com>
To: Volker <volker@vwsoft.com>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/122615: occasional crash/boot while running Xorg
Date: Fri, 11 Apr 2008 19:23:26 -0700

 This is a multi-part message in MIME format.
 --------------010900030603010005020301
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 Content-Transfer-Encoding: 7bit
 
 > please check the information pointed to by the URL Remko was giving.
 
 done, but I sent it directly, so here's a copy of what I sent for the 
 bug followup.
 
 
 --------------010900030603010005020301
 Content-Type: text/plain;
  name="x.txt"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: inline;
  filename="x.txt"
 
 (kgdb) backtrace
 #0  doadump () at pcpu.h:195
 #1  0xc0754d57 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:417
 #2  0xc0755019 in panic (fmt=Variable "fmt" is not available.
 ) at /usr/src/sys/kern/kern_shutdown.c:571
 #3  0xc07cd536 in bufobj_invalbuf (bo=0xc287c500, flags=1, td=0xc2f25000, slpflag=0, slptimeo=0)
     at /usr/src/sys/kern/vfs_subr.c:1075
 #4  0xc07cd862 in vinvalbuf (vp=0xc287c440, flags=1, td=0xc2f25000, slpflag=0, slptimeo=0) at /usr/src/sys/kern/vfs_subr.c:1143
 #5  0xc07cd92f in vgonel (vp=0xc287c440) at /usr/src/sys/kern/vfs_subr.c:2514
 #6  0xc07cdc17 in vgone (vp=0xc287c440) at /usr/src/sys/kern/vfs_subr.c:2472
 #7  0xc06e8185 in devfs_delete (dm=0xc2826100, de=0xc2866580, vp_locked=0) at /usr/src/sys/fs/devfs/devfs_devs.c:265
 #8  0xc06e864d in devfs_populate_loop (dm=0xc2826100, cleanup=0) at /usr/src/sys/fs/devfs/devfs_devs.c:384
 #9  0xc06e898e in devfs_populate (dm=0xc2826100) at /usr/src/sys/fs/devfs/devfs_devs.c:485
 #10 0xc06ec41e in devfs_lookup (ap=0xd09f19b8) at /usr/src/sys/fs/devfs/devfs_vnops.c:601
 #11 0xc0a64e76 in VOP_LOOKUP_APV (vop=0xc0b778e0, a=0xd09f19b8) at vnode_if.c:99
 #12 0xc07c4b61 in lookup (ndp=0xd09f1b80) at vnode_if.h:57
 #13 0xc07c586f in namei (ndp=0xd09f1b80) at /usr/src/sys/kern/vfs_lookup.c:219
 #14 0xc07dc247 in vn_open_cred (ndp=0xd09f1b80, flagp=0xd09f1c78, cmode=0, cred=0xc2d04700, fp=0xc407b168)
     at /usr/src/sys/kern/vfs_vnops.c:188
 #15 0xc07dc513 in vn_open (ndp=0xd09f1b80, flagp=0xd09f1c78, cmode=0, fp=0xc407b168) at /usr/src/sys/kern/vfs_vnops.c:94
 #16 0xc07da197 in kern_open (td=0xc2f25000, path=0x280c4537 <Address 0x280c4537 out of bounds>, pathseg=UIO_USERSPACE, flags=1, 
     mode=0) at /usr/src/sys/kern/vfs_syscalls.c:1028
 #17 0xc07da700 in open (td=0xc2f25000, uap=0xd09f1cfc) at /usr/src/sys/kern/vfs_syscalls.c:995
 #18 0xc0a4f1c5 in syscall (frame=0xd09f1d38) at /usr/src/sys/i386/i386/trap.c:1035
 #19 0xc0a356e0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:196
 #20 0x00000033 in ?? ()
 
 
 frames 10 through 3 showing the lines of code involved
 (kgdb) frame 10
 #10 0xc06ec41e in devfs_lookup (ap=0xd09f19b8) at /usr/src/sys/fs/devfs/devfs_vnops.c:601
 601		devfs_populate(dmp);
 (kgdb) frame 9
 #9  0xc06e898e in devfs_populate (dm=0xc2826100) at /usr/src/sys/fs/devfs/devfs_devs.c:485
 485		while (devfs_populate_loop(dm, 0))
 (kgdb) frame 8
 #8  0xc06e864d in devfs_populate_loop (dm=0xc2826100, cleanup=0) at /usr/src/sys/fs/devfs/devfs_devs.c:384
 384				devfs_delete(dm, de, 0);
 (kgdb) frame 7
 #7  0xc06e8185 in devfs_delete (dm=0xc2826100, de=0xc2866580, vp_locked=0) at /usr/src/sys/fs/devfs/devfs_devs.c:265
 265			vgone(vp);
 (kgdb) frame 6
 #6  0xc07cdc17 in vgone (vp=0xc287c440) at /usr/src/sys/kern/vfs_subr.c:2472
 2472		vgonel(vp);
 (kgdb) frame 5
 #5  0xc07cd92f in vgonel (vp=0xc287c440) at /usr/src/sys/kern/vfs_subr.c:2514
 2514		if (vinvalbuf(vp, V_SAVE, td, 0, 0) != 0)
 (kgdb) frame 4
 #4  0xc07cd862 in vinvalbuf (vp=0xc287c440, flags=1, td=0xc2f25000, slpflag=0, slptimeo=0) at /usr/src/sys/kern/vfs_subr.c:1143
 1143		return (bufobj_invalbuf(&vp->v_bufobj, flags, td, slpflag, slptimeo));
 (kgdb) frame 3
 #3  0xc07cd536 in bufobj_invalbuf (bo=0xc287c500, flags=1, td=0xc2f25000, slpflag=0, slptimeo=0)
     at /usr/src/sys/kern/vfs_subr.c:1075
 1075					panic("vinvalbuf: dirty bufs");
 
 
 (this frame looks interesting so I'm giving you the registers)
 
 (kgdb) frame 16
 #16 0xc07da197 in kern_open (td=0xc2f25000, path=0x280c4537 <Address 0x280c4537 out of bounds>, pathseg=UIO_USERSPACE, flags=1, 
     mode=0) at /usr/src/sys/kern/vfs_syscalls.c:1028
 1028	 	error = vn_open(&nd, &flags, cmode, fp);
 (kgdb) info all-registers
 eax            0x0	0
 ecx            0x0	0
 edx            0x0	0
 ebx            0xc2f25000	-1024307200
 esp            0xd09f1b40	0xd09f1b40
 ebp            0xd09f1c64	0xd09f1c64
 esi            0x0	0
 edi            0xc407b168	-1006128792
 eip            0xc07da197	0xc07da197
 eflags         0x0	0
 cs             0x0	0
 ss             0x0	0
 ds             0x0	0
 es             0x0	0
 fs             0x0	0
 gs             0x0	0
 st0            0	(raw 0x00000000000000000000)
 st1            0	(raw 0x00000000000000000000)
 st2            0	(raw 0x00000000000000000000)
 st3            0	(raw 0x00000000000000000000)
 st4            0	(raw 0x00000000000000000000)
 st5            0	(raw 0x00000000000000000000)
 st6            0	(raw 0x00000000000000000000)
 st7            0	(raw 0x00000000000000000000)
 fctrl          0x0	0
 fstat          0x0	0
 ftag           0x0	0
 fiseg          0x0	0
 fioff          0x0	0
 foseg          0x0	0
 fooff          0x0	0
 fop            0x0	0
 xmm0           {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 
     0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, 
   uint128 = 0x00000000000000000000000000000000}
 xmm1           {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 
     0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, 
   uint128 = 0x00000000000000000000000000000000}
 xmm2           {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 
     0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, 
   uint128 = 0x00000000000000000000000000000000}
 xmm3           {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 
     0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, 
   uint128 = 0x00000000000000000000000000000000}
 xmm4           {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 
     0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, 
   uint128 = 0x00000000000000000000000000000000}
 xmm5           {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 
     0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, 
   uint128 = 0x00000000000000000000000000000000}
 xmm6           {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 
     0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, 
   uint128 = 0x00000000000000000000000000000000}
 xmm7           {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 
     0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, 
   uint128 = 0x00000000000000000000000000000000}
 mxcsr          0x0	0
 mm0            {uint64 = 0x0, v2_int32 = {0x0, 0x0}, v4_int16 = {0x0, 0x0, 0x0, 0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
     0x0, 0x0}}
 mm1            {uint64 = 0x0, v2_int32 = {0x0, 0x0}, v4_int16 = {0x0, 0x0, 0x0, 0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
     0x0, 0x0}}
 mm2            {uint64 = 0x0, v2_int32 = {0x0, 0x0}, v4_int16 = {0x0, 0x0, 0x0, 0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
     0x0, 0x0}}
 mm3            {uint64 = 0x0, v2_int32 = {0x0, 0x0}, v4_int16 = {0x0, 0x0, 0x0, 0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
     0x0, 0x0}}
 mm4            {uint64 = 0x0, v2_int32 = {0x0, 0x0}, v4_int16 = {0x0, 0x0, 0x0, 0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
     0x0, 0x0}}
 mm5            {uint64 = 0x0, v2_int32 = {0x0, 0x0}, v4_int16 = {0x0, 0x0, 0x0, 0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
     0x0, 0x0}}
 mm6            {uint64 = 0x0, v2_int32 = {0x0, 0x0}, v4_int16 = {0x0, 0x0, 0x0, 0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
     0x0, 0x0}}
 mm7            {uint64 = 0x0, v2_int32 = {0x0, 0x0}, v4_int16 = {0x0, 0x0, 0x0, 0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
     0x0, 0x0}}
 
 
 
 
 
 --------------010900030603010005020301--
State-Changed-From-To: feedback->open 
State-Changed-By: vwe 
State-Changed-When: Sat Apr 12 10:10:07 UTC 2008 
State-Changed-Why:  

feedback received, seems to be devfs related (device unplug). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=122615 

From: Bob Frazier <bobf@mrp3.com>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/122615: occasional crash/boot while running Xorg
Date: Thu, 17 Apr 2008 08:18:20 -0700

 It appears that this problem may be related specifically to the SATA 
 controller.
 
 I had several crashes happen to me this morning, most of them without 
 Xorg running.  Prior to this, Xorg had been running for several days 
 without incident.
 
 I should point out that I have 2 jails running from directories on the 
 SATA drive, which is the 2nd drive in my system.  So I can expect file 
 activity on this drive from time to time due to cron, etc. running in 
 the jails.  The SATA drive has a single NFS partition and is 160Gb.
 
 Crash 1:  copying a ~180Mb file from an NFS share on a linux machine to 
 a location on the SATA drive.  System froze up then rebooted.  no core dump.
 
 Crash 2:  From the console (no X running), after copying the same file 
 again (while background checks were being done), copied this same file 
 to a USB ramdisk and started another process (in a different vconsole) 
 to compare a number of existing files against (should be) identical 
 files on the same NFS share as before.  When I issued the 'umount' 
 command, the system rebooted.  No core dump.
 
 Crash 3:  Started the file comparison (again), after manually fsck'ing 
 the partitions on the IDE drive (/, /tmp, /var, /usr) in single-user and 
 pressing CTRL+D to resume startup.  System rebooted with a crash dump 
 (#4 in /var/crash).
 
 Crash 4:  Started the system, booted to single user, fsck'd the 4 
 mountpoints on the IDE drive again, ctrl+D to multi-user, and then 
 started typing in a command.  System froze up and rebooted with a crash 
 dump (#5 in /var/crash).
 
 In each case the crash symptoms are similar to the one I reported here. 
   I'm lacking time at the moment and will follow up with more backtraces 
 for the 2 crashdump files on request.
 
 At the moment I'm running an fsck on the SATA drive with the drive 
 unmounted in multi-user mode (jails not running).  Hopefully this won't 
 crash and I can validate and offload files from this drive.  I am 
 starting to suspect that the SATA controller or the drive itself is at 
 the root of the problem.  The typical symptoms include a message in 
 which the 'ad4' (SATA) drive has some kind of error, followed by a 
 message that suggests it is being removed or not responding or something 
 similar, followed by several reported errors reading/writing LBA 
 locations that seem unusually large for a drive that size, followed by 
 the crash/boot.  Unfortunately this information gets lost every time, if 
 I'm even lucky enough to see the writing on the terminal before the 
 system boots.  The only relevant piece of information that seems to end 
 up in the info.# file is "vinvalbuf: dirtybufs" as the cause for the 
 'panic'.
 
 
State-Changed-From-To: open->feedback 
State-Changed-By: jh 
State-Changed-When: Tue Apr 13 15:34:39 UTC 2010 
State-Changed-Why:  
Can you still reproduce this on recent FreeBSD versions? 


Responsible-Changed-From-To: freebsd-bugs->jh 
Responsible-Changed-By: jh 
Responsible-Changed-When: Tue Apr 13 15:34:39 UTC 2010 
Responsible-Changed-Why:  
Track. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=122615 
State-Changed-From-To: feedback->closed 
State-Changed-By: jh 
State-Changed-When: Wed Apr 14 15:59:16 UTC 2010 
State-Changed-Why:  
Submitter can't reproduce anymore. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=122615 
>Unformatted:
