Bug 31233

Summary: Kernel panics after upgrading to 4.4-STABLE on ASUS P2B running less than a day
Product: Base System Reporter: Kristian Kraemmer Nielsen <freebsd>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 4.4-STABLE   
Hardware: Any   
OS: Any   

Description Kristian Kraemmer Nielsen 2001-10-12 19:30:00 UTC
Machine crashes after running less than a day.
Problem started after upgrading from 3.5-STABLE to 4.4-STABLE.
It is most like to have something to do with the IDE controller and the new ata-drivers since it panics under high disk activity/seeks.
It does not make any difference to disable UDMA, write-cache nor soft-updates.
Panic:

IdlePTD 3276800
initial pcb at 2966c0
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x7145cfb0
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xc01496d2
stack pointer           = 0x10:0xd720ef20
frame pointer           = 0x10:0xd720ef38
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         = 364 (rmserver)
interrupt mask          = none
trap number             = 12
panic: page fault

syncing disks... 104 13 10 9 8 
done
Uptime: 18h53m51s

dumping to dev #ad/0x20001, offset 794120
dump ata0: resetting devices .. done
 --- cut ---
(kgdb) where
#0  dumpsys () at ../../kern/kern_shutdown.c:473
#1  0xc0143efc in boot (howto=256) at ../../kern/kern_shutdown.c:313
#2  0xc01442dc in poweroff_wait (junk=0xc02711ac, howto=-1071182641)
    at ../../kern/kern_shutdown.c:581
#3  0xc023b07f in trap_fatal (frame=0xd720eee0, eva=1900400560)
    at ../../i386/i386/trap.c:956
#4  0xc023ad39 in trap_pfault (frame=0xd720eee0, usermode=0, eva=1900400560)
    at ../../i386/i386/trap.c:849
#5  0xc023a90f in trap (frame={tf_fs = 16, tf_es = -685768688, tf_ds = -685768688, 
      tf_edi = 753273225, tf_esi = 1900400556, tf_ebp = -685707464, 
      tf_isp = -685707508, tf_ebx = 4, tf_edx = -685707516, tf_ecx = 59999, 
      tf_eax = 4, tf_trapno = 12, tf_err = 0, tf_eip = -1072392494, tf_cs = 8, 
      tf_eflags = 66066, tf_esp = -755888352, tf_ss = 2})
    at ../../i386/i386/trap.c:448
#6  0xc01496d2 in nanosleep (p=0xd2f20f20, uap=0xd720ef80)
    at ../../kern/kern_time.c:283
#7  0xc023b2e1 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = -1078001617, 
      tf_edi = 0, tf_esi = 60000, tf_ebp = -1077937184, tf_isp = -685707308, 
      tf_ebx = 673886912, tf_edx = -1, tf_ecx = 4, tf_eax = 240, tf_trapno = 22, 
      tf_err = 2, tf_eip = 673632288, tf_cs = 31, tf_eflags = 659, 
      tf_esp = -1077937220, tf_ss = 47}) at ../../i386/i386/trap.c:1155
#8  0xc022f8a5 in Xint0x80_syscall ()
#9  0x8074fd6 in ?? ()
#10 0x8075302 in ?? ()
#11 0x80728cd in ?? ()
#12 0x8076d8b in ?? ()
---cut---
(kgdb) up 5
#5  0xc023a90f in trap (frame={tf_fs = 16, tf_es = -685768688, tf_ds = -685768688, 
      tf_edi = 753273225, tf_esi = 1900400556, tf_ebp = -685707464, 
      tf_isp = -685707508, tf_ebx = 4, tf_edx = -685707516, tf_ecx = 59999, 
      tf_eax = 4, tf_trapno = 12, tf_err = 0, tf_eip = -1072392494, tf_cs = 8, 
      tf_eflags = 66066, tf_esp = -755888352, tf_ss = 2})
    at ../../i386/i386/trap.c:448
448                             (void) trap_pfault(&frame, FALSE, eva);
(kgdb) frame frame->tf_ebp frame->tf_eip
#0  0xc01496d2 in nanosleep (p=0xd2f20f20, uap=0xd720ef80)
    at ../../kern/kern_time.c:283
