Re: kqueue timer timeout period

2012-07-11 Thread Peter Jeremy
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

Re: kqueue timer timeout period

2012-07-11 Thread Harti Brandt
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 ex

Re: kqueue timer timeout period

2012-07-11 Thread Alexander Motin
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 i

Re: dtraceall.ko with old nfsclient

2012-07-11 Thread Fabian Keil
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 ; USE

kernel ignores default route?

2012-07-11 Thread Michael R. Wayne
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

Re: kernel ignores default route?

2012-07-11 Thread Daniel Hartmeier
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:5

Re: kqueue timer timeout period

2012-07-11 Thread Paul Albrecht
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 peri

Re: [[SPAM]] Re: kqueue timer timeout period

2012-07-11 Thread Paul Albrecht
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 p

kqueue periodic timer confusion

2012-07-11 Thread Paul Albrecht
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

Re: kqueue periodic timer confusion

2012-07-11 Thread Ian Lepore
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 l

Re: kqueue periodic timer confusion

2012-07-11 Thread Davide Italiano
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 li

Re: dtraceall.ko with old nfsclient

2012-07-11 Thread Benjamin Kaduk
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/d

Re: newbus' ivar's limitation..

2012-07-11 Thread Arnaud Lacombe
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:

Re: newbus' ivar's limitation..

2012-07-11 Thread Arnaud Lacombe
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

Re: newbus' ivar's limitation..

2012-07-11 Thread Warner Losh
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