Re: Today's panic on boot problem
Mike Silbersack wrote: On Wed, 27 Feb 2002, Mike Silbersack wrote: Disabling PG_G allows it to work here again as well. Given the problems we're experiencing, backing out the pmap changes of the last two days seems like a good idea. Mike Silby Silbersack Well, I sorta take that back. The box has been up for ~5 minutes now, and the buildworld I started hasn't paniced it yet. I guess this is workable. FWIW: I'm typing this on a kernel with that bandaid right now, but I still manage to panic it immediately by preloading smbfs.ko from the loader. kldload'ing it later works fine, though. -- Michael Nottebrock To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Today's panic on boot problem
On Tue, Feb 26, 2002 at 09:29:51PM -0800, Peter Wemm wrote:
FWIW, turning off PG_G see_ms to help. Change in pmap.c:
#if !defined(SMP) || defined(ENABLE_PG_G)
to:
#if /*!defined(SMP) ||*/ defined(ENABLE_PG_G)
and see how you go. This got me past atkbd0, but it is a very worrying
sign. I now get a vnode related panic. :-(
On my (single processor, non-acpi) system the kernel now completes
booting, but savecore receives a signal 11 after having saved about
235 MB, and all(?) processes after that get a signal 11 or 10 until
finally there's a panic: bad peter. This is absolutely reproducible.
Is there any additional information I should provide?
Bye, Philipp
savecore: writing core to /var/crash/vmcore.22
Feb 27 13:15:40 i609a savecore: reboot after panic: from debugger
pid 175 (savecore), uid 0: exited on signal 11 (core dumped)
Segmentation fault - core dumped
Doing additional network setup: ntpdpid 176 (sh), uid 0: exited on signal 10 (co
re dumped)
Bus error - core dumped
.
Starting final network daemons:.
pid 177 (sh), uid 0: exited on signal 11 (core dumped)
Segmentation fault - core dumped
pid 178 (sh), uid 0: exited on signal 11 (core dumped)
Segmentation fault - core dumped
Starting standard daemons: inetdpid 179 (sh), uid 0: exited on signal 11 (core d
umped)
[...]
Additional TCP options:pid 213 (sh), uid 0: exited on signal 10 (core dumped)
Bus error - core dumped
pid 214 (sh), uid 0: exited on signal 11 (core dumped)
Segmentation fault - core dumped
.
Starting background filesystem checks
Wed Feb 27 13:16T:44 CET 2002
PTE at 0xbfc20404 IS ZERO @ VA 08101000
panic: bad peter
Debugger(panic)
Stopped at Debugger+0x40: xorl%eax,%eax
db
save a crash dump and reboot into old kernel
This GDB was configured as i386-unknown-freebsd...Deprecated bfd_read called at
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb.291/gdb/dbxread.c line 2629
in elfstab_build_psymtabs
Deprecated bfd_read called at
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb.291/gdb/dbxread.c line 935
in fill_symbuf
IdlePTD at phsyical address 0x003ff000
initial pcb at physical address 0x0032f8c0
panicstr: from debugger
panic messages:
---
panic: bad peter
panic: from debugger
Uptime: 1m31s
pfs_vncache_unload(): 1 entries remaining
dumping to dev ad0s1b, offset 589952
dump ata0: resetting devices .. ata0: mask=03 ostat0=50 ostat2=00
ad0: ATAPI 00 00
ata0-slave: ATAPI 00 00
ata0: mask=03 stat0=50 stat1=00
ad0: ATA 01 a5
ata0: devices=01
ad0: invalidating queued requests
ad0: success setting PIO4 on generic chip
done
255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235
234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214
213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193
192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172
171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151
150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130
129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109
108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83
82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54
53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 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
---
#0 dumpsys () at ../../../kern/kern_shutdown.c:504
504 if (!dodump)
(kgdb) bt
#0 dumpsys () at ../../../kern/kern_shutdown.c:504
#1 0xc01a2117 in boot (howto=260) at ../../../kern/kern_shutdown.c:336
#2 0xc01a25a1 in panic (fmt=0xc02a772a from debugger)
at ../../../kern/kern_shutdown.c:646
#3 0xc013784d in db_panic (addr=-1071127031, have_addr=0, count=-1,
modif=0xcf3adb10 ) at ../../../ddb/db_command.c:452
#4 0xc01377eb in db_command (last_cmdp=0xc02ed424, cmd_table=0xc02ed244,
aux_cmd_tablep=0xc02e4020, aux_cmd_tablep_end=0xc02e4024)
at ../../../ddb/db_command.c:348
#5 0xc01378b7 in db_command_loop () at ../../../ddb/db_command.c:474
#6 0xc0139c4b in db_trap (type=3, code=0) at ../../../ddb/db_trap.c:72
#7 0xc027e326 in kdb_trap (type=3, code=0, regs=0xcf3adc0c)
at ../../../i386/i386/db_interface.c:161
#8 0xc028ac18 in trap (frame={tf_fs = 24, tf_es = 16, tf_ds = 16,
tf_edi = -1077804028, tf_esi = 256, tf_ebp = -818226092,
tf_isp = -818226120, tf_ebx = -1070734913, tf_edx = 1017, tf_ecx = 1,
tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1071127148, tf_cs = 8,
tf_eflags = 582, tf_esp = -1070742881, tf_ss = -1070895941})
at ../../../i386/i386/trap.c:589
#9 0xc027e594 in Debugger (msg=0xc02b6cbb panic) at machine/cpufunc.h:66
#10 0xc01a258c in panic (fmt=0xc02de1bf bad peter)
at ../../../kern/kern_shutdown.c:633
#11 0xc0289019 in pmap_remove_pages (pmap=0xcd2fadec, sva=0,
Re: Today's panic on boot problem
Peter Wemm wrote: Mike Silbersack wrote: On Tue, 26 Feb 2002, Peter Wemm wrote: Mike Silbersack wrote: Hm, sounds like UP got optimized out. Gah! That would be a first. :( Well, until I can build a working kernel, I'll just assume that it's a feature. FWIW, turning off PG_G see_ms to help. Change in pmap.c: #if !defined(SMP) || defined(ENABLE_PG_G) to: #if /*!defined(SMP) ||*/ defined(ENABLE_PG_G) and see how you go. This got me past atkbd0, but it is a very worrying sign. I now get a vnode related panic. :-( I've reread the changes about 50 times now and cannot for the life of me see why it works for SMP but not UP. I'm about ready to back it all out. I believe I know what the problem is. Turn off PG_PSE using DISABLE_PSE in your config. If that fixes it, back the code out. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Today's panic on boot problem
I'm experiencing the same double panic on boot that PHK is now; are we the only ones, or is it just that nobody else has updated recently? Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Today's panic on boot problem
Mike Silbersack wrote: I'm experiencing the same double panic on boot that PHK is now; are we the only ones, or is it just that nobody else has updated recently? If you are not using acpica, then you're probably using vm86 for pcibios calls. I've been told that I've broken bios.c.. You may like to try reverting this change: peter 2002/02/25 13:42:23 PST Modified files: sys/i386/i386bios.c sys/i386/include pmap.h Log: Tidy up some warnings Revision ChangesPath 1.47 +7 -6 src/sys/i386/i386/bios.c 1.74 +1 -1 src/sys/i386/include/pmap.h Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Today's panic on boot problem
On 26-Feb-2002 (17:27:19/GMT) Mike Silbersack wrote: I'm experiencing the same double panic on boot that PHK is now; are we the only ones, or is it just that nobody else has updated recently? Mee too, just survied to 4 auto-reboot without messages... Trying with a boot -v I see a keyboard check as last message, I forgot to write down it. Sorry. I can reboot again with that explosive kernel (if _really_ necessary). Now reverted to kernel and modules of 24 Feb (but only kernel and modules, _not_ world) and it is stable (but no speaker). cvsup-ed 3 times on 26.2.2002 (compile take 3/4 hours here). BTW: On built of 25 (to recover /dev/speaker) I noticed some stranges: doing man, ps, even ls make a core dump (sometimes). I'm sure that all is in sync: kern, modules, world and etc. Tryed with and without X, with and without ACPI, normal boot or single user. No differences. As mentioned on my previous mail having both PCA and SPEAKER compiled into kernel kill /dev/speaker. With only speaker or none of them (but loading atspeaker after boot) lead me to a working /dev/speaker. All other stuff doesn't no matter. Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Today's panic on boot problem
On Tue, 26 Feb 2002, Peter Wemm wrote: Mike Silbersack wrote: I'm experiencing the same double panic on boot that PHK is now; are we the only ones, or is it just that nobody else has updated recently? If you are not using acpica, then you're probably using vm86 for pcibios calls. I've been told that I've broken bios.c.. You may like to try reverting this change: peter 2002/02/25 13:42:23 PST Modified files: sys/i386/i386bios.c sys/i386/include pmap.h Log: Tidy up some warnings Revision ChangesPath 1.47 +7 -6 src/sys/i386/i386/bios.c 1.74 +1 -1 src/sys/i386/include/pmap.h Cheers, -Peter I reverted that change, and the double panic still occured. :| FWIW, you're correct in that I'm not using the acpi module. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Today's panic on boot problem
On Tue, 2002-02-26 at 17:38, Peter Wemm wrote: You may like to try reverting this change: A great idea, but unfortunately, incorrect ... -- Michael D. Harnois bilocational bivocational Pastor, Redeemer Lutheran ChurchWashburn, Iowa 1L, UST School of Law Minneapolis, Minnesota Censorship is the strongest drive in human nature; sex is a weak second. -- Phil Kerby To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Today's panic on boot problem
On Tue, 26 Feb 2002, Mike Silbersack wrote: I reverted that change, and the double panic still occured. :| FWIW, you're correct in that I'm not using the acpi module. Mike Silby Silbersack Using ACPI doesn't help here either. Hmph. Can I get a kernel dump that early in the boot process? The dumpon manpage doesn't suggest a way as far as I can tell. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Today's panic on boot problem
On Tue, 26 Feb 2002, David Wolfskill wrote: Date: Tue, 26 Feb 2002 19:46:59 + (GMT) From: Mike Silbersack [EMAIL PROTECTED] Using ACPI doesn't help here either. Hmph. Can I get a kernel dump that early in the boot process? The dumpon manpage doesn't suggest a way as far as I can tell. I was unable to get a dump, even though the panic dropped me into the debugger. Also, I only had the panic on my laptop -- the (SMP) build machine ran fine. Cheers, david (links to my resume at http://www.catwhisker.org/~david) Hm, sounds like UP got optimized out. Ok, I guess we wait... Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Today's panic on boot problem
Mike Silbersack wrote: On Tue, 26 Feb 2002, David Wolfskill wrote: Date: Tue, 26 Feb 2002 19:46:59 + (GMT) From: Mike Silbersack [EMAIL PROTECTED] Using ACPI doesn't help here either. Hmph. Can I get a kernel dump that early in the boot process? The dumpon manpage doesn't suggest a way as far as I can tell. I was unable to get a dump, even though the panic dropped me into the debugger. Also, I only had the panic on my laptop -- the (SMP) build machine ran fine. Cheers, david (links to my resume at http://www.catwhisker.org/~david) Hm, sounds like UP got optimized out. Gah! That would be a first. :( Ok, I guess we wait... Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Today's panic on boot problem
On Tue, 26 Feb 2002, Peter Wemm wrote: Mike Silbersack wrote: Hm, sounds like UP got optimized out. Gah! That would be a first. :( Well, until I can build a working kernel, I'll just assume that it's a feature. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Today's panic on boot problem
Mike Silbersack wrote: On Tue, 26 Feb 2002, Peter Wemm wrote: Mike Silbersack wrote: _ Hm, sounds like UP got optimized out. Gah! That would be a first. :( Well, until I can build a working kernel, I'll just assume that it's a feature. FWIW, turning off PG_G see_ms to help. Change in pmap.c: #if !defined(SMP) || defined(ENABLE_PG_G) to: #if /*!defined(SMP) ||*/ defined(ENABLE_PG_G) and see how you go. This got me past atkbd0, but it is a very worrying sign. I now get a vnode related panic. :-( I've reread the changes about 50 times now and cannot for the life of me see why it works for SMP but not UP. I'm about ready to back it all out. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Today's panic on boot problem
On Tue, 26 Feb 2002, Peter Wemm wrote: FWIW, turning off PG_G see_ms to help. Change in pmap.c: #if !defined(SMP) || defined(ENABLE_PG_G) to: #if /*!defined(SMP) ||*/ defined(ENABLE_PG_G) and see how you go. This got me past atkbd0, but it is a very worrying sign. I now get a vnode related panic. :-( I've reread the changes about 50 times now and cannot for the life of me see why it works for SMP but not UP. I'm about ready to back it all out. Cheers, -Peter Disabling PG_G allows it to work here again as well. Given the problems we're experiencing, backing out the pmap changes of the last two days seems like a good idea. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Today's panic on boot problem
On Wed, 27 Feb 2002, Mike Silbersack wrote: Disabling PG_G allows it to work here again as well. Given the problems we're experiencing, backing out the pmap changes of the last two days seems like a good idea. Mike Silby Silbersack Well, I sorta take that back. The box has been up for ~5 minutes now, and the buildworld I started hasn't paniced it yet. I guess this is workable. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Today's panic :-)
Warner Losh wrote: I've added INVARIANTS and WITNESS to my kernel. Today I get a random panic on boot sometimes: lock order reseral (this doesn't cause the panic, but does seem to happen all the time) 1st vnode interlock last acquired @ ../../usr/ffs/ffs_fsops.c:396 2nd 0xc04837a0 mntvnode @ ../../ufs/ffs/ffs_vfsops.c:457 3rd 0xc80b9e8c vnode interlock @ ../../kern/vfs_subr.c:1872 I keep dropping into ddb with: ad1: 99MB VMware Inc. Virtual Hard Drive [216/15/63] at ata0-slave WDMA2 Mounting root from ufs:/dev/ad0s1a lock order reversal 1st lockmgr last acquired @ ../../kern/kern_lock.c:239 2nd 0xc085d654 ucred @ ../../kern/kern_prot.c:1177 3rd 0xc02b65e0 lockmgr @ ../../kern/kern_lock.c:239 lock order reversal 1st vnode interlock last acquired @ ../../kern/vfs_vnops.c:625 2nd 0xc02d0a60 mntvnode @ ../../ufs/ffs/ffs_vfsops.c:940 3rd 0xc3d7186c vnode interlock @ ../../ufs/ffs/ffs_vfsops.c:949 lock order reversal 1st lockmgr last acquired @ ../../kern/kern_lock.c:239 2nd 0xc02b8620 uidinfo hash @ ../../kern/kern_resource.c:765 3rd 0xc02b65e0 lockmgr @ ../../kern/kern_lock.c:239 lock order reversal 1st lockmgr last acquired @ ../../kern/kern_lock.c:239 2nd 0xc08d321c uidinfo struct @ ../../kern/kern_resource.c:819 3rd 0xc02b65e0 lockmgr @ ../../kern/kern_lock.c:239 hitting 'c' (for continue) allows me to go on This with a kernel CVSUP'd in the last day. I'll CVsup again as I vaguely remember a commit message that may affect this. -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 --- X_.---._/ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Today's panic :-)
In message [EMAIL PROTECTED] Warner Losh writes: : I note that this doesn't happen when the disks are clean on boot, but : does happen when they are dirty. The kernel is as of a cvsup 3pm MST : today. The kernel from 1am last night doesn't seem to have this : problem. Doesn't seem to have this problem that badly. I just got a very similar crash from it. Maybe I'm just lucky with the older one. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Today's panic :-)
On 24-Feb-01 Julian Elischer wrote: Warner Losh wrote: I've added INVARIANTS and WITNESS to my kernel. Today I get a random panic on boot sometimes: lock order reseral (this doesn't cause the panic, but does seem to happen all the time) 1st vnode interlock last acquired @ ../../usr/ffs/ffs_fsops.c:396 2nd 0xc04837a0 mntvnode @ ../../ufs/ffs/ffs_vfsops.c:457 3rd 0xc80b9e8c vnode interlock @ ../../kern/vfs_subr.c:1872 I keep dropping into ddb with: Don't use WITNESS_DDB and you won't drop into ddb. We're not far enough along to make that very livable yet. :( -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Today's panic :-)
On 24-Feb-01 Warner Losh wrote: In message [EMAIL PROTECTED] Bruce Evans writes: : It seems to be another trap while holding sched_lock. This should be : fatal, but the problem is only detected because trap() enables : interrupts. Then an interrupt causes bad things to happen. Unfortunately, : the above omits the critical information: the instruction at sw1b+0x6b. : There is no instruction at that address here. It is apparently just an : access to a swapped-out page for the new process. I can't see how this : ever worked. The page must be faulted in, but this can't be done while : sched_lock is held (not to mention after we have committed to switching : contexts). sw1b+0x6b is ltr %si I note that this doesn't happen when the disks are clean on boot, but does happen when they are dirty. The kernel is as of a cvsup 3pm MST today. The kernel from 1am last night doesn't seem to have this problem. Other people have reported this and I can't reproduce this. The one case I managed to track down so far involved proc0 having pcb_ext bogusly set, resulting in cpu_switch() setting up a bogus GDT entry for a TSS and thus generating a GPF which is the trap you see. The enable_intr() in trap() then sends things downhill fast. I'm not sure yet why processes are having pcb_ext bogusly set. Hmm. Make sure you have rev 1.35 or later of pcb.h. Also, try build a kernel from scratch from fresh sources.. Warner -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Today's panic :-)
I've added INVARIANTS and WITNESS to my kernel. Today I get a random
panic on boot sometimes:
lock order reseral (this doesn't cause the panic, but
does seem to happen all the time)
1st vnode interlock last acquired @ ../../usr/ffs/ffs_fsops.c:396
2nd 0xc04837a0 mntvnode @ ../../ufs/ffs/ffs_vfsops.c:457
3rd 0xc80b9e8c vnode interlock @ ../../kern/vfs_subr.c:1872
kernel trap 12 with interrupts disabled
panic: runq-add: proc 0xc7b28ee0 (fsck_ufs) not SRUN
Debugger("panic")
Stopeed at Debugger+0x44: pushl %ebx
db trace
Debugger(c03d3c03) at Debugger+0x44
panic(c03d4040,c7b28ee0,c7b290a5,282,c7b2b960) at panic+0x70
runq_add(c046ae20,c7b28ee0,c8a4bcra4,c0221ee5,c7b28ee0) at runq_add+0x40
setrunqueue(c7b28ee0) at setrunqueue+0x10
ithread_schedule(c0f0a00,1) at ithread_schedule+0x129
sched_ithd(e) at sched_ithrd+0x3f
Xresume14() at Xresume14+0x8
--- interrupt, eip = 0xc03830fb, esp = 0x286, ebp = 0xc8a4bd34 ---
trap(18,10,10,73b152,0) at trap+0x9b
calltrap() at calltrap+0x5
--- trap 0xc, eip = 0xc03822e9, esp = 0xc8a4bd7c, ebp = 0xc8a4bd90 ---
sw1b(0,...) at sw1b+0x6b
msleep(...) at msleep+0x588
physio(...) at physio+0x30d
spec_read(...) at spec_read+0x71
ufsspec_read(...) at ufsspec_read+0x20
ufs_noperatespec(...) at ufs_noperatespec+0x15
vn_read(...) at vn_read+0x128
dofileread(...) at dofileread+0xb0
read(...) at read+0x36
syscall(...) at syscall+0x551
Xint0x80_syscall() at Xint0x80_syscall+0x23
--- syscall 0x3, eip = 0x8054770, esp = 0xbfbfef60, ebp = 0xbfbfef9c ---
db
Anything that I can do to help? I don't have a core dump of this, but
it is happening often enough to be a pain.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Today's panic :-)
On Fri, 23 Feb 2001, Warner Losh wrote:
I've added INVARIANTS and WITNESS to my kernel. Today I get a random
panic on boot sometimes:
lock order reseral(this doesn't cause the panic, but
does seem to happen all the time)
1st vnode interlock last acquired @ ../../usr/ffs/ffs_fsops.c:396
2nd 0xc04837a0 mntvnode @ ../../ufs/ffs/ffs_vfsops.c:457
3rd 0xc80b9e8c vnode interlock @ ../../kern/vfs_subr.c:1872
kernel trap 12 with interrupts disabled
panic: runq-add: proc 0xc7b28ee0 (fsck_ufs) not SRUN
Debugger("panic")
Stopeed at Debugger+0x44: pushl %ebx
db trace
Debugger(c03d3c03) at Debugger+0x44
panic(c03d4040,c7b28ee0,c7b290a5,282,c7b2b960) at panic+0x70
runq_add(c046ae20,c7b28ee0,c8a4bcra4,c0221ee5,c7b28ee0) at runq_add+0x40
setrunqueue(c7b28ee0) at setrunqueue+0x10
ithread_schedule(c0f0a00,1) at ithread_schedule+0x129
sched_ithd(e) at sched_ithrd+0x3f
Xresume14() at Xresume14+0x8
--- interrupt, eip = 0xc03830fb, esp = 0x286, ebp = 0xc8a4bd34 ---
trap(18,10,10,73b152,0) at trap+0x9b
calltrap() at calltrap+0x5
--- trap 0xc, eip = 0xc03822e9, esp = 0xc8a4bd7c, ebp = 0xc8a4bd90 ---
sw1b(0,...) at sw1b+0x6b
msleep(...) at msleep+0x588
physio(...) at physio+0x30d
spec_read(...) at spec_read+0x71
ufsspec_read(...) at ufsspec_read+0x20
ufs_noperatespec(...) at ufs_noperatespec+0x15
vn_read(...) at vn_read+0x128
dofileread(...) at dofileread+0xb0
read(...) at read+0x36
syscall(...) at syscall+0x551
Xint0x80_syscall() at Xint0x80_syscall+0x23
--- syscall 0x3, eip = 0x8054770, esp = 0xbfbfef60, ebp = 0xbfbfef9c ---
db
Anything that I can do to help? I don't have a core dump of this, but
it is happening often enough to be a pain.
It seems to be another trap while holding sched_lock. This should be
fatal, but the problem is only detected because trap() enables
interrupts. Then an interrupt causes bad things to happen. Unfortunately,
the above omits the critical information: the instruction at sw1b+0x6b.
There is no instruction at that address here. It is apparently just an
access to a swapped-out page for the new process. I can't see how this
ever worked. The page must be faulted in, but this can't be done while
sched_lock is held (not to mention after we have committed to switching
contexts).
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Today's panic :-)
In message [EMAIL PROTECTED] Bruce Evans writes: : It seems to be another trap while holding sched_lock. This should be : fatal, but the problem is only detected because trap() enables : interrupts. Then an interrupt causes bad things to happen. Unfortunately, : the above omits the critical information: the instruction at sw1b+0x6b. : There is no instruction at that address here. It is apparently just an : access to a swapped-out page for the new process. I can't see how this : ever worked. The page must be faulted in, but this can't be done while : sched_lock is held (not to mention after we have committed to switching : contexts). sw1b+0x6b is ltr %si I note that this doesn't happen when the disks are clean on boot, but does happen when they are dirty. The kernel is as of a cvsup 3pm MST today. The kernel from 1am last night doesn't seem to have this problem. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
today's panic
Today's current (buildworld+build kernel), check out at ~10.00 GMT.
I have this problem during 6-7 days, the stable version for me:
FreeBSD newsfeed.gamma.ru 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Mon Oct 2 21:56:00 MSD
2000 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NEWSFEED i386
I haven't any problems till this date.
Server: P2B-DS, BIOS rev. 1012.
kgdb:
(kgdb) symbol-file kernel.debug
Reading symbols from kernel.debug...done.
(kgdb) exec-file /news/crash/kernel.0
(kgdb) core-file /news/crash/vmcore.0
SMP 2 cpus
IdlePTD 2813952
initial pcb at 23e720
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id =
fault virtual address = 0xc
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc015d616
stack pointer = 0x10:0xe2312da4
frame pointer = 0x10:0xe2312dd4
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 = 388 (innd)
trap number = 12
panic: page fault
cpuid = 1; lapic.id =
boot() called on cpu#1
syncing disks... 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
giving up on 20 buffers
Uptime: 1m46s
dumping to dev #da/25, offset 80572
dump 1023 1022 1021 1020 1019 1018 1017 1016 1015 1014 1013 1012 1011 1010 1009 [...]
6 5 4 3 2 1 0
---
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:476
476 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:476
#1 0xc014a52f in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:317
#2 0xc014a954 in poweroff_wait (junk=0xc0217b6f, howto=-611008192)
at /usr/src/sys/kern/kern_shutdown.c:569
#3 0xc01eb544 in trap_fatal (frame=0xe2312d64, eva=12)
at /usr/src/sys/i386/i386/trap.c:939
#4 0xc01eb2a5 in trap_pfault (frame=0xe2312d64, usermode=0, eva=12)
at /usr/src/sys/i386/i386/trap.c:853
#5 0xc01eae03 in trap (frame={tf_fs = -500105192, tf_es = -500105200,
tf_ds = -1072300016, tf_edi = 49, tf_esi = 64, tf_ebp = -500093484,
tf_isp = -500093552, tf_ebx = -1015227740, tf_edx = 0,
tf_ecx = -611008192, tf_eax = 0, tf_trapno = 12, tf_err = 0,
tf_eip = -1072310762, tf_cs = 8, tf_eflags = 66050,
tf_esp = -1015227740, tf_ss = 64}) at /usr/src/sys/i386/i386/trap.c:436
#6 0xc015d616 in selscan (p=0xdb94c140, ibits=0xe2312e28, obits=0xe2312e1c,
nfd=62) at /usr/src/sys/sys/file.h:187
182 struct proc *p;
183 {
184 int error;
185
186 fhold(fp);
187 error = (*fp-f_ops-fo_poll)(fp, events, cred, p);
188 fdrop(fp, p);
189 return (error);
190 }
191
(kgdb) print *fp
$1 = {f_list = {le_next = 0x0, le_prev = 0x0}, f_flag = 0, f_type = 0,
f_count = 0, f_msgcount = 0, f_cred = 0x0, f_ops = 0x0, f_seqcount = 0,
^^^
f_nextoff = 0, f_offset = 0, f_data = 0x0}
#7 0xc015d371 in select (p=0xdb94c140, uap=0xe2312f80)
at /usr/src/sys/kern/sys_generic.c:709
#8 0xc01eb960 in syscall2 (frame={tf_fs = 47, tf_es = 47,
tf_ds = -1078001617, tf_edi = 300, tf_esi = 134660576,
tf_ebp = -1077937204, tf_isp = -500092972, tf_ebx = -1077937332,
tf_edx = 246, tf_ecx = -1, tf_eax = 93, tf_trapno = 7, tf_err = 2,
tf_eip = 672214604, tf_cs = 31, tf_eflags = 515, tf_esp = -1077937568,
tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1139
---Type return to continue, or q return to quit---
#9 0xc01dc294 in Xint0x80_syscall ()
#10 0x805707d in ?? ()
#11 0x804a671 in ?? ()
dmesg -v:
Copyright (c) 1992-2000 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 5.0-CURRENT #0: Mon Oct 9 16:11:26 MSD 2000
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/NEWSFEED
Timecounter "i8254" frequency 1193182 Hz
CPU: Pentium III/Pentium III Xeon/Celeron (451.03-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x673 Stepping = 3
Features=0x387fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,PN,MMX,FXSR,SSE
real memory = 1073729536 (1048564K bytes)
avail memory = 1042202624 (1017776K bytes)
Programming 24 pins in IOAPIC #0
IOAPIC #0 intpin 2 - irq 0
FreeBSD/SMP: Multiprocessor motherboard
cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee0
cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee0
io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0
Preloaded elf kernel "kernel" at 0xc029d000.
Pentium Pro MTRR support enabled
npx0: math processor on motherboard
npx0: INT 16 interface
pcib0: Intel 82443BX (440 BX) host to PCI bridge at pcibus 0 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
Re: today's panic
Today's current (buildworld+build kernel), check out at ~10.00 GMT. I have this problem during 6-7 days, the stable version for me: FreeBSD newsfeed.gamma.ru 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Mon Oct 2 21:56:00 MSD 2000 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NEWSFEED i386 I haven't any problems till this date. The same proble on another server (no crash dump). IP: c01502d8 nm /boot/kernel/kernel | grep c0150 | sort c015025c t pollscan c015031c T openbsd_poll c015032c T seltrue c0150338 T selrecord c0150378 T selwakeup c0150400 T pipe c0150588 t pipespace c01505f0 t pipeinit c0150690 t pipe_read c015098c t pipe_build_write_buffer c0150b44 t pipe_destroy_write_buffer c0150bc8 t pipe_clone_write_buffer c0150c04 t pipe_direct_write c0150edc t pipe_write dmesg: Copyright (c) 1992-2000 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 5.0-CURRENT #0: Mon Oct 9 14:41:38 MSD 2000 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MAIL Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 300682964 Hz CPU: Pentium II/Pentium II Xeon/Celeron (300.68-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x633 Stepping = 3 Features=0x80f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,MMX real memory = 134217728 (131072K bytes) avail memory = 127950848 (124952K bytes) Preloaded elf kernel "kernel" at 0xc0292000. Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface pcib0: Intel 82443LX (440 LX) host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 pcib1: Intel 82443LX (440 LX) 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 atapci0: Busmastering DMA enabled ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: Intel 82371AB/EB (PIIX4) USB controller at 4.2 pci0: Intel 82371AB Power management controller at 4.3 pci0: unknown card (vendor=0x9004, dev=0x8078) at 6.0 irq 9 de0: Digital 21140A Fast Ethernet port 0xb800-0xb87f mem 0xe280-0xe280007f irq 9 at device 9.0 on pci0 de0: 21140A [10-100Mb/s] pass 2.2 de0: address 00:40:33:a2:ae:fe de1: Digital 21140A Fast Ethernet port 0xb400-0xb47f mem 0xe200-0xe27f irq 12 at device 10.0 on pci0 de1: 21140A [10-100Mb/s] pass 2.2 de1: address 00:40:33:a2:af:01 ed0: NE2000 PCI Ethernet (RealTek 8029) port 0xb000-0xb01f irq 10 at device 11.0 on pci0 ed0: address 00:00:1c:3a:3a:39, type NE2000 (16 bit) pci0: S3 Trio graphics accelerator at 12.0 irq 11 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 ed1 at port 0x240-0x25f iomem 0xd8000 irq 5 on isa0 ed1: address 00:c0:6c:54:12:37, type NE2000 (16 bit) 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 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 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: PNP0501 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0700 can't assign resources unknown: PNP0303 can't assign resources DUMMYNET initialized (000608) IP packet filtering initialized, divert disabled, rule-based forwarding enabled, default to deny, logging disabled ad0: 7339MB QUANTUM FIREBALL EL7.6A [15907/15/63] at ata0-master UDMA33 ad2: 7339MB QUANTUM FIREBALL EL7.6A [15907/15/63] at ata1-master UDMA33 Mounting root from ufs:/dev/ad0a WARNING: / was not properly dismounted de0: enabling 100baseTX port de1: enabling 100baseTX port vinum: loaded vinum: reading configuration from /dev/ad2s1d vinum: updating configuration from /dev/ad0s1d de1: link down: cable problem? de1: enabling 10baseT port de1: enabling Full Duplex 10baseT port link_elf: symbol card_set_res_flags_desc undefined To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
