Re: kqueue timer timeout period
On 2012-Jul-10 10:03:08 -0500, Paul Albrecht wrote: >I have a question about the kqueue timer timeout period ... what's data >supposed to be? I thought it was supposed to be the period in >milliseconds, but I seem to off by one. > >For example, if I set date (the timeout period) to 20 milliseconds, I >often wait 21 milliseconds which is very undesirable for my application. FreeBSD is not a real-time OS. The timeouts specified in various syscalls (eg kevent(EVFILT_TIMER), nanosleep(), select(), poll()) specify minimum timeouts. Once the timeout (rounded up to the next tick) has expired, the process will be placed back into the queue of processes eligible to be run by the scheduler - which may impose a further arbitrary delay. Periodic timers are somewhat better behaved: Scheduler delays only impact process scheduling after the timeout expires and the average rate should be very close to that requested. -- Peter Jeremy pgpaFY3z3IfaV.pgp Description: PGP signature
Re: kqueue timer timeout period
On Wed, 11 Jul 2012, Peter Jeremy wrote: PJ>On 2012-Jul-10 10:03:08 -0500, Paul Albrecht wrote: PJ>>I have a question about the kqueue timer timeout period ... what's data PJ>>supposed to be? I thought it was supposed to be the period in PJ>>milliseconds, but I seem to off by one. PJ>> PJ>>For example, if I set date (the timeout period) to 20 milliseconds, I PJ>>often wait 21 milliseconds which is very undesirable for my application. PJ> PJ>FreeBSD is not a real-time OS. The timeouts specified in various PJ>syscalls (eg kevent(EVFILT_TIMER), nanosleep(), select(), poll()) PJ>specify minimum timeouts. Once the timeout (rounded up to the next PJ>tick) has expired, the process will be placed back into the queue PJ>of processes eligible to be run by the scheduler - which may impose PJ>a further arbitrary delay. PJ> PJ>Periodic timers are somewhat better behaved: Scheduler delays only PJ>impact process scheduling after the timeout expires and the average PJ>rate should be very close to that requested. While it is certainly true that FreeBSD is not a real-time OS, this does not explain the timer problems. 2 or 3 month ago I did a simple test with select and poll: I observed a systematic error of about 3-5% of the waiting time. So when you wait for 20ms, you may get 21ms (if running with a low HZ value) because of rounding. But if you wait for 100s, you get 103 or even 105s on a completly idle machine (all services disabled). I think that this is not a problem with beeing non-realtime, but a problem with time-keeping. Shouldn't it be possible to do this better? harti ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: kqueue timer timeout period
Hi. Historically FreeBSD used completely different hardware time sources for time keeping and time events. Not sure about 5%, but the last could be less precise in some cases. FreeBSD 9.0, depending on hardware, can be more precise because of using same time source in both cases. Also there is ongoing GSoC project now by Davide Italiano to handle sub-HZ resolution for time events. Present tests show reaching 20 microseconds precision; and I think it can be improved further. -- Alexander Motin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: dtraceall.ko with old nfsclient
Andriy Gapon wrote: > on 10/07/2012 21:57 Fabian Keil said the following: > > I do not use a completely NFS-free kernel, but I don't build any > > NFS-related modules. Trying to load an unpatched dtraceall results in: > > > > Jul 9 21:58:48 r500 sudo: fk : TTY=pts/16 ; PWD=/home/fk ; USER=root > > ; COMMAND=/sbin/kldload dtraceall Jul 9 21:58:48 r500 kernel: [8922] KLD > > dtnfsclient.ko: depends on oldnfs - not available or version mismatch Jul > > 9 21:58:48 r500 kernel: [8922] linker_load_file: Unsupported file type Jul > > 9 21:58:48 r500 kernel: [8922] KLD dtraceall.ko: depends on dtnfsclient - > > not available or version mismatch Jul 9 21:58:48 r500 kernel: [8922] > > linker_load_file: Unsupported file type > > > > My assumption was that your patch and the "#elif defined (NFSCLIENT)" would > > fix that, and indeed it does, but I later on realized that I actually do > > have NFSCL in the kernel: > > > > fk@r500 /usr/src $sysctl kern.conftxt | grep NFS options NFS_ROOT options > > NFSLOCKD options NFSD options NFSCL > > > > My impression is that the patch is missing an opt_nfs.h inclusion combined > > with the Makefile voodoo to create the file. > > > > The dtraceall module already has an opt_compat.h, even though the Makefile > > logic to create it seems a bit dubious to me. It blindly assumes that > > COMPAT_FREEBSD32 is available on amd64. > > Not sure if I got correctly what the (perceived) problem actually is, but I > have this to say: the proper way of building a module is either via > buildkernel (MODULES_OVERRIDE, etc) or by using KERNBUILDDIR for "independent" > module build if the module has any dependency on kernel options in effect. > This could be a little bit sad (for third-party module providers), but this > seems to be true. > > Sometimes Makefile-s fake kernel options for truly independent module build > (no KERNBUILDDIR) to provide the widest and/or safest feature set. But this > has to be done very carefully to ensure that module<->kernel*s* compatibility > actually occurs. I'm using the following modification of Sean's patch: diff --git a/sys/modules/dtrace/dtraceall/dtraceall.c b/sys/modules/dtrace/dtraceall/dtraceall.c index c57f590..d50b1e5 100644 --- a/sys/modules/dtrace/dtraceall/dtraceall.c +++ b/sys/modules/dtrace/dtraceall/dtraceall.c @@ -67,8 +67,11 @@ MODULE_DEPEND(dtraceall, opensolaris, 1, 1, 1); MODULE_DEPEND(dtraceall, dtrace, 1, 1, 1); MODULE_DEPEND(dtraceall, dtio, 1, 1, 1); MODULE_DEPEND(dtraceall, dtmalloc, 1, 1, 1); +#if defined (NFSCL) MODULE_DEPEND(dtraceall, dtnfscl, 1, 1, 1); +#elif defined (NFSCLIENT) MODULE_DEPEND(dtraceall, dtnfsclient, 1, 1, 1); +#endif #if defined(__amd64__) || defined(__i386__) MODULE_DEPEND(dtraceall, fbt, 1, 1, 1); MODULE_DEPEND(dtraceall, fasttrap, 1, 1, 1); The perceived problem is that after compiling dtraceall with "make buildkernel", installing it with "make installkernel" and rebooting, loading it results in: fk@r500 ~ $kldstat Id Refs AddressSize Name 1 73 0x8020 e492c0 kernel 21 0x8104a000 226928 zfs.ko 3 14 0x81271000 82b8 opensolaris.ko 41 0x8127a000 23a48geom_eli.ko 52 0x8129e000 34380crypto.ko 71 0x812fe000 8640 acpi_video.ko 81 0x81307000 7d00 acpi_ibm.ko 94 0x81412000 29e31usb.ko 101 0x8143c000 32ec usb_quirk.ko 111 0x8144 bded ehci.ko 121 0x8144c000 8d02 umass.ko 131 0x81455000 5c2a nullfs.ko 141 0x8145b000 51ac fdescfs.ko 151 0x81461000 beb4 i915.ko 161 0x8146d000 173ccdrm.ko 171 0x81485000 b25 dtraceall.ko 181 0x81486000 4e00 profile.ko 193 0x8148b000 4073 cyclic.ko 20 10 0x8149 23b931 dtrace.ko 211 0x816cc000 125dasystrace_freebsd32.ko 221 0x816df000 13797systrace.ko 231 0x816f3000 44be sdt.ko 241 0x816f8000 484d lockstat.ko 251 0x816fd000 bce5 fasttrap.ko 261 0x81709000 6553 fbt.ko 271 0x8171 448b dtmalloc.ko 281 0x81715000 43d9 dtio.ko Note that dtnfscl.ko is not loaded even though loading it manually works and I have NFSCL in the kernel. Fabian signature.asc Description: PGP signature
kernel ignores default route?
One of my machines is doing something I can not understand and may have uncovered some form of bug. The kernel appears to be ignoring the default route. Had several people look this over, we can't determine where the route is being hidden. This is 7.4-RELEASE-p2. I suspect that rebooting the box will clear the problem but I would REALLY like to figure out why the routing table is not being followed. I have two routers, on the same ethernet at: 148.59.4.1 (default) 148.59.4.3 & 139.171.192.26 148.59.4.2 (FreeBSD box) This is correct (see routing table below): > traceroute -n 148.59.48.1 traceroute to 148.59.48.1 (148.59.48.1), 64 hops max, 40 byte packets 1 139.171.192.26 7.366 ms 4.748 ms 6.879 ms 2 148.59.48.1 3.357 ms 5.130 ms 3.006 ms And "route" agrees: > route -n get 148.59.48.1 route to: 148.59.48.1 destination: 148.59.48.0 mask: 255.255.255.192 gateway: 148.59.4.3 interface: fxp0 flags: recvpipe sendpipe ssthresh rtt,msecrttvar hopcount mtu expire 0 0 0 0 0 0 1500 0 This is not, it should go out 148.59.4.1: > traceroute -n 148.59.80.1 traceroute to 148.59.80.1 (148.59.80.1), 64 hops max, 40 byte packets 1 139.171.192.26 6.874 ms 6.496 ms 4.288 ms 2 139.171.198.139 5.907 ms 8.251 ms 4.156 ms 3 198.22.65.217 5.246 ms 4.961 ms 4.719 ms 4 198.22.65.222 14.096 ms 4.760 ms 6.545 ms 5 148.59.80.1 5.753 ms 5.813 ms 5.952 ms "route" says it should: > route -n get 148.59.80.1 route to: 148.59.80.1 destination: default mask: default gateway: 148.59.4.1 interface: fxp0 flags: recvpipe sendpipe ssthresh rtt,msecrttvar hopcount mtu expire 0 0 0 0 0 0 1500 0 netstat -rn (minus a few 148.59.4.x machines that can be ignored) Internet: DestinationGatewayFlagsRefs Use Netif Expire default148.59.4.1 UGS 0 667619000 fxp0 10.151.89.0/24 link#1 UC 00em0 10.151.89.49 00:c0:9f:21:b2:31 UHLW1 14lo0 127.0.0.1 127.0.0.1 UH 223811lo0 148.59.4.0/27 link#2 UC 00 fxp0 148.59.4.1 00:a0:c8:2c:5f:38 UHLW2 602 fxp0 47 148.59.4.3 00:a0:c8:2c:5f:38 UHLW50 fxp0 23 148.59.4.64ff:ff:ff:ff:ff:ff UHLWb 114991em0 => 148.59.4.64/26 link#1 UC 00em0 148.59.4.6600:02:b3:e9:0e:c0 UHLW1 8098em0903 148.59.4.130 148.59.4.129 UH 0 2073 tun0 148.59.48.0/26 148.59.4.3 UG1 0 1158 fxp0 148.59.50.0/24 148.59.4.3 UG1 0 194507 fxp0 148.59.80.39 148.59.4.3 UGH100 fxp0 198.11.50.21 148.59.4.3 UGH100 fxp0 224.0.0.5 127.0.0.1 UGH100lo0 224.0.0.6 127.0.0.1 UGH100lo0 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: kernel ignores default route?
On Wed, Jul 11, 2012 at 12:31:11AM -0400, Michael R. Wayne wrote: > I have two routers, on the same ethernet at: > 148.59.4.1 (default) > 148.59.4.3 & 139.171.192.26 > 148.59.4.2 (FreeBSD box) > 148.59.4.0/27 link#2 UC 00 fxp0 > 148.59.4.1 00:a0:c8:2c:5f:38 UHLW2 602 fxp0 47 > 148.59.4.3 00:a0:c8:2c:5f:38 UHLW50 fxp0 23 Which router has MAC 00:a0:c8:2c:5f:38 (00:a0:c8 is Adtrans Inc.)? Is arp -na showing the same MAC for both routers, even though their all in the same segment? Your routing table can distinguish between next-hops .1 and .3 all you want, if ARP for both goes to the same MAC... Daniel ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: kqueue timer timeout period
On Wed, 2012-07-11 at 03:36 -0500, Harti Brandt wrote: > On Wed, 11 Jul 2012, Peter Jeremy wrote: > > PJ>On 2012-Jul-10 10:03:08 -0500, Paul Albrecht wrote: > PJ>>I have a question about the kqueue timer timeout period ... what's data > PJ>>supposed to be? I thought it was supposed to be the period in > PJ>>milliseconds, but I seem to off by one. > PJ>> > PJ>>For example, if I set date (the timeout period) to 20 milliseconds, I > PJ>>often wait 21 milliseconds which is very undesirable for my application. > PJ> > PJ>FreeBSD is not a real-time OS. The timeouts specified in various > PJ>syscalls (eg kevent(EVFILT_TIMER), nanosleep(), select(), poll()) > PJ>specify minimum timeouts. Once the timeout (rounded up to the next > PJ>tick) has expired, the process will be placed back into the queue > PJ>of processes eligible to be run by the scheduler - which may impose > PJ>a further arbitrary delay. > PJ> > PJ>Periodic timers are somewhat better behaved: Scheduler delays only > PJ>impact process scheduling after the timeout expires and the average > PJ>rate should be very close to that requested. > > While it is certainly true that FreeBSD is not a real-time OS, this does > not explain the timer problems. 2 or 3 month ago I did a simple test with > select and poll: I observed a systematic error of about 3-5% of the > waiting time. So when you wait for 20ms, you may get 21ms (if running with > a low HZ value) because of rounding. But if you wait for 100s, you get 103 > or even 105s on a completly idle machine (all services disabled). > > I think that this is not a problem with beeing non-realtime, but a problem > with time-keeping. Shouldn't it be possible to do this better? > I don't think it has anything to do with realtime either. I've been using gentoo linux to run my application using timerfd_create/read for 20 millisecond timing without any problems. > harti -- Paul Albrecht ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [[SPAM]] Re: kqueue timer timeout period
On Wed, 2012-07-11 at 04:42 -0500, Alexander Motin wrote: > Hi. > > Historically FreeBSD used completely different hardware time sources for > time keeping and time events. Not sure about 5%, but the last could be > less precise in some cases. FreeBSD 9.0, depending on hardware, can be > more precise because of using same time source in both cases. Also there > is ongoing GSoC project now by Davide Italiano to handle sub-HZ > resolution for time events. Present tests show reaching 20 microseconds > precision; and I think it can be improved further. > I'm definitely not getting getting 20 millisecond timing with freebsd kqueue which surprised me because I get it with linux linuxfd_create/read using the same hardware. -- Paul Albrecht ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
kqueue periodic timer confusion
Hi,
Sorry about this repost but I'm confused about the responses I received
in my last post so I'm looking for some clarification.
Specifically, I though I could use the kqueue timer as essentially a
"drop in" replacement for linuxfd_create/read, but was surprised that
the accuracy of the kqueue timer is much less than what I need for my
application.
So my confusion at this point is whether this is consider to be a bug or
"feature"?
Here's some test code if you want to verify the problem:
#include
#include
#include
#include
#include
#include
#include
#include
int
main(void)
{
int i,msec;
int kq,nev;
struct kevent inqueue;
struct kevent outqueue;
struct timeval start,end;
if ((kq = kqueue()) == -1) {
fprintf(stderr, "kqueue error!? errno = %s", strerror(errno));
exit(EXIT_FAILURE);
}
EV_SET(&inqueue, 1, EVFILT_TIMER, EV_ADD | EV_ENABLE, 0, 20, 0);
gettimeofday(&start, 0);
for (i = 0; i < 50; i++) {
if ((nev = kevent(kq, &inqueue, 1, &outqueue, 1, NULL)) == -1) {
fprintf(stderr, "kevent error!? errno = %s",
strerror(errno));
exit(EXIT_FAILURE);
} else if (outqueue.flags & EV_ERROR) {
fprintf(stderr, "EV_ERROR: %s\n",
strerror(outqueue.data));
exit(EXIT_FAILURE);
}
}
gettimeofday(&end, 0);
msec = ((end.tv_sec - start.tv_sec) * 1000) + (((100 + end.tv_usec
- start.tv_usec) / 1000) - 1000);
printf("msec = %d\n", msec);
close(kq);
return EXIT_SUCCESS;
}
--
Paul Albrecht
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: kqueue periodic timer confusion
On Wed, 2012-07-11 at 14:52 -0500, Paul Albrecht wrote:
> Hi,
>
> Sorry about this repost but I'm confused about the responses I received
> in my last post so I'm looking for some clarification.
>
> Specifically, I though I could use the kqueue timer as essentially a
> "drop in" replacement for linuxfd_create/read, but was surprised that
> the accuracy of the kqueue timer is much less than what I need for my
> application.
>
> So my confusion at this point is whether this is consider to be a bug or
> "feature"?
>
> Here's some test code if you want to verify the problem:
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> int
> main(void)
> {
> int i,msec;
> int kq,nev;
> struct kevent inqueue;
> struct kevent outqueue;
> struct timeval start,end;
>
> if ((kq = kqueue()) == -1) {
> fprintf(stderr, "kqueue error!? errno = %s", strerror(errno));
> exit(EXIT_FAILURE);
> }
> EV_SET(&inqueue, 1, EVFILT_TIMER, EV_ADD | EV_ENABLE, 0, 20, 0);
>
> gettimeofday(&start, 0);
> for (i = 0; i < 50; i++) {
> if ((nev = kevent(kq, &inqueue, 1, &outqueue, 1, NULL)) ==
> -1) {
> fprintf(stderr, "kevent error!? errno = %s",
> strerror(errno));
> exit(EXIT_FAILURE);
> } else if (outqueue.flags & EV_ERROR) {
> fprintf(stderr, "EV_ERROR: %s\n",
> strerror(outqueue.data));
> exit(EXIT_FAILURE);
> }
> }
> gettimeofday(&end, 0);
>
> msec = ((end.tv_sec - start.tv_sec) * 1000) + (((100 +
> end.tv_usec - start.tv_usec) / 1000) - 1000);
>
> printf("msec = %d\n", msec);
>
> close(kq);
> return EXIT_SUCCESS;
> }
>
>
What you are seeing is "just the way FreeBSD currently works."
Sleeping (in most all of its various forms, and I've just looked at the
kevent code to verify this is true there) is handled by converting the
amount of time to sleep (usually specified in a timeval or timespec
struct) to a count of timer ticks, using an internal routine called
tvtohz() in kern/kern_time.c. That routine rounds up by one tick to
account for the current tick. Whether that's a good idea or not (it
probably was once, and probably not anymore) it's how things currently
work, and could explain the fairly consistant +1ms you're seeing.
Another source of oversleeping is that the length of a tick in
microseconds is simplisticly calculated as 100 / hz on most
hardware, so for HZ=1000, tick=1000. Unless the clock producing the
tick interrupts is running at a frequency exactly divisible by 1000,
that tick-length calculation has some rounding error in it, and it
results in systematic oversleeping. On modern hardware with
high-frequency clocks it's typically less than 1%.
The routines for sleeping in the kernel take a count of ticks for how
long to sleep, so when tvtohz() converts some number of microseconds to
the corresponding number of ticks, any rounding error in the value for
the length of a tick results in oversleeping by some small percentage of
the time you wanted to sleep. Note that this rounding error in
calculating the length of a tick does not result in a systematic skew in
system timekeeping, because when each tick interrupt happens, the system
reads a clock counter register that may or may not be related to the
clock producing tick interrupts; the value in the register is full
precision without the rounding error you get when counting ticks.
It might be an interesting experiment to add kern.hz=1 to
your /boot/loader.conf and see how that affects your test.
-- Ian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: kqueue periodic timer confusion
On Wed, Jul 11, 2012 at 9:52 PM, Paul Albrecht wrote:
>
> Hi,
>
> Sorry about this repost but I'm confused about the responses I received
> in my last post so I'm looking for some clarification.
>
> Specifically, I though I could use the kqueue timer as essentially a
> "drop in" replacement for linuxfd_create/read, but was surprised that
> the accuracy of the kqueue timer is much less than what I need for my
> application.
>
> So my confusion at this point is whether this is consider to be a bug or
> "feature"?
>
> Here's some test code if you want to verify the problem:
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> int
> main(void)
> {
> int i,msec;
> int kq,nev;
> struct kevent inqueue;
> struct kevent outqueue;
> struct timeval start,end;
>
> if ((kq = kqueue()) == -1) {
> fprintf(stderr, "kqueue error!? errno = %s", strerror(errno));
> exit(EXIT_FAILURE);
> }
> EV_SET(&inqueue, 1, EVFILT_TIMER, EV_ADD | EV_ENABLE, 0, 20, 0);
>
> gettimeofday(&start, 0);
> for (i = 0; i < 50; i++) {
> if ((nev = kevent(kq, &inqueue, 1, &outqueue, 1, NULL)) ==
> -1) {
> fprintf(stderr, "kevent error!? errno = %s",
> strerror(errno));
> exit(EXIT_FAILURE);
> } else if (outqueue.flags & EV_ERROR) {
> fprintf(stderr, "EV_ERROR: %s\n",
> strerror(outqueue.data));
> exit(EXIT_FAILURE);
> }
> }
> gettimeofday(&end, 0);
>
> msec = ((end.tv_sec - start.tv_sec) * 1000) + (((100 +
> end.tv_usec - start.tv_usec) / 1000) - 1000);
>
> printf("msec = %d\n", msec);
>
> close(kq);
> return EXIT_SUCCESS;
> }
>
>
> --
> Paul Albrecht
>
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Hi.
As I told you before I'm currently working on this problem.
I wrote a testcase myself, you can find it here:
http://people.freebsd.org/~davide/kqueue/kevent_test.c
As part of my callout(9) rewriting work I've recently converted
kqueue(9) in order to exploit the precision allowed by the new backend
and exposed to consumers via the new interface
(callout_reset_bt_on()).
I ran my testcase and these are the results over 100 iterations:
http://people.freebsd.org/~davide/kqueue/kqueue_res.png
(red line-> old, green line -> new). It seems there's some
improvement, at least for now.
If you want to give it a try checkout the projects/calloutng branch
and apply the following patch
http://people.freebsd.org/~davide/kqueue/kqueue_calloutng.diff (still
in an early stage, if there are some issues, feel free to report
them).
Davide
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: dtraceall.ko with old nfsclient
On Wed, 11 Jul 2012, Fabian Keil wrote:
I'm using the following modification of Sean's patch:
diff --git a/sys/modules/dtrace/dtraceall/dtraceall.c
b/sys/modules/dtrace/dtraceall/dtraceall.c
index c57f590..d50b1e5 100644
--- a/sys/modules/dtrace/dtraceall/dtraceall.c
+++ b/sys/modules/dtrace/dtraceall/dtraceall.c
@@ -67,8 +67,11 @@ MODULE_DEPEND(dtraceall, opensolaris, 1, 1, 1);
MODULE_DEPEND(dtraceall, dtrace, 1, 1, 1);
MODULE_DEPEND(dtraceall, dtio, 1, 1, 1);
MODULE_DEPEND(dtraceall, dtmalloc, 1, 1, 1);
+#if defined (NFSCL)
MODULE_DEPEND(dtraceall, dtnfscl, 1, 1, 1);
+#elif defined (NFSCLIENT)
MODULE_DEPEND(dtraceall, dtnfsclient, 1, 1, 1);
+#endif
#if defined(__amd64__) || defined(__i386__)
MODULE_DEPEND(dtraceall, fbt, 1, 1, 1);
MODULE_DEPEND(dtraceall, fasttrap, 1, 1, 1);
The perceived problem is that after compiling dtraceall with
"make buildkernel", installing it with "make installkernel"
and rebooting, loading it results in:
fk@r500 ~ $kldstat
Id Refs AddressSize Name
1 73 0x8020 e492c0 kernel
21 0x8104a000 226928 zfs.ko
3 14 0x81271000 82b8 opensolaris.ko
41 0x8127a000 23a48geom_eli.ko
52 0x8129e000 34380crypto.ko
71 0x812fe000 8640 acpi_video.ko
81 0x81307000 7d00 acpi_ibm.ko
94 0x81412000 29e31usb.ko
101 0x8143c000 32ec usb_quirk.ko
111 0x8144 bded ehci.ko
121 0x8144c000 8d02 umass.ko
131 0x81455000 5c2a nullfs.ko
141 0x8145b000 51ac fdescfs.ko
151 0x81461000 beb4 i915.ko
161 0x8146d000 173ccdrm.ko
171 0x81485000 b25 dtraceall.ko
181 0x81486000 4e00 profile.ko
193 0x8148b000 4073 cyclic.ko
20 10 0x8149 23b931 dtrace.ko
211 0x816cc000 125dasystrace_freebsd32.ko
221 0x816df000 13797systrace.ko
231 0x816f3000 44be sdt.ko
241 0x816f8000 484d lockstat.ko
251 0x816fd000 bce5 fasttrap.ko
261 0x81709000 6553 fbt.ko
271 0x8171 448b dtmalloc.ko
281 0x81715000 43d9 dtio.ko
Note that dtnfscl.ko is not loaded even though loading
it manually works and I have NFSCL in the kernel.
This is because dtraceall.c only #includes opt_compat.h, and the kernel
build system only passes -include opt_global.h, so the dtraceall module
build has no way of knowing about the NFSCL{IENT,} options defined in
opt_nfs.h. (As you noted earlier in the thread?)
You would still need to address Andriy's comments in order to ensure that
the configuration seen by the module matches the kernel.
-Ben Kaduk
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: newbus' ivar's limitation..
Hi, On Mon, Jul 9, 2012 at 1:17 AM, Arnaud Lacombe wrote: > Hi, > > On Mon, Jul 9, 2012 at 12:37 AM, Warner Losh wrote: >> >> On Jul 8, 2012, at 9:46 PM, Arnaud Lacombe wrote: >> >>> On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh wrote: On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote: > Hi, > > On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh wrote: >> >> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote: >>> Ok, yet another Newbus' limitation. Assuming a device exports more >>> than one interface, and one of its child has need to use more than one >>> interface, each interfaces cannot register, concurrently, its own >>> ivar. While I try to always have a single child per >>> interface/resource, I need to keep some compatibility with the old way >>> of doing thing (POLA wrt. drivers I cannot/will not convert and >>> userland). So, it would have been nice if ivar had been per-interface, >>> not global and unique to one device. >> >> There's one pointer for the ivars. The bus code gets to determine what >> the ivar looks like, because the interface is totally private to the >> bus. So long as it returns the right thing for any key that's >> presented, it doesn't matter quite how things are done. >> >> So I'm not sure I understand what you are saying here. >> > dev0 implements two interfaces: A and B. dev1, child of dev0, needs to > use both interfaces. There is no generic way for dev0 to export > independent ivars for both interface. For now, I restricted the > function of the second interface not to need ivar, but that's kind of > hackish. Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here. >>> I think we should not be talking about the same API here. I have no >>> idea what you mean by "the key to value translation", nor "Ivar >>> numbers". What I refer to is that device_set_ivars() / >>> device_get_ivars() acts on a single instance variables from `struct >>> device': `ivars'. In that case, I do not really see how to set that >>> specific field to two distinct values for each interfaces. >> >> We are talking about the ivar interface. You are just misunderstanding how >> it is used. >> > yes I indeed did... silly, silly me :-) > Actually, no. I wasn't that silly, neither was I misunderstanding anything beside how *you* wanted it to be used, which is, I sorry to say, unacceptable. The last thing I want is to pollute an interface with a single-purpose, hand-crafted, bus. I was to just throw away all that ivar stuff and go into hinted child configuration for now, waiting for FDT... but of course, I figured out after a few hours that hinted child attachment requires `bus_hinted_child' to be set in the parent, as does bus_enumerate_hinted_children() / bus_generic_attach() to explicitly pollute my code. All this stuff should be done implicitly to support N:1 interfaces/client relationship. N *independent* interfaces being provided by a single driver; of course, I'm not even going back to require those interface being provided by multiple drivers, it is already a dead end. I am not even sure any driver in the tree provides more than one interface... For whatever reason, I am more and more thinking that this all new-bus[0] stuff is *way* overkill, static, bloated at will, and missing critical features; a huge PITA to use, for the intended purpose. /me pissed. - Arnaud [0]: damn, why is it even called "newbus", this stuff is 14 years old. It really belongs to a museum, not production code... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: newbus' ivar's limitation..
Hi, On Mon, Jul 9, 2012 at 11:27 AM, John Baldwin wrote: > Also, I think we should do this in general. We already have one example (e.g. > ACPI IVARs start at 100 so that things like the ACPI PCI bus driver can > provide both ACPI and PCI IVARs to child devices). I think we should assign > each bus it's own IVAR range. It would make it easier to determine if a > specific IVAR is event supported. Certainly I think ISA and PCI at a minimum > should be changed to start at, say, 200 and 300. > What's the point doing that ? Let's just resign to the conclusion that FreeBSD devices' subsystem provides no dynamic way for a client device to deals with multiple bus driver. Instead all possible combination have to be harcoded and hand-crafted, when at all possible, to look like they're coming from a single bus... But again, newbus is 14 years old... - Arnaud ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: newbus' ivar's limitation..
On Jul 11, 2012, at 9:47 PM, Arnaud Lacombe wrote: > Hi, > > On Mon, Jul 9, 2012 at 1:17 AM, Arnaud Lacombe wrote: >> Hi, >> >> On Mon, Jul 9, 2012 at 12:37 AM, Warner Losh wrote: >>> >>> On Jul 8, 2012, at 9:46 PM, Arnaud Lacombe wrote: >>> On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh wrote: > > On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote: > >> Hi, >> >> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh wrote: >>> >>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote: Ok, yet another Newbus' limitation. Assuming a device exports more than one interface, and one of its child has need to use more than one interface, each interfaces cannot register, concurrently, its own ivar. While I try to always have a single child per interface/resource, I need to keep some compatibility with the old way of doing thing (POLA wrt. drivers I cannot/will not convert and userland). So, it would have been nice if ivar had been per-interface, not global and unique to one device. >>> >>> There's one pointer for the ivars. The bus code gets to determine what >>> the ivar looks like, because the interface is totally private to the >>> bus. So long as it returns the right thing for any key that's >>> presented, it doesn't matter quite how things are done. >>> >>> So I'm not sure I understand what you are saying here. >>> >> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to >> use both interfaces. There is no generic way for dev0 to export >> independent ivars for both interface. For now, I restricted the >> function of the second interface not to need ivar, but that's kind of >> hackish. > > Only if the IVARs for interface A and interface B have overlapping > values. If the Ivar keys don't overlap, then there's no problems at all. > Certainly less hackish than not using them at all. Since dev0 knows the > layout of the ivar that it set on its child, this presents no problems at > all. It would return the values from A from the right part of the ivar, > and those from B in the right part. Apart from the coordination of Ivar > numbers, as I outlined in my last post, there's no issue here. > I think we should not be talking about the same API here. I have no idea what you mean by "the key to value translation", nor "Ivar numbers". What I refer to is that device_set_ivars() / device_get_ivars() acts on a single instance variables from `struct device': `ivars'. In that case, I do not really see how to set that specific field to two distinct values for each interfaces. >>> >>> We are talking about the ivar interface. You are just misunderstanding how >>> it is used. >>> >> yes I indeed did... silly, silly me :-) >> > Actually, no. I wasn't that silly, neither was I misunderstanding > anything beside how *you* wanted it to be used, which is, I sorry to > say, unacceptable. The last thing I want is to pollute an interface > with a single-purpose, hand-crafted, bus. I was to just throw away all > that ivar stuff and go into hinted child configuration for now, > waiting for FDT... but of course, I figured out after a few hours that > hinted child attachment requires `bus_hinted_child' to be set in the > parent, as does bus_enumerate_hinted_children() / bus_generic_attach() > to explicitly pollute my code. All this stuff should be done > implicitly to support N:1 interfaces/client relationship. N > *independent* interfaces being provided by a single driver; of course, > I'm not even going back to require those interface being provided by > multiple drivers, it is already a dead end. > > I am not even sure any driver in the tree provides more than one interface... > > For whatever reason, I am more and more thinking that this all > new-bus[0] stuff is *way* overkill, static, bloated at will, and > missing critical features; a huge PITA to use, for the intended > purpose. > > /me pissed. > > - Arnaud > > [0]: damn, why is it even called "newbus", this stuff is 14 years old. > It really belongs to a museum, not production code... I'm sorry you feel that way. Honestly, though, I think you'll be more pissed when you find out that the N:1 interface that you want is being done in the wrong domain. But I've been wrong before and look forward to seeing your replacement. acpi_pcib_acpi.c, btw, implements both PCIB interfaces and ACPI interfaces. Warner___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
