Re: Reproducable panic

2001-03-07 Thread Andrea Campi

On Wed, Mar 07, 2001 at 07:25:41PM +0100, Dag-Erling Smorgrav wrote:
 At some point in the past 24 hours, someone broke the kernel so I can
 no longer run linux-opera:

Same here with another Linux binary (Tivoli Storage Manager client).

-- 
   I believe the technical term is "Oops!"

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



RE: Reproducable panic

2001-03-07 Thread John Baldwin


On 07-Mar-01 Dag-Erling Smorgrav wrote:
 At some point in the past 24 hours, someone broke the kernel so I can
 no longer run linux-opera:
 
 root@des /var/crash# gdb -k
 GNU gdb 4.18
 Copyright 1998 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you are
 welcome to change it and/or distribute copies of it under certain conditions.
 Type "show copying" to see the conditions.
 There is absolutely no warranty for GDB.  Type "show warranty" for details.
 This GDB was configured as "i386-unknown-freebsd".
 (kgdb) source ~des/kgdb
 (kgdb) kernel 5
 IdlePTD 4034560
 initial pcb at 326020
 panicstr: from debugger
 panic messages:
 ---
 panic: cpu_switch: not SRUN
 panic: from debugger
 Uptime: 7m24s
 
 dumping to dev ad0b, offset 131104
 dump ata0: resetting devices .. done
 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:478
 478 if (dumping++) {
 (kgdb) where
#0  dumpsys () at ../../kern/kern_shutdown.c:478
#1  0xc019131b in boot (howto=260) at ../../kern/kern_shutdown.c:321
#2  0xc01916e5 in panic (fmt=0xc02940b4 "from debugger")
 at ../../kern/kern_shutdown.c:571
#3  0xc011f1d5 in db_panic (addr=-1071226260, have_addr=0, count=-1,
 modif=0xd06ffc34 "") at ../../ddb/db_command.c:433
#4  0xc011f175 in db_command (last_cmdp=0xc02cd880, cmd_table=0xc02cd6e0,
 aux_cmd_tablep=0xc0310cdc) at ../../ddb/db_command.c:333
#5  0xc011f23a in db_command_loop () at ../../ddb/db_command.c:455
#6  0xc0121403 in db_trap (type=3, code=0) at ../../ddb/db_trap.c:71
#7  0xc0265ffe in kdb_trap (type=3, code=0, regs=0xd06ffd34)
 at ../../i386/i386/db_interface.c:164
#8  0xc0274a3b in trap (frame={tf_fs = 24, tf_es = 16, tf_ds = 16,
   tf_edi = -798482176, tf_esi = 256, tf_ebp = -797966976,
   tf_isp = -797967008, tf_ebx = 2, tf_edx = 1017, tf_ecx = 1021,
   tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1071226260, tf_cs =
 8,
   tf_eflags = 70, tf_esp = -1070857153, tf_ss = -1070967837})
 at ../../i386/i386/trap.c:608
#9  0xc026626c in Debugger (msg=0xc02a53e3 "panic") at machine/cpufunc.h:60
#10 0xc01916dc in panic (fmt=0xc0272cdd "cpu_switch: not SRUN")
 at ../../kern/kern_shutdown.c:569
#11 0xc0272cdd in sw0_2 ()
#12 0xc019b3d8 in msleep (ident=0xc0356158, mtx=0xd0682100, priority=344,
 wmesg=0xc02a7fd8 "poll", timo=201) at ../../kern/kern_synch.c:459
#13 0xc01b00f3 in poll (p=0xd0681fe0, uap=0xd06fff80)
 at ../../kern/sys_generic.c:927
#14 0xc0276510 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
   tf_edi = 142872464, tf_esi = 2000, tf_ebp = 142872424,
   tf_isp = -797966380, tf_ebx = 142872464, tf_edx = 2000, tf_ecx = 1,
   tf_eax = 168, tf_trapno = 12, tf_err = 2, tf_eip = 678761248,
   tf_cs = 31, tf_eflags = 647, tf_esp = 142872400, tf_ss = 47})
 at ../../i386/i386/trap.c:1184
#15 0xc026690d in syscall_with_err_pushed ()
#16 0x285cac35 in ?? ()
 (kgdb) p *(struct proc *)0xd0681fe0

Wrong process.  This is the process that we just put to sleep.  The panic is
complaining about the new process we just chose to run.  I'll try and add in
an appropriate KASSERT() to the runqueue code to actually check this before
we get into cpu_switch and print out what process we are switching to, what its
p_stat is, etc.

This may be my fault in the recent change to linux_machdep.c.  Hmmm, nope:

mtx_lock_spin(sched_lock);
p2-p_stat = SRUN;
setrunqueue(p2);
mtx_unlock_spin(sched_lock);

It should be fine. :(

(The change was to linux_clone()).

-- 

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: reproducable panic?

1999-03-20 Thread Matthew Dillon
:I seem to be able to reproduce a panic on my 4.0 machine (updated
:yesterday, kernel and world, also could crash with a somewhat older
:build)
:
:I have pseudo-device vn  and nfs  in my kernel, not as a module.
:
:When I vnconfig -c /dev/vn0c /nfsmountpoint/somefile,  the system panics
:reliably.
:
:If there is more useful info I could give, or shell accounts, etc,
:please let me know.


test2:/home/dillon# ls -la /var/tmp/ff/test
-rw-r--r--  1 root  wheel  33554432 Mar 20 09:01 /var/tmp/ff/test
test2:/home/dillon# vnconfig -c /dev/vn2c /var/tmp/ff/test
test2:/home/dillon# df
apollo:/images/remote.src   1397423   970331   31529975%/var/tmp/ff

Works for me.  If you have the latest updated yesterday you should be
in good shape.  See if you can narrow down why it is crashing... try
different file sizes for your /nfsmountpoint/somefile, and so forth.

-Matt




To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: reproducable panic?

1999-03-20 Thread Adam
Ok I've been playing around a bit, an iso sized file (500-600mb) seems to
trigger it, and a quite small file seemed to do it too but I forgot which
one, but just now I made a one byte file and vnconfig'ed it and that
paniced. Please try that if you can :) btw I tried a 32mb file like you,
also a 16mb one, and neither made it crash.  Thanks

On Sat, 20 Mar 1999, Matthew Dillon wrote:

 :I seem to be able to reproduce a panic on my 4.0 machine (updated
 :yesterday, kernel and world, also could crash with a somewhat older
 :build)
 :
 :I have pseudo-device vn  and nfs  in my kernel, not as a module.
 :
 :When I vnconfig -c /dev/vn0c /nfsmountpoint/somefile,  the system panics
 :reliably.
 :
 :If there is more useful info I could give, or shell accounts, etc,
 :please let me know.
 
 
 test2:/home/dillon# ls -la /var/tmp/ff/test
 -rw-r--r--  1 root  wheel  33554432 Mar 20 09:01 /var/tmp/ff/test
 test2:/home/dillon# vnconfig -c /dev/vn2c /var/tmp/ff/test
 test2:/home/dillon# df
 apollo:/images/remote.src   1397423   970331   31529975%/var/tmp/ff
 
 Works for me.  If you have the latest updated yesterday you should be
 in good shape.  See if you can narrow down why it is crashing... try
 different file sizes for your /nfsmountpoint/somefile, and so forth.
 
   -Matt
 
 
 
 
 To Unsubscribe: send mail to majord...@freebsd.org
 with unsubscribe freebsd-current in the body of the message
 



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message