Re: msk0 freezes again
On Mon, 13 May 2013 09:13:14, kit wrote: k the marvell network adapter on my shuttle box freezes easily with minimal network traffic..:( k root@test:/home/ktsin # dhclient msk0DHCPDISCOVER on msk0 to 255.255.255.255 port 67 interval 4DHCPDISCOVER on msk0 to 255.255.255.255 port 67 interval 10DHCPDISCOVER on msk0 to 255.255.255.255 port 67 interval 8DHCPOFFER from 192.168.100.1DHCPREQUEST on msk0 to 255.255.255.255 port 67DHCPACK from 192.168.100.1bound to 192.168.100.200 -- renewal in 300 seconds.root@test:/home/ktsin # vmstat -ia | grep mskirq259: mskc0             190      1root@test:/home/ktsin # vmstat -ia | grep mskirq259: mskc0           1148176    7654root@test:/home/ktsin # vmstat -ia | grep mskirq259: mskc0           3643520    22490root@test:/home/ktsin # uname -aFreeBSD test.yahoo.com 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r250365: Thu May  9 07:18:39 MYT 2013   kt...@test.yahoo.com:/tmp/obj/usr/src/sys/SHUTTLE root@test:/home/ktsin # dmesg| grep mskmskc0: Marvell Yukon 88E8057 Gigabit Ethernet k port 0xe800-0xe8ff mem 0xfebfc000-0xfebf irq 18 at device 0.0 on pci3msk0: Marvell Technology Group Ltd. Yukon Ultra 2 Id 0xba Rev 0x00 on mskc0msk0: Ethernet address: 80:ee:73:09:d1:73miibus0: MII bus on msk0msk0: link state changed to DOWNmsk0: link state changed to UPmsk0: watchdog timeoutmsk0: link state changed to DOWN k looks similar to http://www.freebsd.org/cgi/query-pr.cgi?pr=164569, but this time msk freezes on current but works fine on 9.x. k any idea on how to troubleshoot? I have msk card (card=0xe0001458 chip=0x436411ab rev=0x12), and this card stop to work under load with default settings. With hw.msk.msi_disable=1 in /boot/loader.conf this card can work. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
gstat don't work after update to 10.0-CURRENT
gstat don't work after update to 10.0-CURRENT r233947 It don't show any providers, and don't print any errors: # gstat -b dT: 1.166s w: 1.000s L(q) ops/sr/s kBps ms/rw/s kBps ms/w %busy Name # HDD works via ATA_CAM. :~ sysctl kern.disks kern.disks: ada2 ada1 ada0 # camcontrol devlist WDC WD1600JS-00MHB0 02.01C03 at scbus3 target 0 lun 0 (ada0,pass0) WDC WD1600JS-60MHB5 10.02E04 at scbus4 target 0 lun 0 (ada1,pass1) WDC WD5001ABYS-01YNA0 59.01D01 at scbus5 target 0 lun 0 (ada2,pass2) sysctl kern.geom output: http://paste.org.ru/?i2a2zp Any suggestuions how to fix gstat? -- Anton Yuzhaninov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: gstat don't work after update to 10.0-CURRENT
On Tue, 10 Apr 2012 15:19:37, Anton Yuzhaninov wrote: AY gstat don't work after update to 10.0-CURRENT r233947 AY It don't show any providers, and don't print any errors: AY # gstat -b AY dT: 1.166s w: 1.000s AY L(q) ops/sr/s kBps ms/rw/s kBps ms/w %busy Name AY # After reverting r233646 gstat show: dT: 1.001s w: 1.000s L(q) ops/sr/s kBps ms/rw/s kBps ms/w %busy Name 0 0 0 00.0 0 00.00.0 ada0 0 0 0 00.0 0 00.00.0 ada0s1 0 0 0 00.0 0 00.00.0 ada1 1392392 19032.3 0 00.0 91.6 ada2 0 0 0 00.0 0 00.00.0 ada1s1 1392392 19032.4 0 00.0 92.5 ufs/backup 0 0 0 00.0 0 00.00.0 mirror/gm0 0 0 0 00.0 0 00.00.0 mirror/gm0a 0 0 0 00.0 0 00.00.0 mirror/gm0b 0 0 0 00.0 0 00.00.0 mirror/gm0d so problem somewhere in http://svn.freebsd.org/changeset/base/233646 -- Anton Yuzhaninov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
panic on reboot (geli+glabel)
After upgrade to r228059 my system panics on each reboot.
(kgdb) bt
#0 doadump (textdump=0) at pcpu.h:244
#1 0xc04a5c31 in db_dump (dummy=-1067276850, dummy2=0, dummy3=-1,
dummy4=0xc4a0996c ) at /usr/src/sys/ddb/db_command.c:537
#2 0xc04a5713 in db_command (last_cmdp=0xc094b2bc, cmd_table=0x0, dopager=1)
at /usr/src/sys/ddb/db_command.c:448
#3 0xc04a5842 in db_command_loop () at /usr/src/sys/ddb/db_command.c:501
#4 0xc04a765f in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:229
#5 0xc066fcab in kdb_trap (type=12, code=0, tf=0xc4a09bec) at
/usr/src/sys/kern/subr_kdb.c:625
#6 0xc084561e in trap_fatal (frame=0xc4a09bec, eva=4026593588) at
/usr/src/sys/i386/i386/trap.c:966
#7 0xc0845980 in trap_pfault (frame=0xc4a09bec, usermode=0, eva=4026593588) at
/usr/src/sys/i386/i386/trap.c:888
#8 0xc084686f in trap (frame=0xc4a09bec) at /usr/src/sys/i386/i386/trap.c:558
#9 0xc083012c in calltrap () at /usr/src/sys/i386/i386/exception.s:168
#10 0xc062a5ce in _mtx_lock_sleep (m=0x0, tid=3302765280, opts=Variable opts
is not available.
) at /usr/src/sys/kern/kern_mutex.c:370
#11 0xc05d65f3 in g_vfs_orphan (cp=0xc5152900) at
/usr/src/sys/geom/geom_vfs.c:174
#12 0xc05d15eb in g_run_events () at /usr/src/sys/geom/geom_event.c:211
#13 0xc05d2a7e in g_event_procbody (arg=0x0) at
/usr/src/sys/geom/geom_kern.c:122
#14 0xc060dc49 in fork_exit (callout=0xc05d2a14 g_event_procbody, arg=0x0,
frame=0xc4a09d28) at /usr/src/sys/kern/kern_fork.c:995
#15 0xc08301d4 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:275
(kgdb) f 11
#11 0xc05d65f3 in g_vfs_orphan (cp=0xc5152900) at
/usr/src/sys/geom/geom_vfs.c:174
174 mtx_lock(sc-sc_mtx);
(kgdb) p *cp-geom
$8 = {name = 0xc50f2b60 ffs.label/spool2.eli, class = 0xc0912880, geom =
{le_next = 0xc518a980, le_prev = 0xc09128d0}, consumer = {lh_first =
0xc5152900}, provider = {
lh_first = 0x0}, geoms = {tqe_next = 0x0, tqe_prev = 0xc5269d98}, rank = 5,
start = 0, spoiled = 0, attrchanged = 0, dumpconf = 0, access = 0,
orphan = 0xc05d6588 g_vfs_orphan, ioctl = 0, spare0 = 0x0, spare1 = 0x0,
softc = 0x0, flags = 1}
crashinfo:
http://dl.dropbox.com/u/8798217/tmp/core.txt.0.gz
--
Anton Yuzhaninov
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: truss
On Tue, 20 Sep 2011 00:27:22 +0300, Kostik Belousov wrote: KB Could you, please, test the change below ? For me, I still can truss(1) KB or debug with gdb after the change applied. Does truss work for you KB with only this change, without resetting SIGTRAP handler in truss process ? KB KB commit 2ae586c039a55399edc3b34cd40410e0d690a16c KB Author: Konstantin Belousov kos...@pooma.home KB Date: Tue Sep 20 00:25:07 2011 +0300 KB KB Do not deliver SIGTRAP on exec as the normal signal, use ptracestop() KB on syscall exit path. Otherwise, if SIGTRAP is ignored, that tdsendsignal() KB do not want to deliver, and debugger never get a notification of exec. I can confirm - with this patch unmodified truss works when SIGTRAP is ignored. -- Anton Yuzhaninov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: truss
On Tue, 20 Sep 2011 00:27:22 +0300, Kostik Belousov wrote:
With this patch truss works for me:
--- usr.bin/truss/main.c(revision 225504)
+++ usr.bin/truss/main.c(working copy)
@@ -255,6 +255,11 @@ main(int ac, char **av)
if (trussinfo-pid == 0) { /* Start a command ourselves */
command = av;
+ /*
+* SIGTRUP used to stop traced process after execve
+* un-ignore this signal (it can be ignored by parents)
+*/
+ signal(SIGTRAP, SIG_DFL);
trussinfo-pid = setup_and_wait(command);
signal(SIGINT, SIG_IGN);
signal(SIGTERM, SIG_IGN);
KB This is quite a hack. The proper fix should go in kernel, otherwise
KB we cannot debug programs that decided to ignore SIGTRAP. The reason
It seems to be, that in gdb used similar hack:
citrin:~ procstat -i 2433 | fgrep TRAP
2433 dd TRAP -I-
:~ gdb /bin/dd 2433
...
(gdb) next
Single stepping until exit from function write,
which has no line number information.
dd_out (force=1) at dd.c:458
458 if (nw = 0) {
(gdb)
...
:~ procstat -i 2433 | fgrep TRAP
2433 dd TRAP ---
KB Could you, please, test the change below ? For me, I still can truss(1)
KB or debug with gdb after the change applied. Does truss work for you
KB with only this change, without resetting SIGTRAP handler in truss process ?
I'll test this patch.
--
Anton Yuzhaninov
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: truss
On Sun, 18 Sep 2011 16:46:01 +0300, Mikolaj Golub wrote: MG Could you please run ktrace with -i option? The behavior is like if MG ptrace(PT_TRACE_ME) failed in the child by some reason. Unfortunately, truss MG does not check this. ktrace -i for truss sleep 5 http://dl.dropbox.com/u/8798217/tmp/truss_ktrace2.txt -- Anton Yuzhaninov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: truss
On Mon, 19 Sep 2011 15:58:02 +0300, Mikolaj Golub wrote: AY ktrace -i for truss sleep 5 AY http://dl.dropbox.com/u/8798217/tmp/truss_ktrace2.txt MG MG Although ptrace(PT_TRACE_ME,0,0,0) returned 0 the process did not stop after MG execve() and wait4() in parent (which was actually waiting for this stop) MG returned only after the child exit. No I idea why so far :-). MG As I understand SIGTRAP used to stop child process after execve(), but this signal ignored: citrin:~ sleep 300 citrin:~ procstat -i 1991 | fgrep TRAP 1991 sleepTRAP -I- Under FreeBSD 8, where ptrace works for me, this signal is not ignored: x:~ sleep 300 x:~ procstat -i 78716 | fgrep TRAP 78716 sleepTRAP --- -- Anton Yuzhaninov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Dtrace: type mismatch in sys/kern/kern_sig.c
In the file sys/kern/kern_sig.c defined DTrace probe proc:::signal-discard SDT_PROBE_DEFINE(proc, kernel, , signal_discard, signal-discard); SDT_PROBE_ARGTYPE(proc, kernel, , signal_discard, 0, struct thread *); SDT_PROBE_ARGTYPE(proc, kernel, , signal_discard, 1, struct proc *); SDT_PROBE_ARGTYPE(proc, kernel, , signal_discard, 2, int); Then latter this proble called as: SDT_PROBE(proc, kernel, , signal_discard, ps, td, sig, 0, 0 ); type for var ps is struct sigacts* =! struct thread * (bug?) type for var td is struct thread * =! struct proc * (bug?) type for var sig is int == int (ok) To match solaris DTrace probe shuild called as: SDT_PROBE(proc, kernel, , signal_discard, td, p, sig, 0, 0 ); -- Anton Yuzhaninov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: truss
On Mon, 19 Sep 2011 15:00:31 + (UTC), Anton Yuzhaninov wrote:
AY On Mon, 19 Sep 2011 15:58:02 +0300, Mikolaj Golub wrote:
AY ktrace -i for truss sleep 5
AY http://dl.dropbox.com/u/8798217/tmp/truss_ktrace2.txt
MG
MG Although ptrace(PT_TRACE_ME,0,0,0) returned 0 the process did not stop
after
MG execve() and wait4() in parent (which was actually waiting for this stop)
MG returned only after the child exit. No I idea why so far :-).
MG
AY
AY As I understand SIGTRAP used to stop child process after execve(), but
AY this signal ignored:
AY
AY citrin:~ sleep 300
AY citrin:~ procstat -i 1991 | fgrep TRAP
AY 1991 sleepTRAP -I-
AY
AY Under FreeBSD 8, where ptrace works for me, this signal is not ignored:
AY x:~ sleep 300
AY x:~ procstat -i 78716 | fgrep TRAP
AY 78716 sleepTRAP ---
SIGTRAP is ignored by X window manager used by me, and this is inherited across
forks/execs up to the truss.
IMHO truss should restore default signal handler for SIGTRAP.
With this patch truss works for me:
--- usr.bin/truss/main.c(revision 225504)
+++ usr.bin/truss/main.c(working copy)
@@ -255,6 +255,11 @@ main(int ac, char **av)
if (trussinfo-pid == 0) { /* Start a command ourselves */
command = av;
+ /*
+* SIGTRUP used to stop traced process after execve
+* un-ignore this signal (it can be ignored by parents)
+*/
+ signal(SIGTRAP, SIG_DFL);
trussinfo-pid = setup_and_wait(command);
signal(SIGINT, SIG_IGN);
signal(SIGTERM, SIG_IGN);
--
Anton Yuzhaninov
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: truss
On Fri, 09 Sep 2011 15:56:41 -0700, Xin LI wrote: XL -BEGIN PGP SIGNED MESSAGE- XL Hash: SHA256 XL XL On 08/31/11 07:35, Anton Yuzhaninov wrote: It seems to be truss(1) is broken on current :~ truss /bin/echo x x truss: can not get etype: No such process FreeBSD 9.0-BETA1 #0 r224884M i386 from ktrace of turss 3162 trussCALL __sysctl(0xbfbfea00,0x4,0xbfbfe9e0,0xbfbfea10,0,0) 3162 truss SCTL kern.proc.sv_name.3163 3162 trussRET __sysctl -1 errno 3 No such process XL XL Can't seem to be reproducable here, did I missed anything? (note that XL you may need a full world/kernel build). XL Problem still here after svn up and rebuild world/kernel :~ ktrace -t+ truss /usr/bin/true truss: can not get etype: No such process Full ktrace: http://dl.dropbox.com/u/8798217/tmp/truss_ktrace.txt FreeBSD 9.0-BETA2 #1 r225504M i386 Kernel config is not GENERIC - main difference - DTrace added: http://dl.dropbox.com/u/8798217/tmp/kernconf.txt -- Anton Yuzhaninov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
truss
It seems to be truss(1) is broken on current :~ truss /bin/echo x x truss: can not get etype: No such process FreeBSD 9.0-BETA1 #0 r224884M i386 from ktrace of turss 3162 trussCALL __sysctl(0xbfbfea00,0x4,0xbfbfe9e0,0xbfbfea10,0,0) 3162 trussSCTL kern.proc.sv_name.3163 3162 trussRET __sysctl -1 errno 3 No such process -- Anton Yuzhaninov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Switch from legacy ata(4) to CAM-based ATA
On Wed, 20 Apr 2011 12:57:47 +0300, Alexander Motin wrote: AM If somebody has any problems with new ATA stack, please repeat your AM tests with latest HEAD code and contact me if problem is still there. AM Next three weeks before BSDCan I am going to dedicate to fixing possibly AM remaining issues. On motherboard MSI MS-7210 no HDD detected with new GENERIC (r221012). In dmesg I see line like: device_attach: ahci0 attach returned 6 (I have no serial console cable and can't capture full dmesg). From pciconf -vlbc (when I boot with old ata) atapci1@pci0:0:31:2:class=0x01018f card=0x72101462 chip=0x27c08086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801GB/GR/GH (ICH7 Family) Serial ATA Storage Controller' class = mass storage subclass = ATA bar [10] = type I/O Port, range 32, base 0xe880, size 8, enabled bar [14] = type I/O Port, range 32, base 0xe800, size 4, enabled bar [18] = type I/O Port, range 32, base 0xe480, size 8, enabled bar [1c] = type I/O Port, range 32, base 0xe400, size 4, enabled bar [20] = type I/O Port, range 32, base 0xe080, size 16, enabled cap 01[70] = powerspec 2 supports D0 D3 current D0 -- WBR, Anton Yuzhaninov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
geli on r221012
Geli no longer works for me after upgrade to r221012. # geli attach -k ~citrin/private.key /dev/label/spool2 Enter passphrase: # from dmesg: GEOM_ELI: Device label/spool2.eli created. GEOM_ELI: Encryption: Blowfish-CBC 128 GEOM_ELI: Integrity: HMAC/MD5 GEOM_ELI: Crypto: software # dd if=/dev/label/spool2.eli of=/dev/null dd: /dev/label/spool2.eli: Invalid argument 0+0 records in 0+0 records out 0 bytes transferred in 0.000669 secs (0 bytes/sec) # geli status Name Status Components label/spool2.eli ACTIVE label/spool # geli list Geom name: label/spool2.eli State: ACTIVE EncryptionAlgorithm: Blowfish-CBC KeyLength: 128 AuthenticationAlgorithm: HMAC/MD5 Crypto: software UsedKey: 0 Flags: AUTH KeysAllocated: 125 KeysTotal: 125 Providers: 1. Name: label/spool2.eli Mediasize: 59545088000 (55G) Sectorsize: 4096 Mode: r0w0e0 Consumers: 1. Name: label/spool2 Mediasize: 66988228096 (62G) Sectorsize: 512 Mode: r1w1e1 -- WBR, Anton Yuzhaninov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: geli on r221012
On Mon, 25 Apr 2011 13:31:55 + (UTC), Anton Yuzhaninov wrote: AY Geli no longer works for me after upgrade to r221012. AY r220286 works for me. -- WBR, Anton Yuzhaninov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
how to build kernel with CTF data for DTrace?
On this page: http://wiki.freebsd.org/DTrace written, that for 9-current is sufficient to rebild kernel with this options: options DDB_CTF options KDTRACE_HOOKS makeoptions DEBUG=-g makeoptions WITH_CTF=1 I have rebuild kernel with this options, but: $ ctfdump -l /boot/kernel/kernel /boot/kernel/kernel does not contain .SUNW_ctf data Is instruction in wiki outdated? full build log: https://hius.citrin.ru/a/2011-03-23-buildkernel.log FreeBSD 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r219710M -- WBR, Anton Yuzhaninov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: how to build kernel with CTF data for DTrace?
On Wed, 23 Mar 2011 14:08:22 +0200, Andriy Gapon wrote: I have rebuild kernel with this options, but: $ ctfdump -l /boot/kernel/kernel /boot/kernel/kernel does not contain .SUNW_ctf data FreeBSD 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r219710M AG AG Just an idea - do you have WITHOUT_CDDL in your src.conf or something like that? Thsnks, I forgot to removed WITHOUT_CDDL from src.conf -- WBR, Anton Yuzhaninov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
AHCI on ICH7
Is it possible to get AHCI working on this controller:
atap...@pci0:0:31:2:class=0x01018f card=0x72101462 chip=0x27c08086
rev=0x01 hdr=0x00
vendor = 'Intel Corporation'
device = '82801GB/GR/GH (ICH7 Family) Serial ATA Storage
Controller'
class = mass storage
subclass = ATA
bar [10] = type I/O Port, range 32, base 0xe880, size 8, enabled
bar [14] = type I/O Port, range 32, base 0xe800, size 4, enabled
bar [18] = type I/O Port, range 32, base 0xe480, size 8, enabled
bar [1c] = type I/O Port, range 32, base 0xe400, size 4, enabled
bar [20] = type I/O Port, range 32, base 0xe080, size 16, enabled
cap 01[70] = powerspec 2 supports D0 D3 current D0
BIOS show that AHCI 1.0 supported.
I tried this patch with no success:
--- sys/dev/ahci/ahci.c (revision 217301)
+++ sys/dev/ahci/ahci.c (working copy)
@@ -129,6 +129,7 @@
{0x26838086, 0x00, Intel ESB2,0},
{0x27c18086, 0x00, Intel ICH7,0},
{0x27c38086, 0x00, Intel ICH7,0},
+ {0x27c08086, 0x00, Intel ICH7,0},
{0x27c58086, 0x00, Intel ICH7M, 0},
{0x27c68086, 0x00, Intel ICH7M, 0},
{0x28218086, 0x00, Intel ICH8,0},
from dmesg with this patch:
device_attach: ahci0 attach returned 6
--
WBR,
Anton Yuzhaninov
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
panic in deadlkres
I've got panic on 9-current from Jun 25 2010
May be this is bug in deadlock resolver
panic: blockable sleep lock (sleep mutex) process lock @
/usr/src/sys/kern/kern_clock.c:203
db show alllocks
Process 0 (kernel) thread 0xc4dcd270 (100047)
shared sx allproc (allproc) r = 0 (0xc0885ebc) locked @
/usr/src/sys/kern/kern_clock.c:193
db show lock 0xc4dcd270
class: spin mutex
name: D
flags: {SPIN, RECURSE}
state: {OWNED}
(kgdb) bt
#0 doadump () at pcpu.h:248
#1 0xc05ae59f in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416
#2 0xc05ae825 in panic (fmt=Variable fmt is not available.
) at /usr/src/sys/kern/kern_shutdown.c:590
#3 0xc048ff45 in db_panic (addr=Could not find the frame base for db_panic.
) at /usr/src/sys/ddb/db_command.c:478
#4 0xc0490533 in db_command (last_cmdp=0xc086ef1c, cmd_table=0x0, dopager=1)
at /usr/src/sys/ddb/db_command.c:445
#5 0xc0490662 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498
#6 0xc04923ef in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:229
#7 0xc05dade6 in kdb_trap (type=3, code=0, tf=0xc4b31bd0) at
/usr/src/sys/kern/subr_kdb.c:535
#8 0xc078696b in trap (frame=0xc4b31bd0) at /usr/src/sys/i386/i386/trap.c:692
#9 0xc076ca0b in calltrap () at /usr/src/sys/i386/i386/exception.s:165
#10 0xc05daf30 in kdb_enter (why=0xc07ea02d panic, msg=0xc07ea02d panic) at
cpufunc.h:71
#11 0xc05ae806 in panic (fmt=0xc07efd94 blockable sleep lock (%s) %s @ %s:%d)
at /usr/src/sys/kern/kern_shutdown.c:573
#12 0xc05ee30b in witness_checkorder (lock=0xc5148088, flags=9, file=0xc07e3b20
/usr/src/sys/kern/kern_clock.c, line=203, interlock=0x0)
at /usr/src/sys/kern/subr_witness.c:1067
#13 0xc05a093c in _mtx_lock_flags (m=0xc5148088, opts=0, file=0xc07e3b20
/usr/src/sys/kern/kern_clock.c, line=203)
at /usr/src/sys/kern/kern_mutex.c:200
#14 0xc05706a9 in deadlkres () at /usr/src/sys/kern/kern_clock.c:203
#15 0xc0588721 in fork_exit (callout=0xc05705ea deadlkres, arg=0x0,
frame=0xc4b31d38) at /usr/src/sys/kern/kern_fork.c:843
#16 0xc076ca80 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270
--
WBR,
Anton Yuzhaninov
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic in deadlkres
On Fri, 25 Jun 2010 09:50:40 + (UTC), Anton Yuzhaninov wrote:
AY I've got panic on 9-current from Jun 25 2010
It's wrong date. The system is:
FreeBSD 9.0-CURRENT #0: Fri May 28 23:47:37 MSD 2010
AY
AY May be this is bug in deadlock resolver
AY
AY panic: blockable sleep lock (sleep mutex) process lock @
AY /usr/src/sys/kern/kern_clock.c:203
AY
db show alllocks
AY Process 0 (kernel) thread 0xc4dcd270 (100047)
AY shared sx allproc (allproc) r = 0 (0xc0885ebc) locked @
AY /usr/src/sys/kern/kern_clock.c:193
AY
db show lock 0xc4dcd270
AY class: spin mutex
AY name: D
AY flags: {SPIN, RECURSE}
AY state: {OWNED}
--
WBR,
Anton Yuzhaninov
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