283             if (error && SCARG(uap, rmtp)) {
(kgdb) list
278             if (SCARG(uap, rmtp))
279                     if (!useracc((caddr_t)SCARG(uap, rmtp), sizeof(rmt), 
280                         VM_PROT_WRITE))
281                             return (EFAULT);
282             error = nanosleep1(p, &rqt, &rmt);
283             if (error && SCARG(uap, rmtp)) {
284                     error2 = copyout(&rmt, SCARG(uap, rmtp), sizeof(rmt));
285                     if (error2)     /* XXX shouldn't happen, did useracc() above */
286                             return (error2);
287             }


For more information please mail jkkn@jkkn.dk.

Fix: 

Downgrade to 3.5-STABLE I assume. (I have not tested 4.0, 4.1, 4.2, 4.3)
How-To-Repeat: Kernel panic seem to accour under high disk activity/seeks.

Output of dmesg:
Copyright (c) 1992-2001 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD 4.4-STABLE #0: Wed Oct 10 23:33:25 CEST 2001
    jkkn@jkkn.jkkn.net:/usr/src/sys/compile/JKKN_KRNL
Timecounter "i8254"  frequency 1193182 Hz
Timecounter "TSC"  frequency 300683475 Hz
CPU: Pentium II/Pentium II Xeon/Celeron (300.68-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x634  Stepping = 4
  Features=0x80f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,MMX>
real memory  = 402640896 (393204K bytes)
avail memory = 387919872 (378828K bytes)
Preloaded elf kernel "kernel" at 0xc0301000.
Pentium Pro MTRR support enabled
Using $PIR table, 6 entries at 0xc00f0d10
npx0: <math processor> on motherboard
npx0: INT 16 interface
pcib0: <Intel 82443BX (440 BX) host to PCI bridge> on motherboard
pci0: <PCI bus> on pcib0
pcib1: <Intel 82443BX (440 BX) PCI-PCI (AGP) bridge> at device 1.0 on pci0
pci1: <PCI bus> on pcib1
isab0: <Intel 82371AB PCI to ISA bridge> at device 4.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <Intel PIIX4 ATA33 controller> port 0xd800-0xd80f at device 4.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
pci0: <Intel 82371AB/EB (PIIX4) USB controller> at 4.2
chip1: <Intel 82371AB Power management controller> port 0xe800-0xe80f at device 4.3 on pci0
rl0: <RealTek 8139 10/100BaseTX> port 0xd000-0xd0ff mem 0xe3000000-0xe30000ff irq 10 at device 10.0 on pci0
rl0: Ethernet address: 00:40:95:30:2e:5e
miibus0: <MII bus> on rl0
rlphy0: <RealTek internal media interface> on miibus0
rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
pci0: <S3 ViRGE DX/GX graphics accelerator> at 12.0 irq 11
orm0: <Option ROM> at iomem 0xc0000-0xc7fff on isa0
fdc0: <NEC 72065B or clone> at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0
ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/9 bytes threshold
lpt0: <Printer> on ppbus0
lpt0: Interrupt-driven port
ppi0: <Parallel I/O> on ppbus0
IPsec: Initialized Security Association Processing.
ad0: 8207MB <ST38641A> [16676/16/63] at ata0-master UDMA33
ad2: 9641MB <IBM-DTTA-371010> [19590/16/63] at ata1-master UDMA33
acd0: CD-RW <CD-RW CRX100E> at ata1-slave using PIO4
Mounting root from ufs:/dev/ad0s1a
Comment 1 Jens Schweikhardt freebsd_committer freebsd_triage 2002-08-10 15:21:35 UTC
State Changed
From-To: open->feedback

Does this problem persist on 4.6 or -stable?
Comment 2 jkkn 2002-08-11 03:43:37 UTC
Yes, this problem persists on the ASUS motherboard - I checked last week -
keeps crashing.
However I will no longer be able to run tests since we just replaced the
motherboard in the machine
with a brand new pentium 4 intel motherboard which do not seem to have the
problem.

Regards
Kristian
Comment 3 Giorgos Keramidas freebsd_committer freebsd_triage 2002-08-26 05:31:54 UTC
State Changed
From-To: feedback->open

The problem is still there.
Comment 4 iedowse freebsd_committer freebsd_triage 2002-12-01 19:06:03 UTC
State Changed
From-To: open->closed


If the hardware is no longer available to test this, then I guess 
there isn't any point in keeping the PR open.