Re: cvs commit: src/sys/kern kern_timeout.c src/sys/sys callout.h

Attilio Rao wrote:
attilio 2007-11-20 00:37:45 UTC

FreeBSD src repository

Modified files:
sys/kern kern_timeout.c
sys/sys callout.h
Log:
Add the function callout_init_rw() to callout facility in order to use
rwlocks in conjuction with callouts. The function does basically what
callout_init_mtx() alredy does with the difference of using a rwlock
as extra argument.
CALLOUT_SHAREDLOCK flag can be used, now, in order to acquire the lock
only
in read mode when running the callout handler. It has no effects when
used in conjuction with mtx.

In order to implement this, underlying callout functions have been made
completely lock type-unaware, so accordingly with this, sysctl
debug.to_avg_mtxcalls is now changed in the generic
debug.to_avg_lockcalls.

Note: currently the allowed lock classes are mutexes and rwlocks because
callout handlers run in softclock swi, so they cannot sleep and they
cannot acquire sleepable locks like sx or lockmgr.

Requested by: kmacy, pjd, rwatson
Reviewed by: jhb

Revision Changes Path
1.107 +57 -52 src/sys/kern/kern_timeout.c
1.32 +10 -3 src/sys/sys/callout.h
_______________________________________________
cvs-src@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-src
To unsubscribe, send any mail to "cvs-src-unsubscribe@xxxxxxxxxxx"

Did I update at the wrong time? I get this after I rebuilt world trying to
go to multi user:

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0xdeadc0ee
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc075ea03
stack pointer = 0x28:0xe4364c54
frame pointer = 0x28:0xe4364c64
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 12 (swi4: clock sio)
[thread pid 12 tid 100005 ]
Stopped at _mtx_assert+0x53: movl 0x10(%edx),%eax
db> bt
Tracing pid 12 tid 100005 td 0xc3f08440
_mtx_assert(deadc0de,14,c0ac8273,a7,c422f860,...) at _mtx_assert+0x53
unlock_mtx(deadc0de,1,c0aca89d,f2,6,...) at unlock_mtx+0x2a
softclock(0,0,c0ac60de,46f,c3f46364,...) at softclock+0x293
ithread_loop(c3f05280,e4364d38,c0ac5e54,30c,c3f067f8,...) at
ithread_loop+0x1c5
fork_exit(c074e7f0,c3f05280,e4364d38) at fork_exit+0xc5
fork_trampoline() at fork_trampoline+0x8
--- trap 0, eip = 0, esp = 0xe4364d70, ebp = 0 ---
db> show alllocks
Process 12 (swi4: clock sio) thread 0xc3f08440 (100005)
exclusive sleep mutex Giant r = 0 (0xc0be3570) locked
@ /usr/src/sys/kern/kern_mutex.c:151
db> call doadump
Physical memory: 1010 MB
Dumping 48 MB: 33 17 1
Dump complete
= 0xf
db> panic
panic: from debugger
cpuid = 0
Uptime: 23s
Automatic reboot in 15 seconds - press a key on the console to abort

--
Mark Atkinson
atkin901@xxxxxxxxx
(!wired)?(coffee++):(wired);

_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: em0 panic: mutex em0 not owned
    ... this is a race access to callout_stopin em driver. ... basically em_stopboth wants to stop core callout and tx channel ... callout but it only holds core lock. ...
    (freebsd-current)
  • Re: em0 panic: mutex em0 not owned
    ... basically em_stopboth wants to stop core callout and tx channel ... callout but it only holds core lock. ... patch now so the ball is in jfv@ court. ...
    (freebsd-current)
  • Re: em0 panic: mutex em0 not owned
    ... basically em_stopboth wants to stop core callout and tx channel ... callout but it only holds core lock. ... patch now so the ball is in jfv@ court. ...
    (freebsd-current)
  • [RFC] callout overhaul: part I
    ... Some benchmarks posted by rwatson some time ago ( ... would add the support for callout working with rwlock. ... only possible kind of lock to be used in conjuction with callouts and ...
    (freebsd-arch)