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)

Joerg Ruppe-Tanner joerg.ruppe.tanner at gmail.com
Mon Aug 10 07:13:32 UTC 2009


-----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 at pluto ~]# ps -aux -M /var/crash/vmcore.0
> USER   PID %CPU %MEM   VSZ   RSS  TT  STAT STARTED      TIME COMMAND
> [root at 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 at 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 at pluto ~]#     
>
> Should I boot the kernel in debug modus?  I can't believe.
>
> Kind Regards
>
> Jörg
>
>
>
>
> gavin at 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 at gmail.com
email: joerg.ruppe-tanner at 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-----



More information about the freebsd-bugs mailing list