Re: RFC: New event timers infrastructure
Brandon Gooch wrote: > On Sun, Jun 20, 2010 at 3:35 PM, Doug Barton wrote: >> On 06/20/10 08:47, Alexander Motin wrote: >>> While this can be done in sysctl.conf, it would be better to do it in >>> loader.conf to make it applied from the beginning, without on-the-fly >>> timers change. >> You're probably right that for something this fundamental it's better to do >> it in loader.conf, however I wanted to mention that I recently changed the >> rcorder for the "early" boot scripts to run sysctl first for very similar >> reasons. > > This is good information, so sorry if I'm being dense: does this mean > that it should have worked by applying the changes via > /etc/sysctl.conf? "You are too old. You are already born." (c) Sergey Lukyanenko. stathz set much earlier, just before "Starting kernel event timers" logged first time. It can only be affected from loader.conf. > No worries though, I've set it in /boot/loader.conf to avoid any > possible ambiguity or anomalous behavior, and it's working very well! Nice. BTW, I've successfully tested suspend/resume on my amd64 laptop with all timers. -- Alexander Motin ___ 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 powerpc/powerpc
TB --- 2010-06-21 04:21:31 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-06-21 04:21:31 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2010-06-21 04:21:31 - cleaning the object tree TB --- 2010-06-21 04:21:37 - cvsupping the source tree TB --- 2010-06-21 04:21:37 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2010-06-21 04:22:06 - building world TB --- 2010-06-21 04:22:06 - MAKEOBJDIRPREFIX=/obj TB --- 2010-06-21 04:22:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-06-21 04:22:06 - TARGET=powerpc TB --- 2010-06-21 04:22:06 - TARGET_ARCH=powerpc TB --- 2010-06-21 04:22:06 - TZ=UTC TB --- 2010-06-21 04:22:06 - __MAKE_CONF=/dev/null TB --- 2010-06-21 04:22:06 - cd /src TB --- 2010-06-21 04:22:06 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 21 04:22:06 UTC 2010 >>> 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 [...] cc -O2 -pipe -I/obj/powerpc/src/cddl/lib/libdtrace -I/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libdtrace/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libctf/common -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/intel -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknown-pragmas -c dt_grammar.c cc -O2 -pipe -I/obj/powerpc/src/cddl/lib/libdtrace -I/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libdtrace/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libctf/common -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/intel -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_handle.c cc -O2 -pipe -I/obj/powerpc/src/cddl/lib/libdtrace -I/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libdtrace/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libctf/common -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/intel -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_ident.c cc -O2 -pipe -I/obj/powerpc/src/cddl/lib/libdtrace -I/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libdtrace/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libctf/common -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/intel -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_inttab.c cc -O2 -pipe -I/obj/powerpc/src/cddl/lib/libdtrace -I/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libdtrace/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libctf/common -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/intel -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknown-pragmas -c dt_lex.c cc1: warnings being treated as errors /src/cddl/lib/
Re: [CFT] SIFTR - Statistical Information For TCP Research: Uncle Lawrence needs YOU!
On 06/21/10 05:44, Rui Paulo wrote: On 20 Jun 2010, at 20:36, Fabian Keil wrote: Fabian Keil wrote: Fabian Keil wrote: My custom kernel normally doesn't have INVARIANTS and WITNESS enabled, so I'll try to enable them next. The culprit seem to be non-default KTR settings in the kernel while loading alq as a module. Actually whether or not alq is loaded as a module doesn't seem to matter, with: options KTR options KTR_ENTRIES=262144 options KTR_COMPILE=(KTR_SCHED) options KTR_MASK=(KTR_SCHED) options KTR_CPUMASK=0x3 options ALQ options KTR_ALQ enabling siftr panics the system, too. That's probably because your module was built with different compile time options than the ones used in the kernel. These options may change structure sizes, function parameters, etc. and that easily causes panics. hmm I wonder if my instructions to build SIFTR manually are causing your problems. Fabian, is the siftr.ko module you're loading built as part of a "make buildkernel", or did you follow my instructions and "cd /sys/modules/siftr ; make ; kldload ./siftr.ko"? If the latter is true, perhaps try and explicitly build SIFTR as part of "make buildkernel" and see if loading the module built that way still triggers the panic when enabled (the module will be in /usr/obj//sys//modules//sys/modules/siftr/siftr.ko or if you "make installkernel" it'll be in /boot/kernel/kernel/siftr.ko). Cheers, Lawrence ___ 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 arm/arm
TB --- 2010-06-21 01:50:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-06-21 01:50:00 - starting HEAD tinderbox run for arm/arm TB --- 2010-06-21 01:50:00 - cleaning the object tree TB --- 2010-06-21 01:50:07 - cvsupping the source tree TB --- 2010-06-21 01:50:07 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2010-06-21 01:50:30 - building world TB --- 2010-06-21 01:50:30 - MAKEOBJDIRPREFIX=/obj TB --- 2010-06-21 01:50:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-06-21 01:50:30 - TARGET=arm TB --- 2010-06-21 01:50:30 - TARGET_ARCH=arm TB --- 2010-06-21 01:50:30 - TZ=UTC TB --- 2010-06-21 01:50:30 - __MAKE_CONF=/dev/null TB --- 2010-06-21 01:50:30 - cd /src TB --- 2010-06-21 01:50:30 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 21 01:50:39 UTC 2010 >>> 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 [...] cc -O -pipe -I/obj/arm/src/cddl/lib/libdtrace -I/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libdtrace/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libctf/common -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/intel -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknown-pragmas -c dt_grammar.c cc -O -pipe -I/obj/arm/src/cddl/lib/libdtrace -I/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libdtrace/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libctf/common -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/intel -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_handle.c cc -O -pipe -I/obj/arm/src/cddl/lib/libdtrace -I/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libdtrace/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libctf/common -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/intel -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_ident.c cc -O -pipe -I/obj/arm/src/cddl/lib/libdtrace -I/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libdtrace/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libctf/common -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/intel -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_inttab.c cc -O -pipe -I/obj/arm/src/cddl/lib/libdtrace -I/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libdtrace/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libctf/common -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/intel -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknown-pragmas -c dt_lex.c cc1: warnings being treated as errors /src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_lex.l: In function 'yylex': /src/cddl/lib/libdtrace/../../../cddl/cont
Re: [CFT] SIFTR - Statistical Information For TCP Research: Uncle Lawrence needs YOU!
On 06/21/10 00:12, Fabian Keil wrote: Fabian Keil wrote: Lawrence Stewart wrote: On 06/20/10 22:28, Fabian Keil wrote: Taking pf (and altq) out of the picture doesn't seem to make a difference. Wouldn't have expected it to. Will be very curious to know if the panic is triggered in GENERIC. It's not. I, too, get pfil.c related LORs though: lock order reversal: 1st 0x80e5c568 PFil hook read/write mutex (PFil hook read/write mutex) @ /usr/src/sys/net/pfil.c:77 2nd 0x80e5dd68 udp (udp) @ /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:3035 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _rw_rlock() at _rw_rlock+0x5f pf_socket_lookup() at pf_socket_lookup+0x1c5 pf_test_udp() at pf_test_udp+0x8b0 pf_test() at pf_test+0x1089 pf_check_in() at pf_check_in+0x39 pfil_run_hooks() at pfil_run_hooks+0xcf ip_input() at ip_input+0x2ae swi_net() at swi_net+0x151 intr_event_execute_handlers() at intr_event_execute_handlers+0x66 ithread_loop() at ithread_loop+0xb2 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff844d30, rbp = 0 --- lock order reversal: 1st 0x80e5c568 PFil hook read/write mutex (PFil hook read/write mutex) @ /usr/src/sys/net/pfil.c:77 2nd 0x80e5d788 tcp (tcp) @ /usr/src/sys/modules/siftr/../../netinet/siftr.c:698 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _rw_rlock() at _rw_rlock+0x5f siftr_chkpkt() at siftr_chkpkt+0x3c4 pfil_run_hooks() at pfil_run_hooks+0xcf ip_input() at ip_input+0x2ae swi_net() at swi_net+0x151 intr_event_execute_handlers() at intr_event_execute_handlers+0x66 ithread_loop() at ithread_loop+0xb2 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff844d30, rbp = 0 --- My custom kernel normally doesn't have INVARIANTS and WITNESS enabled, so I'll try to enable them next. The culprit seem to be non-default KTR settings in the kernel while loading alq as a module. With the following change siftr works with my non-GENERIC kernel, too: commit f43b8b5171c858df7b419f6a695e9e3b53531a8e Author: Fabian Keil Date: Sun Jun 20 15:43:01 2010 +0200 Disable KTR changes. diff --git a/sys/amd64/conf/ZOEY b/sys/amd64/conf/ZOEY index 6fb3480..c584317 100644 --- a/sys/amd64/conf/ZOEY +++ b/sys/amd64/conf/ZOEY @@ -16,11 +16,11 @@ options ATA_CAM device atapicam options SC_KERNEL_CONS_ATTR=(FG_GREEN|BG_BLACK) -options KTR -options KTR_ENTRIES=262144 -options KTR_COMPILE=(KTR_SCHED) -options KTR_MASK=(KTR_SCHED) -options KTR_CPUMASK=0x3 +#options KTR +#options KTR_ENTRIES=262144 +#options KTR_COMPILE=(KTR_SCHED) +#options KTR_MASK=(KTR_SCHED) +#options KTR_CPUMASK=0x3 options ACCEPT_FILTER_HTTP makeoptions WITH_CTF=yes This smells very fishy. Without "options KTR_ALQ", KTR shouldn't even care if ALQ exists or not. Not only that, but ALQ isn't even used in siftr_chkpkt and you clearly manage to successfully use ALQ to write the module load message to the log file. H... Thanks for taking the time to find the culprit though - I'll see if I can reproduce here. Could you try another thing for me and see if reducing "options KTR_ENTRIES=262144" down to a smaller number (maybe 4096?) and leaving all the other KTR options as they are above (but uncommented) makes any difference? The ktr(4) man page indicates the default is 8192 entries and I'm curious if the your allocation of so many additional entries is making something unhappy. Thanks again for your time helping with this, I really appreciate it. Cheers, Lawrence ___ 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: RFC: New event timers infrastructure
On Sun, Jun 20, 2010 at 3:35 PM, Doug Barton wrote: > On 06/20/10 08:47, Alexander Motin wrote: >> >> While this can be done in sysctl.conf, it would be better to do it in >> loader.conf to make it applied from the beginning, without on-the-fly >> timers change. > > You're probably right that for something this fundamental it's better to do > it in loader.conf, however I wanted to mention that I recently changed the > rcorder for the "early" boot scripts to run sysctl first for very similar > reasons. This is good information, so sorry if I'm being dense: does this mean that it should have worked by applying the changes via /etc/sysctl.conf? No worries though, I've set it in /boot/loader.conf to avoid any possible ambiguity or anomalous behavior, and it's working very well! Alexander, if I haven't said it enough already, thanks! I see that you committed this work, looking forward to wider-spread testing now... -Brandon ___ 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"
[RFC] Changes in stat structures
Hello, I would like to integrate my Google Summer of Code project from the last year [1]. In brief, it was about converting netstat(1) into a library and providing a relatively clean API to access various networking statistics available in the kernel. The project is far from being complete, and it needs review but I decided to split my large patch into smaller pieces and add the results continuously to the FreeBSD src/ repository, otherwise it might vanish. I do not have a src/ commit bit, thus I am also looking for a sponsor for my changes who approves or commits them. My plan of integration is simple: apply the necessary modifications to the kernel, add the sysctl export routines and data structures, add the library (called libnetstat(3)), then adapt and add applications (netstat(1), bsnmpd(1), nettop(1), etc.) to use it. This way I could get some review and continue the development of this library in an interactive style. The first piece of this set is available on my FreeBSD homepage as a separate patch [2], which technically proposes to a "standardization" for the counter values so they could be accessed from both 32-bit and 64-bit environments without problems (via kvm(3) or sysctl(3)). However, I do not know too much about the potential consequences or how such a change should be handled in the tree. For more information (and the complete patch), see the project's wiki page [3]. Any feedback is appreciated. Nothing is carved into stone, I am very open to comments :) Thank you! Cheers, :g [1] http://wiki.freebsd.org/PGJSoC2009 [2] http://people.freebsd.org/~pgj/libnetstat/libnetstat-sys.latest.diff [3] http://wiki.freebsd.org/LibNetstat ___ 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: Dell Perc 5/i Performance issues
On Mon, Jun 21, 2010 at 4:50 AM, Scott Long wrote: > I just set up a machine with the following GPT scheme: > > => 34 5853511613 mfid0 GPT (2.7T) > 34 128 1 freebsd-boot (64K) > 162 862 - free - (431K) > 1024 2097152 2 freebsd-ufs (1.0G) > 2098176 4194304 3 freebsd-swap (2.0G) > 6292480 2097152 4 freebsd-ufs (1.0G) > 8389632 104857600 5 freebsd-ufs (50G) > 113247232 5740264414 6 freebsd-ufs (2.7T) > 5853511646 1 - free - (512B) > > After the first partition, I created a deliberate gap for alignment, > reflected in the second line. The third line shows a starting offset of > sector 1024, which is 512KB. This should be a good generic start point for > most RAID geometries with a stripe size <= 512KB. The rest are normal /, > swap, /var, /usr and /opt partitions. The single free sector on the final > line is probably a calculation error on my part, there's no particular reason > for it. > > The gpart man page has good descriptions on how to create partitions and make > the GPT scheme bootable. It's not very automated, you'll need to have a > calculator handy, but it works. I scripted this as part of our custom installer - it uses the same 1MB offset that Vista/Win7 do which should align for anything with a <= 1MB stripe size: # Device to partition diskdev="/dev/da0" # First partition offset in 512-byte sectors. This should be aligned with # any RAID stripe size for maximum performance. 2048 aligns the partition # start boundary at the 1MiB, consistent with Vista/Windows 7. This should # match all common stripe sizes such as 64kb, 128kb and 256kb. root_offset="2048" # Boot partition offset. This sits just before our first root partition and # stores the boot loader which is used to load the OS. boot_offset="2032" # Initialise the disk with a GPT partition table gpart create -s gpt $diskdev # # System disk partitioning layout # gpart add -l boot -t freebsd-boot -s 16 -b $boot_offset $diskdev # boot p1 gpart add -l root -t freebsd-ufs -s 2G -b $root_offset $diskdev # /p2 gpart add -l swap -t freebsd-swap -s 4G $diskdev # swap p3 gpart add -l var -t freebsd-ufs -s 4G $diskdev # /var p4 gpart add -l usr -t freebsd-ufs$diskdev # /usr p5 # Install the gpt boot code (pmbr into the PMBR, gptboot into our boot partition p1) gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 $diskdev # Make the first partition active # (required for older BIOSes to boot from the GPT PMBR) echo 'a 1' | fdisk -f - $diskdev gpart is smart enough to figure out most of the math for you these days... -- Antony ___ 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: Bug in debug.ncores sysctl code
On Sun, Jun 20, 2010 at 08:38:37PM +0100, Bruce Cran wrote:
> I noticed on my i386 router running 9-CURRENT that the "debug.ncores" sysctl
> appears to get its value from some kernel memory that gets updated frequently:
>
> debug.ncores: -936629388
>
> On line 2967 of sys/kern/kern_sig.c should the value of num_cores instead of
> ncores be getting returned?
"ncores" at the line 2967 is only the name of mib. The following patch
should fix it.
diff --git a/sys/kern/kern_sig.c b/sys/kern/kern_sig.c
index d52cedb..63fe81e 100644
--- a/sys/kern/kern_sig.c
+++ b/sys/kern/kern_sig.c
@@ -2953,7 +2953,8 @@ sysctl_debug_num_cores_check (SYSCTL_HANDLER_ARGS)
{
int error;
int new_val;
-
+
+ new_val = num_cores;
error = sysctl_handle_int(oidp, &new_val, 0, req);
if (error != 0 || req->newptr == NULL)
return (error);
pgpnSQb6emWB8.pgp
Description: PGP signature
Re: [CFT] SIFTR - Statistical Information For TCP Research: Uncle Lawrence needs YOU!
On 20 Jun 2010, at 20:36, Fabian Keil wrote: > Fabian Keil wrote: > >> Fabian Keil wrote: > >>> My custom kernel normally doesn't have INVARIANTS and WITNESS >>> enabled, so I'll try to enable them next. >> >> The culprit seem to be non-default KTR settings in the kernel >> while loading alq as a module. > > Actually whether or not alq is loaded as a module doesn't > seem to matter, with: > > options KTR > options KTR_ENTRIES=262144 > options KTR_COMPILE=(KTR_SCHED) > options KTR_MASK=(KTR_SCHED) > options KTR_CPUMASK=0x3 > options ALQ > options KTR_ALQ > > enabling siftr panics the system, too. That's probably because your module was built with different compile time options than the ones used in the kernel. These options may change structure sizes, function parameters, etc. and that easily causes panics. Regards, -- Rui Paulo ___ 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: RFC: New event timers infrastructure
On 06/20/10 08:47, Alexander Motin wrote: While this can be done in sysctl.conf, it would be better to do it in loader.conf to make it applied from the beginning, without on-the-fly timers change. You're probably right that for something this fundamental it's better to do it in loader.conf, however I wanted to mention that I recently changed the rcorder for the "early" boot scripts to run sysctl first for very similar reasons. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.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"
Bug in debug.ncores sysctl code
I noticed on my i386 router running 9-CURRENT that the "debug.ncores" sysctl appears to get its value from some kernel memory that gets updated frequently: debug.ncores: -936629388 On line 2967 of sys/kern/kern_sig.c should the value of num_cores instead of ncores be getting returned? -- Bruce Cran ___ 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: [CFT] SIFTR - Statistical Information For TCP Research: Uncle Lawrence needs YOU!
Fabian Keil wrote: > Fabian Keil wrote: > > My custom kernel normally doesn't have INVARIANTS and WITNESS > > enabled, so I'll try to enable them next. > > The culprit seem to be non-default KTR settings in the kernel > while loading alq as a module. Actually whether or not alq is loaded as a module doesn't seem to matter, with: options KTR options KTR_ENTRIES=262144 options KTR_COMPILE=(KTR_SCHED) options KTR_MASK=(KTR_SCHED) options KTR_CPUMASK=0x3 options ALQ options KTR_ALQ enabling siftr panics the system, too. Fabian signature.asc Description: PGP signature
Re: Dell Perc 5/i Performance issues
Yeah, there's no value in using the /dev/random devices for testing disk i/o. Use /dev/zero instead. I've known of hardware RAID engines in the past that can recognize certain repeating i/o benchmark patterns and optimize for them, but I have no idea if LSI controllers do this, tho based on your results it's probably safe to say that they don't. Scott On Jun 20, 2010, at 1:09 PM, Artem Belevich wrote: > /dev/random and /dev/urandom are relatively slow and are not suitable > as the source of data for testing modern hard drives' sequential > throughput. > > On my 3GHz dual-core amd63 box both /dev/random and /dev/urandom max > out at ~80MB/s while consuming 100% CPU time on one of the processor > cores. > That would not be enough to saturate single disk with sequential writes. > > --Artem > > > > On Sun, Jun 20, 2010 at 9:51 AM, oizs wrote: >> I've tried almost everything now. >> The battery is probably fine: >> mfiutil show battery >> mfi0: Battery State: >> Manufacture Date: 7/25/2009 >>Serial Number: 3716 >> Manufacturer: SMP-PA1.9 >>Model: DLFR463 >>Chemistry: LION >> Design Capacity: 1800 mAh >> Design Voltage: 3700 mV >> Current Charge: 99% >> >> My results: >> Settings: >> Raid5: >> Stripe: 64k >> mfiutil cache 0 >> mfi0 volume mfid0 cache settings: >> I/O caching: writes >>write caching: write-back >> read ahead: none >> drive write cache: default >> Raid0: >> Stripe: 64k >> mfiutil cache 0 >> mfi0 volume mfid0 cache settings: >> I/O caching: writes >>write caching: write-back >> read ahead: none >> drive write cache: default >> >> Tried to play around with this as well, with almost no difference. >> >> Raid5 >> read: >> dd if=/dev/mfid0 of=/dev/null bs=10M >> 1143+0 records in >> 1143+0 records out >> 11985223680 bytes transferred in 139.104134 secs (86160083 bytes/sec) >> write: >> dd if=/dev/random of=/dev/mfid0 bs=64K >> 22747+0 records in >> 22747+0 records out >> 1490747392 bytes transferred in 23.921103 secs (62319342 bytes/sec) >> >> Raid0 >> read: >> dd if=/dev/mfid0 of=/dev/null bs=64K >> 92470+0 records in >> 92470+0 records out >> 6060113920 bytes transferred in 47.926007 secs (126447294 bytes/sec) >> write: >> dd if=/dev/random of=/dev/mfid0 bs=64K >> 16441+0 records in >> 16441+0 records out >> 1077477376 bytes transferred in 17.232486 secs (62525939 bytes/sec) >> >> I'm writing directly to the device so im not sure any slice issues could >> cause the problems. >> >> -zsozso >> On 2010.06.20. 4:53, Scott Long wrote: >>> >>> Two big things can affect RAID-5 performance: >>> >>> 1. Battery backup. If you don't have a working battery attached to the >>> card, it will turn off the write-back cache, no matter what you do. Check >>> this. If you're unsure, use the mfiutil tool that I added to FreeBSD a few >>> months ago and send me the output. >>> >>> 2. Partition alignment. If you're using classic MBR slices, everything >>> gets misaligned by 63 sectors, making it impossible for the controller to >>> optimize both reads and writes. If the array is used for secondary storage, >>> simply don't use an MBR scheme. If it's used for primary storage, try using >>> GPT instead and setting up your partitions so that they are aligned to large >>> power-of-2 boundaries. >>> >>> Scott >>> >>> On Jun 18, 2010, at 6:27 PM, oizs wrote >>> >> >> ___ >> 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" ___ 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: Dell Perc 5/i Performance issues
/dev/random and /dev/urandom are relatively slow and are not suitable as the source of data for testing modern hard drives' sequential throughput. On my 3GHz dual-core amd63 box both /dev/random and /dev/urandom max out at ~80MB/s while consuming 100% CPU time on one of the processor cores. That would not be enough to saturate single disk with sequential writes. --Artem On Sun, Jun 20, 2010 at 9:51 AM, oizs wrote: > I've tried almost everything now. > The battery is probably fine: > mfiutil show battery > mfi0: Battery State: > Manufacture Date: 7/25/2009 > Serial Number: 3716 > Manufacturer: SMP-PA1.9 > Model: DLFR463 > Chemistry: LION > Design Capacity: 1800 mAh > Design Voltage: 3700 mV > Current Charge: 99% > > My results: > Settings: > Raid5: > Stripe: 64k > mfiutil cache 0 > mfi0 volume mfid0 cache settings: > I/O caching: writes > write caching: write-back > read ahead: none > drive write cache: default > Raid0: > Stripe: 64k > mfiutil cache 0 > mfi0 volume mfid0 cache settings: > I/O caching: writes > write caching: write-back > read ahead: none > drive write cache: default > > Tried to play around with this as well, with almost no difference. > > Raid5 > read: > dd if=/dev/mfid0 of=/dev/null bs=10M > 1143+0 records in > 1143+0 records out > 11985223680 bytes transferred in 139.104134 secs (86160083 bytes/sec) > write: > dd if=/dev/random of=/dev/mfid0 bs=64K > 22747+0 records in > 22747+0 records out > 1490747392 bytes transferred in 23.921103 secs (62319342 bytes/sec) > > Raid0 > read: > dd if=/dev/mfid0 of=/dev/null bs=64K > 92470+0 records in > 92470+0 records out > 6060113920 bytes transferred in 47.926007 secs (126447294 bytes/sec) > write: > dd if=/dev/random of=/dev/mfid0 bs=64K > 16441+0 records in > 16441+0 records out > 1077477376 bytes transferred in 17.232486 secs (62525939 bytes/sec) > > I'm writing directly to the device so im not sure any slice issues could > cause the problems. > > -zsozso > On 2010.06.20. 4:53, Scott Long wrote: >> >> Two big things can affect RAID-5 performance: >> >> 1. Battery backup. If you don't have a working battery attached to the >> card, it will turn off the write-back cache, no matter what you do. Check >> this. If you're unsure, use the mfiutil tool that I added to FreeBSD a few >> months ago and send me the output. >> >> 2. Partition alignment. If you're using classic MBR slices, everything >> gets misaligned by 63 sectors, making it impossible for the controller to >> optimize both reads and writes. If the array is used for secondary storage, >> simply don't use an MBR scheme. If it's used for primary storage, try using >> GPT instead and setting up your partitions so that they are aligned to large >> power-of-2 boundaries. >> >> Scott >> >> On Jun 18, 2010, at 6:27 PM, oizs wrote >> > > ___ > 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: Dell Perc 5/i Performance issues
I just set up a machine with the following GPT scheme: =>34 5853511613 mfid0 GPT (2.7T) 34 128 1 freebsd-boot (64K) 162 862 - free - (431K) 1024 2097152 2 freebsd-ufs (1.0G) 2098176 4194304 3 freebsd-swap (2.0G) 6292480 2097152 4 freebsd-ufs (1.0G) 8389632 104857600 5 freebsd-ufs (50G) 113247232 5740264414 6 freebsd-ufs (2.7T) 5853511646 1 - free - (512B) After the first partition, I created a deliberate gap for alignment, reflected in the second line. The third line shows a starting offset of sector 1024, which is 512KB. This should be a good generic start point for most RAID geometries with a stripe size <= 512KB. The rest are normal /, swap, /var, /usr and /opt partitions. The single free sector on the final line is probably a calculation error on my part, there's no particular reason for it. The gpart man page has good descriptions on how to create partitions and make the GPT scheme bootable. It's not very automated, you'll need to have a calculator handy, but it works. Scott On Jun 20, 2010, at 12:20 PM, Steven Hartland wrote: > Does anyone know of a nice how to guide for achieving this? > > - Original Message - From: "Scott Long" > 2. Partition alignment. If you're using classic MBR slices, everything gets > misaligned by 63 sectors, making it impossible for the controller to optimize > both reads and writes. If the array is used for secondary storage, simply > don't use an MBR scheme. If it's used for primary storage, try using GPT > instead and setting up your partitions so that they are aligned to large > power-of-2 boundaries. > > > > This e.mail is private and confidential between Multiplay (UK) Ltd. and the > person or entity to whom it is addressed. In the event of misdirection, the > recipient is prohibited from using, copying, printing or otherwise > disseminating it or any information contained in it. > In the event of misdirection, illegible or incomplete transmission please > telephone +44 845 868 1337 > or return the E.mail to postmas...@multiplay.co.uk. > ___ 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"
page fault with the following non-sleepable locks held: exclusive sleep mutex ATA state lock
FreeBSD 9.0-CURRENT #1 r209275: Fri Jun 18 08:15:15 CDT 2010 r...@clank.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64 June 17 -CURRENT This panic was seen under VirtualBox on a Windows host. The VM has 2 cores (the host is a Core i7). I this infrequently under a VM. I have yet to see it on real hardware. ... ahcich0: AHCI reset... ahcich0: SATA connect time=0ms status=0123 ahcich0: ready wait time=0ms ahcich0: AHCI reset done: device found (aprobe0:ahcich0:0:0:0): SIGNATURE: ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ahcich1: AHCI reset... Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex ATA state lock (ATA state lock) r = 0 (0xff0002a922c0) locked @ /usr/src/sys/dev/ata/ata-all.c:503 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_warn() at witness_warn+0x2d2 trap() at trap+0x2ee calltrap() at calltrap+0x8 --- trap 0xc, rip = 0x805d8ef1, rsp = 0xff8f6b30, rbp = 0xff8f6b70 --- device_get_softc() at device_get_softc+0x1 ata_interrupt() at ata_interrupt+0x9d intr_event_execute_handlers() at intr_event_execute_handlers+0x66 ithread_loop() at ithread_loop+0xb2 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff8f6d30, rbp = 0 --- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x80 fault code = supervisor read data, page not present instruction pointer = 0x20:0x805d8ef1 stack pointer = 0x28:0xff8f6b30 frame pointer = 0x28:0xff8f6b70 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 12 (irq15: ata1) [ thread pid 12 tid 100025 ] Stopped at device_get_softc+0x1: movq0x80(%rdi),%rax db> ___ 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: Dell Perc 5/i Performance issues
Does anyone know of a nice how to guide for achieving this? - Original Message - From: "Scott Long" 2. Partition alignment. If you're using classic MBR slices, everything gets misaligned by 63 sectors, making it impossible for the controller to optimize both reads and writes. If the array is used for secondary storage, simply don't use an MBR scheme. If it's used for primary storage, try using GPT instead and setting up your partitions so that they are aligned to large power-of-2 boundaries. This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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: Dell Perc 5/i Performance issues
I've tried almost everything now. The battery is probably fine: mfiutil show battery mfi0: Battery State: Manufacture Date: 7/25/2009 Serial Number: 3716 Manufacturer: SMP-PA1.9 Model: DLFR463 Chemistry: LION Design Capacity: 1800 mAh Design Voltage: 3700 mV Current Charge: 99% My results: Settings: Raid5: Stripe: 64k mfiutil cache 0 mfi0 volume mfid0 cache settings: I/O caching: writes write caching: write-back read ahead: none drive write cache: default Raid0: Stripe: 64k mfiutil cache 0 mfi0 volume mfid0 cache settings: I/O caching: writes write caching: write-back read ahead: none drive write cache: default Tried to play around with this as well, with almost no difference. Raid5 read: dd if=/dev/mfid0 of=/dev/null bs=10M 1143+0 records in 1143+0 records out 11985223680 bytes transferred in 139.104134 secs (86160083 bytes/sec) write: dd if=/dev/random of=/dev/mfid0 bs=64K 22747+0 records in 22747+0 records out 1490747392 bytes transferred in 23.921103 secs (62319342 bytes/sec) Raid0 read: dd if=/dev/mfid0 of=/dev/null bs=64K 92470+0 records in 92470+0 records out 6060113920 bytes transferred in 47.926007 secs (126447294 bytes/sec) write: dd if=/dev/random of=/dev/mfid0 bs=64K 16441+0 records in 16441+0 records out 1077477376 bytes transferred in 17.232486 secs (62525939 bytes/sec) I'm writing directly to the device so im not sure any slice issues could cause the problems. -zsozso On 2010.06.20. 4:53, Scott Long wrote: Two big things can affect RAID-5 performance: 1. Battery backup. If you don't have a working battery attached to the card, it will turn off the write-back cache, no matter what you do. Check this. If you're unsure, use the mfiutil tool that I added to FreeBSD a few months ago and send me the output. 2. Partition alignment. If you're using classic MBR slices, everything gets misaligned by 63 sectors, making it impossible for the controller to optimize both reads and writes. If the array is used for secondary storage, simply don't use an MBR scheme. If it's used for primary storage, try using GPT instead and setting up your partitions so that they are aligned to large power-of-2 boundaries. Scott On Jun 18, 2010, at 6:27 PM, oizs wrote ___ 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: Dell Perc 5/i Performance issues
Could you tell me exactly how did you configure your raid? I mean wb/read-ahead/blocksize/stripe etc. Much appreciated. -zsozso On 2010.06.19. 14:26, Svein Skogen (Listmail Account) wrote: On 19.06.2010 11:58, oizs wrote: I tried almost everything raid 0 1 5 10 with all kind of stripes 32/64/128 and settings direct io/cached/read-ahead/wt/wb/disk-cache but nothing seems to work. I changed the card to another dell perc 5 which had an older firmware. Tried 4 kind of motherboards even tried changing the os to linux and windows xp/7. In windows I got some funny results 1.3MB/s with write-back and 150MB/s reads with 5 disks in raid0. I just wanted to have a hw raid with no problems since the motherboard 88sx7042 and bsd did not like eachother. This is from a similar controller running that 8-disk raid5+0 setup: -- CrystalDiskMark 2.2 (C) 2007-2008 hiyohiyo Crystal Dew World : http://crystalmark.info/ -- Sequential Read : 665.383 MB/s Sequential Write : 300.452 MB/s Random Read 512KB : 616.604 MB/s Random Write 512KB : 306.306 MB/s Random Read 4KB : 64.465 MB/s Random Write 4KB :7.646 MB/s Test Size : 100 MB Date : 2010/06/19 14:24:12 You should be looking at number about half of these. I ran the test with adaptive readahead enabled, and write-through for cache (since I run with BBU, I normally use write-back) //Svein ___ 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: RFC: New event timers infrastructure
Brandon Gooch wrote: > On Sun, Jun 20, 2010 at 1:17 AM, Alexander Motin wrote: > In by /boot/loader.conf, I now have: > > # Power Saving > kern.hz="100" > #hint.apic.0.clock="0" > #hint.atrtc.0.clock="0" > hint.p4tcc.0.disabled="1" > hint.p4tcc.1.disabled="1" > hint.acpi_throttle.0.disabled="1" > hint.acpi_throttle.1.disabled="1" > hw.pci.do_power_nodriver="3" > > In /etc/sysctl.conf, I have as suggested: > > kern.eventtimer.timer1=HPET > kern.eventtimer.timer2=NONE > kern.eventtimer.singlemul=1 While this can be done in sysctl.conf, it would be better to do it in loader.conf to make it applied from the beginning, without on-the-fly timers change. > But in my dmesg, I see: > > # dmesg | grep Starting > Starting kernel event timers: LAPIC @ 100Hz, HPET @ 128Hz > Starting kernel event timers: LAPIC @ 400Hz, NONE @ 0Hz > Starting kernel event timers: HPET @ 200Hz, NONE @ 0Hz This is result of changing timers during late boot by sysctl.conf. > So it seems as if the HPET doesn't honor kern.hz setting? Maybe I > still need to explicitly disable the apic timers... All timers now equally honor hz. But except hz, stathz also should be honored, which set once during startup. In your case, as second timer was initially present, system was free to choose stathz frequency, and it chosen 128Hz. When you later disabled second timer, system had to rise first timer frequency to emulate declared stathz. If you move timers selection options from sysctl.conf to loader.conf you will get what you want. > Would you suggest using LAPIC as opposed to HPET? I have seen power > savings being able to use C3 state, but if tickless kernel eventually > buys those savings back, perhaps LAPIC would be better... Tickless operation usually effective only together with C-states. It increases their effectiveness (or even applicability). The only case benefit from tickless operation without C3 - is a virtual machines. So if your LAPIC dies on C3 (it seems not to on Core i5 any more) you have no much other options then avoid it. HPET same time never have problems with C-states, as it located in chipset. But not every HPET is equally useful. Except AMD since at least SB700) and latest Intel chipsets, HPET uses regular IRQs, that are often shared with PCI devices and so hardly could be bound to CPU cores to provide separate events for every core. While tickless operation is still possible in that case, it is somewhat limited, as one core will have wake up every time when any other need event. Mentioned chipset's HPETs same time support FSB interrupts (alike to PCI MSI-X), that are never shared and so timers could be dedicated to CPU cores. >> As result, you will have single timer, running at HZ rate. Instead of >> HPET there you may choose any timer: >> LAPIC - it is per-CPU, so saves on IPI interrupts, supports one-shot >> mode and so suitable for further tickless kernel, but it doesn't work in >> C3 state; > > So if LAPIC is disabled in C3 state, is there a possibility that the > "on-the-fly" method of changing clocks could kick in when the CPU > enters C3 state, switching to the HPET when it happens? On-the-fly timers change is possible, as you have already tried with sysctl.conf. But the switch is not so easy because of LAPIC specifics, and it is meaningless to use LAPIC in that case. If you need to run C3 - turn LAPIC off. -- Alexander Motin ___ 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: [OpenRD Ultimate] e1000phy(88E1149/88E1121) has a initialize issue
Hi Kristof. On Sun, 20 Jun 2010 15:01:00 +0200 Kristof Provost wrote: > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > - - - - - - - > > /* Tell the MAC where to find the PHY so autoneg works */ > > - miisc = LIST_FIRST(&sc->mii->mii_phys); > > - MGE_WRITE(sc, MGE_REG_PHYDEV, miisc->mii_phy); > > + MGE_WRITE(sc, MGE_REG_PHYDEV, sc->phyaddr); > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > - - - - - - - > I think that's correct, but I haven't been able to test it on my board > yet. Does this work for you on a board with two GbE ports? If so I'll > try to get someone to commit it. Yes, good works well. I reported following: http://lists.freebsd.org/pipermail/freebsd-arm/2010-June/002402.html Thank you. -- Norikatsu Shigemura ___ 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: RFC: New event timers infrastructure
On Sun, Jun 20, 2010 at 1:17 AM, Alexander Motin wrote:
> Brandon Gooch wrote:
>> I've been testing these patches since the first iteration
>> (et.20100606), and I haven't discovered any related issues.
>
> Thank you!
>
>> I am unclear about the number of interrupts I should expect from the
>> hpet0 device (compared to the 99 from the rtc at 100Hz), so here is
>> the output of vmstat -i with and without the "et" patches:
>>
>> With "et" patches:
>>
>> interrupt total rate
>> irq1: atkbd0 369 3
>> irq9: acpi0 961 8
>> irq12: psm0 1002 9
>> irq18: uhci5 140 1
>> irq19: uhci2 ehci0* 4823 45
>> irq20: hpet0 23893223
>> irq23: uhci3 ehci111 0
>> irq256: vgapci0 1031 9
>> irq257: hdac0 14 0
>> irq258: iwn04258 39
>> irq259: bge0 1 0
>> Total 36503341
>>
>> Without "et" patches:
>>
>> interrupt total rate
>> irq1: atkbd0 449 2
>> irq0: clk 17334 99
>> irq9: acpi0 1701 9
>> irq12: psm0 8784 50
>> irq18: uhci5 188 1
>> irq19: uhci2 ehci0* 5828 33
>> irq23: uhci3 ehci111 0
>> irq256: vgapci0 1896 10
>> irq257: hdac0 14 0
>> irq258: iwn0 29571169
>> irq259: bge0 1 0
>> Total 65777378
>>
>> And lastly, the values of the kern.eventtimer sysctls:
>>
>> $ sysctl kern.eventtimer
>> kern.eventtimer.choice: HPET(450) HPET1(440) HPET2(440) HPET3(440) i8254(100)
>> kern.eventtimer.timer2: HPET1
>> kern.eventtimer.timer1: HPET
>> kern.eventtimer.singlemul: 4
>
> I don't see there neither LAPIC, nor RTC timer. I suppose you have
> disabled them via device hints. I also suppose you've done it to left
> with only 100Hz IRQs of i8254 timer. Now, with the patch, these two are
> still disabled, but system got 4 more HPET timers. As they have higher
> precedence, two of them were taken (HPET and HPET1). Number if
> interrupts can be explained by the line:
>
> Starting kernel event timers: HPET @ 100Hz, HPET1 @ 128Hz
Yes, I had the LAPIC and RTC timers disabled via my /boot/loader.conf,
as per your suggestions here:
http://wiki.freebsd.org/TuningPowerConsumption
> As result, you've got 228Hz IRQs (which then redistributed to every
> CPU). As your HPET timer doesn't support FSB interrupts, all it's timers
> share same IRQ vector, seen as "hpet0".
Understood.
> If you wish to get back to 100Hz IRQs as before, you may remove your
> previous clock-disabling hints and add instead:
>
> kern.eventtimer.timer1=HPET
> kern.eventtimer.timer2=NONE
> kern.eventtimer.singlemul=1
In by /boot/loader.conf, I now have:
# Power Saving
kern.hz="100"
#hint.apic.0.clock="0"
#hint.atrtc.0.clock="0"
hint.p4tcc.0.disabled="1"
hint.p4tcc.1.disabled="1"
hint.acpi_throttle.0.disabled="1"
hint.acpi_throttle.1.disabled="1"
hw.pci.do_power_nodriver="3"
In /etc/sysctl.conf, I have as suggested:
kern.eventtimer.timer1=HPET
kern.eventtimer.timer2=NONE
kern.eventtimer.singlemul=1
In my /etc/rc.conf, I'm still using:
performance_cpu_freq="NONE"
economy_cpu_freq="NONE"
performance_cx_lowest="C3"
economy_cx_lowest="C3"
I'm running powerd:
powerd_enable="YES"
powerd_flags="-a adaptive -b adaptive -n adaptive"
But in my dmesg, I see:
# dmesg | grep Starting
Starting kernel event timers: LAPIC @ 100Hz, HPET @ 128Hz
Starting kernel event timers: LAPIC @ 400Hz, NONE @ 0Hz
Starting kernel event timers: HPET @ 200Hz, NONE @ 0Hz
So it seems as if the HPET doesn't honor kern.hz setting? Maybe I
still need to explicitly disable the apic timers...
Would you suggest using LAPIC as opposed to HPET? I have seen power
savings being able to use C3 state, but if tickless kernel eventually
buys those savings back, perhaps LAPIC would be better...
> As result, you will have single timer, running at HZ rate. Instead of
> HPET there you may choose any timer:
> LAPIC - it is per-CPU, so saves on IPI interrupts, supports one-shot
> mode and so suitable for further tickless kernel, but it doesn't work in
> C3 state;
So if LAPIC is disabled in C3 state, is there a possibility that the
"on-the-fly" method of changing clocks could kick in when the CPU
enters C3 state, switching to the HPET when it happens?
> HPET{x} - on this hardware it can't be used as per-CPU, it supports
> one-shot mode, but less suitable for further tickless kernel, as CPUs
> can't run independe
[head tinderbox] failure on powerpc/powerpc
TB --- 2010-06-20 13:55:40 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-06-20 13:55:40 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2010-06-20 13:55:40 - cleaning the object tree TB --- 2010-06-20 13:55:45 - cvsupping the source tree TB --- 2010-06-20 13:55:45 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2010-06-20 13:56:08 - building world TB --- 2010-06-20 13:56:08 - MAKEOBJDIRPREFIX=/obj TB --- 2010-06-20 13:56:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-06-20 13:56:08 - TARGET=powerpc TB --- 2010-06-20 13:56:08 - TARGET_ARCH=powerpc TB --- 2010-06-20 13:56:08 - TZ=UTC TB --- 2010-06-20 13:56:08 - __MAKE_CONF=/dev/null TB --- 2010-06-20 13:56:08 - cd /src TB --- 2010-06-20 13:56:08 - /usr/bin/make -B buildworld >>> World build started on Sun Jun 20 13:56:08 UTC 2010 >>> 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 [...] cc -O2 -pipe -I/obj/powerpc/src/cddl/lib/libdtrace -I/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libdtrace/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libctf/common -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/intel -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknown-pragmas -c dt_grammar.c cc -O2 -pipe -I/obj/powerpc/src/cddl/lib/libdtrace -I/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libdtrace/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libctf/common -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/intel -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_handle.c cc -O2 -pipe -I/obj/powerpc/src/cddl/lib/libdtrace -I/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libdtrace/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libctf/common -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/intel -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_ident.c cc -O2 -pipe -I/obj/powerpc/src/cddl/lib/libdtrace -I/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libdtrace/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libctf/common -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/intel -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_inttab.c cc -O2 -pipe -I/obj/powerpc/src/cddl/lib/libdtrace -I/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libdtrace/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libctf/common -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/intel -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknown-pragmas -c dt_lex.c cc1: warnings being treated as errors /src/cddl/lib/
Re: [CFT] SIFTR - Statistical Information For TCP Research: Uncle Lawrence needs YOU!
Fabian Keil wrote: > Lawrence Stewart wrote: > > > On 06/20/10 22:28, Fabian Keil wrote: > > > Taking pf (and altq) out of the picture doesn't seem to make > > > a difference. > > > > Wouldn't have expected it to. Will be very curious to know if the panic > > is triggered in GENERIC. > > It's not. I, too, get pfil.c related LORs though: > > lock order reversal: > 1st 0x80e5c568 PFil hook read/write mutex (PFil hook read/write > mutex) @ /usr/src/sys/net/pfil.c:77 > 2nd 0x80e5dd68 udp (udp) @ > /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:3035 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x2e > witness_checkorder() at witness_checkorder+0x81e > _rw_rlock() at _rw_rlock+0x5f > pf_socket_lookup() at pf_socket_lookup+0x1c5 > pf_test_udp() at pf_test_udp+0x8b0 > pf_test() at pf_test+0x1089 > pf_check_in() at pf_check_in+0x39 > pfil_run_hooks() at pfil_run_hooks+0xcf > ip_input() at ip_input+0x2ae > swi_net() at swi_net+0x151 > intr_event_execute_handlers() at intr_event_execute_handlers+0x66 > ithread_loop() at ithread_loop+0xb2 > fork_exit() at fork_exit+0x12a > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xff844d30, rbp = 0 --- > lock order reversal: > 1st 0x80e5c568 PFil hook read/write mutex (PFil hook read/write > mutex) @ /usr/src/sys/net/pfil.c:77 > 2nd 0x80e5d788 tcp (tcp) @ > /usr/src/sys/modules/siftr/../../netinet/siftr.c:698 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x2e > witness_checkorder() at witness_checkorder+0x81e > _rw_rlock() at _rw_rlock+0x5f > siftr_chkpkt() at siftr_chkpkt+0x3c4 > pfil_run_hooks() at pfil_run_hooks+0xcf > ip_input() at ip_input+0x2ae > swi_net() at swi_net+0x151 > intr_event_execute_handlers() at intr_event_execute_handlers+0x66 > ithread_loop() at ithread_loop+0xb2 > fork_exit() at fork_exit+0x12a > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xff844d30, rbp = 0 --- > > My custom kernel normally doesn't have INVARIANTS and WITNESS > enabled, so I'll try to enable them next. The culprit seem to be non-default KTR settings in the kernel while loading alq as a module. With the following change siftr works with my non-GENERIC kernel, too: commit f43b8b5171c858df7b419f6a695e9e3b53531a8e Author: Fabian Keil Date: Sun Jun 20 15:43:01 2010 +0200 Disable KTR changes. diff --git a/sys/amd64/conf/ZOEY b/sys/amd64/conf/ZOEY index 6fb3480..c584317 100644 --- a/sys/amd64/conf/ZOEY +++ b/sys/amd64/conf/ZOEY @@ -16,11 +16,11 @@ options ATA_CAM device atapicam options SC_KERNEL_CONS_ATTR=(FG_GREEN|BG_BLACK) -options KTR -options KTR_ENTRIES=262144 -options KTR_COMPILE=(KTR_SCHED) -options KTR_MASK=(KTR_SCHED) -options KTR_CPUMASK=0x3 +#options KTR +#options KTR_ENTRIES=262144 +#options KTR_COMPILE=(KTR_SCHED) +#options KTR_MASK=(KTR_SCHED) +#options KTR_CPUMASK=0x3 options ACCEPT_FILTER_HTTP makeoptions WITH_CTF=yes Fabian signature.asc Description: PGP signature
Re: [CFT] SIFTR - Statistical Information For TCP Research: Uncle Lawrence needs YOU!
On 06/20/10 23:15, Fabian Keil wrote:
Lawrence Stewart wrote:
On 06/20/10 22:28, Fabian Keil wrote:
Lawrence Stewart wrote:
On 06/20/10 21:15, Fabian Keil wrote:
Lawrence Stewartwrote:
On 06/20/10 03:58, Fabian Keil wrote:
Lawrence Stewart wrote:
On 06/13/10 18:12, Lawrence Stewart wrote:
The time has come to solicit some external testing for my SIFTR tool.
I'm hoping to commit it within a week or so unless problems are discovered.
I'm interested in all feedback and reports of success/failure, along
with details of the architecture tested and number of CPUs if you would
be so kind.
I got the following hand-transcribed panic maybe a second after
sysctl net.inet.siftr.enabled=1
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
[...]
current process = 12 (swi4: clock)
[ thread pid 12 tid 16 ]
Stopped at siftr_chkpkt+0xd0: addq$0x1,0x8(%r14)
db> where
Tracing pid 12 tid 16 td 0xff00034037e0
siftr_chkpt() at siftr_chkpkt+0xd0
pfil_run_hooks() at pfil_run_hooks+0xb4
ip_output() at ip_output+0x382
tcp_output() tcp_output+0xa41
tcp_timer_rexmt() at tcp_timer_rexmt+0x251
softclock() at softclock+0x291
intr_event_execute_handlers() at intr_event_execute_handlers+0x66
ithread_loop at ithread_loop+0x8e
fork_exit() at fork_exit+0x112
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xff83ad30, rbp = 0 ---
So I've tracked down the line of code where the page fault is occurring:
if (dir == PFIL_IN)
ss->n_in++;
else
ss->n_out++;
ss is a DPCPU (dynamic per-cpu) variable used to keep a set of stats
per-cpu and is initialised at the start of the function like so:
ss = DPCPU_PTR(ss);
So for ss to be NULL, that implies DPCPU_PTR() is returning NULL on your
machine. I know very little about the inner workings of the DPCPU_*
macros, but I'm pretty sure the way I use them in SIFTR is correct or at
least as intended.
siftr_chkpkt() passes ss to siftr_chkreinject() before dereferencing
it itself. I think if ss was NULL, the panic should already occur in
siftr_chkreinject().
Yes but siftr_chkreinject() only dereferences ss in the exceptional case
of a malloc failure or duplicate pkt. It's unlikely either case happens
for you and so wouldn't trigger the panic.
To be sure I added:
diff --git a/sys/netinet/siftr.c b/sys/netinet/siftr.c
index 8bc3498..b9fdfe4 100644
--- a/sys/netinet/siftr.c
+++ b/sys/netinet/siftr.c
@@ -788,6 +788,16 @@ siftr_chkpkt(void *arg, struct mbuf **m, struct ifnet
*ifp, int dir,
if (siftr_chkreinject(*m, dir, ss))
goto ret;
+ if (ss == NULL) {
+ printf("ss is NULL");
+ ss = DPCPU_PTR(ss);
+ if (ss == NULL) {
+ printf("ss is still NULL");
+ goto ret;
+ }
+}
+
+
if (dir == PFIL_IN)
ss->n_in++;
else
which doesn't seem to affect the problem.
As in it still panics and the "ss is NULL" message is not printed? I
would have expected to at least see "ss is NULL" printed if my
hypothesis was correct... hmm.
Yes, it still panics, but no message is printed.
It was just pointed out to me that ss doesn't have to be NULL in order
to cause the page fault (duh). It could also just be a garbage ptr which
is why your print statement isn't firing.
Can you trigger the panic again and look for some information along the
lines of "fault virtual address = ..." as part of the panic info.
Knowing the faulting address would be useful and may help further diagnosis.
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0xff7f808f9de8
fault code = supervisor write data, page not present
instruction pointer = 0x20:0x8241f800
stack pointer = 0x28:0xff83a7d0
frame pointer = 0x28:0xff83a840
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
None of this looks too crazy, but at least one person I've been chatting
to about this thinks the faulting address doesn't look quite right for a
DPCPU variable.
Can you please get the following additional info from DDB:
show reg
show dpcpu_offset
p/x pcpu_entry_modspace
And can you also please identify the upstream FreeBSD revision number
your kernel source is based on (as opposed to the GIT rev) so we can
make sure we're looking at the same base sources you're running.
current process = 12 (swi4: clock)
[ thread pid 12 tid 16 ]
Stopped at siftr_chkpkt+0xd0: addq$0x1,0x8(%r14)
db> where
Tracing pid 12 tid 16 td 0xff00034037e0
siftr_chkpt() at siftr_chkpkt+0xd0
pfil_run_hooks() at pfil_run_hooks+0xb4
ip_output() at ip_output+0x382
tcp_output() tcp_output+0xa41
tcp_timer_
Re: [CFT] SIFTR - Statistical Information For TCP Research: Uncle Lawrence needs YOU!
Lawrence Stewart wrote:
> On 06/20/10 22:28, Fabian Keil wrote:
> > Lawrence Stewart wrote:
> >
> >> On 06/20/10 21:15, Fabian Keil wrote:
> >>> Lawrence Stewart wrote:
> >>>
> On 06/20/10 03:58, Fabian Keil wrote:
> > Lawrence Stewartwrote:
> >
> >> On 06/13/10 18:12, Lawrence Stewart wrote:
> >
> >>> The time has come to solicit some external testing for my SIFTR tool.
> >>> I'm hoping to commit it within a week or so unless problems are
> >>> discovered.
> >
> >>> I'm interested in all feedback and reports of success/failure, along
> >>> with details of the architecture tested and number of CPUs if you
> >>> would
> >>> be so kind.
> >
> > I got the following hand-transcribed panic maybe a second after
> > sysctl net.inet.siftr.enabled=1
> >
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 1; apic id = 01
> > [...]
> > current process = 12 (swi4: clock)
> > [ thread pid 12 tid 16 ]
> > Stopped at siftr_chkpkt+0xd0: addq$0x1,0x8(%r14)
> > db>where
> > Tracing pid 12 tid 16 td 0xff00034037e0
> > siftr_chkpt() at siftr_chkpkt+0xd0
> > pfil_run_hooks() at pfil_run_hooks+0xb4
> > ip_output() at ip_output+0x382
> > tcp_output() tcp_output+0xa41
> > tcp_timer_rexmt() at tcp_timer_rexmt+0x251
> > softclock() at softclock+0x291
> > intr_event_execute_handlers() at intr_event_execute_handlers+0x66
> > ithread_loop at ithread_loop+0x8e
> > fork_exit() at fork_exit+0x112
> > fork_trampoline() at fork_trampoline+0xe
> > --- trap 0, rip = 0, rsp = 0xff83ad30, rbp = 0 ---
>
> So I've tracked down the line of code where the page fault is occurring:
>
> if (dir == PFIL_IN)
> ss->n_in++;
> else
> ss->n_out++;
>
> ss is a DPCPU (dynamic per-cpu) variable used to keep a set of stats
> per-cpu and is initialised at the start of the function like so:
>
> ss = DPCPU_PTR(ss);
>
> So for ss to be NULL, that implies DPCPU_PTR() is returning NULL on your
> machine. I know very little about the inner workings of the DPCPU_*
> macros, but I'm pretty sure the way I use them in SIFTR is correct or at
> least as intended.
> >>>
> >>> siftr_chkpkt() passes ss to siftr_chkreinject() before dereferencing
> >>> it itself. I think if ss was NULL, the panic should already occur in
> >>> siftr_chkreinject().
> >>
> >> Yes but siftr_chkreinject() only dereferences ss in the exceptional case
> >> of a malloc failure or duplicate pkt. It's unlikely either case happens
> >> for you and so wouldn't trigger the panic.
> >>
> >>> To be sure I added:
> >>>
> >>> diff --git a/sys/netinet/siftr.c b/sys/netinet/siftr.c
> >>> index 8bc3498..b9fdfe4 100644
> >>> --- a/sys/netinet/siftr.c
> >>> +++ b/sys/netinet/siftr.c
> >>> @@ -788,6 +788,16 @@ siftr_chkpkt(void *arg, struct mbuf **m, struct
> >>> ifnet *ifp, int dir,
> >>> if (siftr_chkreinject(*m, dir, ss))
> >>> goto ret;
> >>>
> >>> + if (ss == NULL) {
> >>> + printf("ss is NULL");
> >>> + ss = DPCPU_PTR(ss);
> >>> + if (ss == NULL) {
> >>> + printf("ss is still NULL");
> >>> + goto ret;
> >>> + }
> >>> +}
> >>> +
> >>> +
> >>> if (dir == PFIL_IN)
> >>> ss->n_in++;
> >>> else
> >>>
> >>> which doesn't seem to affect the problem.
> >>
> >> As in it still panics and the "ss is NULL" message is not printed? I
> >> would have expected to at least see "ss is NULL" printed if my
> >> hypothesis was correct... hmm.
> >
> > Yes, it still panics, but no message is printed.
>
> It was just pointed out to me that ss doesn't have to be NULL in order
> to cause the page fault (duh). It could also just be a garbage ptr which
> is why your print statement isn't firing.
>
> Can you trigger the panic again and look for some information along the
> lines of "fault virtual address = ..." as part of the panic info.
> Knowing the faulting address would be useful and may help further diagnosis.
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0xff7f808f9de8
fault code = supervisor write data, page not present
instruction pointer = 0x20:0x8241f800
stack pointer = 0x28:0xff83a7d0
frame pointer = 0x28:0xff83a840
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 12 (swi4: clock)
[ thread pid 12 tid 16 ]
Stopped at siftr_chkpkt+0xd0: addq$0x1,0x8(%r14)
db> where
Tracing pid 12 tid 16 td 0xff00034037e0
siftr_chkpt() at siftr_ch
Re: [OpenRD Ultimate] e1000phy(88E1149/88E1121) has a initialize issue
On 2010-06-20 21:03:51 (+0900), Norikatsu Shigemura wrote: > On Sun, 13 Jun 2010 22:13:31 +0200 > Kristof Provost wrote: > > > I have a OpenRD Ultimate, which has two GbE ports - if_mge(4). But > > > I couldn't use mge1 like following. So I tried to investigate. > > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > > - - - - - - - - > > > Jun 13 05:02:14 sidearms kernel: mge1: watchdog timeout > > > Jun 13 05:02:14 sidearms kernel: mge1: Timeout on link-up > > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > > - - - - - - - - > > I believe the mge(4) driver incorrectly configures the PHY address for > > the second interface. Can you give the attached patch a try? > > Thank you. I think so, too. And, by FDT, I suggest following > patch. > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - - > /* Tell the MAC where to find the PHY so autoneg works */ > - miisc = LIST_FIRST(&sc->mii->mii_phys); > - MGE_WRITE(sc, MGE_REG_PHYDEV, miisc->mii_phy); > + MGE_WRITE(sc, MGE_REG_PHYDEV, sc->phyaddr); > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - - > I think that's correct, but I haven't been able to test it on my board yet. Does this work for you on a board with two GbE ports? If so I'll try to get someone to commit it. Regards, Kristof ___ 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: [CFT] SIFTR - Statistical Information For TCP Research: Uncle Lawrence needs YOU!
On 06/20/10 22:28, Fabian Keil wrote:
Lawrence Stewart wrote:
On 06/20/10 21:15, Fabian Keil wrote:
Lawrence Stewart wrote:
On 06/20/10 03:58, Fabian Keil wrote:
Lawrence Stewartwrote:
On 06/13/10 18:12, Lawrence Stewart wrote:
The time has come to solicit some external testing for my SIFTR tool.
I'm hoping to commit it within a week or so unless problems are discovered.
I'm interested in all feedback and reports of success/failure, along
with details of the architecture tested and number of CPUs if you would
be so kind.
I got the following hand-transcribed panic maybe a second after
sysctl net.inet.siftr.enabled=1
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
[...]
current process = 12 (swi4: clock)
[ thread pid 12 tid 16 ]
Stopped at siftr_chkpkt+0xd0: addq$0x1,0x8(%r14)
db>where
Tracing pid 12 tid 16 td 0xff00034037e0
siftr_chkpt() at siftr_chkpkt+0xd0
pfil_run_hooks() at pfil_run_hooks+0xb4
ip_output() at ip_output+0x382
tcp_output() tcp_output+0xa41
tcp_timer_rexmt() at tcp_timer_rexmt+0x251
softclock() at softclock+0x291
intr_event_execute_handlers() at intr_event_execute_handlers+0x66
ithread_loop at ithread_loop+0x8e
fork_exit() at fork_exit+0x112
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xff83ad30, rbp = 0 ---
So I've tracked down the line of code where the page fault is occurring:
if (dir == PFIL_IN)
ss->n_in++;
else
ss->n_out++;
ss is a DPCPU (dynamic per-cpu) variable used to keep a set of stats
per-cpu and is initialised at the start of the function like so:
ss = DPCPU_PTR(ss);
So for ss to be NULL, that implies DPCPU_PTR() is returning NULL on your
machine. I know very little about the inner workings of the DPCPU_*
macros, but I'm pretty sure the way I use them in SIFTR is correct or at
least as intended.
siftr_chkpkt() passes ss to siftr_chkreinject() before dereferencing
it itself. I think if ss was NULL, the panic should already occur in
siftr_chkreinject().
Yes but siftr_chkreinject() only dereferences ss in the exceptional case
of a malloc failure or duplicate pkt. It's unlikely either case happens
for you and so wouldn't trigger the panic.
To be sure I added:
diff --git a/sys/netinet/siftr.c b/sys/netinet/siftr.c
index 8bc3498..b9fdfe4 100644
--- a/sys/netinet/siftr.c
+++ b/sys/netinet/siftr.c
@@ -788,6 +788,16 @@ siftr_chkpkt(void *arg, struct mbuf **m, struct ifnet
*ifp, int dir,
if (siftr_chkreinject(*m, dir, ss))
goto ret;
+ if (ss == NULL) {
+ printf("ss is NULL");
+ ss = DPCPU_PTR(ss);
+ if (ss == NULL) {
+ printf("ss is still NULL");
+ goto ret;
+ }
+}
+
+
if (dir == PFIL_IN)
ss->n_in++;
else
which doesn't seem to affect the problem.
As in it still panics and the "ss is NULL" message is not printed? I
would have expected to at least see "ss is NULL" printed if my
hypothesis was correct... hmm.
Yes, it still panics, but no message is printed.
It was just pointed out to me that ss doesn't have to be NULL in order
to cause the page fault (duh). It could also just be a garbage ptr which
is why your print statement isn't firing.
Can you trigger the panic again and look for some information along the
lines of "fault virtual address = ..." as part of the panic info.
Knowing the faulting address would be useful and may help further diagnosis.
Perhaps the way I discovered the line number at which the panic occurred
was wrong. I compiled SIFTR on my amd64 dev server with "CFLAGS+=-g" in
the SIFTR Makefile to get debug symbols, ran "objdump -Sd siftr.ko | vim
-", searched for the instruction reported in the panic message i.e.
"addq $0x1,0x8(%r14)" and then with a bit of trial and error, recompiled
SIFTR with the line of code "volatile int blah = 0; blah = 2;" at
various points in the function and looking at the change in the objdump
output to pinpoint which line of C code corresponded with the "addq"
instruction.
The "volatile int blah = 0; blah = 2;" compiles to "movl
$0x0,0xffd4(%rbp)" followed immediately by "movl
$0x2,0xffd4(%rbp)". When I put that code above the "if (dir
== PFIL_IN)" statement I see the objdump output show the assembly code
before the "addq" instruction and when I move it after the if statement
the assembly code moves after the "addq" instruction.
That's a neat trick.
Indeed, and I thank phk@ for suggesting it to me.
Perhaps you could reproduce the above procedure and see if you identify
the same point in the siftr_chkpkt function I did for the instruction
referenced by the panic message?
I do. Using:
diff --git a/sys/netinet/siftr.c b/sys/netinet/siftr.c
index b9fdfe4..fc6bd9a 100644
--- a/sys/netinet/siftr.c
+++ b/sys/netinet/siftr.c
@@ -797,12 +797,15 @@ siftr_chkpkt(void *ar
Re: [CFT] SIFTR - Statistical Information For TCP Research: Uncle Lawrence needs YOU!
Lawrence Stewart wrote:
> On 06/20/10 21:15, Fabian Keil wrote:
> > Lawrence Stewart wrote:
> >
> >> On 06/20/10 03:58, Fabian Keil wrote:
> >>> Lawrence Stewart wrote:
> >>>
> On 06/13/10 18:12, Lawrence Stewart wrote:
> >>>
> > The time has come to solicit some external testing for my SIFTR tool.
> > I'm hoping to commit it within a week or so unless problems are
> > discovered.
> >>>
> > I'm interested in all feedback and reports of success/failure, along
> > with details of the architecture tested and number of CPUs if you would
> > be so kind.
> >>>
> >>> I got the following hand-transcribed panic maybe a second after
> >>> sysctl net.inet.siftr.enabled=1
> >>>
> >>> Fatal trap 12: page fault while in kernel mode
> >>> cpuid = 1; apic id = 01
> >>> [...]
> >>> current process = 12 (swi4: clock)
> >>> [ thread pid 12 tid 16 ]
> >>> Stopped atsiftr_chkpkt+0xd0: addq$0x1,0x8(%r14)
> >>> db> where
> >>> Tracing pid 12 tid 16 td 0xff00034037e0
> >>> siftr_chkpt() at siftr_chkpkt+0xd0
> >>> pfil_run_hooks() at pfil_run_hooks+0xb4
> >>> ip_output() at ip_output+0x382
> >>> tcp_output() tcp_output+0xa41
> >>> tcp_timer_rexmt() at tcp_timer_rexmt+0x251
> >>> softclock() at softclock+0x291
> >>> intr_event_execute_handlers() at intr_event_execute_handlers+0x66
> >>> ithread_loop at ithread_loop+0x8e
> >>> fork_exit() at fork_exit+0x112
> >>> fork_trampoline() at fork_trampoline+0xe
> >>> --- trap 0, rip = 0, rsp = 0xff83ad30, rbp = 0 ---
> >>
> >> So I've tracked down the line of code where the page fault is occurring:
> >>
> >> if (dir == PFIL_IN)
> >> ss->n_in++;
> >> else
> >> ss->n_out++;
> >>
> >> ss is a DPCPU (dynamic per-cpu) variable used to keep a set of stats
> >> per-cpu and is initialised at the start of the function like so:
> >>
> >> ss = DPCPU_PTR(ss);
> >>
> >> So for ss to be NULL, that implies DPCPU_PTR() is returning NULL on your
> >> machine. I know very little about the inner workings of the DPCPU_*
> >> macros, but I'm pretty sure the way I use them in SIFTR is correct or at
> >> least as intended.
> >
> > siftr_chkpkt() passes ss to siftr_chkreinject() before dereferencing
> > it itself. I think if ss was NULL, the panic should already occur in
> > siftr_chkreinject().
>
> Yes but siftr_chkreinject() only dereferences ss in the exceptional case
> of a malloc failure or duplicate pkt. It's unlikely either case happens
> for you and so wouldn't trigger the panic.
>
> > To be sure I added:
> >
> > diff --git a/sys/netinet/siftr.c b/sys/netinet/siftr.c
> > index 8bc3498..b9fdfe4 100644
> > --- a/sys/netinet/siftr.c
> > +++ b/sys/netinet/siftr.c
> > @@ -788,6 +788,16 @@ siftr_chkpkt(void *arg, struct mbuf **m, struct ifnet
> > *ifp, int dir,
> > if (siftr_chkreinject(*m, dir, ss))
> > goto ret;
> >
> > + if (ss == NULL) {
> > + printf("ss is NULL");
> > + ss = DPCPU_PTR(ss);
> > + if (ss == NULL) {
> > + printf("ss is still NULL");
> > + goto ret;
> > + }
> > +}
> > +
> > +
> > if (dir == PFIL_IN)
> > ss->n_in++;
> > else
> >
> > which doesn't seem to affect the problem.
>
> As in it still panics and the "ss is NULL" message is not printed? I
> would have expected to at least see "ss is NULL" printed if my
> hypothesis was correct... hmm.
Yes, it still panics, but no message is printed.
> Perhaps the way I discovered the line number at which the panic occurred
> was wrong. I compiled SIFTR on my amd64 dev server with "CFLAGS+=-g" in
> the SIFTR Makefile to get debug symbols, ran "objdump -Sd siftr.ko | vim
> -", searched for the instruction reported in the panic message i.e.
> "addq $0x1,0x8(%r14)" and then with a bit of trial and error, recompiled
> SIFTR with the line of code "volatile int blah = 0; blah = 2;" at
> various points in the function and looking at the change in the objdump
> output to pinpoint which line of C code corresponded with the "addq"
> instruction.
>
> The "volatile int blah = 0; blah = 2;" compiles to "movl
> $0x0,0xffd4(%rbp)" followed immediately by "movl
> $0x2,0xffd4(%rbp)". When I put that code above the "if (dir
> == PFIL_IN)" statement I see the objdump output show the assembly code
> before the "addq" instruction and when I move it after the if statement
> the assembly code moves after the "addq" instruction.
That's a neat trick.
> Perhaps you could reproduce the above procedure and see if you identify
> the same point in the siftr_chkpkt function I did for the instruction
> referenced by the panic message?
I do. Using:
diff --git a/sys/netinet/siftr.c b/sys/netinet/siftr.c
index b9fdfe4..fc6bd9a 100644
--- a/sys/netinet/siftr.c
+++ b/sys/netinet/siftr.c
@@ -797,12 +797,15 @@ siftr_chkpkt(void *arg, struct mbuf **m, struct ifnet
Re: [OpenRD Ultimate] e1000phy(88E1149/88E1121) has a initialize issue
Hi yongari. On Tue, 15 Jun 2010 11:09:23 -0700 Pyun YongHyeon wrote: > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > - - - - - - - > > Jun 13 05:02:14 sidearms kernel: mge1: watchdog timeout > > Jun 13 05:02:14 sidearms kernel: mge1: Timeout on link-up > ^ > This part looks like a bug in mge(4). Driver does not know how long > it would take to get a valid link. Waiting for valid link in driver > initialization does not work(e.g Starting controller without UTP > cable may always fail on mge(4)). I think mge(4) should implement > correct link state change handling. Thanks for your pointed out. I didn't notice. I'll fix this issue like following on mge_start_locked(). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - if ((ifp->if_drv_flags & (IFF_DRV_RUNNING | IFF_DRV_OACTIVE)) != - IFF_DRV_RUNNING) + if (IFM_SUBTYPE(sc->mii->mii_media_active) == IFM_NONE || + (ifp->if_drv_flags & (IFF_DRV_RUNNING | IFF_DRV_OACTIVE)) != IFF_DRV_RUNNING) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > I found a initialize issue in e1000phy.c. > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > - - - - - - - > > --- sys/dev/mii/e1000phy.c.orig 2010-05-01 10:17:15.282196000 +0900 > > +++ sys/dev/mii/e1000phy.c 2010-06-13 16:19:46.616650536 +0900 > > @@ -278,6 +278,7 @@ > > case MII_MODEL_MARVELL_E1118: > > break; > > case MII_MODEL_MARVELL_E1116: > > + case MII_MODEL_MARVELL_E1149: > > page = PHY_READ(sc, E1000_EADR); > > /* Select page 3, LED control register. */ > > PHY_WRITE(sc, E1000_EADR, 3); > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > - - - - - - - > > I confirmed OK on my environment, OpenRD Ultimate has a 88E1121(I > > saw it, physically): > Once it was there but I removed it due to some other issues seen on > Yukon Ultra. That part will program LED access so I guess it > wouldn't affect normal network activity. Hum..., like following? At least, by current way, second NIC doesn't link-up if link connected. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - case MII_MODEL_MARVELL_E1118: + case MII_MODEL_MARVELL_E1149: break; case MII_MODEL_MARVELL_E1116: page = PHY_READ(sc, E1000_EADR); /* Select page 3, LED control register. */ PHY_WRITE(sc, E1000_EADR, 3); - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > 88E1116R might be RGMII variant of 88E1116. Because I don't have > controller that has 88E1116R I didn't treat it as 88E1116. With > that change could you use straight cable without help of MDI/MDI-X > converter? Sorry, I don't have 88E1116R machine, so I don't know. ___ 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: [OpenRD Ultimate] e1000phy(88E1149/88E1121) has a initialize issue
Hi Kristof. On Sun, 13 Jun 2010 22:13:31 +0200 Kristof Provost wrote: > > I have a OpenRD Ultimate, which has two GbE ports - if_mge(4). But > > I couldn't use mge1 like following. So I tried to investigate. > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > - - - - - - - > > Jun 13 05:02:14 sidearms kernel: mge1: watchdog timeout > > Jun 13 05:02:14 sidearms kernel: mge1: Timeout on link-up > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > - - - - - - - > I believe the mge(4) driver incorrectly configures the PHY address for > the second interface. Can you give the attached patch a try? Thank you. I think so, too. And, by FDT, I suggest following patch. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - /* Tell the MAC where to find the PHY so autoneg works */ - miisc = LIST_FIRST(&sc->mii->mii_phys); - MGE_WRITE(sc, MGE_REG_PHYDEV, miisc->mii_phy); + MGE_WRITE(sc, MGE_REG_PHYDEV, sc->phyaddr); - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- Norikatsu Shigemura ___ 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: [CFT] SIFTR - Statistical Information For TCP Research: Uncle Lawrence needs YOU!
On 06/20/10 21:15, Fabian Keil wrote:
Lawrence Stewart wrote:
On 06/20/10 03:58, Fabian Keil wrote:
Lawrence Stewart wrote:
On 06/13/10 18:12, Lawrence Stewart wrote:
The time has come to solicit some external testing for my SIFTR tool.
I'm hoping to commit it within a week or so unless problems are discovered.
I'm interested in all feedback and reports of success/failure, along
with details of the architecture tested and number of CPUs if you would
be so kind.
I got the following hand-transcribed panic maybe a second after
sysctl net.inet.siftr.enabled=1
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
[...]
current process = 12 (swi4: clock)
[ thread pid 12 tid 16 ]
Stopped at siftr_chkpkt+0xd0: addq$0x1,0x8(%r14)
db> where
Tracing pid 12 tid 16 td 0xff00034037e0
siftr_chkpt() at siftr_chkpkt+0xd0
pfil_run_hooks() at pfil_run_hooks+0xb4
ip_output() at ip_output+0x382
tcp_output() tcp_output+0xa41
tcp_timer_rexmt() at tcp_timer_rexmt+0x251
softclock() at softclock+0x291
intr_event_execute_handlers() at intr_event_execute_handlers+0x66
ithread_loop at ithread_loop+0x8e
fork_exit() at fork_exit+0x112
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xff83ad30, rbp = 0 ---
So I've tracked down the line of code where the page fault is occurring:
if (dir == PFIL_IN)
ss->n_in++;
else
ss->n_out++;
ss is a DPCPU (dynamic per-cpu) variable used to keep a set of stats
per-cpu and is initialised at the start of the function like so:
ss = DPCPU_PTR(ss);
So for ss to be NULL, that implies DPCPU_PTR() is returning NULL on your
machine. I know very little about the inner workings of the DPCPU_*
macros, but I'm pretty sure the way I use them in SIFTR is correct or at
least as intended.
siftr_chkpkt() passes ss to siftr_chkreinject() before dereferencing
it itself. I think if ss was NULL, the panic should already occur in
siftr_chkreinject().
Yes but siftr_chkreinject() only dereferences ss in the exceptional case
of a malloc failure or duplicate pkt. It's unlikely either case happens
for you and so wouldn't trigger the panic.
To be sure I added:
diff --git a/sys/netinet/siftr.c b/sys/netinet/siftr.c
index 8bc3498..b9fdfe4 100644
--- a/sys/netinet/siftr.c
+++ b/sys/netinet/siftr.c
@@ -788,6 +788,16 @@ siftr_chkpkt(void *arg, struct mbuf **m, struct ifnet
*ifp, int dir,
if (siftr_chkreinject(*m, dir, ss))
goto ret;
+ if (ss == NULL) {
+ printf("ss is NULL");
+ ss = DPCPU_PTR(ss);
+ if (ss == NULL) {
+ printf("ss is still NULL");
+ goto ret;
+ }
+}
+
+
if (dir == PFIL_IN)
ss->n_in++;
else
which doesn't seem to affect the problem.
As in it still panics and the "ss is NULL" message is not printed? I
would have expected to at least see "ss is NULL" printed if my
hypothesis was correct... hmm.
Perhaps the way I discovered the line number at which the panic occurred
was wrong. I compiled SIFTR on my amd64 dev server with "CFLAGS+=-g" in
the SIFTR Makefile to get debug symbols, ran "objdump -Sd siftr.ko | vim
-", searched for the instruction reported in the panic message i.e.
"addq $0x1,0x8(%r14)" and then with a bit of trial and error, recompiled
SIFTR with the line of code "volatile int blah = 0; blah = 2;" at
various points in the function and looking at the change in the objdump
output to pinpoint which line of C code corresponded with the "addq"
instruction.
The "volatile int blah = 0; blah = 2;" compiles to "movl
$0x0,0xffd4(%rbp)" followed immediately by "movl
$0x2,0xffd4(%rbp)". When I put that code above the "if (dir
== PFIL_IN)" statement I see the objdump output show the assembly code
before the "addq" instruction and when I move it after the if statement
the assembly code moves after the "addq" instruction.
Perhaps you could reproduce the above procedure and see if you identify
the same point in the siftr_chkpkt function I did for the instruction
referenced by the panic message?
Could you please go ahead and retest using a GENERIC kernel and see if
you can reproduce? There could be something in your custom kernel
causing the offsets or linker set magic used by the DPCPU bits to break
which in turn is triggering this panic in SIFTR.
I'll retry without pf first, and with GENERIC afterwards.
Sounds good, thanks.
Cheers,
Lawrence
___
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 arm/arm
TB --- 2010-06-20 11:25:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-06-20 11:25:00 - starting HEAD tinderbox run for arm/arm TB --- 2010-06-20 11:25:00 - cleaning the object tree TB --- 2010-06-20 11:25:06 - cvsupping the source tree TB --- 2010-06-20 11:25:06 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2010-06-20 11:25:47 - building world TB --- 2010-06-20 11:25:47 - MAKEOBJDIRPREFIX=/obj TB --- 2010-06-20 11:25:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-06-20 11:25:47 - TARGET=arm TB --- 2010-06-20 11:25:47 - TARGET_ARCH=arm TB --- 2010-06-20 11:25:47 - TZ=UTC TB --- 2010-06-20 11:25:47 - __MAKE_CONF=/dev/null TB --- 2010-06-20 11:25:47 - cd /src TB --- 2010-06-20 11:25:47 - /usr/bin/make -B buildworld >>> World build started on Sun Jun 20 11:25:48 UTC 2010 >>> 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 [...] cc -O -pipe -I/obj/arm/src/cddl/lib/libdtrace -I/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libdtrace/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libctf/common -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/intel -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknown-pragmas -c dt_grammar.c cc -O -pipe -I/obj/arm/src/cddl/lib/libdtrace -I/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libdtrace/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libctf/common -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/intel -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_handle.c cc -O -pipe -I/obj/arm/src/cddl/lib/libdtrace -I/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libdtrace/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libctf/common -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/intel -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_ident.c cc -O -pipe -I/obj/arm/src/cddl/lib/libdtrace -I/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libdtrace/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libctf/common -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/intel -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_inttab.c cc -O -pipe -I/obj/arm/src/cddl/lib/libdtrace -I/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libdtrace/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libctf/common -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/intel -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknown-pragmas -c dt_lex.c cc1: warnings being treated as errors /src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_lex.l: In function 'yylex': /src/cddl/lib/libdtrace/../../../cddl/cont
Re: [CFT] SIFTR - Statistical Information For TCP Research: Uncle Lawrence needs YOU!
Lawrence Stewart wrote:
> On 06/20/10 03:58, Fabian Keil wrote:
> > Lawrence Stewart wrote:
> >
> >> On 06/13/10 18:12, Lawrence Stewart wrote:
> >
> >>> The time has come to solicit some external testing for my SIFTR tool.
> >>> I'm hoping to commit it within a week or so unless problems are
> >>> discovered.
> >
> >>> I'm interested in all feedback and reports of success/failure, along
> >>> with details of the architecture tested and number of CPUs if you would
> >>> be so kind.
> >
> > I got the following hand-transcribed panic maybe a second after
> > sysctl net.inet.siftr.enabled=1
> >
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 1; apic id = 01
> > [...]
> > current process = 12 (swi4: clock)
> > [ thread pid 12 tid 16 ]
> > Stopped at siftr_chkpkt+0xd0: addq$0x1,0x8(%r14)
> > db> where
> > Tracing pid 12 tid 16 td 0xff00034037e0
> > siftr_chkpt() at siftr_chkpkt+0xd0
> > pfil_run_hooks() at pfil_run_hooks+0xb4
> > ip_output() at ip_output+0x382
> > tcp_output() tcp_output+0xa41
> > tcp_timer_rexmt() at tcp_timer_rexmt+0x251
> > softclock() at softclock+0x291
> > intr_event_execute_handlers() at intr_event_execute_handlers+0x66
> > ithread_loop at ithread_loop+0x8e
> > fork_exit() at fork_exit+0x112
> > fork_trampoline() at fork_trampoline+0xe
> > --- trap 0, rip = 0, rsp = 0xff83ad30, rbp = 0 ---
>
> So I've tracked down the line of code where the page fault is occurring:
>
> if (dir == PFIL_IN)
> ss->n_in++;
> else
> ss->n_out++;
>
> ss is a DPCPU (dynamic per-cpu) variable used to keep a set of stats
> per-cpu and is initialised at the start of the function like so:
>
> ss = DPCPU_PTR(ss);
>
> So for ss to be NULL, that implies DPCPU_PTR() is returning NULL on your
> machine. I know very little about the inner workings of the DPCPU_*
> macros, but I'm pretty sure the way I use them in SIFTR is correct or at
> least as intended.
siftr_chkpkt() passes ss to siftr_chkreinject() before dereferencing
it itself. I think if ss was NULL, the panic should already occur in
siftr_chkreinject().
To be sure I added:
diff --git a/sys/netinet/siftr.c b/sys/netinet/siftr.c
index 8bc3498..b9fdfe4 100644
--- a/sys/netinet/siftr.c
+++ b/sys/netinet/siftr.c
@@ -788,6 +788,16 @@ siftr_chkpkt(void *arg, struct mbuf **m, struct ifnet
*ifp, int dir,
if (siftr_chkreinject(*m, dir, ss))
goto ret;
+ if (ss == NULL) {
+ printf("ss is NULL");
+ ss = DPCPU_PTR(ss);
+ if (ss == NULL) {
+ printf("ss is still NULL");
+ goto ret;
+ }
+}
+
+
if (dir == PFIL_IN)
ss->n_in++;
else
which doesn't seem to affect the problem.
> Could you please go ahead and retest using a GENERIC kernel and see if
> you can reproduce? There could be something in your custom kernel
> causing the offsets or linker set magic used by the DPCPU bits to break
> which in turn is triggering this panic in SIFTR.
I'll retry without pf first, and with GENERIC afterwards.
Fabian
signature.asc
Description: PGP signature
Re: [CFT] SIFTR - Statistical Information For TCP Research: Uncle Lawrence needs YOU!
Hi Fabian, On 06/20/10 03:58, Fabian Keil wrote: Lawrence Stewart wrote: On 06/13/10 18:12, Lawrence Stewart wrote: The time has come to solicit some external testing for my SIFTR tool. I'm hoping to commit it within a week or so unless problems are discovered. I'm interested in all feedback and reports of success/failure, along with details of the architecture tested and number of CPUs if you would be so kind. I got the following hand-transcribed panic maybe a second after sysctl net.inet.siftr.enabled=1 Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 [...] current process = 12 (swi4: clock) [ thread pid 12 tid 16 ] Stopped at siftr_chkpkt+0xd0: addq$0x1,0x8(%r14) db> where Tracing pid 12 tid 16 td 0xff00034037e0 siftr_chkpt() at siftr_chkpkt+0xd0 pfil_run_hooks() at pfil_run_hooks+0xb4 ip_output() at ip_output+0x382 tcp_output() tcp_output+0xa41 tcp_timer_rexmt() at tcp_timer_rexmt+0x251 softclock() at softclock+0x291 intr_event_execute_handlers() at intr_event_execute_handlers+0x66 ithread_loop at ithread_loop+0x8e fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff83ad30, rbp = 0 --- So I've tracked down the line of code where the page fault is occurring: if (dir == PFIL_IN) ss->n_in++; else ss->n_out++; ss is a DPCPU (dynamic per-cpu) variable used to keep a set of stats per-cpu and is initialised at the start of the function like so: ss = DPCPU_PTR(ss); So for ss to be NULL, that implies DPCPU_PTR() is returning NULL on your machine. I know very little about the inner workings of the DPCPU_* macros, but I'm pretty sure the way I use them in SIFTR is correct or at least as intended. Could you please go ahead and retest using a GENERIC kernel and see if you can reproduce? There could be something in your custom kernel causing the offsets or linker set magic used by the DPCPU bits to break which in turn is triggering this panic in SIFTR. Whether its your custom changes breaking DPCPU or DPCPU being fragile remains to be seen, but the good news for me is that it looks like SIFTR is off the hook :) Cheers, Lawrence ___ 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"
