Re: fix for dhclient+aliases
On Wed, Nov 02, 2005 at 11:08:53PM -0500, Anish Mistry wrote: > On Wednesday 02 November 2005 07:12 pm, Brooks Davis wrote: > > I've got a proposed fix for dhclient interactions with IPv4 > > aliases. It turns out that my speculation that it was driver > > issues was wrong and that dhclient with reacting to the aliases > > themselves. I suspect there may be issues with some drivers, but > > that's not the main problem. > > > > This patch adds a flag which causes dhclient to ignore address > > changes that it didn't cause. Does this seem like an acceptable > > solution? I'd probably add an rc.conf variable similar to > > background_dhclient. > > > It works on my laptop's rl running CURRENT :). If deemed acceptable, > would it be possible to get this into RELENG_6_0. 6.0-RELEASE has been tagged so no. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgppQAM78YB54.pgp Description: PGP signature
Re: fix for dhclient+aliases
Speaking of dhclient and aliases. Has anyone sucessfully used the
alias { ... } syntax of dhclient.conf after switching dhclients? I
used to use the following in my dhclient.conf, but had to comment it
out when the OpenBSD dhclient was imported.
|alias {
| interface "sis1";
| fixed-address 192.168.100.2;
| option subnet-mask 255.255.255.0;
|}
I hope to check out this patch shortly. Thanks.
-James
On 11/2/05, Brooks Davis <[EMAIL PROTECTED]> wrote:
> I've got a proposed fix for dhclient interactions with IPv4 aliases. It
> turns out that my speculation that it was driver issues was wrong and
> that dhclient with reacting to the aliases themselves. I suspect there
> may be issues with some drivers, but that's not the main problem.
>
> This patch adds a flag which causes dhclient to ignore address changes
> that it didn't cause. Does this seem like an acceptable solution? I'd
> probably add an rc.conf variable similar to background_dhclient.
>
> -- Brooks
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fix for dhclient+aliases
On Wednesday 02 November 2005 07:12 pm, Brooks Davis wrote: > I've got a proposed fix for dhclient interactions with IPv4 > aliases. It turns out that my speculation that it was driver > issues was wrong and that dhclient with reacting to the aliases > themselves. I suspect there may be issues with some drivers, but > that's not the main problem. > > This patch adds a flag which causes dhclient to ignore address > changes that it didn't cause. Does this seem like an acceptable > solution? I'd probably add an rc.conf variable similar to > background_dhclient. > It works on my laptop's rl running CURRENT :). If deemed acceptable, would it be possible to get this into RELENG_6_0. Thank you for working on this issue. -- Anish Mistry pgpaJkPjVGxfU.pgp Description: PGP signature
allocating 14KB memory per packet compression/decompression results in vm_fault
dear everybody, i am trying to compress/decompress ip packets. for this i have implemented the adaptive lzw compression. i put the code in the ip_output.c and do my compression/decompression just before the if_output() function call so that i won't interfere with the ip processing of the kernel. for my compression/decompression i use string tables and temporary buffers which take about 14KB of memory per packet. I used malloc() to allocate the memory space. i made the call as below: malloc(4096,M_TEMP, M_NOWAIT); I call the malloc 3 to 4 times with 4096 bytes. and release it with call to free() I also sometimes allocate an mbuf during compression/decompression. i use the macro-- struct mbuf *m; MGET(m, M_DONTWAIT,MT_DATA); MCLGET(m,M_DONTWAIT); These are the memory operations i perform in my code. Now when i run the modified kernel the behaviour is unpredictable. The compression/decompression works fine with expected results. But soon the kernel would crash with vm_fault: message. -Is the memory requirement of 14KB per packet too high to be allocated by the kernel ?? - Are there any other techniqures to allocate memory in kernel without producing vm_faults ?? - Am I not following the correct procedures to allocate and deallocate memory in kernel space ?? - Or is the problem elsewhere ?? I am really confused and don't know what to do as this is the only thing that is holding me back to implement the compression/decompression module. I know you guys can provide some help/info. Thanks kamal - Yahoo! FareChase - Search multiple travel sites in one click. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
fix for dhclient+aliases
I've got a proposed fix for dhclient interactions with IPv4 aliases. It
turns out that my speculation that it was driver issues was wrong and
that dhclient with reacting to the aliases themselves. I suspect there
may be issues with some drivers, but that's not the main problem.
This patch adds a flag which causes dhclient to ignore address changes
that it didn't cause. Does this seem like an acceptable solution? I'd
probably add an rc.conf variable similar to background_dhclient.
-- Brooks
- Forwarded message from Brooks Davis <[EMAIL PROTECTED]> -
From: Brooks Davis <[EMAIL PROTECTED]>
Date: Wed, 2 Nov 2005 23:54:08 GMT
To: Perforce Change Reviews <[EMAIL PROTECTED]>
Subject: PERFORCE change 86258 for review
http://perforce.freebsd.org/chv.cgi?CH=86258
Change 86258 by [EMAIL PROTECTED] on 2005/11/02 23:53:14
Add a -a option to allow IPv4 aliases to be set on an interface.
Affected files ...
.. //depot/user/brooks/cleanup/sbin/dhclient/dhclient.8#6 edit
.. //depot/user/brooks/cleanup/sbin/dhclient/dhclient.c#8 edit
Differences ...
//depot/user/brooks/cleanup/sbin/dhclient/dhclient.8#6 (text+ko)
@@ -46,7 +46,7 @@
.Nd "Dynamic Host Configuration Protocol (DHCP) client"
.Sh SYNOPSIS
.Nm
-.Op Fl dqu
+.Op Fl abdqu
.Op Fl c Ar file
.Op Fl l Ar file
.Ar interface
@@ -63,6 +63,11 @@
.Pp
The options are as follows:
.Bl -tag -width ".Fl c Ar file"
+.It Fl a
+Allows IPv4 aliases to be added to the interface.
+Normally,
+.Nm
+exits if IPv4 addresses are added to or deleted from the interface.
.It Fl b
Forces
.Nm
//depot/user/brooks/cleanup/sbin/dhclient/dhclient.c#8 (text+ko)
@@ -103,6 +103,7 @@
#define TIME_MAX 2147483647
+intallow_aliases;
intlog_priority;
intno_daemon;
intunknown_ok = 1;
@@ -203,6 +204,8 @@
ifam = (struct ifa_msghdr *)rtm;
if (ifam->ifam_index != ifi->index)
break;
+ if (allow_aliases)
+ break;
if (findproto((char *)(ifam + 1), ifam->ifam_addrs) != AF_INET)
break;
if (ifi == NULL)
@@ -227,12 +230,30 @@
goto die;
case RTM_DELADDR:
ifam = (struct ifa_msghdr *)rtm;
+
if (ifam->ifam_index != ifi->index)
break;
if (findproto((char *)(ifam + 1), ifam->ifam_addrs) != AF_INET)
break;
if (scripttime == 0 || t < scripttime + 10)
break;
+
+ sa = get_ifa((char *)(ifam + 1), ifam->ifam_addrs);
+ if (sa == NULL)
+ goto die;
+
+ if ((a.len = sizeof(struct in_addr)) > sizeof(a.iabuf))
+ error("king bula sez: len mismatch");
+ memcpy(a.iabuf, &((struct sockaddr_in *)sa)->sin_addr, a.len);
+ if (addr_eq(a, defaddr))
+ break;
+
+ for (l = ifi->client->active; l != NULL; l = l->next)
+ if (addr_eq(a, l->address))
+ break;
+
+ if (l == NULL) /* deleted addr is not the one we set */
+ break;
goto die;
case RTM_IFINFO:
ifm = (struct if_msghdr *)rtm;
@@ -301,8 +322,11 @@
openlog(__progname, LOG_PID | LOG_NDELAY, DHCPD_LOG_FACILITY);
setlogmask(LOG_UPTO(LOG_INFO));
- while ((ch = getopt(argc, argv, "bc:dl:nqu")) != -1)
+ while ((ch = getopt(argc, argv, "abc:dl:nqu")) != -1)
switch (ch) {
+ case 'a':
+ allow_aliases = 1;
+ break;
case 'b':
immediate_daemon = 1;
break;
- End forwarded message -
--
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
pgpMf4SvFYMg0.pgp
Description: PGP signature
Re: locking in a device driver
In message: <[EMAIL PROTECTED]> Scott Long <[EMAIL PROTECTED]> writes: : Dinesh Nair wrote: : > : > : > On 11/03/05 03:12 Warner Losh said the following: : > : >> Yes. if you tsleep with signals enabled, the periodic timer will go : >> off, and you'll return early. This typically isn't what you want : >> either. : > : > : > looks like i've got a lot of work to do, poring thru all the ioctls for : > the device and trying to use another method to wait instead of tsleep(). : : Note that a thread can block on select/poll in 4.x and still allow other : threads to run. I used this to solve a very similar problem to your in : a 4.x app of mine. I have the app thread wait on select() on the device : node for the driver. When the driver gets to a state when an ioctl : won't block (like data being available to read), then it does the : appropriate magic in it's d_poll method. select in userland sees this, : allows the thread to resume running, and the thread then calls ioctl. : Of course you have to be careful that you don't have multiple threads : competing for the same data or that the data won't somehow disappear : before the ioctl call runs. But it does work. Look at the aac(4) : driver for my example of this. Yes. If you have the ability to know that an ioctl won't block before you call it, that would work too. This method is a little trickier, like you say, but can be made to work. I've also seen ioctls that were split into a 'foo_start' and 'foo_finish' pair (someimtes with a non-blocking foo_status) to get around this restriction... While ioctls generally cannot block, one can use these sorts of techniques to avoid blocking. I'm glad that kernel threads are here so we don't have to keep propigating these hacks... Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: locking in a device driver
On 11/03/05 05:15 Scott Long said the following: before the ioctl call runs. But it does work. Look at the aac(4) driver for my example of this. i will, it sounds like a good solution. The other option is to use rfork, aka 'linuxthreads' to similate threads i could try with linuxthreads, but some calls which are not threadsafe may be made by the userland app. -- Regards, /\_/\ "All dogs go to heaven." [EMAIL PROTECTED](0 0)http://www.alphaque.com/ +==oOO--(_)--OOo==+ | for a in past present future; do| | for b in clients employers associates relatives neighbours pets; do | | echo "The opinions here in no way reflect the opinions of my $a $b." | | done; done | +=+ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: locking in a device driver
On 11/03/05 05:17 M. Warner Losh said the following: this is to create a helper program that gets the ioctl request over a pipe or socket, does the call to the kernel and then returns the results. Not idea, I'll grant, but it is an alternative worth no, that wont work. the userland app is asterisk, a well known open source IP PBX, and i dont think keeping a different set of patches for asterisk is going to work too well. libpthread by default, others if you use libmap.conf which explains why it works on 5.x, but not on 4.x. -- Regards, /\_/\ "All dogs go to heaven." [EMAIL PROTECTED](0 0)http://www.alphaque.com/ +==oOO--(_)--OOo==+ | for a in past present future; do| | for b in clients employers associates relatives neighbours pets; do | | echo "The opinions here in no way reflect the opinions of my $a $b." | | done; done | +=+ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: locking in a device driver
In message: <[EMAIL PROTECTED]> Dinesh Nair <[EMAIL PROTECTED]> writes: : : : On 11/03/05 03:12 Warner Losh said the following: : > Yes. if you tsleep with signals enabled, the periodic timer will go : > off, and you'll return early. This typically isn't what you want : > either. : : looks like i've got a lot of work to do, poring thru all the ioctls for the : device and trying to use another method to wait instead of tsleep(). If you have to run on 4.x, that may be the case. The other way around this is to create a helper program that gets the ioctl request over a pipe or socket, does the call to the kernel and then returns the results. Not idea, I'll grant, but it is an alternative worth thinking about if the number of ioctls is large and the impact of conversion to read/write channels is big. : > works. If you use libc_r on 5, you'll see exactly this behavior. If : > you use libpthread or libthr, you won't. : : i use gcc -pthread, so it's libc_r on 4.x. what does 'gcc -pthread' link to : on 5.x ? libpthread by default, others if you use libmap.conf Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: locking in a device driver
Dinesh Nair wrote: On 11/03/05 03:12 Warner Losh said the following: Yes. if you tsleep with signals enabled, the periodic timer will go off, and you'll return early. This typically isn't what you want either. looks like i've got a lot of work to do, poring thru all the ioctls for the device and trying to use another method to wait instead of tsleep(). Note that a thread can block on select/poll in 4.x and still allow other threads to run. I used this to solve a very similar problem to your in a 4.x app of mine. I have the app thread wait on select() on the device node for the driver. When the driver gets to a state when an ioctl won't block (like data being available to read), then it does the appropriate magic in it's d_poll method. select in userland sees this, allows the thread to resume running, and the thread then calls ioctl. Of course you have to be careful that you don't have multiple threads competing for the same data or that the data won't somehow disappear before the ioctl call runs. But it does work. Look at the aac(4) driver for my example of this. The other option is to use rfork, aka 'linuxthreads' to similate threads via linked processes that share their address space. Each 'thread' is actually a process, and if one 'thread' blocks the rest are still allowed to run. It's more heavy-weight than real threads, but it does also work. works. If you use libc_r on 5, you'll see exactly this behavior. If you use libpthread or libthr, you won't. i use gcc -pthread, so it's libc_r on 4.x. what does 'gcc -pthread' link to on 5.x ? lpthread, I believe. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: locking in a device driver
On 11/03/05 04:27 M. Warner Losh said the following: that this is the case: sleep in an ioctl, and the entire process hangs until the ioctl returns. which is probably what's happening in my case. i've got 4 threads spun off, and one thread reads what the other writes and vice versa. after writing, a thread goes off into an ioctl or a read where a tsleep() is executed. this would block the reader thread as well if libc_r were to be used, as is what i am using. -- Regards, /\_/\ "All dogs go to heaven." [EMAIL PROTECTED](0 0)http://www.alphaque.com/ +==oOO--(_)--OOo==+ | for a in past present future; do| | for b in clients employers associates relatives neighbours pets; do | | echo "The opinions here in no way reflect the opinions of my $a $b." | | done; done | +=+ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: locking in a device driver
On 11/03/05 03:12 Warner Losh said the following: Yes. if you tsleep with signals enabled, the periodic timer will go off, and you'll return early. This typically isn't what you want either. looks like i've got a lot of work to do, poring thru all the ioctls for the device and trying to use another method to wait instead of tsleep(). works. If you use libc_r on 5, you'll see exactly this behavior. If you use libpthread or libthr, you won't. i use gcc -pthread, so it's libc_r on 4.x. what does 'gcc -pthread' link to on 5.x ? -- Regards, /\_/\ "All dogs go to heaven." [EMAIL PROTECTED](0 0)http://www.alphaque.com/ +==oOO--(_)--OOo==+ | for a in past present future; do| | for b in clients employers associates relatives neighbours pets; do | | echo "The opinions here in no way reflect the opinions of my $a $b." | | done; done | +=+ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: locking in a device driver
M. Warner Losh wrote: In message: <[EMAIL PROTECTED]> Julian Elischer <[EMAIL PROTECTED]> writes: : Dinesh Nair wrote: : : > : > : > On 10/28/05 10:52 M. Warner Losh said the following: : > : >> libc_r will block all other threads in the application while an ioctl : >> executes. libpthread and libthr won't. I've had several bugs at work : > : > : > so if the userland thread does an ioctl, and the the driver goes to : > tsleep() when the ioctl is received, all other threads are also : > blocked from executing, i.e wont be context switched to run ? : : in 4.x and earlier. a tsleep saves your spl level but re-enables the : interrupts (from memory) : when you re-awaken you are given your spl level again.. That's true, but irrelevant. yes I misread the question. : All other threads are allowed to run. That is not true.[*] *NO* other threads in your process run. Period. None. Zero. Nada. Zilch. Your process is hung until the ioctl returns. That's the fundamental problem with userland thread packages such as libc_r. the answer is in the misread context and should have read, "while your process is doingthe tsleep other processes can run" I missed the bit about him talking about libc_r and was thinking about only in the kernel. I've had to work around this issue many times, and I'm 100% certain that this is the case: sleep in an ioctl, and the entire process hangs until the ioctl returns. Warner [*] Other processes on the system will run, true. Interrutps will happen and run. But that's not what was being ask. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: locking in a device driver
In message: <[EMAIL PROTECTED]> Julian Elischer <[EMAIL PROTECTED]> writes: : Dinesh Nair wrote: : : > : > : > On 10/28/05 10:52 M. Warner Losh said the following: : > : >> libc_r will block all other threads in the application while an ioctl : >> executes. libpthread and libthr won't. I've had several bugs at work : > : > : > so if the userland thread does an ioctl, and the the driver goes to : > tsleep() when the ioctl is received, all other threads are also : > blocked from executing, i.e wont be context switched to run ? : : in 4.x and earlier. a tsleep saves your spl level but re-enables the : interrupts (from memory) : when you re-awaken you are given your spl level again.. That's true, but irrelevant. : All other threads are allowed to run. That is not true.[*] *NO* other threads in your process run. Period. None. Zero. Nada. Zilch. Your process is hung until the ioctl returns. That's the fundamental problem with userland thread packages such as libc_r. I've had to work around this issue many times, and I'm 100% certain that this is the case: sleep in an ioctl, and the entire process hangs until the ioctl returns. Warner [*] Other processes on the system will run, true. Interrutps will happen and run. But that's not what was being ask. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: locking in a device driver
Dinesh Nair wrote: On 10/28/05 10:52 M. Warner Losh said the following: libc_r will block all other threads in the application while an ioctl executes. libpthread and libthr won't. I've had several bugs at work so if the userland thread does an ioctl, and the the driver goes to tsleep() when the ioctl is received, all other threads are also blocked from executing, i.e wont be context switched to run ? in 4.x and earlier. a tsleep saves your spl level but re-enables the interrupts (from memory) when you re-awaken you are given your spl level again.. All other threads are allowed to run. lower level code (the interupt executed part is not allowed to ever sleep) is this behaviour only 4.x specific or is it also there in 5.x ? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: locking in a device driver
From: Dinesh Nair <[EMAIL PROTECTED]> Subject: Re: locking in a device driver Date: Thu, 03 Nov 2005 02:23:32 +0800 > > > On 10/28/05 10:52 M. Warner Losh said the following: > > libc_r will block all other threads in the application while an ioctl > > executes. libpthread and libthr won't. I've had several bugs at work > > so if the userland thread does an ioctl, and the the driver goes to > tsleep() when the ioctl is received, all other threads are also blocked > from executing, i.e wont be context switched to run ? Yes. if you tsleep with signals enabled, the periodic timer will go off, and you'll return early. This typically isn't what you want either. > is this behaviour only 4.x specific or is it also there in 5.x ? This behavior is libc_r specific. Any userland threadding library will have these issues. It is fundamental to how userland threadding works. If you use libc_r on 5, you'll see exactly this behavior. If you use libpthread or libthr, you won't. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: locking in a device driver
Dinesh Nair wrote: On 11/02/05 06:12 Julian Elischer said the following: depends on what they are using it for.. if it's a WAN interface, then splimp. (INTR_TYPE_NET) if ppp or several other moduels are loaded, teh tty and net masks are combined anyhow.. it's a quad-span E1/T1 line card which would be carrying voice PRIs. the card interrupts every 1000 times a second. I'd go for NET with data/voice convergence, it makes sense to me. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: locking in a device driver
On 10/28/05 10:52 M. Warner Losh said the following: libc_r will block all other threads in the application while an ioctl executes. libpthread and libthr won't. I've had several bugs at work so if the userland thread does an ioctl, and the the driver goes to tsleep() when the ioctl is received, all other threads are also blocked from executing, i.e wont be context switched to run ? is this behaviour only 4.x specific or is it also there in 5.x ? -- Regards, /\_/\ "All dogs go to heaven." [EMAIL PROTECTED](0 0)http://www.alphaque.com/ +==oOO--(_)--OOo==+ | for a in past present future; do| | for b in clients employers associates relatives neighbours pets; do | | echo "The opinions here in no way reflect the opinions of my $a $b." | | done; done | +=+ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
skc0: unknown media type: 0x0
Hello! After another reboot, I started getting the message in subject and thus have lost my network connection. The card used to be identified as: sk0: on skc0 [] I initially rebooted to add RAM to the machine, but have since tried to take the extra memory back out to no avail :-( Short of a sudden hardware problem, what could be the reason for this? Thanks! -mi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: queue/list macros
On Tue, 1 Nov 2005, Max Laier wrote: > All, > > inspired by: > http://marc.theaimsgroup.com/?l=openbsd-tech&m=112966325607754&w=2 > > I rolled this diff and would like to commit it. TRASHIT() is defined only > under QUEUE_MACRO_DEBUG so this should be save for all and only affect people > prepared to do debbuging. > > Any objections? Thanks for letting me know, somehow it never ocurred to me that the other BSDs could have something here. Stupid but true. TRASHIT is better that setting the fields to NULL, as I did before (this was backed out). I have posted a new diff to [EMAIL PROTECTED] some days ago. -Otto ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sysprof, interrupting threads
On Wednesday 02 November 2005 04:37 am, Viktor Vasilev wrote: > Hello fellow hackers, > > I was thinking of porting the linux sysprof kernel and userland tools > to FreeBSD. I spent some time studying the code and wrote a skeleton > driver that uses the callout mechanism to wake up periodically. That > was only to discover, that the context in which the driver awakes is > that of the software clock interrupt. > > The linux sysprof driver uses a timer hook API that was introduced in > the 2.6 kernel series. I don't have a profound understanding of the > linux kernel but it seems that the hook gets executed in the process > context that was currently executing as the tick happened. > > My question is, is there a better place to plant the code, so that it > executes periodically in the context of the current runnging thread? > I was also thinking of traversing the list of processes but I'm not > sure if I can tell which one was interrupted by the swi. > > Any suggestions are wellcome. hardclock_process() and statclock_process() (poorly named, should really be s/process/thread/ at this point). I believe kernel gprof profiling is done in statclock_process for example. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Contributing to FreeBSD list of things todo
In message: <[EMAIL PROTECTED]> Ben Siemon <[EMAIL PROTECTED]> writes: : I have a suggestion for things dev people could do to help out with : code already done. I noticed the suggestion for compiling with -Wall : enabled. Would it serve any purpose to compile the sources with -ansi : and or -pedantic as well? I am fairly new to FreeBSD so forgive me if : this has alread been addressed. -ansi and/or -pedantic would show where the gcc extensions are used. There's a lot of places in the tree where they are, so this would take a lot of work to make clean. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: silly gcc bug in RELENG_6
Brian Buchanan wrote: test.c: In function `foobar': test.c:6: error: invalid application of `sizeof' to incomplete type `test.c' Looks like someone goofed up some printf() args. yah, but it's in the gcc code itself, no FreeBSD modification. cheers simon -- Serve - BSD +++ RENT this banner advert +++ASCII Ribbon /"\ Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
sysprof, interrupting threads
Hello fellow hackers, I was thinking of porting the linux sysprof kernel and userland tools to FreeBSD. I spent some time studying the code and wrote a skeleton driver that uses the callout mechanism to wake up periodically. That was only to discover, that the context in which the driver awakes is that of the software clock interrupt. The linux sysprof driver uses a timer hook API that was introduced in the 2.6 kernel series. I don't have a profound understanding of the linux kernel but it seems that the hook gets executed in the process context that was currently executing as the tick happened. My question is, is there a better place to plant the code, so that it executes periodically in the context of the current runnging thread? I was also thinking of traversing the list of processes but I'm not sure if I can tell which one was interrupted by the swi. Any suggestions are wellcome. Best regards, Viktor -- I think and think for months and years. Ninety nine times, the conclusion is false. The hundredth time I am right. -- Albert Einstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: select(2) timeout precision
On Wed, Nov 02, 2005 at 01:31:39AM -0600, Mike Silbersack wrote: > > On Tue, 1 Nov 2005, Viktor Vasilev wrote: > > >With FreeBSD 5.4-RELEASE I almost constantly get ~2 microseconds > >delta. That is with 100HZ kernel on PIII 500MHz or Sempron 64 2800+ > > Put kern.hz=1000 in /boot/loader.conf to kick it up to 1000Hz, that > should improve the accuracy a lot. Indeed! That did the trick. > The optimizations in the url someone else posted should probably be > integrated into FreeBSD, but moving to a higher Hz setting is a > necessity in either case. I've read in the lists, that in -CURRENT 1000HZ and PREEMPTION are in the GENERIC kernel. It'll be interesting to see how it performs there. With 6.0 around the corner, I'll give it a try soon. Thank you and Mihail Balikov for the pointers. Cheers, Viktor -- I think and think for months and years. Ninety nine times, the conclusion is false. The hundredth time I am right. -- Albert Einstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [FreeBSD-Announce] New Logo
On Tuesday 01 November 2005 18:19, [EMAIL PROTECTED] wrote: > 4. I sure ain't going to wear a T-shirt with that on it. sad story - i'm too... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
