Problem with kernel mod compilation
Hi everyone, I'm currently developing a kernel module for a Gig. Ethernet card and I've run into problems with my file tree and the kernel mkdep mechanism. I have two files in my source directory which I've created under /usr/src/sys/dev/yk yk being my driver I've updated /usr/src/sys/conf/files (since I want this beast to work under all architectures) and I've created a copy of GENERIC, called YK, with my device yk as an option. Now, the problem is that I have a number of files in a header subdirectory under /dev/yk which I have to include. I cannot modify these header files, since they're company-wide include files which get included by just about everybody. They're only changed if ABSOLUTELY necessary. My subtree looks like this: ../dev/yk/if_yk.c ../dev/yk/if_yk.h ../dev/yk/h/headerfile1.h ../dev/yk/common/h/headerfile2.h These additional header files get included by if_yk.h (which gets included by if_yk.c) When I do a make depend, it says it can't find h/headerfile1.h etc etc. I need to pass a -I flag to mkdep, but I have no idea how to do this ie. what files to modify. Can anyone help, please? Cheers, Gerald -- S y s K o n n e c t G m b H A Marvell Company Siemensstr. 23 D-76275 Ettlingen, Germany - Gerald Heinig Software Engineer - phone: + 49 (0) 7243 502 354 fax:+49 (0) 7243 502 364 email: [EMAIL PROTECTED] http://www.syskonnect.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD lacks PPPoE (pppoa3 solution)
On 10/07/2003 21:45, Nuno Teixeira wrote: > > Hi, > > Please see http://speedtouch.sourceforge.net/index.php?/news.en.html > > "Real" PPPoE with a ethernet card connected with a ADSL Modem works. > > This problem is related with ISPs that supports *only* PPPoE protocol > with USB Modems (this case Alcatel) that "emulates" ethernet with > TUN/TAP devices. USB modems don't have a connection to ethernet cards. > > FreeBSD pppoa port works ok with Alcatel USB Modems but only for PPPoA > protocols and not PPPoE. > > Almost all europe ISPs only support PPPoE and not PPPoA (I don't know > the reason why). Except in the UK where it seems to be the other way around (for DSL services at least) - incidently do you know that it is impossible to use another modem with your ISP ? I had an Alcatel SpeedTouch USB and I ditched in favour of an Alcatel SpeedTouch Home (ethernet socket), once I had configured everything with the various settings I could get online using mpd (I've now documented this in the Handbook). But then, I was using PPPoA so perhaps my experiences are useless here. > Thanks, > > Nuno Teixeira > -- Dominic ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Race in kevent
On Thu, 10 Jul 2003, John Baldwin wrote: JB> JB>On 10-Jul-2003 Harti Brandt wrote: JB>> On Wed, 9 Jul 2003, John Baldwin wrote: JB>> JB>> JB>On 09-Jul-2003 Harti Brandt wrote: JB>> JB>> JB>> JB>> Hi, JB>> JB>> JB>> JB>> I just had a crash while typing ^C to a program that has a kevent timer JB>> JB>> running. The crash was: JB>> JB>> JB>> JB>> callout_stop JB>> JB>> callout_reset JB>> JB>> filt_timerexpire JB>> JB>> softclock JB>> JB>> JB>> JB>> and callout_stop was accessing freed memory (0xdeadc0e2). After looking JB>> JB>> some time at the filt_timerdetach, callout_stop and softclock I think the JB>> JB>> following happened: JB>> JB>> JB>This is becoming a common race unfortunately. :( See the hacks in JB>> JB>msleep() that use TDF_TIMEOUT in coooperationg with endtsleep() and JB>> JB>the recent commit to the realtimer callout code for ways to work around JB>> JB>this race. JB>> JB>> In both places the thread just sleeps until the timeout has fired (when I JB>> understand this correctly). While this is a possible workaround also for JB>> kevent() (which only holds Giant as far as I can see) this is by no means JB>> a solution for other callers. While looking through the tree I have found JB>> several issues with timeouts which probably should be resolved or they JB>> will hit us with SMP: JB> JB>Yes, they sleep until the callout has finished executing. Note that the JB>callout has _already_ fired. The common case is that it is blocked on JB>the lock that the code trying to stop the callout is holding. Thus, you JB>are going to have to have special case code in your callout handler JB>_anyway_ to handle these edge cases, so there really isn't a super-duper JB>easy-clean solution. This is with MPSAFE callouts. !MPSAFE callouts will block before calling the handler when the try to acquire Giant. I'm assuming here, that the thread that calls callout_stop() must already have Giant (this is a valid assumption, isn't it?). In this case we can clear the cached copy (c_func) of the callout in callout_stop() and softclock will notice this when it has aquired Giant. We just need to make this cached copy global. For the MPSAFE case there is nothing we can do I suppose. JB>> - the CALLOUT_ACTIVE flag is not maintained correctly. softclock() fails JB>> to clear this flag after the timeout has fired. callout_stop() clears JB>> CALLOUT_ACTIVE if it finds the callout not PENDING. This is wrong if JB>> the callout is just about to be called (in this case it is !PENDING JB>> but ACTIVE). This makes callout_active() useless. JB> JB>The problem is in the API. One of the design goals is that a callout can JB>re-fire itself. Thus, softclock can't touch the callout once it has fired JB>it. This design goal is the reason for much of the confusion. JB> JB>> - using callout_active() on a callout_handle. Callouts for JB>> callout_handles (timeout(9)) are allocated from a common pool. So you may JB>> just check the wrong callout if the callout has already fired and has been JB>> reallocated to another user. Handles allocated with timeout(9) can only JB>> be passed to untimeout(9) JB> JB>The idea is that timeout(9) and untimeout(9) are a deprecated interface and JB>code should be using the callout(9) API instead. Note that timeout(9)'s can JB>never be marked MPSAFE. JB> JB>> I think we should try to make the callout interface usable without races JB>> for the !MPSAFE case (see mail from Eric Jacobs). For the MPSAFE case the JB>> caller should be responsible for this. And we should probably better JB>> document the interface. JB>> JB>> Going to think about this... JB> JB>Well, you need to consider the design goal above as it throws several JB>wrenches into the works. One possibility is that we could ditch the JB>design goal. Another possibility is that we could expand the callout JB>API to allow for periodict callouts and not just one-shot callouts. That would probably be a good idea. Scheduling the new callout before calling the callout routine would be a good idea. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: raw socket programming SOLVED
Wes Peters wrote:
On Saturday 05 July 2003 08:01 pm, Alin-Adrian Anton wrote:
Yes, it works now, with these includes:
---
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
---
Believe it or not, the advice in style(9) is quite helpful in putting
include files in their correct order. I'm so used to doing things in
similar order that I re-wrote your original program as:
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
int main() { printf("foo\n"); }
after grepping for n_long in /usr/include. The order of the netinet
includes; in.h then ip.h then tcp.h, seems logical to me. Perhaps a
(re-) reading of the instructions on include files in style(9) is in
order.
Thank you, I just read it. You are right. :-)
Alin.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
IPFW fun
Hey- I have a freebsd gateway machine that runs ipfw and nat for my home network and I want to add a rule that redirects VNC packets through the gateway to my windows machine so that I can VNC to my home machine to do some stuff. How should I phrase the rule correctly without screwing up the natd service? I am guessing it should go something like this: ipfw add 1000 divert ip from any to 192.168.0.253:5800 via ep1 Is this correct? I need it to only redirect packets for the VNC port. Thanks -ts ~ "On really romantic nights of self, I go salsa dancing with my confusion." ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Application
THIS IS AN AUTO-RESPONSE MESSAGE - PLEASE DO NOT REPLY TO THIS MESSAGE
Please read carefully! This may be the only response we send you.
Thank you for writing Meganameservers, Megamailservers and
Megawebservers. This address is designated for reporting violations
of our Abuse and Spamming Policy. We make every effort to investigate
all reports of abusive activity in a timely manner. The information
that you have provided will be used to investigate the incident for
violations of our abuse and Spamming Policy, which you can view at:
http://meganameservers.com/ourpolicy.html
We are unable to provide a personal reply to each report unless
additional information is required, so THIS MAY BE THE ONLY RESPONSE
YOU WILL RECEIVE. When reporting violations, please follow these
guidelines in order to significantly expedite the investigation
process:
* > To report unsolicited commercial email (UCE/spam), please forward
the entire message, including full headers, leaving the original
subject line intact. You will recognize full headers by the "received"
line(s) shown. If you need assistance in enabling full headers,
please refer to the help section of your email client.
* > To report off-topic commercial newsgroup postings, please forward
a copy of the offending post, including full headers, leaving the
original subject line intact.
* > If you are writing to report abusive usage of the Windows
Messenger Service ("pop-up spam"), use the following link to disable
the Messenger service. This form of abuse does not originate from
our network and we cannot be held responsible for its presence on
your computer.
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q330904
* > To report scans, probes, hacking attempts, or similar activity,
please include an excerpt of your auto-generated log files showing
ONLY THE INCIDENTS PERTAINING TO MEGAMAILSERVERS, cut & pasted
directly into the email message, including:
*Offending IP Address
*Date
*Specific Time
*Time Zone
*Source/Destination Ports
*Any other brief pertinent details
*** Screenshots cannot be accepted in lieu of log excerpts ***
*** Please DO NOT INCLUDE TRACEROUTES, WHOIS LOOKUPS, or PING results,
as these do not contribute to the investigation, and can often cause
the message to become "garbled" or unreadable ***
*** Please make sure that you are not sending an attachment that
is in a proprietary format (i.e. a log file readable only by your
firewall program or one that requires special software to view,
.xls). If you do send an attachment, please note the format type
in your email message ***
Thank you,
-
Meganameservers, Megawebservers, and Megamailservers
Incident Response Team - [EMAIL PROTECTED]
-
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD reference..in SCO lawsuit
http://www.byte.com/documents/s=8276/byt1055784622054/0616_marshall.html (yeah right) --- Begin Message --- http://www.byte.com/documents/s=8276/byt1055784622054/0616_marshall.html . --- End Message --- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPFW fun
On Fri, Jul 11, 2003 at 11:07:55AM -0400, Tom Servo wrote: > Hey- > I have a freebsd gateway machine that runs ipfw and nat for my home network > and I want to add a rule that redirects VNC packets through the gateway to > my windows machine so that I can VNC to my home machine to do some stuff. > How should I phrase the rule correctly without screwing up the natd service? > I am guessing it should go something like this: ipfw add 1000 divert ip > from any to 192.168.0.253:5800 via ep1 Is this correct? I need it to only > redirect packets for the VNC port. Thanks -ts [ Cc'ed to freebsd-questions ... ] in case of inbound nat in rc.firewall ipfw add 1000 divert natd tcp from any to 192.168.0.253 5800 in recv ep1 ipfw add 1000 divert natd tcp from 5800 to any /etc/natd.conf interfase ep1 use_sockets yes same_ports yes redirect_port tcp :5800 192.168.0.253:5800 /sbin/natd -f /etc/natd sh /etc/rc.firewall -- zhuravlev alexander ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
portupgrade
Hello, I've written a simple script to make my life easier, but there is a problem with that script and I can't figure out the source of that problem. if [ "$variables" != "" ]; then echo "portupgrade -m '$variables' $progname" (portupgrade -m \'$variables\' $progname) else echo "portupgrade $progname" (portupgrade $progname) fi The problem is simple. Whenever this script confronts a program which needs to be upgraded, portupgrade removes the old version and then script terminates without any error messages, while several instances of bash and linker continue to run in the background for several seconds, and then also terminate. The new version of the program never gets installed. What I can't understand is the reason why the script terminates without any error messages while it still has several cycle to go. It doesn't terminate if there aren't any programs that need to be upgraded (portupgrade simply responds with the message that there is nothing to upgrade), and goes through the same cycles without spitting out any error messages. My guess is that something weird happens when portupgrade starts to install the upgraded version of the removed program, but I have no idea what exactly that is. I'd be more than thankful if you could point out the place where I do something in a wrong way. I also have attached a full version of that script, in case if you want to take a look at it. Thanks ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PPP vs mpd (was: FreeBSD lacks PPPoE (pppoa3 solution))
On Fri, Jul 11, 2003 at 05:46:02AM +0100, Pedro F. Giffuni wrote: > Hi; > > I wanted to bring this up a little later but since there is a somewhat related > thread I thought I might as well bring this now. Our default PPPd is extremely > outdated. The version in the distribution is a patched-up version of Paul's PPP > 2.3.5 which is maintained now at http://dp.samba.org/ppp/. Version 2.3.5 is > obsoleted and the latest version doesn't support *BSD. The main problem involved in updating it has merging the FreeBSD changes into the significantly different pppd code. If the Debian people have done this, then it could be updated - you didn't post a link to the patches though. Kris pgp0.pgp Description: PGP signature
getpwnam + getpwnam_r + LinuxThreads port = deadlock
Hi -hackers,
System: FreeBSD 5.0-CURRENT cvsupped around 5.0-RELEASE
I'm writing an app that links with the LinuxThreads
(/usr/ports/devel/linuxthreads) and also uses getpwnam(). The problem:
a deadlock. GDB backtrace:
(gdb) bt
#0 0x28140053 in sigsuspend () from /usr/lib/libc.so.5
#1 0x28090428 in __pthread_wait_for_restart_signal () from
/usr/local/lib/liblthread.so.3
#2 0x28090548 in __pthread_suspend_old () from /usr/local/lib/liblthread.so.3
#3 0x2808d5fc in __pthread_alt_lock () from /usr/local/lib/liblthread.so.3
#4 0x28090df0 in pthread_mutex_lock () from /usr/local/lib/liblthread.so.3
#5 0x2808595b in getpwnam_r () from /usr/local/lib/liblthread.so.3
#6 0x2815405b in getpwuid_r () from /usr/lib/libc.so.5
#7 0x28153fab in getpwuid_r () from /usr/lib/libc.so.5
#8 0x28154129 in getpwnam () from /usr/lib/libc.so.5
#9 0x28085966 in getpwnam_r () from /usr/local/lib/liblthread.so.3
#10 0x2815405b in getpwuid_r () from /usr/lib/libc.so.5
#11 0x28153fab in getpwuid_r () from /usr/lib/libc.so.5
#12 0x28154129 in getpwnam () from /usr/lib/libc.so.5
#13 0x080495ca in check_pwinfo (username=0x155 ,
passwd=0x155 , group=0xbfbfeed8)
#14 0x0804a212 in handle_connection (tb=0xbfbff988)
#15 0x0804a52b in main (argc=4, argv=0xbfbff9f8)
#16 0x080494f5 in _start ()
(gdb) f 13
#13 0x080495ca in check_pwinfo (username=0x155 ,
passwd=0x155 , group=0xbfbfeed8)
43 pw = getpwnam (username);
Basically: FreeBSD implements getpwnam() as a wrapper around
getpwnam_r(), as seen in src/lib/libc/gen/getpwent.c:
struct passwd *
getpwnam(const char *name)
{
union key key;
key.name = name;
return (getpw(wrap_getpwnam_r, key));
}
While LinuxThreads does the opposite, basically using getpwnam() +
mutex to make getpwnam_r, as seen in
ports/devel/linuxthreads/work/linuxthreads-2.2.3_11/getpw_r.c:
int getpwnam_r (const char *name, struct passwd *result,
char *buffer, size_t buflen,
struct passwd ** resptr)
{
struct passwd * p;
int retval;
pthread_mutex_lock (&getpw_mutex);
p = getpwnam (name);
if (p == NULL) {
*resptr = NULL;
retval = ESRCH;
} else
if (convert (p, result, buffer, buflen) != 0) {
*resptr = NULL;
retval = ERANGE;
} else {
*resptr = result;
retval = 0;
}
pthread_mutex_unlock (&getpw_mutex);
return retval;
}
So basically, my app calls getpwnam(), which calls the overridden
getpwnam_r() from LinuxThreads, which calls getpwnam() from libc
again, and then calls getpwnam_r() from LinuxThreads again, and
deadlocks trying to recursively lock its own mutex. Obviously, if
there was no mutex the stack would leak out the back of my computer
:-)
Any ideas here?
-- Josh
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
