This is 6.4-stable from April.
System locks up while in `sysctl dev.cpu` (with coretemp kldloaded).
So as far as I understand sched_bind() binds an executing thread to
nonexistent CPU 255.
Same behavior on coretemp built on 6.2.
db> ps
pid ppid pgrp uid state wmesg wchan cmd
34381 34380 34381 0 R+ CPU 255 sysctl
[...]
db> bt 34381
Tracing pid 34381 tid 100166 td 0xc8634680
sched_switch(c8634680,0,1) at sched_switch+0x143
mi_switch(1,0,c86347e0,4,c0a4e510,...) at mi_switch+0x1ba
sched_bind(c8634680,4,c856f3b0,0,c0836b3b,...) at sched_bind+0x52
coretemp_get_temp_sysctl(c8ef56c0,c908c200,0,eebebc04,c8ef56c0,...) at
coretemp_get_temp_sysctl+0x47
sysctl_root(0,eebebc74,4,eebebc04) at sysctl_root+0x107
userland_sysctl(c8634680,eebebc74,4,0,bfbfda8c,0,0,0,eebebc70,0) at
userland_sysctl+0x112
__sysctl(c8634680,eebebd04) at __sysctl+0x93
syscall(3b,3b,3b,4,bfbfda8c,...) at syscall+0x2bf
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x2812407b, esp =
0xbfbfd9fc, ebp = 0xbfbfda38 ---
static int
coretemp_get_temp(device_t dev)
{
uint64_t msr;
int temp;
int cpu = device_get_unit(dev);
struct coretemp_softc *sc = device_get_softc(dev);
char stemp[16];
mtx_lock_spin(&sched_lock);
sched_bind(curthread, cpu);
^^^
mtx_unlock_spin(&sched_lock);
--
wbr,
pluknet
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
