From owner-freebsd-bugs@FreeBSD.ORG Mon Apr 21 03:20:01 2008 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93F61106566B for ; Mon, 21 Apr 2008 03:20:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 646828FC24 for ; Mon, 21 Apr 2008 03:20:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m3L3K1ie052030 for ; Mon, 21 Apr 2008 03:20:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3L3K17D052029; Mon, 21 Apr 2008 03:20:01 GMT (envelope-from gnats) Resent-Date: Mon, 21 Apr 2008 03:20:01 GMT Resent-Message-Id: <200804210320.m3L3K17D052029@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, "Mikhail T." Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B4C01065670 for ; Mon, 21 Apr 2008 03:16:53 +0000 (UTC) (envelope-from mi@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.freebsd.org (Postfix) with ESMTP id 13C978FC14 for ; Mon, 21 Apr 2008 03:16:52 +0000 (UTC) (envelope-from mi@aldan.algebra.com) Received: from aldan.algebra.com (localhost [127.0.0.1]) by aldan.algebra.com (8.14.2/8.14.1) with ESMTP id m3L3GiZj001204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 20 Apr 2008 23:16:45 -0400 (EDT) (envelope-from mi@aldan.algebra.com) Received: (from mi@localhost) by aldan.algebra.com (8.14.2/8.14.1/Submit) id m3L3Gim4001203; Sun, 20 Apr 2008 23:16:44 -0400 (EDT) (envelope-from mi) Message-Id: <200804210316.m3L3Gim4001203@aldan.algebra.com> Date: Sun, 20 Apr 2008 23:16:44 -0400 (EDT) From: "Mikhail T." To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Subject: kern/122951: video-transfer via fwcontrol triggers a panic (fwdev) X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2008 03:20:01 -0000 >Number: 122951 >Category: kern >Synopsis: video-transfer via fwcontrol triggers a panic (fwdev) >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Apr 21 03:20:01 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Mikhail T. >Release: FreeBSD 7.0-STABLE amd64 >Organization: Virtual Estates, Inc. (http://sybpipe.com/) >Environment: System: FreeBSD aldan.algebra.com 7.0-STABLE FreeBSD 7.0-STABLE #0: Sat Mar 8 16:02:37 EST 2008 root@aldan.algebra.com:/meow/obj/var/src/sys/SILVER-SMP amd64 The system is 2-CPU (4-core) Opteron with 4Gb of RAM. Next to each CPU there are 4 memory slots. In my computer only half of the slots are populated -- with 1Gb sticks -- two by each CPU. The firewire is identified/detected as: fwohci0: mem 0x9e3fc800-0x9e3fcfff,0x9e3f8000-0x9e3fbfff irq 18 at device 6.0 on pci2 fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:00:00:00:00:00:f0:12 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:00:00:00:f0:12 fwe0: Ethernet address: 02:00:00:00:f0:12 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc1, gen=1, CYCLEMASTER mode >Description: I first thought, that the problem has something to with the "Enable hardware memory hole" and "Enable software memory hole" settings in the BIOS. Unfortunately, as I just experienced, enabling only the hardware hole still leaves the panic entirely possible -- it just does not strike right away. It says: "vm_fault: fault on nofault entry, addr ...." >How-To-Repeat: fwcontrol -M mpg -R file.mpg The kgdb's output: [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd". There is no member named pathname. Reading symbols from /opt/modules/fuse.ko...done. Loaded symbols for /opt/modules/fuse.ko Reading symbols from /opt/modules/rtc.ko...done. Loaded symbols for /opt/modules/rtc.ko Unread portion of the kernel message buffer: fwohci0: Isochronous receive err 8402(long) panic: vm_fault: fault on nofault entry, addr: ffffffffb0713000 cpuid = 0 Uptime: 3h55m18s Physical memory: 3607 MB Dumping 532 MB:fwohci0: Isochronous receive err 8402(long) 517 501fwohci0: Isochronous receive err 8402(long) 485 469fwohci0: Isochronous receive err 8402(long) 453fwohci0: Isochronous receive err 8402(long) 437fwohci0: Isochronous receive err 8402(long) fwohci0: Isochronous receive err 8402(long) 421 405fwohci0: Isochronous receive err 8402(long) 389 373 357 341 325 309 293 277 261 245 229 213 197 181 165 149 133 117 101 85 69 53 37 21 5 #0 doadump () at pcpu.h:194 194 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); (kgdb) #0 doadump () at pcpu.h:194 #1 0x0000000000000004 in ?? () #2 0xffffffff802e8b60 in boot (howto=260) at /var/src/sys/kern/kern_shutdown.c:409 #3 0xffffffff802e8f7d in panic (fmt=0x104
) at /var/src/sys/kern/kern_shutdown.c:563 #4 0xffffffff80424f63 in vm_fault (map=0xffffff0001000000, vaddr=18446744072374792192, fault_type=1 '\001', fault_flags=0) at /var/src/sys/vm/vm_fault.c:275 #5 0xffffffff8045a4ff in trap_pfault (frame=0xffffffffb22798d0, usermode=0) at /var/src/sys/amd64/amd64/trap.c:630 #6 0xffffffff8045ae49 in trap (frame=0xffffffffb22798d0) at /var/src/sys/amd64/amd64/trap.c:410 #7 0xffffffff8043f17e in calltrap () at /var/src/sys/amd64/amd64/exception.S:169 #8 0xffffffff804596db in copyout () at /var/src/sys/amd64/amd64/support.S:257 #9 0xffffffff802f0440 in uiomove (cp=0xffffffffb0710000, n=28275, uio=0xffffffffb2279b00) at /var/src/sys/kern/kern_subr.c:168 #10 0xffffffff8021901a in fw_read (dev=Variable "dev" is not available. ) at /var/src/sys/dev/firewire/fwdev.c:403 #11 0xffffffff80297ca4 in devfs_read_f (fp=0xffffff0122325a50, uio=0xffffffffb2279b00, cred=Variable "cred" is not available. ) at /var/src/sys/fs/devfs/devfs_vnops.c:880 #12 0xffffffff8031da7d in dofileread (td=0xffffff01384739c0, fd=3, fp=0xffffff0122325a50, auio=0xffffffffb2279b00, offset=Variable "offset" is not available. ) at file.h:242 #13 0xffffffff8031ddee in kern_readv (td=0xffffff01384739c0, fd=3, auio=0xffffffffb2279b00) at /var/src/sys/kern/sys_generic.c:192 #14 0xffffffff8031dedc in read (td=0x60a70c, uap=0xffffffffb0713000) at /var/src/sys/kern/sys_generic.c:108 #15 0xffffffff8045a700 in syscall (frame=0xffffffffb2279c70) at /var/src/sys/amd64/amd64/trap.c:852 #16 0xffffffff8043f38b in Xfast_syscall () at /var/src/sys/amd64/amd64/exception.S:290 #17 0x000000080070a34c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) >Fix: If the software memory hole is enabled in the BIOS, the panic is guaranteed to happen even on a freshly-booted machine. The only work-around is to perform the transfers on a freshly booted machine. Once the X-sessions are up (and more RAM is in use), the panic is likely even when only the hardware memory hole is enabled. >Release-Note: >Audit-Trail: >Unformatted: