Re: Panic in boot after flushing buffers
Interesting. I've also been seeing this on alphas. Do you have sys/dev/randomdev/randomdev.c v1.5? M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic in boot after flushing buffers
On Fri, 30 Jun 2000, Mark Murray wrote: Interesting. I've also been seeing this on alphas. Do you have sys/dev/randomdev/randomdev.c v1.5? Now I do. Better. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Panic in boot after flushing buffers
Hello,
I am running -CURRENT from June 27, 2000 (started cvsup around 19:05)
on a PII 266 MHz with 32MB RAM and one IDE disk.
Initially, I noticed that while syncing disks during a reboot, the
system would always give up before finishing. To capture the output,
I configured the kernel to use a serial console by setting flags for
the serial port in the hints file (hint.sio.0.flags="0xb0").
Now, instead of just failing to sync the disks, the system panics about
two out of every three reboots.
The kernel config file (MONSTER) is included as an attachment, as well
as the hints file. Below is the panic information and stack trace.
Let me know if you would like any more information (this is my first
crack at running -CURRENT, so I'm new at this).
Regards,
-brian
System shutdown time has arrived
Shutting down daemon processes: .
Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped
Waiting (max 60 seconds) for system process `syncer' to stop...stopped
syncing disks...
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xc090b5bd
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc014c638
stack pointer = 0x10:0xc3b66f0c
frame pointer = 0x10:0xc3b66f20
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 1 (init)
interrupt mask = none
panic: from debugger
panic: from debugger
Uptime: 11m4s
dumping to dev #ad/0x20001, offset 65536
dump ata0: resetting devices .. done
32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
---
#0 boot (howto=260) at ../../kern/kern_shutdown.c:303
303 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0 boot (howto=260) at ../../kern/kern_shutdown.c:303
#1 0xc014cbd5 in panic (fmt=0xc02656f4 "from debugger")
at ../../kern/kern_shutdown.c:553
#2 0xc011f479 in db_panic (addr=-1072380360, have_addr=0, count=1,
modif=0xc3b66d78 "") at ../../ddb/db_command.c:433
#3 0xc011f419 in db_command (last_cmdp=0xc0294b78, cmd_table=0xc02949d8,
aux_cmd_tablep=0xc02b4880) at ../../ddb/db_command.c:333
#4 0xc011f4de in db_command_loop () at ../../ddb/db_command.c:455
#5 0xc012169b in db_trap (type=12, code=0) at ../../ddb/db_trap.c:71
#6 0xc0244626 in kdb_trap (type=12, code=0, regs=0xc3b66ecc)
at ../../i386/i386/db_interface.c:158
#7 0xc0252698 in trap_fatal (frame=0xc3b66ecc, eva=3230709181)
at ../../i386/i386/trap.c:922
#8 0xc0252371 in trap_pfault (frame=0xc3b66ecc, usermode=0, eva=3230709181)
at ../../i386/i386/trap.c:820
#9 0xc0251f2b in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16,
tf_edi = -1011454080, tf_esi = 1, tf_ebp = -1011454176,
tf_isp = -1011454216, tf_ebx = -1064258240, tf_edx = 160160,
tf_ecx = -1070796288, tf_eax = 455, tf_trapno = 12, tf_err = 0,
tf_eip = -1072380360, tf_cs = 8, tf_eflags = 66050,
tf_esp = -1011479040, tf_ss = 1}) at ../../i386/i386/trap.c:426
#10 0xc014c638 in boot (howto=0) at ../../kern/kern_shutdown.c:234
#11 0xc014c40c in reboot (p=0xc3b60e00, uap=0xc3b66f80)
---Type return to continue, or q return to quit---
at ../../kern/kern_shutdown.c:146
#12 0xc0252971 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = -1077936612, tf_esi = -1077936624, tf_ebp = -1077936836,
tf_isp = -1011453996, tf_ebx = -1077936732, tf_edx = -1, tf_ecx = 4,
tf_eax = 55, tf_trapno = 7, tf_err = 2, tf_eip = 134536452, tf_cs = 31,
tf_eflags = 643, tf_esp = -1077937056, tf_ss = 47})
at ../../i386/i386/trap.c:1126
#13 0xc0244f65 in Xint0x80_syscall ()
#14 0x80486ee in ?? ()
#15 0x8048478 in ?? ()
#16 0x8048139 in ?? ()
--
Brian O'Shea
[EMAIL PROTECTED]
#
# MONSTER -- Based on the GENERIC kernel configuration file
#
machine i386
cpu I686_CPU
ident MONSTER
maxusers32
hints "MONSTER.hints" #Default places to look for devices.
makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols
options MATH_EMULATE#Support for x87 emulation
options INET#InterNETworking
options INET6 #IPv6 communications protocols
options FFS #Berkeley Fast Filesystem
options FFS_ROOT#FFS usable as root device [keep this!]
options SOFTUPDATES #Enable FFS soft updates support
options MFS #Memory Filesystem
options MD_ROOT #MD is a potential root device
options NFS #Network Filesystem
options NFS_ROOT#NFS usable as root device, NFS required
options MSDOSFS #MSDOS Filesystem
options CD9660 #ISO 9660 Filesystem
Re: Panic in boot after flushing buffers
Hi
I fixed this yesterday; please re-cvsup and reboot.
You should have sys/dev/randomdev/randomdev.c v1.5 to fix this.
M
I am running -CURRENT from June 27, 2000 (started cvsup around 19:05)
on a PII 266 MHz with 32MB RAM and one IDE disk.
Initially, I noticed that while syncing disks during a reboot, the
system would always give up before finishing. To capture the output,
I configured the kernel to use a serial console by setting flags for
the serial port in the hints file (hint.sio.0.flags="0xb0").
Now, instead of just failing to sync the disks, the system panics about
two out of every three reboots.
The kernel config file (MONSTER) is included as an attachment, as well
as the hints file. Below is the panic information and stack trace.
Let me know if you would like any more information (this is my first
crack at running -CURRENT, so I'm new at this).
Regards,
-brian
System shutdown time has arrived
Shutting down daemon processes: .
Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped
Waiting (max 60 seconds) for system process `syncer' to stop...stopped
syncing disks...
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xc090b5bd
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc014c638
stack pointer = 0x10:0xc3b66f0c
frame pointer = 0x10:0xc3b66f20
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 1 (init)
interrupt mask = none
panic: from debugger
panic: from debugger
Uptime: 11m4s
dumping to dev #ad/0x20001, offset 65536
dump ata0: resetting devices .. done
32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6
5 4 3 2 1
---
#0 boot (howto=260) at ../../kern/kern_shutdown.c:303
303 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0 boot (howto=260) at ../../kern/kern_shutdown.c:303
#1 0xc014cbd5 in panic (fmt=0xc02656f4 "from debugger")
at ../../kern/kern_shutdown.c:553
#2 0xc011f479 in db_panic (addr=-1072380360, have_addr=0, count=1,
modif=0xc3b66d78 "") at ../../ddb/db_command.c:433
#3 0xc011f419 in db_command (last_cmdp=0xc0294b78, cmd_table=0xc02949d8,
aux_cmd_tablep=0xc02b4880) at ../../ddb/db_command.c:333
#4 0xc011f4de in db_command_loop () at ../../ddb/db_command.c:455
#5 0xc012169b in db_trap (type=12, code=0) at ../../ddb/db_trap.c:71
#6 0xc0244626 in kdb_trap (type=12, code=0, regs=0xc3b66ecc)
at ../../i386/i386/db_interface.c:158
#7 0xc0252698 in trap_fatal (frame=0xc3b66ecc, eva=3230709181)
at ../../i386/i386/trap.c:922
#8 0xc0252371 in trap_pfault (frame=0xc3b66ecc, usermode=0, eva=3230709181)
at ../../i386/i386/trap.c:820
#9 0xc0251f2b in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16,
tf_edi = -1011454080, tf_esi = 1, tf_ebp = -1011454176,
tf_isp = -1011454216, tf_ebx = -1064258240, tf_edx = 160160,
tf_ecx = -1070796288, tf_eax = 455, tf_trapno = 12, tf_err = 0,
tf_eip = -1072380360, tf_cs = 8, tf_eflags = 66050,
tf_esp = -1011479040, tf_ss = 1}) at ../../i386/i386/trap.c:426
#10 0xc014c638 in boot (howto=0) at ../../kern/kern_shutdown.c:234
#11 0xc014c40c in reboot (p=0xc3b60e00, uap=0xc3b66f80)
---Type return to continue, or q return to quit---
at ../../kern/kern_shutdown.c:146
#12 0xc0252971 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = -1077936612, tf_esi = -1077936624, tf_ebp = -1077936836,
tf_isp = -1011453996, tf_ebx = -1077936732, tf_edx = -1, tf_ecx = 4,
tf_eax = 55, tf_trapno = 7, tf_err = 2, tf_eip = 134536452, tf_cs = 31,
tf_eflags = 643, tf_esp = -1077937056, tf_ss = 47})
at ../../i386/i386/trap.c:1126
#13 0xc0244f65 in Xint0x80_syscall ()
#14 0x80486ee in ?? ()
#15 0x8048478 in ?? ()
#16 0x8048139 in ?? ()
--
Brian O'Shea
[EMAIL PROTECTED]
--7ZAtKRhVyVSsbBD2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=MONSTER
#
# MONSTER -- Based on the GENERIC kernel configuration file
#
machine i386
cpu I686_CPU
ident MONSTER
maxusers 32
hints "MONSTER.hints" #Default places to look for devices.
makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols
options MATH_EMULATE#Support for x87 emulation
options INET#InterNETworking
options INET6 #IPv6 communications protocols
options FFS #Berkeley Fast Filesystem
options FFS_ROOT#FFS usable as root device [keep this!]
options SOFTUPDATES #Enable FFS soft updates support
options MFS #Memory Filesystem
Re: Panic in boot after flushing buffers
Interesting. I've also been seeing this on alphas. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
