Re: sysctl with regex?
Andrew Brampton wrote: Today I was writing a script to read all the dev.cpu.?.temperature sysctl OIDs. I was parsing them using a simple grep, but it occurred to me it might be better if sysctl supported some form of regexp. For example instead of typing: sysctl -a | grep dev.cpu.*.temperature I could write: sysctl dev.cpu.*.temperature which would display all the OIDs that match dev.cpu.*.temperature. This is better than grep because when I issue a sysctl -a the program retrieves many variables that I am not interested in (which later get filtered by grep). I'm not sure such a feature is really necessary. What's wrong with this approach? $ sysctl dev.cpu | grep temperature When you need that in a script, there's an even more elegant way to do it: NCPU=`sysctl -n hw.ncpu` OIDS=`jot -w dev.cpu.%d.temperature $NCPU 0` sysctl $OIDS There's no need to use sysctl -a. After all, the UNIX way of doing things is to combine the existing tools instead of duplicate features in many tools. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Documentation is like sex; when it's good, it's very, very good, and when it's bad, it's better than nothing. -- Dick Brandon ___ 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: sysctl with regex?
Garrett Cooper yanef...@gmail.com writes:
C-shell globs as some programming languages referring to it as,
i.e. perl (which this is a subset of the globs concept) allow for
expansion via `*' to be `anything'. Regexp style globs for what you're
looking for would be either .* (greedy) or .+ (non-greedy), with it
being most likely the latter case.
Uh, not quite.
Formally, a regular expression is a textual representation of a finite
state machine that describes a context-free grammar.
A glob pattern can be trivially translated to a regular expression, but
not the other way around. Basically, * in a glob pattern corresponds to
[^/]*, ? corresponds to ., and [abcd] and [^abcd] have the same meaning
as in a regular expression. The glob pattern syntax has no equivalent
for +, ?, {m,n}, (foo|bar), etc.
Some shells implement something that resembles alternations, where
{foo,bar} corresponds to (foo|bar), but these are expanded before the
glob pattern. For instance, /tmp/{*,*} is expanded to /tmp/* /tmp/*,
which is then expanded to two complete copies of the list of files and
directories in /tmp.
There is no such thing as a regexp style glob, and I have no idea what
you mean by a subset of the globs concept or where Perl fits into the
discussion.
Finally, .* and .+ are *both* greedy. Perl's regular expression syntax
includes non-greedy variants for both (.*? and .+? respectively).
Note that the [], +, ? and {m,n} notations are merely shorthand for
expressions which can be expressed using only concatenation, alternation
and the kleene star, which are the only operations available in formal
regular expressions.
I'll see if I can whip up a quick patch in the next day or so -- but
before I do that, does it make more sense to do globs or regular
expressions? There are pluses and minuses to each version and would
require some degree of parsing (and potentially escaping).
I think you'll find that, at least in this particular case, regular
expressions are an order of magnitude harder to implement than glob
patterns.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
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: System() returning ECHILD error on FreeBSD 7.2
Naveen Gujje gujjenav...@gmail.com wrote:
signal(SIGCHLD, SigChildHandler);
void
SigChildHandler(int sig)
{
pid_t pid;
/* get status of all dead procs */
do {
int procstat;
pid = waitpid(-1, procstat, WNOHANG);
if (pid 0) {
if (errno == EINTR)
continue; /* ignore it */
else {
if (errno != ECHILD)
perror(getting waitpid);
pid = 0;/* break out */
}
}
else if (pid != 0)
syslog(LOG_INFO, child process %d completed, (int) pid);
} while (pid);
signal(SIGCHLD, SigChildHandler);
}
There are several problems with your signal handler.
First, the perror() and syslog() functions are not re-entrant,
so they should not be used inside signal handlers. This can
lead to undefined behaviour. Please refer to the sigaction(2)
manual page for a list of functions that are considered safe
to be used inside signal handlers.
Second, you are using functions that may change the value of
the global errno variable. Therefore you must save its value
at the beginning of the signal handler, and restore it at the
end.
Third (not a problem in this particular case, AFAICT, but
still good to know): Unlike SysV systems, BSD systems do
_not_ automatically reset the signal action when the handler
is called. Therefore you do not have to call signal() again
in the handler (but it shouldn't hurt either). Because of
the semantic difference of the signal() function on different
systems, it is preferable to use sigaction(2) instead in
portable code.
And, in some other part of the code, we call system() to add an ethernet
interface. This system() call is returning -1 with errno set to ECHILD,
though the passed command is executed successfully. I have noticed that,
the problem is observed only after we register SigChildHandler. If I have a
simple statement like system(ls) before and after the call to
signal(SIGCHLD, SigChildHandler), the call before setting signal handler
succeeds without errors and the call after setting signal handler returns -1
with errno set to ECHILD.
Here, I believe that within the system() call, the child exited before the
parent got a chance to call _wait4 and thus resulted in ECHILD error.
I don't think that can happen.
But, for the child to exit without notifying the parent, SIGCHLD has to be
set to SIG_IGN in the parent and this is not the case, because we are already
setting it to SigChildHandler. If I set SIGCHLD to SIG_DFL before calling
system() then i don't see this problem.
I would like to know how setting SIGCHLD to SIG_DFL or SigChildHanlder is
making the difference.
The system() function temporarily blocks SIGCHLD (i.e. it
adds the signal to the process' signal mask). However,
blocking is different from ignoring: The signal is held
as long as it is blocked, and as soon as it is removed
from the mask, it is delivered, i.e. your signal handler
is called right before the system() function returns.
And since you don't save the errno value, your signal
handler overwrites the value returned from the system()
function. So you get ECHILD.
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
What is this talk of 'release'? We do not make software 'releases'.
Our software 'escapes', leaving a bloody trail of designers and quality
assurance people in its wake.
___
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: sysctl with regex?
On Wed, Feb 10, 2010 at 12:24:57PM +0100, Dag-Erling Sm??rgrav wrote: Garrett Cooper yanef...@gmail.com writes: C-shell globs as some programming languages referring to it as, i.e. perl (which this is a subset of the globs concept) allow for expansion via `*' to be `anything'. Regexp style globs for what you're looking for would be either .* (greedy) or .+ (non-greedy), with it being most likely the latter case. Uh, not quite. Formally, a regular expression is a textual representation of a finite state machine that describes a context-free grammar. I dont think so regular expressions describe regular languages which are a strict subset of context free languages. the practical difference is that you cannot describe for example expressions with parenthesis with a regular expression while you can with a context free grammar... for more info see: http://en.wikipedia.org/wiki/Chomsky_hierarchy ___ 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: sysctl with regex?
Roman Divacky rdiva...@freebsd.org writes: Dag-Erling Smørgrav d...@des.no writes: Formally, a regular expression is a textual representation of a finite state machine that describes a context-free grammar. I dont think so regular expressions describe regular languages which are a strict subset of context free languages. The practical difference is that you cannot describe for example expressions with parenthesis with a regular expression while you can with a context free grammar... You mean nested parentheses? You're right, I didn't think of that. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: sysctl with regex?
On Wed, Feb 10, 2010 at 01:14:01PM +0100, Roman Divacky wrote: Formally, a regular expression is a textual representation of a finite state machine that describes a context-free grammar. I dont think so regular expressions describe regular languages which are a strict subset of context free languages. The sentence is still correct, strictly speaking :) Not all context-free grammars can be represented by a FSM, those that can be are the regular languages. Joerg ___ 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: our little daemon abused as symbol of the evil
KAYVEN RIESE wrote: Isn't what we are looking at here defamation of character?? Our beloved=20 Daemon is being accused of browser history stealing! Yes, an abuse. Interesting skimming the article though, if heavy on the math. Earlier, ref: From: Oliver Fromme o...@lurza.secnetix.de Message-id: 201002081220.o18ckxfl035...@lurza.secnetix.de On the bottom of this page ... http://www.freebsd.org/art.html . the text states that Marshall Kirk McKusick is the trademark holder for the BSD Daemon image. However, on another page (I don't have the URL right now) it says that Kirk owns the copyright of the daemon. I guess one of the web pages needs to be corrected, but I don't know which one. :-) I sent a send-pr cc'd Kirk Oliver so hopefully someone can correct. http://www.freebsd.org/cgi/query-pr.cgi?pr=143724 Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text not quoted-printable, HTML or Base64 http://www.asciiribbon.org ___ 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: How can I force boot from alternate drive with boot.config?
On Tuesday 09 February 2010 2:22:53 pm Peter Steele wrote: So, more precisely, if I wanted to boot from drive 1, I'd use this? 1:ad(1p3)/boot/loader Yes, unless there are more bugs hiding. :-) I fixed a few in August last year. Well, I'll give it a try and let you know if I find new bugs... :-) I just tried this and it works as advertised--thanks. One question though: Why does this string list the device number twice? The man page describes it as bios_drive:interface(unit,[slice,]part)filename where bios_drive is the drive number as recognized by the BIOS. 0 for the first drive, 1 for the second drive, etc., and unit is the unit number of the drive on the interface being used. 0 for the first drive, 1 for the second drive, etc. I think the unit number is largely ignored now. The kernel used to believe it for finding /, but the loader now reads /etc/fstab and sets a variable in kenv to tell the kernel where to find /. This sounds like it's describing the same thing, but not exactly, but I've always used the same value in both fields and it's always worked. Is there a case where these values might be different? In the test I just did I booted from the fourth drive of a four drive system using The BIOS drive number is based on however the BIOS works, and the code knows that ad and da are hard drives, so it adds 0x80 to the BIOS drive number to obtain the real BIOS drive number, but for fd it just uses the drive number as-is. 3:ad(3p4)/boot/loader I know my hardware and knew ad10 mapped to the fourth drive and would be referenced as drive 3 in this context. But how would I determine this generically? For example, given something like /dev/adN, how do I know what number I'd use for this drive in boot.config? It's not generically mappable really. It depends on any option ROMs you may have among other things. Typically if all you have is ATA device (adX), then the lowest numbered adX device would be 0, the next adX device would be 1, etc. However, if you have drives attached to multiple storage controllers then it depends on the order the controllers register their option ROMs with the BIOS. -- John Baldwin ___ 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: Strange problem with 8-stable, VMWare vSphere 4 AMD CPUs (unexpected shutdowns)
On Wed, 10 Feb 2010, Ivan Voras wrote: It looks like I've stumbled upon a bug in vSphere 4 (recent update) with FreeBSD/amd64 8.0/8-stable (but not 7.x) guests on Opteron(s). In this combination, everything works fine until a moderate load is started - a buildworld is enough. About five minutes after the load starts, the vSphere client starts getting timeouts while talking with the host and soon after the guest VM is forcibly shut down without any trace of a reason in various logs. The same VM runs fine on hosts with Xeon CPUs. The shutdown happens regardless if there is a vSphere client connected. This is very repeatable, on Sun Fire X4140 hosts. With 7.x/7.stable guests everything works fine. I'm posting this for future reference and to see if anyone has encountered something like that, or has an idea why this happens. Is it related to this thread: http://lists.freebsd.org/pipermail/freebsd-stable/2010-February/054755.html I have been fighting other issues (mainly countless Command WRITE(10) took X.XYZ seconds in the VM's vmware.log file under moderate I/O) with VMware Workstation 7 on a Linux host with an AMD Phenom(tm) II X4 945 Processor, but I still have more testing to see if I can work through it. I also do not want to take over this thread. Sean -- s...@freebsd.org ___ 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: Strange problem with 8-stable, VMWare vSphere 4 AMD CPUs (unexpected shutdowns)
on 10/02/2010 17:36 Ivan Voras said the following: It looks like I've stumbled upon a bug in vSphere 4 (recent update) with FreeBSD/amd64 8.0/8-stable (but not 7.x) guests on Opteron(s). In this combination, everything works fine until a moderate load is started - a buildworld is enough. About five minutes after the load starts, the vSphere client starts getting timeouts while talking with the host and soon after the guest VM is forcibly shut down without any trace of a reason in various logs. The same VM runs fine on hosts with Xeon CPUs. The shutdown happens regardless if there is a vSphere client connected. This is very repeatable, on Sun Fire X4140 hosts. With 7.x/7.stable guests everything works fine. I'm posting this for future reference and to see if anyone has encountered something like that, or has an idea why this happens. Wild guess - try disabling superpages in the guests. -- Andriy Gapon ___ 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: sysctl with regex?
On Wed, Feb 10, 2010 at 2:51 AM, Oliver Fromme o...@lurza.secnetix.de wrote: Andrew Brampton wrote: Today I was writing a script to read all the dev.cpu.?.temperature sysctl OIDs. I was parsing them using a simple grep, but it occurred to me it might be better if sysctl supported some form of regexp. For example instead of typing: sysctl -a | grep dev.cpu.*.temperature I could write: sysctl dev.cpu.*.temperature which would display all the OIDs that match dev.cpu.*.temperature. This is better than grep because when I issue a sysctl -a the program retrieves many variables that I am not interested in (which later get filtered by grep). I'm not sure such a feature is really necessary. What's wrong with this approach? $ sysctl dev.cpu | grep temperature When you need that in a script, there's an even more elegant way to do it: NCPU=`sysctl -n hw.ncpu` OIDS=`jot -w dev.cpu.%d.temperature $NCPU 0` sysctl $OIDS There's no need to use sysctl -a. After all, the UNIX way of doing things is to combine the existing tools instead of duplicate features in many tools. True... while I was looking at where to insert the expression matcher, I couldn't see a single *good* location where to put it because all of the APIs in sysctl(1) are print or return an OID integer without thoroughly hacking up the source (even though it is largely hacked up today from the looks of it). Ugh. -Garrett ___ 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: Strange problem with 8-stable, VMWare vSphere 4 AMD CPUs (unexpected shutdowns)
on 10/02/2010 19:05 Ivan Voras said the following: On 02/10/10 17:05, Andriy Gapon wrote: on 10/02/2010 17:36 Ivan Voras said the following: It looks like I've stumbled upon a bug in vSphere 4 (recent update) with FreeBSD/amd64 8.0/8-stable (but not 7.x) guests on Opteron(s). In this combination, everything works fine until a moderate load is started - a buildworld is enough. About five minutes after the load starts, the vSphere client starts getting timeouts while talking with the host and soon after the guest VM is forcibly shut down without any trace of a reason in various logs. The same VM runs fine on hosts with Xeon CPUs. The shutdown happens regardless if there is a vSphere client connected. This is very repeatable, on Sun Fire X4140 hosts. With 7.x/7.stable guests everything works fine. I'm posting this for future reference and to see if anyone has encountered something like that, or has an idea why this happens. Wild guess - try disabling superpages in the guests. It looks like your guess is perfectly correct :) The guest has been doing buildworlds for an hour and it works fine. Thanks! It's strange how this doesn't affect the Xeons... I really can not tell more but there seems to be an issue between our implementation of superpages (very unique) and AMD processors from 10h family. I'd recommend not using superpages feature with those processors for time being. -- Andriy Gapon ___ 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: sysctl with regex?
2010/2/10 Dag-Erling Smørgrav d...@des.no:
Garrett Cooper yanef...@gmail.com writes:
C-shell globs as some programming languages referring to it as,
i.e. perl (which this is a subset of the globs concept) allow for
expansion via `*' to be `anything'. Regexp style globs for what you're
looking for would be either .* (greedy) or .+ (non-greedy), with it
being most likely the latter case.
Uh, not quite.
Formally, a regular expression is a textual representation of a finite
state machine that describes a context-free grammar.
A glob pattern can be trivially translated to a regular expression, but
not the other way around. Basically, * in a glob pattern corresponds to
[^/]*, ? corresponds to ., and [abcd] and [^abcd] have the same meaning
The former is a positive assertion, where the latter is a negative
assertion -- how can they have the same meaning?
as in a regular expression. The glob pattern syntax has no equivalent
for +, ?, {m,n}, (foo|bar), etc.
+, {}, and () -- no... that's typically an extension to shell expanded
values (IIRC). ? however, is a supported glob quantifier [from
glob(3)]:
The argument pattern is a pointer to a pathname pattern to be expanded.
The glob() argument matches all accessible pathnames against the pattern
and creates a list of the pathnames that match. In order to have access
to a pathname, glob() requires search permission on every component of a
path except the last and read permission on each directory of any file-
name component of pattern that contains any of the special characters
`*', `?' or `['.
Some shells implement something that resembles alternations, where
{foo,bar} corresponds to (foo|bar), but these are expanded before the
glob pattern. For instance, /tmp/{*,*} is expanded to /tmp/* /tmp/*,
which is then expanded to two complete copies of the list of files and
directories in /tmp.
There is no such thing as a regexp style glob, and I have no idea what
you mean by a subset of the globs concept or where Perl fits into the
discussion.
This is what I'm referring to:
http://perldoc.perl.org/functions/glob.html . Semantically I was wrong
in areas in my original statement, but I was trying to hand wave from
a basic `I don't know how globs vs regexps work', without the
technical lexigram discussion.
Finally, .* and .+ are *both* greedy. Perl's regular expression syntax
includes non-greedy variants for both (.*? and .+? respectively).
Yes, but I didn't explicitly note those forms.
Note that the [], +, ? and {m,n} notations are merely shorthand for
expressions which can be expressed using only concatenation, alternation
and the kleene star, which are the only operations available in formal
regular expressions.
I'll see if I can whip up a quick patch in the next day or so -- but
before I do that, does it make more sense to do globs or regular
expressions? There are pluses and minuses to each version and would
require some degree of parsing (and potentially escaping).
I think you'll find that, at least in this particular case, regular
expressions are an order of magnitude harder to implement than glob
patterns.
Yes... I wholeheartedly agree...
Thanks :),
-Garrett
___
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: System() returning ECHILD error on FreeBSD 7.2
Naveen Gujje gujjenaveen at gmail.com
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers wrote:
signal(SIGCHLD, SigChildHandler);
void
SigChildHandler(int sig)
{
pid_t pid;
/* get status of all dead procs */
do {
int procstat;
pid = waitpid(-1, procstat, WNOHANG);
if (pid 0) {
if (errno == EINTR)
continue; /* ignore it */
else {
if (errno != ECHILD)
perror(getting waitpid);
pid = 0;/* break out */
}
}
else if (pid != 0)
syslog(LOG_INFO, child process %d completed, (int) pid);
} while (pid);
signal(SIGCHLD, SigChildHandler);
}
There are several problems with your signal handler.
First, the perror() and syslog() functions are not re-entrant,
so they should not be used inside signal handlers. This can
lead to undefined behaviour. Please refer to the sigaction(2)
manual page for a list of functions that are considered safe
to be used inside signal handlers.
Second, you are using functions that may change the value of
the global errno variable. Therefore you must save its value
at the beginning of the signal handler, and restore it at the
end.
Third (not a problem in this particular case, AFAICT, but
still good to know): Unlike SysV systems, BSD systems do
_not_ automatically reset the signal action when the handler
is called. Therefore you do not have to call signal() again
in the handler (but it shouldn't hurt either). Because of
the semantic difference of the signal() function on different
systems, it is preferable to use sigaction(2) instead in
portable code.
Okay, I followed your suggestion and changed my SigChildHandler to
void
SigChildHandler(int sig)
{
pid_t pid;
int status;
int saved_errno = errno;
while (((pid = waitpid( (pid_t) -1, status, WNOHANG)) 0) ||
((-1 == pid) (EINTR == errno)))
;
errno = saved_errno;
}
and used sigaction(2) to register this handler. Still, system(3) returns
-1 with errno set to ECHILD.
And, in some other part of the code, we call system() to add an ethernet
interface. This system() call is returning -1 with errno set to ECHILD,
though the passed command is executed successfully. I have noticed that,
the problem is observed only after we register SigChildHandler. If I have a
simple statement like system(ls) before and after the call to
signal(SIGCHLD, SigChildHandler), the call before setting signal handler
succeeds without errors and the call after setting signal handler returns -1
with errno set to ECHILD.
Here, I believe that within the system() call, the child exited before the
parent got a chance to call _wait4 and thus resulted in ECHILD error.
I don't think that can happen.
But, for the child to exit without notifying the parent, SIGCHLD has to be
set to SIG_IGN in the parent and this is not the case, because we
are already
setting it to SigChildHandler. If I set SIGCHLD to SIG_DFL before calling
system() then i don't see this problem.
I would like to know how setting SIGCHLD to SIG_DFL or SigChildHanlder is
making the difference.
The system() function temporarily blocks SIGCHLD (i.e. it
adds the signal to the process' signal mask). However,
blocking is different from ignoring: The signal is held
as long as it is blocked, and as soon as it is removed
from the mask, it is delivered, i.e. your signal handler
is called right before the system() function returns.
Yes, I agree with you. Here, I believe, the point in blocking SIGCHLD
is to give preference to wait4() of system() over any other waitXXX() in
parent process. But I still cant get the reason for wait4() to return -1.
And since you don't save the errno value, your signal
handler overwrites the value returned from the system()
function. So you get ECHILD.
I had a debug print just after wait4() in system() and before we unblock
SIGCHLD. And it's clear that wait4() is returning -1 with errno as ECHILD.
Best regards
Oliver
--
___
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: System() returning ECHILD error on FreeBSD 7.2
On Wed, Feb 10, 2010 at 9:25 AM, Naveen Gujje gujjenav...@gmail.com wrote:
Naveen Gujje gujjenaveen at gmail.com
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers wrote:
signal(SIGCHLD, SigChildHandler);
void
SigChildHandler(int sig)
{
pid_t pid;
/* get status of all dead procs */
do {
int procstat;
pid = waitpid(-1, procstat, WNOHANG);
if (pid 0) {
if (errno == EINTR)
continue; /* ignore it */
else {
if (errno != ECHILD)
perror(getting waitpid);
pid = 0; /* break out */
}
}
else if (pid != 0)
syslog(LOG_INFO, child process %d completed, (int) pid);
} while (pid);
signal(SIGCHLD, SigChildHandler);
}
There are several problems with your signal handler.
First, the perror() and syslog() functions are not re-entrant,
so they should not be used inside signal handlers. This can
lead to undefined behaviour. Please refer to the sigaction(2)
manual page for a list of functions that are considered safe
to be used inside signal handlers.
Second, you are using functions that may change the value of
the global errno variable. Therefore you must save its value
at the beginning of the signal handler, and restore it at the
end.
Third (not a problem in this particular case, AFAICT, but
still good to know): Unlike SysV systems, BSD systems do
_not_ automatically reset the signal action when the handler
is called. Therefore you do not have to call signal() again
in the handler (but it shouldn't hurt either). Because of
the semantic difference of the signal() function on different
systems, it is preferable to use sigaction(2) instead in
portable code.
Okay, I followed your suggestion and changed my SigChildHandler to
void
SigChildHandler(int sig)
{
pid_t pid;
int status;
int saved_errno = errno;
while (((pid = waitpid( (pid_t) -1, status, WNOHANG)) 0) ||
((-1 == pid) (EINTR == errno)))
;
errno = saved_errno;
}
and used sigaction(2) to register this handler. Still, system(3) returns
-1 with errno set to ECHILD.
And, in some other part of the code, we call system() to add an ethernet
interface. This system() call is returning -1 with errno set to ECHILD,
though the passed command is executed successfully. I have noticed that,
the problem is observed only after we register SigChildHandler. If I have
a
simple statement like system(ls) before and after the call to
signal(SIGCHLD, SigChildHandler), the call before setting signal handler
succeeds without errors and the call after setting signal handler returns
-1
with errno set to ECHILD.
Here, I believe that within the system() call, the child exited before the
parent got a chance to call _wait4 and thus resulted in ECHILD error.
I don't think that can happen.
But, for the child to exit without notifying the parent, SIGCHLD has to be
set to SIG_IGN in the parent and this is not the case, because we
are already
setting it to SigChildHandler. If I set SIGCHLD to SIG_DFL before calling
system() then i don't see this problem.
I would like to know how setting SIGCHLD to SIG_DFL or SigChildHanlder is
making the difference.
The system() function temporarily blocks SIGCHLD (i.e. it
adds the signal to the process' signal mask). However,
blocking is different from ignoring: The signal is held
as long as it is blocked, and as soon as it is removed
from the mask, it is delivered, i.e. your signal handler
is called right before the system() function returns.
Yes, I agree with you. Here, I believe, the point in blocking SIGCHLD
is to give preference to wait4() of system() over any other waitXXX() in
parent process. But I still cant get the reason for wait4() to return -1.
And since you don't save the errno value, your signal
handler overwrites the value returned from the system()
function. So you get ECHILD.
I had a debug print just after wait4() in system() and before we unblock
SIGCHLD. And it's clear that wait4() is returning -1 with errno as ECHILD.
Isn't this section of the system(3) libcall essentially doing what
you want, s.t. you'll never be able to get the process status when you
call waitpid(2)?
do {
pid = _wait4(savedpid, pstat, 0, (struct rusage *)0);
} while (pid == -1 errno == EINTR);
break;
You typically get status via wait*(2) when using exec*(2) or via
the return codes from system(3), not system(3) with wait*(2)...
Thanks,
-Garrett
___
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: System() returning ECHILD error on FreeBSD 7.2
on 10/02/2010 19:52 Garrett Cooper said the following:
Isn't this section of the system(3) libcall essentially doing what
you want, s.t. you'll never be able to get the process status when you
call waitpid(2)?
do {
pid = _wait4(savedpid, pstat, 0, (struct rusage *)0);
} while (pid == -1 errno == EINTR);
break;
You typically get status via wait*(2) when using exec*(2) or via
the return codes from system(3), not system(3) with wait*(2)...
Exactly. I think that SIGCHLD handler would effectively 'reap' the child and
thus
wait*() in system would rightfully return ECHILD (perhaps after doing EINTR
iteration of the loop).
--
Andriy Gapon
___
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: Strange problem with 8-stable, VMWare vSphere 4 AMD CPUs (unexpected shutdowns)
On 10 February 2010 18:13, Andriy Gapon a...@icyb.net.ua wrote: on 10/02/2010 19:05 Ivan Voras said the following: On 02/10/10 17:05, Andriy Gapon wrote: Wild guess - try disabling superpages in the guests. It looks like your guess is perfectly correct :) The guest has been doing buildworlds for an hour and it works fine. Thanks! It's strange how this doesn't affect the Xeons... I really can not tell more but there seems to be an issue between our implementation of superpages (very unique) and AMD processors from 10h family. I'd recommend not using superpages feature with those processors for time being. When you say very unique is it in the it is not Linux or Windows sense or do we do something nonstandard? ___ 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
NFS write corruption on 8.0-RELEASE
Hi! I think I've reported that before, the I thought it's been fixed, however I still get data corruptions when writing on NFS volumes. Now I wonder - is nobody really using NFS, or do I have that much of uncommon setup, or this is some kind of local problem? Client: 8.0-RELEASE i386 Server: 8.0-RELEASE amd64 mount options: nfs rw,nosuid,noexec,nfsv3,intr,soft,tcp,bg,nolockd Server has ZFS, but the same thing happens when sharing UFS placed on md(4). I've prepared a special 1GB file to determine the details of corruption: it's filled with 32-bit numbers each equal to it's own offset in the file. That is, like that: 00 00 00 00 04 00 00 00 08 00 00 00 0c 00 00 00 || 0010 10 00 00 00 14 00 00 00 18 00 00 00 1c 00 00 00 || 0020 20 00 00 00 24 00 00 00 28 00 00 00 2c 00 00 00 | ...$...(...,...| 0030 30 00 00 00 34 00 00 00 38 00 00 00 3c 00 00 00 |0...4...8..| I've copied that file over NFS from client to server around 50 times, and got 3 corruptions on 8th, 28th and 36th copies. Case1: single currupted block 3779CF88-3779 (12408 bytes). Data in block is shifted 68 bytes up, loosing first 68 bytes are filling last 68 bytes with garbage. Interestingly, among that garbage is my hostname. Case2: single currupted block 2615CFA0-2615 (12384 bytes). Data is shifted by 44 bytes in the same way. Case3: single currepted block 3AA947A8-3AA97FFF (14424 bytes). Data is shifted by 36 bytes in the same way. Any ideas? PS. Diffs of corrupted blocks in a text format are here: http://people.freebsd.org/~amdmi3/diff.1.txt http://people.freebsd.org/~amdmi3/diff.2.txt http://people.freebsd.org/~amdmi3/diff.3.txt -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ 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: Strange problem with 8-stable, VMWare vSphere 4 AMD CPUs (unexpected shutdowns)
on 10/02/2010 20:03 Ivan Voras said the following: When you say very unique is it in the it is not Linux or Windows sense or do we do something nonstandard? The former - neither Linux, Windows or OpenSolaris seem to have what we have. So we might be the first testers for certain processor features. We don't do anything that strays from specifications. -- Andriy Gapon ___ 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: Strange problem with 8-stable, VMWare vSphere 4 AMD CPUs (unexpected shutdowns)
On 10 February 2010 19:10, Andriy Gapon a...@icyb.net.ua wrote: on 10/02/2010 20:03 Ivan Voras said the following: When you say very unique is it in the it is not Linux or Windows sense or do we do something nonstandard? The former - neither Linux, Windows or OpenSolaris seem to have what we have. I can't find the exact documents but I think both Windows MegaUltimateServer (the highest priced version of Windows Server, whatever it's called today) and Linux (though disabled and marked Experimental) have it, or have some kind of support for large pages that might not be as pervasive (maybe they use it for kernel only?). I have no idea about (Open)Solaris. ___ 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: Strange problem with 8-stable, VMWare vSphere 4 AMD CPUs (unexpected shutdowns)
On 10 February 2010 19:26, Ivan Voras ivo...@freebsd.org wrote: On 10 February 2010 19:10, Andriy Gapon a...@icyb.net.ua wrote: on 10/02/2010 20:03 Ivan Voras said the following: When you say very unique is it in the it is not Linux or Windows sense or do we do something nonstandard? The former - neither Linux, Windows or OpenSolaris seem to have what we have. I can't find the exact documents but I think both Windows MegaUltimateServer (the highest priced version of Windows Server, whatever it's called today) and Linux (though disabled and marked Experimental) have it, or have some kind of support for large pages that might not be as pervasive (maybe they use it for kernel only?). I have no idea about (Open)Solaris. VMWare documentation about large pages: http://www.vmware.com/files/pdf/large_pg_performance.pdf I think I remember reading that on Windows, the application must use a special syscall to allocate an area with large pages, but I can't find the document. ___ 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: Strange problem with 8-stable, VMWare vSphere 4 AMD CPUs (unexpected shutdowns)
on 10/02/2010 20:26 Ivan Voras said the following: On 10 February 2010 19:10, Andriy Gapon a...@icyb.net.ua wrote: on 10/02/2010 20:03 Ivan Voras said the following: When you say very unique is it in the it is not Linux or Windows sense or do we do something nonstandard? The former - neither Linux, Windows or OpenSolaris seem to have what we have. I can't find the exact documents but I think both Windows MegaUltimateServer (the highest priced version of Windows Server, whatever it's called today) and Linux (though disabled and marked Experimental) have it, or have some kind of support for large pages that might not be as pervasive (maybe they use it for kernel only?). I have no idea about (Open)Solaris. I haven't said that those OSes do not use large pages. I've said what I've said :-) -- Andriy Gapon ___ 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: Strange problem with 8-stable, VMWare vSphere 4 AMD CPUs (unexpected shutdowns)
On 10 February 2010 19:35, Andriy Gapon a...@icyb.net.ua wrote: on 10/02/2010 20:26 Ivan Voras said the following: On 10 February 2010 19:10, Andriy Gapon a...@icyb.net.ua wrote: on 10/02/2010 20:03 Ivan Voras said the following: When you say very unique is it in the it is not Linux or Windows sense or do we do something nonstandard? The former - neither Linux, Windows or OpenSolaris seem to have what we have. I can't find the exact documents but I think both Windows MegaUltimateServer (the highest priced version of Windows Server, whatever it's called today) and Linux (though disabled and marked Experimental) have it, or have some kind of support for large pages that might not be as pervasive (maybe they use it for kernel only?). I have no idea about (Open)Solaris. I haven't said that those OSes do not use large pages. I've said what I've said :-) Ok :) Is there a difference between large pages as they are commonly known and superpages as in FreeBSD ? In other words - are you referencing some specific mechanism, like automatic promotion / demotion of the large pages or maybe something else? ___ 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: sysctl with regex?
Garrett Cooper yanef...@gmail.com writes:
Dag-Erling Smørgrav d...@des.no writes:
A glob pattern can be trivially translated to a regular expression, but
not the other way around. Basically, * in a glob pattern corresponds to
[^/]*, ? corresponds to ., and [abcd] and [^abcd] have the same meaning
The former is a positive assertion, where the latter is a negative
assertion -- how can they have the same meaning?
Read the entire sentence. BTW, neither of these are assertions, and
neither of these is negative in any sense, they are just different ways
of selecting characters from the alphabet (in the extended sense).
as in a regular expression. The glob pattern syntax has no equivalent
for +, ?, {m,n}, (foo|bar), etc.
+, {}, and () -- no... that's typically an extension to shell expanded
values (IIRC). ?
I can't make sense of this - I'm not sure whether you misunderstood what
I wrote, or just failed to express yourself clearly...
Finally, .* and .+ are *both* greedy. Perl's regular expression syntax
includes non-greedy variants for both (.*? and .+? respectively).
Yes, but I didn't explicitly note those forms.
No, but you claimed that .+ is not non-greedy, which is incorrect.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
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: System() returning ECHILD error on FreeBSD 7.2
On Wed, Feb 10, 2010 at 11:28 PM, Andriy Gapon a...@icyb.net.ua wrote:
on 10/02/2010 19:52 Garrett Cooper said the following:
Isn't this section of the system(3) libcall essentially doing what
you want, s.t. you'll never be able to get the process status when you
call waitpid(2)?
do {
pid = _wait4(savedpid, pstat, 0, (struct rusage *)0);
} while (pid == -1 errno == EINTR);
break;
You typically get status via wait*(2) when using exec*(2) or via
the return codes from system(3), not system(3) with wait*(2)...
Exactly. I think that SIGCHLD handler would effectively 'reap' the child
and thus
wait*() in system would rightfully return ECHILD (perhaps after doing EINTR
iteration of the loop).
Since we block SIGCHLD signal in system(3) till we return from wait4(), i
think there
is no way in which SIGCHLD handler gets invoked? Am I correct or Am I
missing something?
If I do the following then I don't see any problem
oldsa = signal(SIGCHLD, SIG_DFL);
if (0 != system(command))
exit(1);
signal(SIGCHLD, oldsa);
Thanks,
Naveen Gujje
--
Andriy Gapon
___
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: NFS write corruption on 8.0-RELEASE
Dmitry Marakasov amd...@amdmi3.ru wrote: I think I've reported that before, the I thought it's been fixed, however I still get data corruptions when writing on NFS volumes. Now I wonder - is nobody really using NFS, or do I have that much of uncommon setup, or this is some kind of local problem? NFS works fine for me. I'm using -stable, not -release, though. Client: 8.0-RELEASE i386 Server: 8.0-RELEASE amd64 mount options: nfs rw,nosuid,noexec,nfsv3,intr,soft,tcp,bg,nolockd I recommend not using the soft option. This is an excerpt from Solaris' mount_nfs(1M) manpage: File systems that are mounted read-write or that con- tain executable files should always be mounted with the hard option. Applications using soft mounted file systems may incur unexpected I/O errors, file corrup- tion, and unexpected program core dumps. The soft option is not recommended. FreeBSD's manual page doesn't contain such a warning, but maybe it should. (It contains a warning not to use soft with NFSv4, though, for different reasons.) Also note that the nolockd option means that processes on different clients won't see each other's locks. That means that you will get corruption if they rely on locking. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Perl will consistently give you what you want, unless what you want is consistency. -- Larry Wall ___ 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: System() returning ECHILD error on FreeBSD 7.2
On Wed, Feb 10, 2010 at 12:44:57PM +0530, Naveen Gujje wrote: [SIGCHLD handler that calls waitpid()] And, in some other part of the code, we call system() to add an ethernet interface. This system() call is returning -1 with errno set to ECHILD, though the passed command is executed successfully. I have noticed that, the problem is observed only after we register SigChildHandler. If I have a simple statement like system(ls) before and after the call to signal(SIGCHLD, SigChildHandler), the call before setting signal handler succeeds without errors and the call after setting signal handler returns -1 with errno set to ECHILD. Here, I believe that within the system() call, the child exited before the parent got a chance to call _wait4 and thus resulted in ECHILD error. But, for the child to exit without notifying the parent, SIGCHLD has to be set to SIG_IGN in the parent and this is not the case, because we are already setting it to SigChildHandler. If I set SIGCHLD to SIG_DFL before calling system() then i don't see this problem. I would like to know how setting SIGCHLD to SIG_DFL or SigChildHanlder is making the difference. I think your process is multi-threaded. In a single-threaded process, system()'s signal masking will ensure it will reap the zombie, leaving the signal handler with nothing (in fact, as of FreeBSD 7.0 it will not be called at all unless there are other child processes). In a multi-threaded process, each thread has its own signal mask and system() can only affect its own thread's signal mask. If another thread has SIGCHLD unblocked, the signal handler will race with system() trying to call waitpid() first. Possible fixes are using siginfo_t information to only waitpid() child processes you know about, setting up the signal masks so the bad situation does not occur (note that the signal mask is inherited across pthread_create()) and calling fork/execve and managing the child process exit yourself. Note that POSIX does not require system() to be thread-safe. -- Jilles Tjoelker ___ 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: sysctl with regex?
On Feb 10, 2010, at 10:42 AM, Dag-Erling Smørgrav wrote:
Garrett Cooper yanef...@gmail.com writes:
Dag-Erling Smørgrav d...@des.no writes:
A glob pattern can be trivially translated to a regular expression, but
not the other way around. Basically, * in a glob pattern corresponds to
[^/]*, ? corresponds to ., and [abcd] and [^abcd] have the same meaning
The former is a positive assertion, where the latter is a negative
assertion -- how can they have the same meaning?
Read the entire sentence. BTW, neither of these are assertions, and
neither of these is negative in any sense, they are just different ways
of selecting characters from the alphabet (in the extended sense).
Yes, I mentally omitted the second half because of the sentence construction.
Sorry .
as in a regular expression. The glob pattern syntax has no equivalent
for +, ?, {m,n}, (foo|bar), etc.
+, {}, and () -- no... that's typically an extension to shell expanded
values (IIRC). ?
I can't make sense of this - I'm not sure whether you misunderstood what
I wrote, or just failed to express yourself clearly...
Ok -- redo: +, {} and () aren't typical shell glob operators. They're typically
extensions in certain shells (bash for instance).
Finally, .* and .+ are *both* greedy. Perl's regular expression syntax
includes non-greedy variants for both (.*? and .+? respectively).
Yes, but I didn't explicitly note those forms.
No, but you claimed that .+ is not non-greedy, which is incorrect.
Yes. My previous understanding was incorrect. Thanks for the clarification :).
Cheers,
-Garrett___
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
KLD hello.ko: depends on kernel - not available or version mismatch
Hello Hackers, I am working on learning to write FreeBSD drivers; however, I have some practice writing IOKit drivers for MacOSX (they are entirely different I know!). The code I am working with can be found here: http://pastebin.com/m2bbb393c and I am getting the error: dontpanic# kldload ./hello.ko kldload: can't load ./hello.ko: Exec format error dmesg reads: dontpanic# kldload ./hello.ko kldload: can't load ./hello.ko: Exec format error and finally uname -a: FreeBSD dontpanic.union.edu 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r198859: Wed Feb 10 09:59:54 EST 2010 ja...@dontpanic.union.edu:/usr/obj/usr/src_klog/sys/DONTPANIC amd64 any information pointing me to being able to load this driver would be greatly appreciated. respectfully, james toy ___ 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: KLD hello.ko: depends on kernel - not available or version mismatch
On 11.02.2010 5:25, james toy wrote: any information pointing me to being able to load this driver would be greatly appreciated. Probably you have source code with different __FreeBSD_version. Check output of these commands: grep __FreeBSD_version /usr/src/sys/param.h sysctl kern.osreldate -- WBR, Andrey V. Elsukov ___ 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: How can I force boot from alternate drive with boot.config?
John Baldwin wrote: I think the unit number is largely ignored now. The kernel used to believe it for finding /, but the loader now reads /etc/fstab and sets a variable in kenv to tell the kernel where to find /. One of the most annoying improvements for the decade from my perspective.. because if / is not going to be where the loader thinks / is (because that is a different F with a different /etc/fstab) then you need to do lots of fancy footwork to undo the damage. Oh and it's not terribly well documented how to get around it. (that I've found) ___ 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: KLD hello.ko: depends on kernel - not available or version mismatch
james toy wrote: Hello Hackers, I am working on learning to write FreeBSD drivers; however, I have some practice writing IOKit drivers for MacOSX (they are entirely different I know!). The code I am working with can be found here: http://pastebin.com/m2bbb393c and I am getting the error: dontpanic# kldload ./hello.ko kldload: can't load ./hello.ko: Exec format error dmesg reads: dontpanic# kldload ./hello.ko kldload: can't load ./hello.ko: Exec format error and finally uname -a: FreeBSD dontpanic.union.edu 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r198859: Wed Feb 10 09:59:54 EST 2010 ja...@dontpanic.union.edu:/usr/obj/usr/src_klog/sys/DONTPANIC amd64 any information pointing me to being able to load this driver would be greatly appreciated. That error is a sort of catch-all. But the kernel linker should put some more specific information out in the kernel console/dmseg. so 'dmesg' may help you if you have something like a bad symbol. respectfully, james toy ___ 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 ___ 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
