Re: powerd causing crash on Mini-ITX EN1200
Perhaps, but I rarely run Xorg. I use the machine as a gateway for our network in the house. I've noticed it most often when under a network load but that might not be a real correlation. On Thu, Feb 26, 2009 at 2:47 PM, Paul B. Mahol wrote: > On 2/26/09, Ross Penner wrote: >> Hi, >> >> When I enable powerd, it is only but a matter of time before my >> machine will lock up completely. I've had this problem since I've >> migrated to FreeBSD 7 from 6. FreeBSD 6 never seemed to have any >> problems. I doesn't seem to create a dump so I've had no luck on that >> end. I'm quite perplexed on how to proceed to help get this problem >> documented so it can be fixed. >> >> #uname -a >> FreeBSD rosbox.dyndns.org 7.1-STABLE FreeBSD 7.1-STABLE #0: Thu Feb 26 >> 00:38:44 PST 2009 >> r...@rosbox.dyndns.org:/usr/obj/usr/src/sys/MYKERNEL7 i386 >> >> Is there anything else I con provide that would be of assistance? > > I'm aware of livelock between syscons and powerd which is not trivial to > reproduce (at least for me). > Does it locks in Xorg too? > > -- > Paul > ___ 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"
Re: ural driver stalls under FreeBSD7.1
Weongyo Jeong wrote: > On Thu, Feb 26, 2009 at 06:04:17PM -0800, Sam Leffler wrote: >> Bengt Ahlgren wrote: >>> Weongyo Jeong writes: >>> On Thu, Feb 26, 2009 at 01:20:36PM +0900, Nathan Butcher wrote: > I have a Buffalo WLI-U2-KG54-AI wireless USB adaptor. > It has been malfunctioning for quite a while under FreeBSD7.0 and 7.1 > > Typically, It works for a while until eventually it stalls data > transfers completely. It always seems to do this after an unspecified > amount of time. > > I know the hardware isn't at fault because the device works fine under > Linux. > Could you please check that `ifconfig -bgscan' disabling the background scan helps your symptom? >>> The above sounds like the same problem as this: >>> >>> http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011376.html >>> http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html >>> >>> The problem is in the background scanning logic in sys/net80211. >> I don't see how you come to this conclusion. ural is a totally >> different driver than ath and so far as I can recall you never found the >> cause for your problem w/ ath. Most of the usb wireless drivers do a >> haphazard job of synchronizing async tasks like bg scan with the >> foreground tx/rx processing. This can lead to firmware and/or usb >> issues. ath does not have these issues but I am aware of at least one >> problem w/ bg scanning in ath under RELENG_7 (that is not present in HEAD). > > I agree with sam because I saw some cases like stalls during background > scanning that most of them I think it's caused by H/W miss-operation or > miss-configuration by mistakes of driver. I'll do some testing without the bgscan and report back. (haven't had time recently) ___ 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"
Re: ural driver stalls under FreeBSD7.1
On Thu, Feb 26, 2009 at 06:04:17PM -0800, Sam Leffler wrote: > Bengt Ahlgren wrote: > >Weongyo Jeong writes: > > > >>On Thu, Feb 26, 2009 at 01:20:36PM +0900, Nathan Butcher wrote: > >> > >>>I have a Buffalo WLI-U2-KG54-AI wireless USB adaptor. > >>>It has been malfunctioning for quite a while under FreeBSD7.0 and 7.1 > >>> > >>>Typically, It works for a while until eventually it stalls data > >>>transfers completely. It always seems to do this after an unspecified > >>>amount of time. > >>> > >>>I know the hardware isn't at fault because the device works fine under > >>>Linux. > >>> > >>Could you please check that `ifconfig -bgscan' disabling the > >>background scan helps your symptom? > > > >The above sounds like the same problem as this: > > > >http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011376.html > >http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html > > > >The problem is in the background scanning logic in sys/net80211. > > I don't see how you come to this conclusion. ural is a totally > different driver than ath and so far as I can recall you never found the > cause for your problem w/ ath. Most of the usb wireless drivers do a > haphazard job of synchronizing async tasks like bg scan with the > foreground tx/rx processing. This can lead to firmware and/or usb > issues. ath does not have these issues but I am aware of at least one > problem w/ bg scanning in ath under RELENG_7 (that is not present in HEAD). I agree with sam because I saw some cases like stalls during background scanning that most of them I think it's caused by H/W miss-operation or miss-configuration by mistakes of driver. regards, Weongyo Jeong ___ 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"
Re: ural driver stalls under FreeBSD7.1
Bengt Ahlgren wrote: Weongyo Jeong writes: On Thu, Feb 26, 2009 at 01:20:36PM +0900, Nathan Butcher wrote: I have a Buffalo WLI-U2-KG54-AI wireless USB adaptor. It has been malfunctioning for quite a while under FreeBSD7.0 and 7.1 Typically, It works for a while until eventually it stalls data transfers completely. It always seems to do this after an unspecified amount of time. I know the hardware isn't at fault because the device works fine under Linux. Could you please check that `ifconfig -bgscan' disabling the background scan helps your symptom? The above sounds like the same problem as this: http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011376.html http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html The problem is in the background scanning logic in sys/net80211. I don't see how you come to this conclusion. ural is a totally different driver than ath and so far as I can recall you never found the cause for your problem w/ ath. Most of the usb wireless drivers do a haphazard job of synchronizing async tasks like bg scan with the foreground tx/rx processing. This can lead to firmware and/or usb issues. ath does not have these issues but I am aware of at least one problem w/ bg scanning in ath under RELENG_7 (that is not present in HEAD). Sam ___ 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"
Re: 7.1 hangs in cache_lookup mutex?
On Thursday 26 February 2009 5:27:07 pm Guy Helmer wrote: > John Baldwin wrote: > > On Thursday 26 February 2009 4:22:15 pm Guy Helmer wrote: > > > >> db> show sleepchain 23110 > >> thread 100181 (pid 23110, vmstat) blocked on sx "user map" XLOCK > >> thread 100208 (pid 23092, kvoop) is on a run queue > >> db> show sleepchain 23092 > >> thread 100208 (pid 23092, kvoop) is on a run queue > >> > > > > Ah, so this is normal (well, mostly) in that kvoop is simply on the run queue > > waiting for a CPU. Can you find the thread pointer for kvoop and check on > > things such as if it is pinned and if so to which CPU (td_pinned will tell > > you the first, and td_sched->ts_cpu will tell you the second with ULE). > > > (kgdb) print td->td_pinned > $2 = 0 Ok, not pinned. > From my captured ddb run: > cpuid= 3 > curthread= 0xc5e2f000: pid 23090 "filter" > curpcb = 0xe6f90d90 > fpcurthread = none > idlethread = 0xc442daf0: pid 11 "idle: cpu3" > APIC ID = 7 > currentldt = 0x50 > spin locks held: At http://www.freebsd.org/~jhb/gdb/ you can find my kgdb scripts. If you source gdb6 you can run 'runtds' which will show you what each CPU is doing (more or less) in ps-style output. > I sure wish I could find the root cause of the hangs. On a hunch, I > tried setting "machdep.cpu_idle_hlt=0" on the amd64 machine, and it has > run 32 hours without a hang. It could just be coincidence, though... Ahhh, that actually could explain it perhaps. Do your CPUs support C2 or higher sleep states for idle? You can try limiting it to only C1 (or disable C1E in your BIOS if it has an option for that) to see if that fixes it. -- John Baldwin ___ 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"
Re: powerd causing crash on Mini-ITX EN1200
On 2/26/09, Ross Penner wrote: > Hi, > > When I enable powerd, it is only but a matter of time before my > machine will lock up completely. I've had this problem since I've > migrated to FreeBSD 7 from 6. FreeBSD 6 never seemed to have any > problems. I doesn't seem to create a dump so I've had no luck on that > end. I'm quite perplexed on how to proceed to help get this problem > documented so it can be fixed. > > #uname -a > FreeBSD rosbox.dyndns.org 7.1-STABLE FreeBSD 7.1-STABLE #0: Thu Feb 26 > 00:38:44 PST 2009 > r...@rosbox.dyndns.org:/usr/obj/usr/src/sys/MYKERNEL7 i386 > > Is there anything else I con provide that would be of assistance? I'm aware of livelock between syscons and powerd which is not trivial to reproduce (at least for me). Does it locks in Xorg too? -- Paul ___ 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"
Re: 7.1 hangs in cache_lookup mutex?
John Baldwin wrote:
On Thursday 26 February 2009 4:22:15 pm Guy Helmer wrote:
db> show sleepchain 23110
thread 100181 (pid 23110, vmstat) blocked on sx "user map" XLOCK
thread 100208 (pid 23092, kvoop) is on a run queue
db> show sleepchain 23092
thread 100208 (pid 23092, kvoop) is on a run queue
Ah, so this is normal (well, mostly) in that kvoop is simply on the run queue
waiting for a CPU. Can you find the thread pointer for kvoop and check on
things such as if it is pinned and if so to which CPU (td_pinned will tell
you the first, and td_sched->ts_cpu will tell you the second with ULE).
(kgdb) print td->td_pinned
$2 = 0
(kgdb) print td->td_sched->ts_cpu
$3 = 3 '\003'
(kgdb) print td->td_state
$4 = TDS_RUNQ
From my captured ddb run:
cpuid= 3
curthread= 0xc5e2f000: pid 23090 "filter"
curpcb = 0xe6f90d90
fpcurthread = none
idlethread = 0xc442daf0: pid 11 "idle: cpu3"
APIC ID = 7
currentldt = 0x50
spin locks held:
Back to kgdb:
(kgdb) proc 23090
[Switching to thread 131 (Thread 100199)]#0 cpustop_handler () at
atomic.h:253
253 ATOMIC_ASM(set, int, "orl %1,%0", "ir", v);
(kgdb) where
#0 cpustop_handler () at atomic.h:253
#1 0xc07eedef in ipi_nmi_handler () at ../../../i386/i386/mp_machdep.c:1300
#2 0xc07f85e0 in trap (frame=0xe6f90b64) at ../../../i386/i386/trap.c:216
#3 0xc07e02db in calltrap () at ../../../i386/i386/exception.s:159
#4 0xc068a066 in witness_unlock (lock=0xc5e4cb2c, flags=0,
file=0xc08529f0 "../../../kern/kern_descrip.c", line=2083)
at ../../../kern/subr_witness.c:1266
#5 0xc065c95e in _sx_sunlock (sx=0xc5e4cb2c,
file=0xc08529f0 "../../../kern/kern_descrip.c", line=2083)
at ../../../kern/kern_sx.c:294
#6 0xc062e1ab in fget_read (td=0xc5e2f000, fd=15, fpp=0xe6f90c34)
at ../../../kern/kern_descrip.c:2083
#7 0xc068c2e8 in kern_readv (td=0xc5e2f000, fd=15, auio=0xe6f90c60)
at ../../../kern/sys_generic.c:189
#8 0xc068c3ff in read (td=0xc5e2f000, uap=0xe6f90cfc)
at ../../../kern/sys_generic.c:108
#9 0xc07f8343 in syscall (frame=0xe6f90d38) at
../../../i386/i386/trap.c:1090
#10 0xc07e0340 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255
#11 0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) frame 4
#4 0xc068a066 in witness_unlock (lock=0xc5e4cb2c, flags=0,
file=0xc08529f0 "../../../kern/kern_descrip.c", line=2083)
at ../../../kern/subr_witness.c:1266
1266if (witness_cold || witness_watch == 0 ||
lock->lo_witness == NULL ||
(kgdb) print *lock
$5 = {lo_name = 0xc0852b03 "filedesc structure",
lo_type = 0xc0852b03 "filedesc structure", lo_flags = 37421056,
lo_witness_data = {lod_list = {stqe_next = 0xc091c228},
lod_witness = 0xc091c228}}
Then you will want to see what is running on that CPU. You might want to
check your other coredump and find the td_state member of the thread for
kvoop there as well.
On the amd64, kvoop was on the run queue for cpu 1 and another process,
filter, looks like it must have been running in user mode when I broke
into ddb:
(kgdb) proc 33201
[Switching to thread 127 (Thread 100113)]#0 cpustop_handler () at
atomic.h:264
264 ATOMIC_ASM(set, int, "orl %1,%0", "ir", v);
(kgdb) where
#0 cpustop_handler () at atomic.h:264
#1 0x8050c560 in ipi_nmi_handler ()
at ../../../amd64/amd64/mp_machdep.c:1119
#2 0x8051aba7 in trap (frame=0x9fe18f40)
at ../../../amd64/amd64/trap.c:198
#3 0x805013eb in nmi_calltrap ()
at ../../../amd64/amd64/exception.S:427
#4 0x280af9d4 in ?? ()
Previous frame inner to this frame (corrupt stack?)
I sure wish I could find the root cause of the hangs. On a hunch, I
tried setting "machdep.cpu_idle_hlt=0" on the amd64 machine, and it has
run 32 hours without a hang. It could just be coincidence, though...
Thanks for your help,
Guy
___
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"
Re: 7.1 hangs in cache_lookup mutex?
On Thursday 26 February 2009 4:22:15 pm Guy Helmer wrote: > db> show sleepchain 23110 > thread 100181 (pid 23110, vmstat) blocked on sx "user map" XLOCK > thread 100208 (pid 23092, kvoop) is on a run queue > db> show sleepchain 23092 > thread 100208 (pid 23092, kvoop) is on a run queue Ah, so this is normal (well, mostly) in that kvoop is simply on the run queue waiting for a CPU. Can you find the thread pointer for kvoop and check on things such as if it is pinned and if so to which CPU (td_pinned will tell you the first, and td_sched->ts_cpu will tell you the second with ULE). Then you will want to see what is running on that CPU. You might want to check your other coredump and find the td_state member of the thread for kvoop there as well. -- John Baldwin ___ 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"
Re: 7.1 hangs in cache_lookup mutex?
John Baldwin wrote:
On Wednesday 25 February 2009 10:02:16 am Guy Helmer wrote:
John Baldwin wrote:
On Tuesday 24 February 2009 4:46:28 pm Guy Helmer wrote:
I think I may have found a clue regarding some of the hangs I'm seeing
on FreeBSD 7.1.
I have a program (kvoop), compiled under FreeBSD 6 and using
compatibility libraries under FreeBSD 7, that seems to be consistently
involved during these hangs. This time, I noticed that many processes
are stopped, waiting on the ufs lock. I can't tell for certain, but I
assume this kvoop process 33203 is blocking the other processes. The
kvoop process looks to me like it is waiting for a mutex, but nothing
shows up being deadlocked. Am I on the right track? Is there something
else I should be looking for?
(kgdb) proc 33203
[Switching to thread 129 (Thread 100241)]#0 sched_switch (
td=0xff0019109a50, newtd=0x0, flags=1)
at ../../../kern/sched_ule.c:1944
1944cpuid = PCPU_GET(cpuid);
(kgdb) where
#0 sched_switch (td=0xff0019109a50, newtd=0x0, flags=1)
at ../../../kern/sched_ule.c:1944
#1 0x803a573b in mi_switch (flags=1, newtd=0x0)
at ../../../kern/kern_synch.c:440
#2 0x803d1214 in turnstile_wait (ts=Variable "ts" is not available.
)
at ../../../kern/subr_turnstile.c:748
#3 0x80392db0 in _mtx_lock_sleep (m=0x8083c220,
tid=18446742974618442320, opts=Variable "opts" is not available.
) at ../../../kern/kern_mutex.c:420
#4 0x80392ea6 in _mtx_lock_flags (m=0x8083c220, opts=0,
file=0x805bd438 "../../../kern/vfs_cache.c", line=327)
at ../../../kern/kern_mutex.c:186
#5 0x80403bc6 in cache_lookup (dvp=0xff00013e0dc8,
vpp=0xa2d93a18, cnp=0xa2d93a40)
at ../../../kern/vfs_cache.c:327
#6 0x80404093 in vfs_cache_lookup (ap=Variable "ap" is not
available.
)
at ../../../kern/vfs_cache.c:674
#7 0x805628a0 in VOP_LOOKUP_APV (vop=0x8076e440,
a=0xa2d936b0) at vnode_if.c:99
#8 0x80409afd in lookup (ndp=0xa2d939f0) at vnode_if.h:57
#9 0x8040a824 in namei (ndp=0xa2d939f0)
at ../../../kern/vfs_lookup.c:219
#10 0x8041dc4f in vn_open_cred (ndp=0xa2d939f0,
flagp=0xa2d9393c, cmode=0, cred=0xff0001588600,
fp=0xff0001964200) at ../../../kern/vfs_vnops.c:188
#11 0x8041ccc7 in kern_open (td=0xff0019109a50,
path=0xac30 , pathseg=Variable
"pathseg" is not available.
)
at ../../../kern/vfs_syscalls.c:1032
#12 0x80544660 in ia32_syscall (frame=0xa2d93c80)
at ../../../amd64/ia32/ia32_syscall.c:182
#13 0x805014d0 in Xint0x80_syscall () at ia32_exception.S:65
#14 0x28284037 in ?? ()
(kgdb) frame 4
#4 0x80392ea6 in _mtx_lock_flags (m=0x8083c220, opts=0,
file=0x805bd438 "../../../kern/vfs_cache.c", line=327)
at ../../../kern/kern_mutex.c:186
186 _get_sleep_lock(m, curthread, opts, file, line);
(kgdb) list
181 ("mtx_lock() of spin mutex %s @ %s:%d",
m->lock_object.lo_name,
182 file, line));
183 WITNESS_CHECKORDER(&m->lock_object, opts | LOP_NEWORDER
| LOP_EXCLUSIVE,
184 file, line);
185
186 _get_sleep_lock(m, curthread, opts, file, line);
187 LOCK_LOG_LOCK("LOCK", &m->lock_object, opts,
m->mtx_recurse, file,
188 line);
189 WITNESS_LOCK(&m->lock_object, opts | LOP_EXCLUSIVE,
file, line);
190 curthread->td_locks++;
(kgdb) print *m
$2 = {lock_object = {lo_name = 0x805bd5d2 "Name Cache",
lo_type = 0x805bd5d2 "Name Cache", lo_flags = 16973824,
lo_witness_data = {lod_list = {stqe_next = 0x807cd600},
lod_witness = 0x807cd600}}, mtx_lock = 4, mtx_recurse = 0}
Is this from a coredump or while the system is live? mtx_lock = 4 indicates
the mutex is unlocked, so there shouldn't be any threads waiting on it.
That was from running kgdb on a vmcore file. Would the state of the
mutex be different than if I was running kgdb on a live kernel?
Well, if it was live perhaps the thread wasn't hung but was changing states
while you were watching it. However, that is not true in a coredump. This is
a very disturbing bug as it means something is broken in the mutex
implementation
itself. Have you reproduced this on multiple machines?
The trace above is from a Supermicro X6DHR-8G motherboard with dual
3.6GHz Nocona Xeons running the amd64 architecture w/ SCHED_ULE.
Here is a similar situation on a completely different machine running
the same process load -- Supermicro P4DPR-8G2 with dual 2.4GHz Xeons --
running the i386 architecture w/ SCHED_ULE. Process 23092 has exclusive
sx "user map" and is waiting on mutex "vm page queue mutex"; a bunch of
other processes are stuck on allproc becaus
Re: [releng_7 tinderbox] failure on sparc64/sparc64
On Thursday 26 February 2009 1:54:49 pm FreeBSD Tinderbox wrote: > [...] > :> hack.c > cc -shared -nostdlib hack.c -o hack.So > rm -f hack.c > MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc > -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > -include opt_global.h -fno-common -finline-limit=15000 --param > inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin > -mcmodel=medany -msoft-float -ffreestanding -Werror vers.c > linking kernel > vm_map.o(.text+0x3324): In function `vm_map_find': > : undefined reference to `pmap_align_superpage' > *** Error code 1 Gah, sorry for the breakage. I have found the relevant change in HEAD to MFC and am trying to merge it, but am having some issues with NFS at the moment that are making it take a while. The two SVN changes I've found so far that are relevant are 175397 and 178893. -- John Baldwin ___ 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"
RE: qemu+aio vs C2
> I see something unusual and surprising for me: if I kldload aio for > qemu's sake > and then actually start qemu, I see that share of C2 in cx_usage is > constantly > dropping and then finally there is "too many short sleeps, backing off > to C1". > > This is on i386 with stable/7 as of r188116. I've been running qemu w/ stable-7 with no problems. Could you paste the actual error messages as well as a full DMESG? # uname -a FreeBSD kkutzko 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Fri Oct 10 13:10:49 EDT 2008 server.local:/usr/obj/usr/src/sys/KK i386 # --- Kevin Systems Administrator http://www.stardothosting.com/linux-vps-hosting http://wiki.stardothosting.com ___ 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"
[releng_7 tinderbox] failure on sparc64/sparc64
TB --- 2009-02-26 17:42:23 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-02-26 17:42:23 - starting RELENG_7 tinderbox run for sparc64/sparc64 TB --- 2009-02-26 17:42:23 - cleaning the object tree TB --- 2009-02-26 17:42:41 - cvsupping the source tree TB --- 2009-02-26 17:42:41 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/sparc64/sparc64/supfile TB --- 2009-02-26 17:42:51 - building world TB --- 2009-02-26 17:42:51 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-26 17:42:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-26 17:42:51 - TARGET=sparc64 TB --- 2009-02-26 17:42:51 - TARGET_ARCH=sparc64 TB --- 2009-02-26 17:42:51 - TZ=UTC TB --- 2009-02-26 17:42:51 - __MAKE_CONF=/dev/null TB --- 2009-02-26 17:42:51 - cd /src TB --- 2009-02-26 17:42:51 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 26 17:42:53 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Feb 26 18:42:22 UTC 2009 TB --- 2009-02-26 18:42:22 - generating LINT kernel config TB --- 2009-02-26 18:42:22 - cd /src/sys/sparc64/conf TB --- 2009-02-26 18:42:22 - /usr/bin/make -B LINT TB --- 2009-02-26 18:42:23 - building LINT kernel TB --- 2009-02-26 18:42:23 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-26 18:42:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-26 18:42:23 - TARGET=sparc64 TB --- 2009-02-26 18:42:23 - TARGET_ARCH=sparc64 TB --- 2009-02-26 18:42:23 - TZ=UTC TB --- 2009-02-26 18:42:23 - __MAKE_CONF=/dev/null TB --- 2009-02-26 18:42:23 - cd /src TB --- 2009-02-26 18:42:23 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 26 18:42:23 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror vers.c linking kernel vm_map.o(.text+0x3324): In function `vm_map_find': : undefined reference to `pmap_align_superpage' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-02-26 18:54:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-02-26 18:54:48 - ERROR: failed to build lint kernel TB --- 2009-02-26 18:54:48 - 3800.23 user 368.36 system 4345.76 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-sparc64-sparc64.full ___ 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"
Re: ural driver stalls under FreeBSD7.1
Weongyo Jeong writes: > On Thu, Feb 26, 2009 at 01:20:36PM +0900, Nathan Butcher wrote: >> I have a Buffalo WLI-U2-KG54-AI wireless USB adaptor. >> It has been malfunctioning for quite a while under FreeBSD7.0 and 7.1 >> >> Typically, It works for a while until eventually it stalls data >> transfers completely. It always seems to do this after an unspecified >> amount of time. >> >> I know the hardware isn't at fault because the device works fine under >> Linux. > > Could you please check that `ifconfig -bgscan' disabling the > background scan helps your symptom? The above sounds like the same problem as this: http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011376.html http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html The problem is in the background scanning logic in sys/net80211. Bengt ___ 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"
[releng_7 tinderbox] failure on powerpc/powerpc
TB --- 2009-02-26 16:35:32 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-02-26 16:35:32 - starting RELENG_7 tinderbox run for powerpc/powerpc TB --- 2009-02-26 16:35:32 - cleaning the object tree TB --- 2009-02-26 16:35:56 - cvsupping the source tree TB --- 2009-02-26 16:35:56 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/powerpc/powerpc/supfile TB --- 2009-02-26 16:36:05 - building world TB --- 2009-02-26 16:36:05 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-26 16:36:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-26 16:36:05 - TARGET=powerpc TB --- 2009-02-26 16:36:05 - TARGET_ARCH=powerpc TB --- 2009-02-26 16:36:05 - TZ=UTC TB --- 2009-02-26 16:36:05 - __MAKE_CONF=/dev/null TB --- 2009-02-26 16:36:05 - cd /src TB --- 2009-02-26 16:36:05 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 26 16:36:06 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Feb 26 17:42:38 UTC 2009 TB --- 2009-02-26 17:42:38 - generating LINT kernel config TB --- 2009-02-26 17:42:38 - cd /src/sys/powerpc/conf TB --- 2009-02-26 17:42:38 - /usr/bin/make -B LINT TB --- 2009-02-26 17:42:38 - building LINT kernel TB --- 2009-02-26 17:42:38 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-26 17:42:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-26 17:42:38 - TARGET=powerpc TB --- 2009-02-26 17:42:38 - TARGET_ARCH=powerpc TB --- 2009-02-26 17:42:38 - TZ=UTC TB --- 2009-02-26 17:42:38 - __MAKE_CONF=/dev/null TB --- 2009-02-26 17:42:38 - cd /src TB --- 2009-02-26 17:42:38 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 26 17:42:38 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror vers.c linking kernel vm_map.o(.text+0x3938): In function `vm_map_find': : undefined reference to `pmap_align_superpage' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-02-26 17:55:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-02-26 17:55:04 - ERROR: failed to build lint kernel TB --- 2009-02-26 17:55:04 - 3990.27 user 374.40 system 4771.90 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-powerpc-powerpc.full ___ 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"
powerd causing crash on Mini-ITX EN1200
Hi, When I enable powerd, it is only but a matter of time before my machine will lock up completely. I've had this problem since I've migrated to FreeBSD 7 from 6. FreeBSD 6 never seemed to have any problems. I doesn't seem to create a dump so I've had no luck on that end. I'm quite perplexed on how to proceed to help get this problem documented so it can be fixed. #uname -a FreeBSD rosbox.dyndns.org 7.1-STABLE FreeBSD 7.1-STABLE #0: Thu Feb 26 00:38:44 PST 2009 r...@rosbox.dyndns.org:/usr/obj/usr/src/sys/MYKERNEL7 i386 Is there anything else I con provide that would be of assistance? Thank you, Ross Penner ___ 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"
Re: qemu+aio vs C2
on 26/02/2009 18:27 Paul B. Mahol said the following: > On 2/26/09, Andriy Gapon wrote: >> I see something unusual and surprising for me: if I kldload aio for qemu's >> sake >> and then actually start qemu, I see that share of C2 in cx_usage is >> constantly >> dropping and then finally there is "too many short sleeps, backing off to >> C1". >> >> This is on i386 with stable/7 as of r188116. >> >> I am out of ideas. > > And qemu guest is? > > Perhaps you should try changing guest kern.hz sysctl setting. > I dont think related comitt got MFC-ed to STABLE. > For what I've been doing the guest was our boot code and loader. Nothing beyond that. And, pardon me, how guest software could affect host's hardware in this way? As i understand only a hardware even of some sort could interrupt C2. -- Andriy Gapon ___ 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"
Re: qemu+aio vs C2
On 2/26/09, Andriy Gapon wrote: > > I see something unusual and surprising for me: if I kldload aio for qemu's > sake > and then actually start qemu, I see that share of C2 in cx_usage is > constantly > dropping and then finally there is "too many short sleeps, backing off to > C1". > > This is on i386 with stable/7 as of r188116. > > I am out of ideas. And qemu guest is? Perhaps you should try changing guest kern.hz sysctl setting. I dont think related comitt got MFC-ed to STABLE. -- Paul ___ 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"
qemu+aio vs C2
I see something unusual and surprising for me: if I kldload aio for qemu's sake and then actually start qemu, I see that share of C2 in cx_usage is constantly dropping and then finally there is "too many short sleeps, backing off to C1". This is on i386 with stable/7 as of r188116. I am out of ideas. -- Andriy Gapon ___ 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"
Re: 7.1 hangs in cache_lookup mutex?
On Wednesday 25 February 2009 10:02:16 am Guy Helmer wrote:
> John Baldwin wrote:
> > On Tuesday 24 February 2009 4:46:28 pm Guy Helmer wrote:
> >
> >> I think I may have found a clue regarding some of the hangs I'm seeing
> >> on FreeBSD 7.1.
> >> I have a program (kvoop), compiled under FreeBSD 6 and using
> >> compatibility libraries under FreeBSD 7, that seems to be consistently
> >> involved during these hangs. This time, I noticed that many processes
> >> are stopped, waiting on the ufs lock. I can't tell for certain, but I
> >> assume this kvoop process 33203 is blocking the other processes. The
> >> kvoop process looks to me like it is waiting for a mutex, but nothing
> >> shows up being deadlocked. Am I on the right track? Is there something
> >> else I should be looking for?
> >>
> >> (kgdb) proc 33203
> >> [Switching to thread 129 (Thread 100241)]#0 sched_switch (
> >> td=0xff0019109a50, newtd=0x0, flags=1)
> >> at ../../../kern/sched_ule.c:1944
> >> 1944cpuid = PCPU_GET(cpuid);
> >> (kgdb) where
> >> #0 sched_switch (td=0xff0019109a50, newtd=0x0, flags=1)
> >> at ../../../kern/sched_ule.c:1944
> >> #1 0x803a573b in mi_switch (flags=1, newtd=0x0)
> >> at ../../../kern/kern_synch.c:440
> >> #2 0x803d1214 in turnstile_wait (ts=Variable "ts" is not
> >> available.
> >> )
> >> at ../../../kern/subr_turnstile.c:748
> >> #3 0x80392db0 in _mtx_lock_sleep (m=0x8083c220,
> >> tid=18446742974618442320, opts=Variable "opts" is not available.
> >> ) at ../../../kern/kern_mutex.c:420
> >> #4 0x80392ea6 in _mtx_lock_flags (m=0x8083c220, opts=0,
> >> file=0x805bd438 "../../../kern/vfs_cache.c", line=327)
> >> at ../../../kern/kern_mutex.c:186
> >> #5 0x80403bc6 in cache_lookup (dvp=0xff00013e0dc8,
> >> vpp=0xa2d93a18, cnp=0xa2d93a40)
> >> at ../../../kern/vfs_cache.c:327
> >> #6 0x80404093 in vfs_cache_lookup (ap=Variable "ap" is not
> >> available.
> >> )
> >> at ../../../kern/vfs_cache.c:674
> >> #7 0x805628a0 in VOP_LOOKUP_APV (vop=0x8076e440,
> >> a=0xa2d936b0) at vnode_if.c:99
> >> #8 0x80409afd in lookup (ndp=0xa2d939f0) at vnode_if.h:57
> >> #9 0x8040a824 in namei (ndp=0xa2d939f0)
> >> at ../../../kern/vfs_lookup.c:219
> >> #10 0x8041dc4f in vn_open_cred (ndp=0xa2d939f0,
> >> flagp=0xa2d9393c, cmode=0, cred=0xff0001588600,
> >> fp=0xff0001964200) at ../../../kern/vfs_vnops.c:188
> >> #11 0x8041ccc7 in kern_open (td=0xff0019109a50,
> >> path=0xac30 , pathseg=Variable
> >> "pathseg" is not available.
> >> )
> >> at ../../../kern/vfs_syscalls.c:1032
> >> #12 0x80544660 in ia32_syscall (frame=0xa2d93c80)
> >> at ../../../amd64/ia32/ia32_syscall.c:182
> >> #13 0x805014d0 in Xint0x80_syscall () at ia32_exception.S:65
> >> #14 0x28284037 in ?? ()
> >>
> >> (kgdb) frame 4
> >> #4 0x80392ea6 in _mtx_lock_flags (m=0x8083c220, opts=0,
> >> file=0x805bd438 "../../../kern/vfs_cache.c", line=327)
> >> at ../../../kern/kern_mutex.c:186
> >> 186 _get_sleep_lock(m, curthread, opts, file, line);
> >> (kgdb) list
> >> 181 ("mtx_lock() of spin mutex %s @ %s:%d",
> >> m->lock_object.lo_name,
> >> 182 file, line));
> >> 183 WITNESS_CHECKORDER(&m->lock_object, opts | LOP_NEWORDER
> >> | LOP_EXCLUSIVE,
> >> 184 file, line);
> >> 185
> >> 186 _get_sleep_lock(m, curthread, opts, file, line);
> >> 187 LOCK_LOG_LOCK("LOCK", &m->lock_object, opts,
> >> m->mtx_recurse, file,
> >> 188 line);
> >> 189 WITNESS_LOCK(&m->lock_object, opts | LOP_EXCLUSIVE,
> >> file, line);
> >> 190 curthread->td_locks++;
> >>
> >> (kgdb) print *m
> >> $2 = {lock_object = {lo_name = 0x805bd5d2 "Name Cache",
> >> lo_type = 0x805bd5d2 "Name Cache", lo_flags = 16973824,
> >> lo_witness_data = {lod_list = {stqe_next = 0x807cd600},
> >> lod_witness = 0x807cd600}}, mtx_lock = 4, mtx_recurse = 0}
> >>
> >
> > Is this from a coredump or while the system is live? mtx_lock = 4
> > indicates
> > the mutex is unlocked, so there shouldn't be any threads waiting on it.
> >
> >
> That was from running kgdb on a vmcore file. Would the state of the
> mutex be different than if I was running kgdb on a live kernel?
Well, if it was live perhaps the thread wasn't hung but was changing states
while you were watching it. However, that is not true in a coredump. This is
a very disturbing bug as it means something is broken in the mutex
implementation
itself. Have you reproduced this on multiple machines?
--
John Baldwin
___
freebsd-stable@freebsd.org
Re: What startup script is supposed to handle ipv6_defaultrouter="..."?
Hi, * Trond Endrestøl [090226 13:19]: > Sorry about the noise. > Maybe I wasn't too patient, but I will swear that netstat -rnf inet6 > showed no default route even when it was supposed to. And yes, I did > reboot the system to verify my settings. > Again, my bad. I have the problem sometimes that the system tries to get IPv6 router advertisments before the interface is up. In this case it doesn't retry, at least not within the time frame I was patient enough to wait. In this case I usually call rtsol by hand to get the parameters. Wolfgang ___ 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"
Re: What startup script is supposed to handle ipv6_defaultrouter="..."?
Sorry about the noise. Maybe I wasn't too patient, but I will swear that netstat -rnf inet6 showed no default route even when it was supposed to. And yes, I did reboot the system to verify my settings. Again, my bad. -- -- Trond Endrestøl | trond.endres...@fagskolen.gjovik.no ACM, NAS, NUUG, SAGE, USENIX | FreeBSD 6.2-STABLE & Pine 4.64___ 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"
Re: What startup script is supposed to handle ipv6_defaultrouter="..."?
On Thu, 26 Feb 2009 09:42+0100, Trond Endrestøl wrote: > On a system running 7.1-STABLE as of early February, cvsup'd with > tag=RELENG_7 just prior to recompiling the system, setting > ipv6_defaultrouter="..." in /etc/rc.conf seems to have no effect. > I'm forced to set the IPv6 gateway using commands outside the regular > startup scripts. For the record, here are the IPv6 related variables found in this particular system's /etc/rc.conf file: ipv6_enable="YES" ipv6_defaultrouter="2001:700::::1" ipv6_ifconfig_em0="2001:700::::24 prefixlen 64" If I leave out the static address assignment on em0 and the static router address, the system gets both an autoconfigurated IPv6 address as well as receiving the router's link local IPv6 address and the system will use that LL address as the default router. I'm merely interested in giving em0 a static IPv6 address, and if possible leave everything else to be determined by the router's advertisement. Do I need to fiddle with one or more sysctl variables? -- -- Trond Endrestøl | trond.endres...@fagskolen.gjovik.no ACM, NAS, NUUG, SAGE, USENIX | FreeBSD 6.2-STABLE & Pine 4.64___ 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"
Re: What startup script is supposed to handle ipv6_defaultrouter="..."?
On Thu, 26 Feb 2009, Trond Endrestøl wrote: On a system running 7.1-STABLE as of early February, cvsup'd with tag=RELENG_7 just prior to recompiling the system, setting ipv6_defaultrouter="..." in /etc/rc.conf seems to have no effect. I'm forced to set the IPv6 gateway using commands outside the regular startup scripts. The command grep ipv6_defaultrouter /etc/rc.d/* doesn't give anything useful, either. I guess /etc/rc.d/network_ipv6 is missing the required code. I guess it's in /etc/network.subr Did you se ipv6_enable="YES" in rc.conf as well? /bz -- Bjoern A. Zeeb The greatest risk is not taking one.___ 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"
What startup script is supposed to handle ipv6_defaultrouter="..."?
On a system running 7.1-STABLE as of early February, cvsup'd with tag=RELENG_7 just prior to recompiling the system, setting ipv6_defaultrouter="..." in /etc/rc.conf seems to have no effect. I'm forced to set the IPv6 gateway using commands outside the regular startup scripts. The command grep ipv6_defaultrouter /etc/rc.d/* doesn't give anything useful, either. I guess /etc/rc.d/network_ipv6 is missing the required code. Here's the revision string from my /etc/rc.d/network_ipv6: # $FreeBSD: src/etc/rc.d/network_ipv6,v 1.37 2004/10/07 13:55:26 mtm Exp $ Is this the correct revision number for tag=RELENG_7? -- -- Trond Endrestøl | trond.endres...@fagskolen.gjovik.no ACM, NAS, NUUG, SAGE, USENIX | FreeBSD 6.2-STABLE & Pine 4.64___ 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"
