Date: Mon, 10 Aug 2009 08:42:05 +0200 From: Joerg Ruppe-Tanner <joerg.ruppe.tanner@gmail.com> To: gavin@FreeBSD.org Cc: freebsd-bugs@FreeBSD.org Subject: Re: kern/137117: [panic] panic after spinlock held too long with FreeBSD 7.2-RELEASE-p2 on CPU: Intel(R) Atom(TM) CPU 330 @ 1.60GHz (1618.46-MHz K8-class CPU) Message-ID: <4A7FC13D.2010305@gmail.com> In-Reply-To: <4A6DF441.2070509@gmail.com> References: <200907271425.n6REPvCE078654@freefall.freebsd.org> <4A6DF441.2070509@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format. --------------020506040501030203080103 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 gavin For Your Information: I have tried this patch http://people.freebsd.org/~rink/tmp/ipi_7stable.diff And added this Options options KDB # Kernel with KDB Framework options KDB_UNATTENDED # Kernel with KDB Framework change the default value of the debug.debugger _on_panic sysctl to 0 options KDB_TRACE # Kernel with KDB Framework change the default value of the debug.trace_on _panic sysctl to 1 But the ule scheduler still make a panic when idle 100% or near 100%. And the kernel doesn't write every vmcore :( On Productive Maschines i can't aktive the whitness options. My solution was to bulid a kernel with sched_4bsd schedular and it works. If I have time, I make the test on a 3rd Machine and option whitness when the Problem is still alive and not fixed elsewhere. Kind Regards Jörg Joerg Ruppe-Tanner wrote: > gavin > > Here the output from /var/crash/vmcore.0 > [root@pluto ~]# ps -aux -M /var/crash/vmcore.0 > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND > [root@pluto ~]# > > To reproduce is only waiting. > The main problem is that the system only one time create a vmcore > file, the other times the only solution was power off the maschine not > keyboard interaction. > The Problem apears with release 7.2. With release 7.1 there was no > problems. > > I have some Problems with ddb command even with sysctl > debug.ddb.textdump.pendinding=1. > Here are my sysctl debug > > [root@pluto ~]# sysctl debug > debug.acpi.semaphore_debug: 0 > debug.acpi.suspend_bounce: 0 > debug.acpi.do_powerstate: 1 > debug.acpi.acpi_ca_version: 20070320 > debug.acpi.ec.timeout: 750 > debug.acpi.ec.polled: 0 > debug.acpi.ec.burst: 0 > debug.acpi.batt.batt_sleep_ms: 0 > debug.firewire_debug: 0 > debug.fwmem_debug: 0 > debug.if_fwe_debug: 0 > debug.if_fwip_debug: 0 > debug.sbp_debug: 0 > debug.mddebug: 0 > debug.elf64_legacy_coredump: 0 > debug.elf64_trace: 0 > debug.bootverbose: 0 > debug.boothowto: 0 > debug.cpufreq.verbose: 0 > debug.cpufreq.lowest: 0 > debug.sizeof.cdev_priv: 376 > debug.sizeof.cdev: 288 > debug.sizeof.g_bioq: 72 > debug.sizeof.g_consumer: 96 > debug.sizeof.g_provider: 136 > debug.sizeof.g_geom: 136 > debug.sizeof.g_class: 136 > debug.sizeof.kinfo_proc: 1088 > debug.sizeof.buf: 640 > debug.sizeof.bio: 216 > debug.sizeof.proc: 1144 > debug.sizeof.vnode: 504 > debug.sizeof.devstat: 288 > debug.sizeof.namecache: 72 > debug.to_avg_mpcalls: 2000 > debug.to_avg_mtxcalls: 0 > debug.to_avg_gcalls: 1145 > debug.to_avg_depth: 3279 > debug.umtx.umtx_pi_allocated: 0 > debug.kdb.stop_cpus: 1 > debug.kdb.trap_code: 0 > debug.kdb.trap: 0 > debug.kdb.panic: 0 > debug.kdb.enter: 0 > debug.kdb.current: > debug.kdb.available: > debug.rman_debug: 0 > debug.ttydebug: 0 > debug.disablefullpath: 0 > debug.disablecwd: 0 > debug.vfscache: 1 > debug.numcachehv: 12695 > debug.numcache: 71522 > debug.numneg: 4468 > debug.ncnegfactor: 16 > debug.nchash: 131071 > debug.vnlru_nowhere: 0 > debug.rush_requests: 0 > debug.mpsafevfs: 1 > debug.if_tun_debug: 0 > debug.nlm_debug: 0 > debug.collectsnapstats: 0 > debug.snapdebug: 0 > debug.dopersistence: 0 > debug.dir_entry: 2378 > debug.direct_blk_ptrs: 869 > debug.inode_bitmap: 2093 > debug.indir_blk_ptrs: 666 > debug.sync_limit_hit: 0 > debug.ino_limit_hit: 0 > debug.blk_limit_hit: 0 > debug.ino_limit_push: 0 > debug.blk_limit_push: 0 > debug.worklist_push: 0 > debug.maxindirdeps: 50 > debug.tickdelay: 2 > debug.max_softdeps: 400000 > debug.dobkgrdwrite: 1 > debug.bigcgs: 0 > debug.dircheck: 0 > debug.minidump: 1 > debug.stop_cpus_with_nmi: 1 > debug.psm.pkterrthresh: 2 > debug.psm.usecs: 500000 > debug.psm.secs: 0 > debug.psm.errusecs: 0 > debug.psm.errsecs: 2 > debug.psm.hz: 20 > debug.psm.loglevel: 0 > debug.fdc.settle: 0 > debug.fdc.spec2: 16 > debug.fdc.spec1: 175 > debug.fdc.retries: 10 > debug.fdc.debugflags: 0 > debug.fdc.fifo: 8 > debug.elf32_legacy_coredump: 0 > debug.elf32_trace: 0 > debug.nullfs_bug_bypass: 0 > [root@pluto ~]# > > Should I boot the kernel in debug modus? I can't believe. > > Kind Regards > > Jörg > > > > > gavin@FreeBSD.org wrote: > > Synopsis: [panic] panic after spinlock held too long with FreeBSD > 7.2-RELEASE-p2 on CPU: Intel(R) Atom(TM) CPU 330 @ 1.60GHz > (1618.46-MHz K8-class CPU) > > State-Changed-From-To: open->feedback > > State-Changed-By: gavin > > State-Changed-When: Mon Jul 27 13:32:23 UTC 2009 > > State-Changed-Why: > > To submitter: Firstly, could you please provide the output of: > > > ps -aux -M /var/crash/vmcore.0 > > > Also, is this something that has only ever happened once, or can you > reproduce > > it easily? Are you in a position where you can get information > out of the > > system from the kernel debugger if it happens again? If so, the > output > > of "show alllocks; alltrace; ps; show allpcpu" would be very useful. > > > If you don't have interactive access to the debugger, have no way of > logging > > the output, or need the achine up as quickly as possible, you > should be > able > > to make use of the textdump(4) facility, enabled from the command > prompt as > > follows: > > > ddb script kdb.enter.panic="textdump set; capture on; show > allpcpu; bt; > ps; alltrace; show alllock; call doadump; reset" > > sysctl debug.ddb.textdump.pending=1 > > > then please provide the ddb.txt from /var/crash > > > > Responsible-Changed-From-To: freebsd-bugs->gavin > > Responsible-Changed-By: gavin > > Responsible-Changed-When: Mon Jul 27 13:32:23 UTC 2009 > > Responsible-Changed-Why: > > Track > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=137117 > > > - -- Joerg Ruppe-Tanner Schuetzenweg 19 3294 Bueren an der Aare email: joerg.ruppe.tanner@gmail.com email: joerg.ruppe-tanner@ch-open.ch http://www.jrtnet.ch Tel.: (+41) 32 351 5840 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREDAAYFAkp/wTkACgkQaUHqwWEIg1tC0ACfSavYCZvrl3Xn1DEWJYEsB0MH qmYAnjcP2mT7p2riSLTlMeQJqbEks6eB =CRo/ -----END PGP SIGNATURE----- --------------020506040501030203080103--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A7FC13D.2010305>