Re: BSDInstall: merging to HEAD
On Jan 14, 2011, at 19:31 , Marcel Moolenaar wrote: > On Jan 14, 2011, at 10:26 AM, Nathan Whitehorn wrote: > >> The final architecture on which we use sysinstall, ia64, is currently >> unsupported, because I don't know how to set up booting on those systems -- >> patches to solve this are very much welcome. > > Don't let this stop you. I'll work with you on this after the dust > has settled. Just out of random curiosity. Seriously. Exactly why, short of "of course it runs", in which case NetBSD is --> way, why are we even trying to handle ia64 as a platform, regardless of tier, when it is patently obvious that it is going absolutely _nowhere_ in terms of a viable platform? I ask the question in all seriousness. Ports/Packages, well, a decent amount of them won't work on anything less than (i386|amd64) but that's nothing new. But even spending time building them for, what, the <200 (I'm being generous) folks that run FreeBSD/ia64. We _have_ a 64-bit platform. It's /amd. The fact that even as we speak, random chip manufacturers are banging out new P4/Xeon processors conforming to this standard, years after they had a vague chance to steal the server market, indicates that this line is dead. _dead_. DEAD. At least I can pick up a box for <$50 from ebay and run /sparc64 on it. Say the same for /ia64? Didn't think so. Nuke it. From orbit. With extreme prejudice. -aDe ___ 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: Profiling code execution on amd64?
On Fri, Jan 14, 2011 at 10:10 PM, Steve Kargl wrote: > On Fri, Jan 14, 2011 at 03:40:46PM -0500, George Neville-Neil wrote: >> >> On Jan 13, 2011, at 23:05 , Steve Kargl wrote: >> >> > On Thu, Jan 13, 2011 at 10:08:30PM -0500, Ryan Stone wrote: >> >> I would suggest using hwpmc for profiling: >> >> >> >> # kldload hwpmc >> >> # pmcstat -S unhalted-cycles -O /tmp/samples.out ../penetration >> >> # pmcstat -R /tmp/samples.out -G /tmp/penetration.txt >> >> >> >> >> >> You can also get pmcstat to generate gprof-compatible output with -g, >> >> but I never use the mode so I'm really not sure what it gives you. I >> >> think that you have to run gprof on the output or something, but don't >> >> hold me to that. >> > >> > >> > Thanks. I'll give it a try, but my initial attempt seems to >> > indicate that one needs to be root to use hwpmc. >> > >> > laptop:kargl[210] pmcstat -S unhalted-cycles -O /tmp/samples.out >> > ../penetration >> > pmcstat: ERROR: Cannot allocate system-mode pmc with specification >> > "unhalted-cycles": Operation not permitted >> > >> >> You only need to be root to profile the kernel or someone else's process. >> >> This tutorial might help: >> >> www.dcbsdcon.org/speakers/slides/neville-neil_dcbsdcon2009.pdf >> > > Thanks. I'll look at the tutorial. Meanwhile, should gprof > be removed from the base system because it appears broken? Instead of just removing things, why not determine why things are broken and try to fix them? -Garrett ___ 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: Profiling code execution on amd64?
On Fri, Jan 14, 2011 at 03:40:46PM -0500, George Neville-Neil wrote: > > On Jan 13, 2011, at 23:05 , Steve Kargl wrote: > > > On Thu, Jan 13, 2011 at 10:08:30PM -0500, Ryan Stone wrote: > >> I would suggest using hwpmc for profiling: > >> > >> # kldload hwpmc > >> # pmcstat -S unhalted-cycles -O /tmp/samples.out ../penetration > >> # pmcstat -R /tmp/samples.out -G /tmp/penetration.txt > >> > >> > >> You can also get pmcstat to generate gprof-compatible output with -g, > >> but I never use the mode so I'm really not sure what it gives you. I > >> think that you have to run gprof on the output or something, but don't > >> hold me to that. > > > > > > Thanks. I'll give it a try, but my initial attempt seems to > > indicate that one needs to be root to use hwpmc. > > > > laptop:kargl[210] pmcstat -S unhalted-cycles -O /tmp/samples.out > > ../penetration > > pmcstat: ERROR: Cannot allocate system-mode pmc with specification > > "unhalted-cycles": Operation not permitted > > > > You only need to be root to profile the kernel or someone else's process. > > This tutorial might help: > > www.dcbsdcon.org/speakers/slides/neville-neil_dcbsdcon2009.pdf > Thanks. I'll look at the tutorial. Meanwhile, should gprof be removed from the base system because it appears broken? -- Steve ___ 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"
[head tinderbox] failure on amd64/amd64
TB --- 2011-01-15 01:10:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-01-15 01:10:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-01-15 01:10:00 - cleaning the object tree TB --- 2011-01-15 01:10:26 - cvsupping the source tree TB --- 2011-01-15 01:10:26 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-01-15 01:10:38 - building world TB --- 2011-01-15 01:10:38 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-15 01:10:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-15 01:10:38 - TARGET=amd64 TB --- 2011-01-15 01:10:38 - TARGET_ARCH=amd64 TB --- 2011-01-15 01:10:38 - TZ=UTC TB --- 2011-01-15 01:10:38 - __MAKE_CONF=/dev/null TB --- 2011-01-15 01:10:38 - cd /src TB --- 2011-01-15 01:10:38 - /usr/bin/make -B buildworld >>> World build started on Sat Jan 15 01:10:42 UTC 2011 >>> 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Jan 15 03:19:32 UTC 2011 TB --- 2011-01-15 03:19:32 - generating LINT kernel config TB --- 2011-01-15 03:19:32 - cd /src/sys/amd64/conf TB --- 2011-01-15 03:19:32 - /usr/bin/make -B LINT TB --- 2011-01-15 03:19:32 - building LINT kernel TB --- 2011-01-15 03:19:32 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-15 03:19:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-15 03:19:32 - TARGET=amd64 TB --- 2011-01-15 03:19:32 - TARGET_ARCH=amd64 TB --- 2011-01-15 03:19:32 - TZ=UTC TB --- 2011-01-15 03:19:32 - __MAKE_CONF=/dev/null TB --- 2011-01-15 03:19:32 - cd /src TB --- 2011-01-15 03:19:32 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jan 15 03:19:32 UTC 2011 >>> 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 -frename-registers -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=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue vers.c linking kernel nfs_nfsdkrpc.o(.text+0x49): In function `nfsrvd_init': : undefined reference to `nfsd_master_proc' *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-01-15 03:33:57 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-01-15 03:33:57 - ERROR: failed to build lint kernel TB --- 2011-01-15 03:33:57 - 6889.09 user 1193.27 system 8636.39 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full ___ 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"
[head tinderbox] failure on i386/i386
TB --- 2011-01-15 01:10:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-01-15 01:10:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-01-15 01:10:00 - cleaning the object tree TB --- 2011-01-15 01:10:26 - cvsupping the source tree TB --- 2011-01-15 01:10:26 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-01-15 01:15:51 - building world TB --- 2011-01-15 01:15:51 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-15 01:15:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-15 01:15:51 - TARGET=i386 TB --- 2011-01-15 01:15:51 - TARGET_ARCH=i386 TB --- 2011-01-15 01:15:51 - TZ=UTC TB --- 2011-01-15 01:15:51 - __MAKE_CONF=/dev/null TB --- 2011-01-15 01:15:51 - cd /src TB --- 2011-01-15 01:15:51 - /usr/bin/make -B buildworld >>> World build started on Sat Jan 15 01:15:51 UTC 2011 >>> 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 Sat Jan 15 02:57:29 UTC 2011 TB --- 2011-01-15 02:57:29 - generating LINT kernel config TB --- 2011-01-15 02:57:29 - cd /src/sys/i386/conf TB --- 2011-01-15 02:57:29 - /usr/bin/make -B LINT TB --- 2011-01-15 02:57:30 - building LINT kernel TB --- 2011-01-15 02:57:30 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-15 02:57:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-15 02:57:30 - TARGET=i386 TB --- 2011-01-15 02:57:30 - TARGET_ARCH=i386 TB --- 2011-01-15 02:57:30 - TZ=UTC TB --- 2011-01-15 02:57:30 - __MAKE_CONF=/dev/null TB --- 2011-01-15 02:57:30 - cd /src TB --- 2011-01-15 02:57:30 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jan 15 02:57:30 UTC 2011 >>> 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=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue vers.c linking kernel nfs_nfsdkrpc.o(.text+0x38): In function `nfsrvd_init': : undefined reference to `nfsd_master_proc' *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-01-15 03:12:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-01-15 03:12:38 - ERROR: failed to build lint kernel TB --- 2011-01-15 03:12:38 - 5674.47 user 913.55 system 7357.42 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full ___ 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"
[head tinderbox] failure on i386/pc98
TB --- 2011-01-15 01:10:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-01-15 01:10:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-01-15 01:10:00 - cleaning the object tree TB --- 2011-01-15 01:10:22 - cvsupping the source tree TB --- 2011-01-15 01:10:22 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-01-15 01:10:37 - building world TB --- 2011-01-15 01:10:37 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-15 01:10:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-15 01:10:37 - TARGET=pc98 TB --- 2011-01-15 01:10:37 - TARGET_ARCH=i386 TB --- 2011-01-15 01:10:37 - TZ=UTC TB --- 2011-01-15 01:10:37 - __MAKE_CONF=/dev/null TB --- 2011-01-15 01:10:37 - cd /src TB --- 2011-01-15 01:10:37 - /usr/bin/make -B buildworld >>> World build started on Sat Jan 15 01:10:38 UTC 2011 >>> 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 Sat Jan 15 02:51:28 UTC 2011 TB --- 2011-01-15 02:51:28 - generating LINT kernel config TB --- 2011-01-15 02:51:28 - cd /src/sys/pc98/conf TB --- 2011-01-15 02:51:28 - /usr/bin/make -B LINT TB --- 2011-01-15 02:51:28 - building LINT kernel TB --- 2011-01-15 02:51:28 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-15 02:51:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-15 02:51:28 - TARGET=pc98 TB --- 2011-01-15 02:51:28 - TARGET_ARCH=i386 TB --- 2011-01-15 02:51:28 - TZ=UTC TB --- 2011-01-15 02:51:28 - __MAKE_CONF=/dev/null TB --- 2011-01-15 02:51:28 - cd /src TB --- 2011-01-15 02:51:28 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jan 15 02:51:28 UTC 2011 >>> 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=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue vers.c linking kernel nfs_nfsdkrpc.o(.text+0x38): In function `nfsrvd_init': : undefined reference to `nfsd_master_proc' *** Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-01-15 03:04:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-01-15 03:04:32 - ERROR: failed to build lint kernel TB --- 2011-01-15 03:04:32 - 5538.61 user 924.33 system 6871.55 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full ___ 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: BSDInstall: merging to HEAD
On Jan 14, 2011, at 10:26 AM, Nathan Whitehorn wrote: > The final architecture on which we use sysinstall, ia64, is currently > unsupported, because I don't know how to set up booting on those systems -- > patches to solve this are very much welcome. Don't let this stop you. I'll work with you on this after the dust has settled. FYI, -- Marcel Moolenaar xcl...@mac.com ___ 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: unknown mtx_assert at /usr/src/sys/x86/x86/io_apic.c:161
John: Thanks, I actually didn¹t see the MCA errors on the screen as the system has reloaded but noted them in the ddb.txt file last night. The Motherboard, CPU, Memory and PS were replaced today. I¹ll post back if this has or not corrected the problem but I suspect you are on target in that the hardware was defective. This machine was remote and I found the fan in the power supply not working, so I¹m suspecting that the CPU was or other logic was damaged. Thanks for your reply. --mikej On 1/14/11 4:13 PM, "John Baldwin" wrote: > On Thursday, January 13, 2011 11:26:46 am Michael Jung wrote: >> > Links to crash info below. >> > http://216.26.153.6/msgbuf.txt > > This might be a hardware problem. The panic you got is a "should never > happen" panic. Note that in the code line sourced, the second argument to > mtx_assert() is MA_OWNED. The panic is saying that it is some invalid value > (i.e. something other than MA_OWNED). Given that is a constant, that's not > very likely at all barring some hardware glitch. > > You do have a somewhat scary looking machine check logged before your panic: > > MCA: Bank 1, Status 0xd171 > MCA: Global Cap 0x0105, Status 0x > MCA: Vendor "AuthenticAMD", ID 0x20fc2, APIC ID 0 > MCA: CPU 0 COR OVER ICACHE L1 EVICT error > > It is a correctable error, but given the nature of the panic I'd suspect a > hardware problem. > > mcelog doesn't provide many more details: > > HARDWARE ERROR. This is *NOT* a software problem! > Please contact your hardware vendor > CPU 0 1 instruction cache >bit62 = error overflow (multiple errors) > memory/cache error 'evict mem transaction, instruction transaction, level 1' > STATUS d171 MCGSTATUS 0 > MCGCAP 105 APICID 0 SOCKETID 0 > CPUID Vendor AMD Family 15 Model 44 > > -- > John Baldwin > CONFIDENTIALITY NOTE: This message is intended only for the use of the individual or entity to whom it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, please notify us by telephone at (502) 212-4001 or notify us at PAI , Dept. 99, 11857 Commonwealth Drive, Louisville, KY 40299. Thank you. ___ 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: Profiling code execution on amd64?
On Jan 13, 2011, at 23:05 , Steve Kargl wrote: > On Thu, Jan 13, 2011 at 10:08:30PM -0500, Ryan Stone wrote: >> I would suggest using hwpmc for profiling: >> >> # kldload hwpmc >> # pmcstat -S unhalted-cycles -O /tmp/samples.out ../penetration >> # pmcstat -R /tmp/samples.out -G /tmp/penetration.txt >> >> >> You can also get pmcstat to generate gprof-compatible output with -g, >> but I never use the mode so I'm really not sure what it gives you. I >> think that you have to run gprof on the output or something, but don't >> hold me to that. > > > Thanks. I'll give it a try, but my initial attempt seems to > indicate that one needs to be root to use hwpmc. > > laptop:kargl[210] pmcstat -S unhalted-cycles -O /tmp/samples.out > ../penetration > pmcstat: ERROR: Cannot allocate system-mode pmc with specification > "unhalted-cycles": Operation not permitted > You only need to be root to profile the kernel or someone else's process. This tutorial might help: www.dcbsdcon.org/speakers/slides/neville-neil_dcbsdcon2009.pdf Best, George ___ 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: unknown mtx_assert at /usr/src/sys/x86/x86/io_apic.c:161
On Thursday, January 13, 2011 11:26:46 am Michael Jung wrote: > Links to crash info below. > http://216.26.153.6/msgbuf.txt This might be a hardware problem. The panic you got is a "should never happen" panic. Note that in the code line sourced, the second argument to mtx_assert() is MA_OWNED. The panic is saying that it is some invalid value (i.e. something other than MA_OWNED). Given that is a constant, that's not very likely at all barring some hardware glitch. You do have a somewhat scary looking machine check logged before your panic: MCA: Bank 1, Status 0xd171 MCA: Global Cap 0x0105, Status 0x MCA: Vendor "AuthenticAMD", ID 0x20fc2, APIC ID 0 MCA: CPU 0 COR OVER ICACHE L1 EVICT error It is a correctable error, but given the nature of the panic I'd suspect a hardware problem. mcelog doesn't provide many more details: HARDWARE ERROR. This is *NOT* a software problem! Please contact your hardware vendor CPU 0 1 instruction cache bit62 = error overflow (multiple errors) memory/cache error 'evict mem transaction, instruction transaction, level 1' STATUS d171 MCGSTATUS 0 MCGCAP 105 APICID 0 SOCKETID 0 CPUID Vendor AMD Family 15 Model 44 -- John Baldwin ___ 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: Endless CAM messages with recent CURRENT
Marcus, Can you have a look at this? --HPS On Friday 14 January 2011 16:21:00 Rainer Hurling wrote: > After looking around I had been able to localise the cause for the > described messages, see below: > > On 14.01.2011 10:07 (UTC+1), Rainer Hurling wrote: > > Today I updated my 9.0-CURRENT system (amd64) to revision 199506: After > > rebooting I get the following messages two times per second in an > > endless run: > > > > > > - > > ... > > Jan 14 09:37:47 krabat kernel: (sg1:umass-sim0:0:0:0): > > cam_periph_release_locked: release 0xfe0009f41200 when refcount is > > zero Jan 14 09:37:47 krabat kernel: > > Jan 14 09:37:48 krabat kernel: (sg2:umass-sim0:0:0:1): > > cam_periph_release_locked: release 0xfe0009f41100 when refcount is > > zero Jan 14 09:37:48 krabat kernel: > > ... > > - > > When turning off hald no more of these messages appear. hald is trying > to poll the card reader, but it does not like this. So prohibiting the > polling in /usr/local/share/hal/fdi/preprobe/20thirdparty/ solves my > problem: > > #cat 10-broken-usb-card-reader.fdi > > > > > > > > > > int="0x0716"> > type="bool">false > > > > > > > > > sg1 and sg2 are devices from my front panel card reader Silverstone > > SST-FP35B: > > > > #camcontrol devlist > > [..snip..] > > at scbus6 target 0 lun 0 (sg1,pass3,da0) > > at scbus6 target 0 lun 1 (sg2,pass4,da1) > > > > > > Is it possible that the last changes in usb code (xhci) or in cam code > > are responsible for this? Does anyone else observe this behaviour? > > A more generic approach would be to integrate the polling info into > /usr/local/share/hal/fdi/preprobe/10osvendor/20-broken-usb-sticks.fdi. > Is anyone willing to integrate the code (.fdi file or some quirks) in > the usb stuff? > > > In that case Linux is offering some more info about this device: > > #lssub > Bus 002 Device 002: ID05e3:0716 Genesys Logic, Inc. USB2.0 Multislot > Card Reader/Writer > idVendor 0x05e3 Genesys Logic, Inc. > > #usb-devices > T: Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 > D: Ver=2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 > P: Vendor=05e3 ProdID=0176 Rev=97.44 > S: Product=USB Storage > S: SerialNumber=9744 > C: #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA > I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage > > > Note, that the card reader from Benesys Logic is only one device of some > more (firewire, eSATA, USB slots ...), which are provided from the > 'Silverstone SST-FP35B' front panel access unit. > > > Please let me know if you need more info or if I can test something. > > Thanks in advance, > Rainer Hurling > ___ > 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" ___ 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: HEADSUP: Realtime thread scheduling changed
2011/1/14 John Baldwin : > Note that as a result of these > changes, rtprio threads will no longer share priorities with interactive > timeshare threads. Instead, rtprio threads are now always more important than > non-rt threads. Great! I was thinking about the split of timesharing threads and realtime threads for years, and now you've actually implemented that! Alexander Churanov ___ 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"
BSDInstall: merging to HEAD
As those of you who have been reading freebsd-sysinstall and freebsd-arch know, I have been working for a few weeks on a lightweight new installer named 'bsdinstall'. This is designed to replace sysinstall for the 9.0 release. After two weeks of testing and bug fixes on the sysinstall list, I believe this now has all required functionality and is ready to be merged into the main source tree. I would like to do this on Tuesday, 18 January. Switching this to be the default installer would happen a few weeks after that, pending discussion on release formats with the release engineering team. This should provide a sufficient testing period before 9.0 and allow a maximal number of bugs to be discovered and solved before the release is shipped. Demo ISO for i386: http://people.freebsd.org/~nwhitehorn/bsdinstall-i386-20110114.iso.bz2 SVN repository: svn://svn.freebsd.org/base/user/nwhitehorn/bsdinstall Wiki page: http://wiki.freebsd.org/BSDInstall Goals - The primary goal of BSDInstall is to provide an easily extensible installer without the limitations of sysinstall, in order to allow more modern installations of FreeBSD. This means that it should have additional features to support modern setups, but simultaneously frees us to remove complicating features of sysinstall like making sure everything fits in floppy disk-sized chunks. New Features: - Allows installation onto GPT disks on x86 systems - Can do installations spanning multiple disks - Allows installation into jails - Eases PXE installation - Virtualization friendly: can install from a live system onto disk images - Works on PowerPC - Streamlined system installation - More flexible scripting - Easily tweakable - All install CDs are live CDs Architecture BSDInstall is a set of tools that are called in sequence by a master script. These tools are, for example, the partition editor, the thing that fetches the distributions from the network, the thing that untars them, etc. Since these are just called in sequence from a shell script, a scripted installation can easily replace them with other things, (e.g. hard-coded gpart commands), leave steps out, add new ones, or interleave additional system modifications. Status -- This provides functionality most similar to the existing sysinstall 'Express' track. It installs working, bootable systems you can ssh into immediately after reboot on i386, amd64, sparc64, powerpc, and powerpc64. There is untested support for pc98. The final architecture on which we use sysinstall, ia64, is currently unsupported, because I don't know how to set up booting on those systems -- patches to solve this are very much welcome. There are still some missing features that I would like to see in the release, but these do not significantly impact the functionality of the installer. Some will be addressed before merging to HEAD, in particular the lack of a man page for bsdinstall. Others, like configuration of wireless networking and ZFS installation, can happen between merge and release. The test ISOs are also lacking a ports tree at the moment, which is a statement about the slow upload speed of my DSL line and not about the final layout of releases. Please send any questions, comments, or patches you may have, and please be aware when replying that this email has been cross-posted to three lists. Technical discussion (bug reports, for instance) should be directed to the freebsd-sysinstall list only. Most other discussion belongs on -sysinstall and -current. -Nathan ___ 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: HEADSUP: Realtime thread scheduling changed
On Friday, January 14, 2011 12:22:18 pm Daniel Eischen wrote: > On Fri, 14 Jan 2011, John Baldwin wrote: > > > This is just a heads up that I've committed some changes to how the > > scheduler > > handles realtime thread priorities. Please let me know of any issues you > > encounter with nice, rtprio, or idprio. Note that as a result of these > > changes, rtprio threads will no longer share priorities with interactive > > timeshare threads. Instead, rtprio threads are now always more important > > than > > non-rt threads. > > Cool - thanks for doing this! Is this something that could > be MFC'able to 8? That's a harder question. This changes the effective value of the P* priority constants passed to *sleep(). That would be an ABI change for kernel modules. We could either 1) decide that it is an ABI change worth making (probably doubtful since it is mostly a new feature rather than a major bug fix) or 2) maybe MFC it but make the different priority ranges be subject to some global kernel config option. 2) isn't super ideal since you have to really make sure kernel modules are compiled with the same setting for that option to avoid weird behavior. I will MFC all the other changes I've made prior to this in which case this change would be the only local patch someone would need to have this. -- John Baldwin ___ 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: HEADSUP: Realtime thread scheduling changed
On Fri, 14 Jan 2011, John Baldwin wrote: This is just a heads up that I've committed some changes to how the scheduler handles realtime thread priorities. Please let me know of any issues you encounter with nice, rtprio, or idprio. Note that as a result of these changes, rtprio threads will no longer share priorities with interactive timeshare threads. Instead, rtprio threads are now always more important than non-rt threads. Cool - thanks for doing this! Is this something that could be MFC'able to 8? -- DE ___ 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"
HEADSUP: Realtime thread scheduling changed
This is just a heads up that I've committed some changes to how the scheduler
handles realtime thread priorities. Please let me know of any issues you
encounter with nice, rtprio, or idprio. Note that as a result of these
changes, rtprio threads will no longer share priorities with interactive
timeshare threads. Instead, rtprio threads are now always more important than
non-rt threads.
--
John Baldwin
--- Begin Message ---
Author: jhb
Date: Fri Jan 14 17:06:54 2011
New Revision: 217410
URL: http://svn.freebsd.org/changeset/base/217410
Log:
Rework realtime priority support:
- Move the realtime priority range up above kernel sleep priorities and
just below interrupt thread priorities.
- Contract the interrupt and kernel sleep priority ranges a bit so that
the timesharing priority band can be increased. The new timeshare range
is now slightly larger than the old realtime + timeshare ranges.
- Change the ULE scheduler to no longer use realtime priorities for
interactive threads. Instead, the larger timeshare range is now split
into separate subranges for interactive and non-interactive ("batch")
threads. The end result is that interactive threads and non-interactive
threads still use the same priority ranges as before, but realtime
threads now have a separate, dedicated priority range.
- Do not modify the priority of non-timeshare threads in sched_sleep()
or via cv_broadcastpri(). Realtime and idle priority threads will
no longer have their priorities affected by sleeping in the kernel.
Reviewed by: jeff
Modified:
head/sys/kern/sched_4bsd.c
head/sys/kern/sched_ule.c
head/sys/kern/subr_sleepqueue.c
head/sys/sys/priority.h
Modified: head/sys/kern/sched_4bsd.c
==
--- head/sys/kern/sched_4bsd.c Fri Jan 14 16:42:13 2011(r217409)
+++ head/sys/kern/sched_4bsd.c Fri Jan 14 17:06:54 2011(r217410)
@@ -908,7 +908,7 @@ sched_sleep(struct thread *td, int pri)
THREAD_LOCK_ASSERT(td, MA_OWNED);
td->td_slptick = ticks;
td->td_sched->ts_slptime = 0;
- if (pri)
+ if (pri != 0 && PRI_BASE(td->td_pri_class) == PRI_TIMESHARE)
sched_prio(td, pri);
if (TD_IS_SUSPENDED(td) || pri >= PSOCK)
td->td_flags |= TDF_CANSWAP;
Modified: head/sys/kern/sched_ule.c
==
--- head/sys/kern/sched_ule.c Fri Jan 14 16:42:13 2011(r217409)
+++ head/sys/kern/sched_ule.c Fri Jan 14 17:06:54 2011(r217410)
@@ -118,11 +118,17 @@ static struct td_sched td_sched0;
/*
* Priority ranges used for interactive and non-interactive timeshare
- * threads. Interactive threads use realtime priorities.
- */
-#definePRI_MIN_INTERACTPRI_MIN_REALTIME
-#definePRI_MAX_INTERACTPRI_MAX_REALTIME
-#definePRI_MIN_BATCH PRI_MIN_TIMESHARE
+ * threads. The timeshare priorities are split up into four ranges.
+ * The first range handles interactive threads. The last three ranges
+ * (NHALF, x, and NHALF) handle non-interactive threads with the outer
+ * ranges supporting nice values.
+ */
+#definePRI_TIMESHARE_RANGE (PRI_MAX_TIMESHARE - PRI_MIN_TIMESHARE
+ 1)
+#definePRI_INTERACT_RANGE ((PRI_TIMESHARE_RANGE -
SCHED_PRI_NRESV) / 2)
+
+#definePRI_MIN_INTERACTPRI_MIN_TIMESHARE
+#definePRI_MAX_INTERACT(PRI_MIN_TIMESHARE + PRI_INTERACT_RANGE
- 1)
+#definePRI_MIN_BATCH (PRI_MIN_TIMESHARE + PRI_INTERACT_RANGE)
#definePRI_MAX_BATCH PRI_MAX_TIMESHARE
/*
@@ -1893,6 +1899,8 @@ sched_sleep(struct thread *td, int prio)
td->td_slptick = ticks;
if (TD_IS_SUSPENDED(td) || prio >= PSOCK)
td->td_flags |= TDF_CANSWAP;
+ if (PRI_BASE(td->td_pri_class) != PRI_TIMESHARE)
+ return;
if (static_boost == 1 && prio)
sched_prio(td, prio);
else if (static_boost && td->td_priority > static_boost)
Modified: head/sys/kern/subr_sleepqueue.c
==
--- head/sys/kern/subr_sleepqueue.c Fri Jan 14 16:42:13 2011
(r217409)
+++ head/sys/kern/subr_sleepqueue.c Fri Jan 14 17:06:54 2011
(r217410)
@@ -745,7 +745,8 @@ sleepq_resume_thread(struct sleepqueue *
/* Adjust priority if requested. */
MPASS(pri == 0 || (pri >= PRI_MIN && pri <= PRI_MAX));
- if (pri != 0 && td->td_priority > pri)
+ if (pri != 0 && td->td_priority > pri &&
+ PRI_BASE(td->td_pri_class) == PRI_TIMESHARE)
sched_prio(td, pri);
/*
Modified: head/sys/sys/priority.h
==
--- head/sys/sys/priority.h Fri Jan 14 16:42:13 2011(r217409)
+++ head
Re: Endless CAM messages with recent CURRENT
After looking around I had been able to localise the cause for the described messages, see below: On 14.01.2011 10:07 (UTC+1), Rainer Hurling wrote: Today I updated my 9.0-CURRENT system (amd64) to revision 199506: After rebooting I get the following messages two times per second in an endless run: - ... Jan 14 09:37:47 krabat kernel: (sg1:umass-sim0:0:0:0): cam_periph_release_locked: release 0xfe0009f41200 when refcount is zero Jan 14 09:37:47 krabat kernel: Jan 14 09:37:48 krabat kernel: (sg2:umass-sim0:0:0:1): cam_periph_release_locked: release 0xfe0009f41100 when refcount is zero Jan 14 09:37:48 krabat kernel: ... - When turning off hald no more of these messages appear. hald is trying to poll the card reader, but it does not like this. So prohibiting the polling in /usr/local/share/hal/fdi/preprobe/20thirdparty/ solves my problem: #cat 10-broken-usb-card-reader.fdi int="0x0716"> type="bool">false sg1 and sg2 are devices from my front panel card reader Silverstone SST-FP35B: #camcontrol devlist [..snip..] at scbus6 target 0 lun 0 (sg1,pass3,da0) at scbus6 target 0 lun 1 (sg2,pass4,da1) Is it possible that the last changes in usb code (xhci) or in cam code are responsible for this? Does anyone else observe this behaviour? A more generic approach would be to integrate the polling info into /usr/local/share/hal/fdi/preprobe/10osvendor/20-broken-usb-sticks.fdi. Is anyone willing to integrate the code (.fdi file or some quirks) in the usb stuff? In that case Linux is offering some more info about this device: #lssub Bus 002 Device 002: ID05e3:0716 Genesys Logic, Inc. USB2.0 Multislot Card Reader/Writer idVendor 0x05e3 Genesys Logic, Inc. #usb-devices T: Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver=2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=05e3 ProdID=0176 Rev=97.44 S: Product=USB Storage S: SerialNumber=9744 C: #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage Note, that the card reader from Benesys Logic is only one device of some more (firewire, eSATA, USB slots ...), which are provided from the 'Silverstone SST-FP35B' front panel access unit. Please let me know if you need more info or if I can test something. Thanks in advance, Rainer Hurling ___ 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"
Endless CAM messages with recent CURRENT
Today I updated my 9.0-CURRENT system (amd64) to revision 199506: After rebooting I get the following messages two times per second in an endless run: - ... Jan 14 09:37:47 krabat kernel: (sg1:umass-sim0:0:0:0): cam_periph_release_locked: release 0xfe0009f41200 when refcount is zero Jan 14 09:37:47 krabat kernel: Jan 14 09:37:48 krabat kernel: (sg2:umass-sim0:0:0:1): cam_periph_release_locked: release 0xfe0009f41100 when refcount is zero Jan 14 09:37:48 krabat kernel: ... - sg1 and sg2 are devices from my front panel card reader Silverstone SST-FP35B: #camcontrol devlist [..snip..] at scbus6 target 0 lun 0 (sg1,pass3,da0) at scbus6 target 0 lun 1 (sg2,pass4,da1) Is it possible that the last changes in usb code (xhci) or in cam code are responsible for this? Does anyone else observe this behaviour? Please let me know if you need more info or if I can test something. Thank you for any hint, Rainer Hurling ___ 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"
