Re: multiple issues with devstat_*(9)
Alexander Best wrote: On Fri Apr 1 11, John Baldwin wrote: On Thursday, March 31, 2011 6:33:39 pm Alexander Best wrote: i think there are multiple issues with devstat. i found the following in devicestat.h: ... funny thing is i found the following in scsi_pass.c: softc-device_stats = devstat_new_entry(pass, periph-unit_number, 0, DEVSTAT_NO_BLOCKSIZE | (no_tags ? DEVSTAT_NO_ORDERED_TAGS : 0), softc-pd_type | DEVSTAT_TYPE_IF_SCSI | DEVSTAT_TYPE_PASS, DEVSTAT_PRIORITY_PASS); ...so pass* *should* show up under iostat -t scsi. As I can see, this is a bug (or feature) of the libdevstat / devstat_selectdevs(). If you specify any -t, then pass devices will be reported only if you request pass specifically. Hmm, pass devices for adaX should not be SCSI though, they should be ide I think. i think the situation with ATA_CAM should be discussed further. still besides this issue there are many more with devstat(3). i'll try to track all the devstat_new_entry() occurrences and see if some issues can be fixed. maybe only the proper DEVSTAT_* args were forgotten. Assuming that SCSI and IDE in -t option means transport type, and assuming that we count everything except ATA and SATA as SCSI, I've made following patch, that should fix issues from the CAM side: http://people.freebsd.org/~mav/cam.devstat.patch Any objections? Or SCSI/IDE there expected to mean command set? -- 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
prefer tsc timecounter when it's good
Guys, what do you think about the following change? The idea is mark TSC as the best timecounter when it's invariant and synchronized between cores. Unfortunately I don't have code to auto-detect the synchronization and keep relying on the corresponding tunable. I thought about auto-setting it for single-package configurations, but even that information is currently not trivial to get out of our mp (i386/amd64) machdep code. --- a/sys/x86/x86/tsc.c +++ b/sys/x86/x86/tsc.c @@ -169,6 +169,9 @@ init_TSC_tc(void) printf(TSC timecounter disabled: APM enabled.\n); } + if (tsc_is_invariant) + tsc_timecounter.tc_quality = 1200; + #ifdef SMP /* * We can not use the TSC in SMP mode unless the TSCs on all CPUs -- Andriy Gapon ___ 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] adding -Wmissing-include-dirs to CWARNFLAGS
hi there,
i'd like to propose adding -Wmissing-include-dirs to CWARNFLAGS. this will let
tinderbox fail, if any new kernel code was committed with (a) broken include
dir(s).
i ran a test via
make toolchains
make MAKE_JUST_KERNELS=yes tinderbox
and nothing seemed to go wrong with the extra warning enabled. i even found a
missing include dir, which should be fixed by the attached patch.
opinions?
so far i've only tested this with gcc. i think someone on #freebsd-clang told
me that -Wmissing-include-dirs is a noop for clang (for whatever reasons).
cheers.
alex
--
a13x
diff --git a/sys/modules/netgraph/atm/ccatm/Makefile
b/sys/modules/netgraph/atm/ccatm/Makefile
index 5626536..8bf741d 100644
--- a/sys/modules/netgraph/atm/ccatm/Makefile
+++ b/sys/modules/netgraph/atm/ccatm/Makefile
@@ -12,6 +12,6 @@ KMOD= ng_ccatm
SRCS= ng_ccatm.c cc_conn.c cc_data.c cc_dump.c cc_port.c cc_sig.c \
cc_user.c unisap.c
-CFLAGS+= -I${LIBBASE} -I${LIBBASE}/netnatm/ccatm -DCCATM_DEBUG
+CFLAGS+= -I${LIBBASE} -DCCATM_DEBUG
.include bsd.kmod.mk
___
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: prefer tsc timecounter when it's good
Hi-- On Apr 7, 2011, at 10:12 AM, Andriy Gapon wrote: what do you think about the following change? The idea is mark TSC as the best timecounter when it's invariant and synchronized between cores. Unfortunately I don't have code to auto-detect the synchronization and keep relying on the corresponding tunable. I thought about auto-setting it for single-package configurations, but even that information is currently not trivial to get out of our mp (i386/amd64) machdep code. In theory, most machines with P-state invariant TSCs should have their counters completely synchronized, even if there are multiple packages: http://software.intel.com/en-us/forums/showthread.php?t=74798 http://www.intel.com/Assets/PDF/manual/253668.pdf ...the exception would be very large machines with multiple mainboards. Regards, -- -Chuck ___ 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: prefer tsc timecounter when it's good
On Thursday 07 April 2011 01:12 pm, Andriy Gapon wrote: Guys, what do you think about the following change? The idea is mark TSC as the best timecounter when it's invariant and synchronized between cores. Unfortunately I don't have code to auto-detect the synchronization and keep relying on the corresponding tunable. I know Intel is claiming that TSCs for all cores/packages reset to zero when they receive a synchronous INIT/RESET IPI. I haven't really verified their claim but I think it may be good enough for our AP startup code. However, AMD processors never had such guarantee, AFAIK. I thought about auto-setting it for single-package configurations, but even that information is currently not trivial to get out of our mp (i386/amd64) machdep code. It isn't easy ATM. :-/ --- a/sys/x86/x86/tsc.c +++ b/sys/x86/x86/tsc.c @@ -169,6 +169,9 @@ init_TSC_tc(void) printf(TSC timecounter disabled: APM enabled.\n); } + if (tsc_is_invariant) + tsc_timecounter.tc_quality = 1200; + #ifdef SMP /* * We can not use the TSC in SMP mode unless the TSCs on all CPUs Although it looks okay, please don't commit it just yet. I am working in this area actively. Also, if the Intel's claim is true, i.e., TSCs reset to zero when APs start, we cannot use TSC as a timecounter hardware until all APs are started properly. Thanks, Jung-uk Kim ___ 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: prefer tsc timecounter when it's good
On 4/7/11 10:12 AM, Andriy Gapon wrote: Guys, what do you think about the following change? The idea is mark TSC as the best timecounter when it's invariant and synchronized between cores. Unfortunately I don't have code to auto-detect the synchronization and keep relying on the corresponding tunable. I thought about auto-setting it for single-package configurations, but even that information is currently not trivial to get out of our mp (i386/amd64) machdep code. --- a/sys/x86/x86/tsc.c +++ b/sys/x86/x86/tsc.c @@ -169,6 +169,9 @@ init_TSC_tc(void) printf(TSC timecounter disabled: APM enabled.\n); } + if (tsc_is_invariant) + tsc_timecounter.tc_quality = 1200; I like this. I have to set the timecounter to TSC manually on my machines as using teh default (fast-acpi) slows my tests down by 10%-20% mind you if one were to be able to put the tunable into /boot, one could put the sysctl into /etc/sysctl.conf to do the same thing.. + #ifdef SMP /* * We can not use the TSC in SMP mode unless the TSCs on all CPUs ___ 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] adding -Wmissing-include-dirs to CWARNFLAGS
On Thu, Apr 7, 2011 at 11:55 AM, Alexander Best arun...@freebsd.org wrote: hi there, i'd like to propose adding -Wmissing-include-dirs to CWARNFLAGS. this will let tinderbox fail, if any new kernel code was committed with (a) broken include dir(s). i ran a test via make toolchains make MAKE_JUST_KERNELS=yes tinderbox and nothing seemed to go wrong with the extra warning enabled. i even found a missing include dir, which should be fixed by the attached patch. opinions? so far i've only tested this with gcc. i think someone on #freebsd-clang told me that -Wmissing-include-dirs is a noop for clang (for whatever reasons). make -f /etc/src.conf -VMODULES_OVERRIDE and make -f /etc/src.conf -VMODULES_OVERRIDE say... (tinderbox should also really ignore these files, but it doesn't currently)? Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] adding -Wmissing-include-dirs to CWARNFLAGS
On Thu, Apr 7, 2011 at 1:53 PM, Garrett Cooper yaneg...@gmail.com wrote: On Thu, Apr 7, 2011 at 11:55 AM, Alexander Best arun...@freebsd.org wrote: hi there, i'd like to propose adding -Wmissing-include-dirs to CWARNFLAGS. this will let tinderbox fail, if any new kernel code was committed with (a) broken include dir(s). i ran a test via make toolchains make MAKE_JUST_KERNELS=yes tinderbox and nothing seemed to go wrong with the extra warning enabled. i even found a missing include dir, which should be fixed by the attached patch. opinions? so far i've only tested this with gcc. i think someone on #freebsd-clang told me that -Wmissing-include-dirs is a noop for clang (for whatever reasons). make -f /etc/src.conf -VMODULES_OVERRIDE and make -f /etc/src.conf -VMODULES_OVERRIDE say... (tinderbox should also really ignore these files, but it doesn't currently)? Sorry. Second invocation should have been make.conf, not src.conf. ___ 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] adding -Wmissing-include-dirs to CWARNFLAGS
On Thu Apr 7 11, Garrett Cooper wrote: On Thu, Apr 7, 2011 at 1:53 PM, Garrett Cooper yaneg...@gmail.com wrote: On Thu, Apr 7, 2011 at 11:55 AM, Alexander Best arun...@freebsd.org wrote: hi there, i'd like to propose adding -Wmissing-include-dirs to CWARNFLAGS. this will let tinderbox fail, if any new kernel code was committed with (a) broken include dir(s). i ran a test via make toolchains make MAKE_JUST_KERNELS=yes tinderbox and nothing seemed to go wrong with the extra warning enabled. i even found a missing include dir, which should be fixed by the attached patch. opinions? so far i've only tested this with gcc. i think someone on #freebsd-clang told me that -Wmissing-include-dirs is a noop for clang (for whatever reasons). make -f /etc/src.conf -VMODULES_OVERRIDE and make -f /etc/src.conf -VMODULES_OVERRIDE say... (tinderbox should also really ignore these files, but it doesn't currently)? otaku% make -f /etc/src.conf -VMODULES_OVERRIDE netgraph/netgraph netgraph/socket netgraph/bluetooth/bluetooth netgraph/bluetooth/hci netgraph/bluetooth/l2cap netgraph/bluetooth/socket netgraph/bluetooth/ubt tmpfs sound/sound sound/driver/hda usb/uhid procfs pseudofs linux linprocfs linsysfs lindev usb/quirk geom opensolaris dtrace cyclic nfsclient krpc nfs_common nfslock otaku% make -f /etc/make.conf -VMODULES_OVERRIDE netgraph/netgraph netgraph/socket netgraph/bluetooth/bluetooth netgraph/bluetooth/hci netgraph/bluetooth/l2cap netgraph/bluetooth/socket netgraph/bluetooth/ubt tmpfs sound/sound sound/driver/hda usb/uhid procfs pseudofs linux linprocfs linsysfs lindev usb/quirk geom opensolaris dtrace cyclic nfsclient krpc nfs_common nfslock ...however i checked and tinderbox *does* ignore src.conf and make.conf. the _.* log files show that modules were being build which are not returned by the commands above. i think having this flag would be very useful, because it would force people to make sure their include dirs are correct. Sorry. Second invocation should have been make.conf, not src.conf. -- a13x ___ 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] adding -Wmissing-include-dirs to CWARNFLAGS
On Thu, Apr 7, 2011 at 2:22 PM, Alexander Best arun...@freebsd.org wrote: On Thu Apr 7 11, Garrett Cooper wrote: On Thu, Apr 7, 2011 at 1:53 PM, Garrett Cooper yaneg...@gmail.com wrote: On Thu, Apr 7, 2011 at 11:55 AM, Alexander Best arun...@freebsd.org wrote: hi there, i'd like to propose adding -Wmissing-include-dirs to CWARNFLAGS. this will let tinderbox fail, if any new kernel code was committed with (a) broken include dir(s). i ran a test via make toolchains make MAKE_JUST_KERNELS=yes tinderbox and nothing seemed to go wrong with the extra warning enabled. i even found a missing include dir, which should be fixed by the attached patch. opinions? so far i've only tested this with gcc. i think someone on #freebsd-clang told me that -Wmissing-include-dirs is a noop for clang (for whatever reasons). make -f /etc/src.conf -VMODULES_OVERRIDE and make -f /etc/src.conf -VMODULES_OVERRIDE say... (tinderbox should also really ignore these files, but it doesn't currently)? otaku% make -f /etc/src.conf -VMODULES_OVERRIDE netgraph/netgraph netgraph/socket netgraph/bluetooth/bluetooth netgraph/bluetooth/hci netgraph/bluetooth/l2cap netgraph/bluetooth/socket netgraph/bluetooth/ubt tmpfs sound/sound sound/driver/hda usb/uhid procfs pseudofs linux linprocfs linsysfs lindev usb/quirk geom opensolaris dtrace cyclic nfsclient krpc nfs_common nfslock otaku% make -f /etc/make.conf -VMODULES_OVERRIDE netgraph/netgraph netgraph/socket netgraph/bluetooth/bluetooth netgraph/bluetooth/hci netgraph/bluetooth/l2cap netgraph/bluetooth/socket netgraph/bluetooth/ubt tmpfs sound/sound sound/driver/hda usb/uhid procfs pseudofs linux linprocfs linsysfs lindev usb/quirk geom opensolaris dtrace cyclic nfsclient krpc nfs_common nfslock ...however i checked and tinderbox *does* ignore src.conf and make.conf. the _.* log files show that modules were being build which are not returned by the commands above. i think having this flag would be very useful, because it would force people to make sure their include dirs are correct. Sorry. Second invocation should have been make.conf, not src.conf. Ok then. I stand corrected for not having tested out my claim beforehand. Yes, I agree that adding this flag in the default set is a good idea. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: prefer tsc timecounter when it's good
on 07/04/2011 23:00 Jung-uk Kim said the following: Although it looks okay, please don't commit it just yet. I am working in this area actively. Also, if the Intel's claim is true, i.e., TSCs reset to zero when APs start, we cannot use TSC as a timecounter hardware until all APs are started properly. Great! Thank you for the info and your work. -- Andriy Gapon ___ 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: multiple issues with devstat_*(9)
on 07/04/2011 13:59 Alexander Motin said the following: Any objections? Or SCSI/IDE there expected to mean command set? Sorry for saying something potentially stupid, but... do we actually have any reason to make that distinction from any practical point? -- Andriy Gapon ___ 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
