FreeBSD 8.0 amd64 fwohci1: <NEC uPD72871/2> mem 0xfdeff000-0xfdefffff irq 19 at device 8.0 on pci2 The command /usr/sbin/fwcontrol -u 1 -S file.dv quickly and reproducably panics the kernel. 4 attempts -> 4 panics. Panic #1: I wasn't expecting the panic the first time, so by the time I got to the console the lovely firmware had already scribbled all over the panic (I assume) message. ====================================================== Panic #2: Output of fwcontrol: NTSC 012 On the console: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x4b631d1411d0 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80857d67 stack pointer = 0x28:0xffffff8040677830 frame pointer = 0x28:0xffffff8040677860 code segment = base rx0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 2177 (fwcontrol) trap number = 12 panic: page fault cpuid = 0 Uptime: 7m28s Cannot dump. Device not defined or unavailable. Automatic reboot in 15 seconds - press a key on the console to abort ====================================================== Panic #3: No output from fwcontrol this time. On the console: kernel trap 9 with interrupts disabled Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xffffffff80846e63 stack pointer = 0x28:0xffffff80406db880 frame pointer = 0x28:0xffffff80406db8e0 code segment = base rx0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 2156 (fwcontrol) trap number = 9 panic: general protection fault cpuid = 0 Uptime: 4m51s <HUNG> Had to press reset. ====================================================== Panic #4: this time in single user mode. Userlnd was still scribling on the screen, after the page fault, but it is another trap 12: page fault while in kernel mode, probably the same as #2. ====================================================== Using a FreeBSD 7.1 binary of fwcontrol with 8.0 kernel does not cause a panic. Developers please note: you do NOT need a firewire device to receive the DV data. All you need is a firewire controller and a DV file. If you don't have a DV file, ffmpeg can transcode mpeg to DV. The file doesn't need to be very long, the panic happens in less than one second. The good news: it should be easy and fast to reproduce. Fix: Workaround: use 7.1 binary of fwcontrol(8). How-To-Repeat: # fwcontrol -S file.dv
Responsible Changed From-To: freebsd-bugs->freebsd-firewire Over to maintainer(s).
New info: I compiled the 7.1 fwcontrol(8) sources under 8.0 -> kernel panic. :-( I compiled the 8.0 fwcontrol(8) sources under 7.1 -> no panic. (I made /usr/include a symlink to the include directory that matched=20 the sources.) Can anyone duplicate these results? So it appears that the problem is the compiler rather than the=20 fwcontrol(8) sources?
> All you need is a firewire controller and a DV file. If you > don't have a DV file, ffmpeg can transcode mpeg to DV. As it turns out, you don't even need a DV file. The problem can be duplicated using bits from /dev/zero.
I think that this panic looks like this? -bash-4.2# fwcontrol -u 0 -S file.dv NTSC pa01nic: vm_phys_alloc_contig: alignment must be a power of 2 cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x187 vm_phys_alloc_contig() at vm_phys_alloc_contig+0x5e5 kmem_alloc_contig() at kmem_alloc_contig+0x8e contigmalloc() at contigmalloc+0x39 bus_dmamem_alloc() at bus_dmamem_alloc+0x8b fwdma_malloc_size() at fwdma_malloc_size+0x33 fwdma_malloc_multiseg() at fwdma_malloc_multiseg+0x18b fwohci_db_init() at fwohci_db_init+0x10d fwohci_itxbuf_enable() at fwohci_itxbuf_enable+0x69 fw_write() at fw_write+0x359 devfs_write_f() at devfs_write_f+0xb1 dofilewrite() at dofilewrite+0x85 kern_writev() at kern_writev+0x6c writev() at writev+0x41 syscallenter() at syscallenter+0x1aa syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xdd
Sean writes: > I think that this panic looks like this? > > -bash-4.2# fwcontrol -u 0 -S file.dv > NTSC > pa01nic: vm_phys_alloc_contig: alignment must be a power of 2 That certainly looks like a panic. Â Do you get the same power of 2 alignment one every time? Â As you can see in the PR, I got at least 2 different panics. (seems odd) Â Mine didn't say anything about power of 2 alignment, unless the first one did. Does compiling the 8.x fwcontrol with a 7.x compiler avoid the panic for you?
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped
Keyword: crash – in lieu of summary line prefix: [panic] * bulk change for the keyword * summary lines may be edited manually (not in bulk). Keyword descriptions and search interface: <https://bugs.freebsd.org/bugzilla/describekeywords.cgi>