kern/122951: video-transfer via fwcontrol triggers a panic (fwdev)

[Mikhail T.]

>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 at 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: <Texas Instruments TSB43AB22/A> 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: <IEEE1394(FireWire) bus> on fwohci0
fwe0: <Ethernet over FireWire> 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 <Address 0x104 out of bounds>)
    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: