When compiling programs (e.g. wget, or samba-2.0.7), 4.1-stable crashes on my machine (Pentium 120, 96 megs RAM). The weird thing is, that the kernel compiled fine. Every other compilation crashed the machine hard. (Page fault in kernel mode) Hardware: ATI xpert@work Mach64 gfx-card VIA 82C586 IDE-Controller (according to dmesg) VIA VT6102 Rhine II nic Elsa Quickstep 1000pro PCI ISDN-card The hardware is fairly old, however, it used to run rock solid under Linux. It's somewhat weird, that although the harddrive (a Fujitsu 8 GB IDE-drive) and the mainboard both support UDMA33, but when fbsd tries to mount the hd, it complains about a command timeout: ad0: READ command timeout - resetting ata0: resetting devices .. done It does that 3 times, and then it falls back into PIO mode. Fix: none How-To-Repeat: compile some stuff from the ports, or transfer about 400-500 megs via NFS to the pc.
State Changed From-To: open->feedback Could you get a backtrace with debugging symbols? You'll need a debugging kernel (``makeoptions DEBUG=-g'' in the kernel config file and config'd with config -g). Once you have one, have a look at the instructions at: http://www.freebsd.org/handbook/kerneldebug.html Be sure to send your follow-up to <freebsd-gnats-submit@freebsd.org>, preserving the Subject line of this e-mail message.
> Could you get a backtrace with debugging symbols? You'll > need a debugging kernel (``makeoptions DEBUG=-g'' in the > kernel config file and config'd with config -g). > Once you have one, have a look at the instructions at: > http://www.freebsd.org/handbook/kerneldebug.html > Be sure to send your follow-up to > <freebsd-gnats-submit@freebsd.org>, preserving the Subject > line of this e-mail message. > http://www.freebsd.org/cgi/query-pr.cgi?pr=20685 hm. weird. I just compiled the kernel with the debugging options, and now it doesn't seem to crash any more... my box has now been compiling licq for about half an hour, and it hasn't panic'ed yet. With the old kernel it crashed after two or three minutes of compiling. I guess, you can mark the bug report as resolved. I don't know *what* caused that unstability (I'd really like to know), but it it now seems to be gone. Sorry for the trouble! Regards, Jonas -- Sent through GMX FreeMail - http://www.gmx.net
> Could you get a backtrace with debugging symbols? You'll > need a debugging kernel (``makeoptions DEBUG=-g'' in the > kernel config file and config'd with config -g). Sorry, I was too quick. It now only takes quite a while longer until it crashes. I'll send you a backtrace tomorrow. Regards, Jonas -- Sent through GMX FreeMail - http://www.gmx.net
IdlePTD 3776512 initial pcb at 2fba20 panicstr: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x15 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0253568 stack pointer = 0x10:0xc7726e80 frame pointer = 0x10:0xc7726e88 code segment = base rx0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 11929 (pkg_info) interrupt mask = none trap number = 12 panic: page fault syncing disks... 326 326 319 291 267 250 208 156 101 49 done Uptime: 2h37m40s 0 boot (howto=256) at ../../kern/kern_shutdown.c:302 302 dumppcb.pcb_cr3 = rcr3(); (kgdb) where #0 boot (howto=256) at ../../kern/kern_shutdown.c:302 #1 0xc0159d68 in poweroff_wait (junk=0xc02cb90f, howto=-949032320) at ../../kern/kern_shutdown.c:552 #2 0xc0286485 in trap_fatal (frame=0xc7726e40, eva=21) at ../../i386/i386/trap.c:927 #3 0xc028615d in trap_pfault (frame=0xc7726e40, usermode=0, eva=21) at ../../i386/i386/trap.c:820 #4 0xc0285d2f in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = 672108544, tf_esi = 0, tf_ebp = -948801912, tf_isp = -948801940, tf_ebx = -947292192, tf_edx = 1, tf_ecx = 1239613, tf_eax = 33620, tf_trapno = 12, tf_err = 0, tf_eip = -1071303320, tf_cs = 8, tf_eflags = 66050, tf_esp = 0, tf_ss = -948884608}) at ../../i386/i386/trap.c:426 #5 0xc0253568 in vm_page_lookup (object=0xc78977e0, pindex=0) at ../../vm/vm_page.c:501 #6 0xc024bf88 in vm_fault (map=0xc7712b80, vaddr=672108544, fault_type=3 '\003', fault_flags=8) at ../../vm/vm_fault.c:288 #7 0xc02860f2 in trap_pfault (frame=0xc7726fa8, usermode=1, eva=672109440) at ../../i386/i386/trap.c:800 #8 0xc0285c2f in trap (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 671653972, tf_esi = 672109440, tf_ebp = -1077941788, tf_isp = -948801580, tf_ebx = 671485992, tf_edx = 671499008, tf_ecx = 671436340, tf_eax = 671600640, tf_trapno = 12, tf_err = 7, tf_eip = 671436346, tf_cs = 31, tf_eflags = 66050, tf_esp = -1077941828, tf_ss = 47}) at ../../i386/i386/trap.c:349 #9 0x28054e3a in ?? () #10 0x28052ba0 in ?? () #11 0x280517ab in ?? () I'm not at all familiar with debugging, so you have to tell me which frames I have to look at ;) -- Sent through GMX FreeMail - http://www.gmx.net
Could you please tell us if you are still having this problem with newer versions of FreeBSD? DES -- Dag-Erling Smorgrav - des@ofug.org
State Changed From-To: feedback->closed Automatic feedback timeout. If additional feedback that warrants the re-opening of this PR is available but not included in the audit trail, please include the feedback in a reply to this message (preserving the Subject line) and ask that the PR be re-opened.