Re: Could not bind
| I have written a server program that listens on port 3000. The program | works very well except for one feature. I am asking if that is normal, | or whether I forgot something. | | If I run the program it does fine. If I then kill the program (after it | has accepted connections), and then run the program again, the bind | function fails to work, and I get a message like Could not bind (see | program below). If I wait a while, like a minute or two, then the | program will work again. Is this normal behavior, or did I miss | something? [ snip ] This is normal behavior. bind() will fail if there are still sockets in the TIME_WAIT (and other) states. To get around this, you want to use set the SO_REUSEPORT option using setsockopt(). -Dan -- Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gethostbyXXXX_r()
| Are there any plans of making gethostbyname_r() and gethostbyaddr_r() | available in FreeBSD? May be somebody already has them almost ready | to be commited? Or are there any considered wrong way to go? | | The reason I'm asking is that I actually have a local patch implementing | them here (only for DNS for now). Is it good idea to put some effort to | finalaze it and submit a PR? Or I'd better not waist time on that? | | Please complete it, let me know when you submit the PR i'll try | to get it integrated. I believe BIND9 has a completely thread-safe libresolv now. -Dan -- There is nothing wrong with Southern California that a rise in the ocean level wouldn't cure. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: threadsafe name resolution
| i've just received confirmation from the author of the KAME resolution code | that it isn't at all thread safe: | | Sure. As noted in name6.c, thread related stuff is not implemented yet. | Since our resolver code based on bind4 doesn't aware thread safeness, | all I can do now would be only putting mutex, anyway. | | sure enough, name6.c says: | | /* | * TODO for thread safe | * use mutex for _hostconf, _hostconf_init. | * rewrite resolvers to be thread safe | */ | | now, i'd say that it's fairly important for some form of threadsafe name | resolution to exist. until the KAME code is fixed, how about adding in the | ipv4 _r methods that have been discussed from time to time? or, at the very | least, put something in the manpage for getipnodebyname and friends | indicating that the funcs are not threadsafe. | | as you can probably tell, i wasted several hours worth of work bumping into | this problem. The problem lies deeper than that. Calls like gethostbyname() and friends are not threadsafe either, as they use an internal struct hostent and return a pointer to it (that another thread would happily clobber with its own data). Thread-happy functions we're supposed to be added by the Vixie people, and since I haven't checked up on it in about a year, they could be in there by now, but since we use BINDs name-resolver library, it's a contrib/ issue and our policy isn't to hack up the contrib/ tree. Of course, the door is always open for you to write the code and submit it to the bind team. 8) -Dan -- Man is a rational animal who always loses his temper when he is called upon to act in accordance with the dictates of reason. -- Oscar Wilde To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: threadsafe name resolution
| Is there a reason that ADNS won't work for this? | | http://www.chiark.greenend.org.uk/~ian/adns/ Technically, no. Morally, it's GNU. :-) -- Man is a rational animal who always loses his temper when he is called upon to act in accordance with the dictates of reason. -- Oscar Wilde To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How to make *real* random bits.
| Indeed, Poul's idea has massive geek potential. | | However, for the geek impaired, there is always the 82802 Random | Number Generator which is included on newer Intel chipsets. It may | not be the holy grail of randomness, but nearly every PC will have | one, and I think it'd be good if FreeBSD could at least use it to | gather entropy. I already have a driver for this chip. It just needs to be ported to markm's work, and perhaps beaten into not using pmap_mapdev(). -Dan -- Man is a rational animal who always loses his temper when he is called upon to act in accordance with the dictates of reason. -- Oscar Wilde To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: bin/18312: FreeBSD System Recovery -- mt not statically linked
| There's not much point statically linking mt if it's sitting in | /usr/bin. On the face of it it does seem a good candidate to move | to /bin. | | Given that having things move around in the base system carries with it | varying degrees of pain, can you guys just explain why this is actually | necessary? Didn't someone point out a way to use restore in the absence | of mt? | | Yes, that was me. But maybe they're /usr that they want to restore isn't in | dump(8) format. I dunno- this is why I asked. It seems to me on the face of it | a reasonable thing to have- basic device manipulation available w/o /usr. But | there's no particular end to the number of things you *could* want to be | availble if someone takes a Mossberger to your /usr. So, I'm of two minds | about this. Instead of going through pains of moving everything around, why not build a static mt on the rescue disk only? -- Dan Moschuk ([EMAIL PROTECTED]) "Don't get even -- get odd!" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Toshiba 4260 screen problem
Greetings, I've got myself a bright new shiny Toshiba 4260 laptop, with one small problem. I cannot seem to get the screen any bigger than a small window (similiar to Fn + F on my Vaio). Any ideas how I can get this full screen? -Dan -- Dan Moschuk ([EMAIL PROTECTED]) "Don't get even -- get odd!" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Multithread safe gethostbyname() ?
| Is there a MT-safe implementation of gethostbyname() in FreeBSD (3.4/4.0)? | | On Solaris there is gethostbyname_r(). Calling gethostbyname() with in | two threads cause both threads to block. | | No. :( Until we get one you can work around it by using a mutex around | calls to gethost* to allow only 1 thread to call them at a time. That won't work either, since, if I remember correctly, the returned struct hostent is static. -Dan -- Dan Moschuk ([EMAIL PROTECTED]) "Waste not fresh tears on old griefs." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Help? Device driver 'make depend' errors from comments
| First, I made up a makefile and got my driver compiling cleanly | standalone in my directory. So the code is known good with respect | to compiling under FreeBSD with gcc. Then I moved the code under | the /sys hierarchy, fixed up my configuration file, and did a 'config' | for my kernel. So far, so good. | | But then when I moved to the compile directory and did a 'make depend', | all heck broke loose. I'm getting hundreds of errors and/or warnings. | Checking the code, it seems to be complaining (or rather getting | confused) about two major things: [ snip. ] When you compile standalone, do you use the same -W options as the kernel does when it compiles? That may account for the millions of warnings you getting when trying to build your driver with the regular kernel build. Cheers, -- Dan Moschuk ([EMAIL PROTECTED]) "Waste not fresh tears on old griefs." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Odd TCP problem
Greetings, I've encounted somewhat of an odd problem that seemed to appear out of nowhere after my last -current upgrade a week or two ago. I rebuild last night and the problem is still around. Basically, near the end of the TCP transaction, consistant retransmission leads to the connection timing out. In the first example, my -current laptop is talking to a postgres database server running solaris7 on an ultra sparc. The program runs, and in the exact same spot each time (updating the last record) it stops. Here's a tcpdump: 14:20:01.894645 spirit.1100 eclipse.5432: P 1176338:1176373(35) ack 136575 win 17520 (DF) 14:20:01.897467 eclipse.5432 spirit.1100: P 136575:136624(49) ack 1176373 win 8760 (DF) 14:20:01.897951 spirit.1100 eclipse.5432: P 1176373:1176756(383) ack 136624 win 17520 (DF) 14:20:01.908113 eclipse.5432 spirit.1100: P 136624:136649(25) ack 1176756 win 8760 (DF) 14:20:01.910717 spirit.1100 eclipse.5432: . 1176756:1178216(1460) ack 136649 win 17520 (DF) 14:20:01.911188 spirit.1100 eclipse.5432: P 1178216:1178807(591) ack 136649 win 17520 (DF) 14:20:01.978311 eclipse.5432 spirit.1100: . ack 1178216 win 8760 (DF) 14:20:02.977968 spirit.1100 eclipse.5432: P 1178216:1178807(591) ack 136649 win 17520 (DF) 14:20:04.977986 spirit.1100 eclipse.5432: P 1178216:1178807(591) ack 136649 win 17520 (DF) 14:20:08.978058 spirit.1100 eclipse.5432: P 1178216:1178807(591) ack 136649 win 17520 (DF) 14:20:16.978187 spirit.1100 eclipse.5432: P 1178216:1178807(591) ack 136649 win 17520 (DF) 14:20:32.978432 spirit.1100 eclipse.5432: P 1178216:1178807(591) ack 136649 win 17520 (DF) 14:21:04.978917 spirit.1100 eclipse.5432: P 1178216:1178807(591) ack 136649 win 17520 (DF) This continues until spirit gives up and resets the connection. As you can see, its like eclipse vanished. Now, running a tcpdump on eclipse shows that these packets are in fact reaching the machine, its just not responding to them. It's not a problem with postgres itself, as the same problem can also be observed sending mail. Everything goes fine until after the DATA stage, where we become stuck in the above retransmission loop. Ideas? -- Dan Moschuk ([EMAIL PROTECTED]) "Waste not fresh tears on old griefs." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: DeCSS
| IMHO, what would be FAR better would be for things that use the Xing keys | to go away, and something else used that exploited the weaknesses of the | CSS system itself. A couple of researchers have found that CSS is *SO | PATHETICALLY WEAK* that it takes merely a few seconds on a reasonably quick | computer to break the session key for the DVD without having *any* | knowledge of the compromised Xing key. That way the MPAA and CCA can't | claim that you are using a stolen key, because you are not using any of the | 512 player keys. You are simply figuring out what the session key is. Correct! CSS is so pathetic that breaking it in runtime is quite easily accomplished. Each DVD has a disk key, which is stored in a five byte hash on the disk. The disk key is also stored encrypted with all the various player keys. The layout looks something like this: 5 byte disk key hash Disk key encrypted with player key 1 Disk key encrypted with player key 2 ... Disk key encrypted with player key n When a disk is inserted, the player decrypts the disk key with its assigned player key, then hashes it and compares it to the 5 byte hash. Since CSS is a 40bit cipher (something to do with US export regulations I'm sure), attacking the keyspace is quite trivial to do (about a complexity of 2^25). Another interesting point is that with one player key compromised, one can derive the rest of the player keys through a similar search. -- Dan Moschuk ([EMAIL PROTECTED]) "Waste not fresh tears on old griefs." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Crypto in the kernel: where how?
| US sites mirror their crypto from freebsd.org, international ones from the | international repository. The preferred path is for code to be committed | by international people to the international repository, since it can be | imported from there back into the US - if we can avoid it we shouldn't | commit stuff to the US repository on its own since that prevents most of | our users (by geography) from accessing it. However at least in the case | of OpenSSL (which I'm planning to import into internat when I go home to | australia next week :-) the two will have to be divergent due to the | patent restrictions on RSA. The RSA patent makes things a lot more difficult. If we do add some crypto into the kernel I suggest we use patent-free algorithms to start with. -- Dan Moschuk ([EMAIL PROTECTED]) "Cure for global warming: One giant heatsink and dual fans!" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Crypto in the kernel: where how?
| This was actually part of an unrelated point I was making - RSA will | definitely not be going into the kernel anywhere at this point! In | general, we want the two crypto repositories to stay in sync which | generally means propagating from internat - freefall, but we can't do it | for RSA. Indeed. So, the crypto stuff stays on internat and is then imported to freefall? How does that affect our mirror sites? Are we not then exporting it out to the world from freefall, or is the crypto stuff snagged from internat as well? I would much rather see freefall move a few thousand miles north! :-) -- Dan Moschuk ([EMAIL PROTECTED]) "Cure for global warming: One giant heatsink and dual fans!" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Ok, that's it, enough is enough! (rpc.lockd)
| I reviewed the NFSv4 specs recently and came to the same conclusion. To do | it right will be quite a bit of work and would include a decent kernel | side implementation of rpc and gssapi. Cool! I can take that "I volunteer" ? :-) -- Dan Moschuk ([EMAIL PROTECTED]) "Cure for global warming: One giant heatsink and dual fans!" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Ok, that's it, enough is enough! (rpc.lockd)
| I'm fairly certain that rpc.lockd is included with Darwin from Apple, | I've not closely compared it to what we have in -STABLE or -CURRENT | to see if it actually works. | | It doesn't, sorry... if someone gets a *BSD version of NFS locking operating | I'd help see it into Darwin. | | BTW, is anyone working on NFS Version 4 for BSD? Rick? A few of us talked about this on IRC a few weeks ago and it was decided that when/if we implement NFSv4 it would have to be from scratch. A pretty big task. -- Dan Moschuk ([EMAIL PROTECTED]) "Cure for global warming: One giant heatsink and dual fans!" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PThreads and Sockets
| Try this.
|
| void *serverstart(void *ptr)
| {
| int sd2;
|
| sd2 = *((int *) ptr);
| ...
| }
|
| There is a race condition. You're passing sd2's address to serverstart()
| and inside serverstart() you def' the pointer. What if
| "sd2=accept(sd, (struct sockaddr*)cad, alen)" gets
| executed before your previous serverstart() finishs "sd2 = *((int*)ptr)"?
Since accept isn't atomic, it would be best to enclose the whole sha-bang in
a mutex up until the sd2 = *((int *) ptr) call finishes.
--
Dan Moschuk ([EMAIL PROTECTED])
"Try not. Do, or do not. There is no try."
-- Yoda
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: PThreads and Sockets
| int sd2;
| if((sd2=accept(sd, (struct sockaddr*)cad, alen)) 0) {
| pthread_create(thread1, pthread_attr_default,
| serverstart, sd2);
| }
|
| Then the serverstart function:
|
| void *serverstart(void *ptr)
| {
| int *sd2;
| sd2 = (int*)ptr;
|
| dowhatever(sd2);
| }
|
| Any ideas as to what I'm doing wrong? Also, thanks for your help.
|
| Rob
Try this.
void *serverstart(void *ptr)
{
int sd2;
sd2 = *((int *) ptr);
...
}
--
Dan Moschuk ([EMAIL PROTECTED])
"Cure for global warming: One giant heatsink and dual fans!"
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
VAIO F270, ep0 and -current
Greetings,
I have been in light contact with Warner over the course of the last couple
of weeks, and I am still at wits end with this one.
Currently, my laptop (VAIO F270 with a 3Com 589E pcmcia nic card) runs
3.3-REL with the PAO hacks, and works near-perfect. However, I would love
to use this machine as a development box, which means I should really be
running current on it.
Now, everything but pccard works, which fails with ENOTTY on the following
ioctl() call:
usr.sbin/pccard/pccardd/cardd.c, line 590:
if (ioctl(sp-fd, PIOCSDRV, drv)) {
This is now the only thing holding me back. Anyone had a similar experience?
Relevant configuration follows.
pccard.conf
--
io 0x240-0x360
irq 3 5 10 11 13 15
memory 0xd4000 96k
card "3Com" "Megahertz 589E"
config 0x1 "ep0" ?
insert echo 3Com Megahertz Ethernet card inserted
insert /etc/pccard_ether ep0
remove echo 3Com Megahertz Ethernet card removed
remove /sbin/ifconfig ep0 delete
the kernel config is a chopped down PCCARD
Cheers,
--
Dan Moschuk ([EMAIL PROTECTED])
"Cure for global warming: One giant heatsink and dual fans!"
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: file system full
| Too many open file descriptors. This has nothing to do with | the file system. | | Is there anyway this can be gotten around? A friend has a mail server | that will spontaneously do this then crash. | | Jamie If you're csh'ish, you can use the ``limit'' command to see what your allowed openfiles are. You can raise this with ``unlimit''. You will also want to look at a few kernel options if the above doesn't fix it. -- Dan Moschuk ([EMAIL PROTECTED]) "Try not. Do, or do not. There is no try." -- Yoda To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: updating packages automatically...
| If you're interested, I've got patches for sysutils/pkg_version | that support a '-c' flag (for 'commands') that show you the commands | you should run to update any out of date ports. I cron this and mail | the output out once a week. | | You could have it automatically create and execute a shell script if | you wanted. Sample output from one of my boxes is: [snip] I think this is a great idea, and certainly one of the things (the only thing?) I actually liked debian. I would much rather see this integrated somewhere in /etc/periodic/weekly, and have it output a shell script that can be run manually. -- Dan Moschuk ([EMAIL PROTECTED]) "Try not. Do, or do not. There is no try." -- Yoda To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mrtg,FreeBSD, asus p2b temperature
| Does anybody have any tips for using the above combination for graphing temperatures? | | Leif As far as I know, MRTG is only able to fetch data from SNMP MIBs. Which, in order to get the information you're looking for, two things have to happen. You need to first have the kernel fetch that information from the motherboard, and then some userland program to return it in the form of an SNMP response. So, unless you are prepared to dust off that C compiler, you're out of luck. -- Dan Moschuk ([EMAIL PROTECTED]) "Try not. Do, or do not. There is no try." -- Yoda To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
| Yeah, that IS a horrible idea of mine. :) Changing the API should be a last | resort, though, since we don't want to introduce to many FreeBSDisms into the | already-fragmented-enough Unix world. | | Just a thought, how does Linux's GNU libc handle gethostby* in threaded apps? | | Probably the way POSIX specifies, which would certainly be *our* target. And does POSIX specify it? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
| Yeah, that IS a horrible idea of mine. :) Changing the API should be a last | resort, though, since we don't want to introduce to many FreeBSDisms into the | already-fragmented-enough Unix world. | | Just a thought, how does Linux's GNU libc handle gethostby* in threaded apps? | | Probably the way POSIX specifies, which would certainly be *our* target. And does POSIX specify it? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: gethostbyaddr() and threads.
| } If no one has any objections, I'd like to start on this tomorrow. | | You might want to grab the latest BIND release from ftp.isc.org. One | of the comments in the CHANGES file from a while ago is: | | 384. [feature] there is now a nearly-thread-safe resolver API, with | the old non-thread-safe API being a set of stubs on | top of this. it is possible to program without _res. | note: the documentation has not been updated. also | note: IRS is a thread-ready API, get*by*() is not. | (see ../contrib/manyhosts for an example application.) | | There's no sense re-inventing any more wheels than necessary. Great! This makes my job even easier! Does anyone have any issues with merging the new bind resolver API into libc? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: gethostbyaddr() and threads.
| After quite an exhausting night (of all the ways I didn't want to spend my | Sunday...) I've managed to track down a problem that has been frustrating me | all night. The problem exists with multiple threads calling gethostbyaddr() | (not necessarily at the same time). | | src/lib/libc/net/gethostbydns.c seems to use a load of static | variables in a non-thread-safe fashion. Yes, I noticed that as well. I also noticed that gethostbyaddr_r worked "less" than gethostbyaddr did (the result was that all threads ended up thrashing each other, and not of them continued on). I was going to use res_query, but noticed that it too used static buffers (although it looks pretty easy to fix). Would anyone be offended if I were to produce a few patches to fix up these routines once and for all? Should I just produce a few #ifdef _THREAD_SAFEs or try full blown routines (gethostbyaddr_r, res_query_r)? Thanks, Dan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
| After quite an exhausting night (of all the ways I didn't want to spend my | Sunday...) I've managed to track down a problem that has been frustrating me | all night. The problem exists with multiple threads calling gethostbyaddr() | (not necessarily at the same time). | | src/lib/libc/net/gethostbydns.c seems to use a load of static | variables in a non-thread-safe fashion. Yes, I noticed that as well. I also noticed that gethostbyaddr_r worked less than gethostbyaddr did (the result was that all threads ended up thrashing each other, and not of them continued on). I was going to use res_query, but noticed that it too used static buffers (although it looks pretty easy to fix). Would anyone be offended if I were to produce a few patches to fix up these routines once and for all? Should I just produce a few #ifdef _THREAD_SAFEs or try full blown routines (gethostbyaddr_r, res_query_r)? Thanks, Dan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: gethostbyaddr() and threads.
| Well, I guess we might as well change the API, since everyone else does. Unless | someone comes up with a bettter idea, of course :) | | -Joe The API should not change. There is already enough descrepency between UNIXs to warrant programs like autoconf, we should not introduce another. We should introduce a gethostbyaddr_r function, which shouldn't be all that though to implement.
gethostbyaddr() and threads.
Greetings, After quite an exhausting night (of all the ways I didn't want to spend my Sunday...) I've managed to track down a problem that has been frustrating me all night. The problem exists with multiple threads calling gethostbyaddr() (not necessarily at the same time). Here's a debug output from my program: Thread 134978048 sleeping... Thread 134978560 sleeping... Thread 134978048 awakened! Thread 134978048 checking status of 162.18.75.91 Thread 134978048 looking up 162.18.75.91 Thread 134978048 calling gethostbyaddr() Thread 134978560 awakened! Thread 134978560 checking status of 162.18.75.91 Thread 134978560 sleeping... Thread 134978560 awakened! Thread 134978560 checking status of 202.188.127.2 Thread 134978560 looking up 202.188.127.2 Thread 134978560 calling gethostbyaddr() Thread 134978560 finished gethostbyaddr() Thread 134978560 checking status of 200.231.47.8 Thread 134978560 looking up 200.231.47.8 Thread 134978560 calling gethostbyaddr() As you can see, gethostbyaddr() when called from the first thread never returns, while the last thread continues on. This happens no matter how many threads I create. Creating 200 threads produces much longer debug output, but the result is the same, the first 199 threads created never return from gethostbyaddr(), while the last one continues on its merry way. I am hoping someone can shed a little more light on this subject, and possibly explain why this is happening and perhaps how to fix it. I've tested this on both -stable and -current branches. Regards, Dan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
gethostbyaddr() and threads.
Greetings, After quite an exhausting night (of all the ways I didn't want to spend my Sunday...) I've managed to track down a problem that has been frustrating me all night. The problem exists with multiple threads calling gethostbyaddr() (not necessarily at the same time). Here's a debug output from my program: Thread 134978048 sleeping... Thread 134978560 sleeping... Thread 134978048 awakened! Thread 134978048 checking status of 162.18.75.91 Thread 134978048 looking up 162.18.75.91 Thread 134978048 calling gethostbyaddr() Thread 134978560 awakened! Thread 134978560 checking status of 162.18.75.91 Thread 134978560 sleeping... Thread 134978560 awakened! Thread 134978560 checking status of 202.188.127.2 Thread 134978560 looking up 202.188.127.2 Thread 134978560 calling gethostbyaddr() Thread 134978560 finished gethostbyaddr() Thread 134978560 checking status of 200.231.47.8 Thread 134978560 looking up 200.231.47.8 Thread 134978560 calling gethostbyaddr() As you can see, gethostbyaddr() when called from the first thread never returns, while the last thread continues on. This happens no matter how many threads I create. Creating 200 threads produces much longer debug output, but the result is the same, the first 199 threads created never return from gethostbyaddr(), while the last one continues on its merry way. I am hoping someone can shed a little more light on this subject, and possibly explain why this is happening and perhaps how to fix it. I've tested this on both -stable and -current branches. Regards, Dan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Beating system usage down
Greetings, A machine that I hold very close under my wing has been very contently chugging along for the last few months with practically no idle processor. However, I noticed that the CPUs are spinning a lot of cycles in the system area. CPU states: 5.5% user, 0.0% nice, 88.9% system, 4.0% interrupt, 1.6% idle First, some background. The machine is a Dual P2-450 with 1GB of RAM. It runs apache, and currently handles 90 hits a second, with each of those hits spawning various CGIs (one per hit) that completes in under a second. My first theory was that the kernel was uselessly spinning in various record locks via fcntl(). However, as a test I removed all file locking from the various CGIs and noticed no change in the system usage. My second theory was the overhead with the SMP code. So, I removed it from the kernel and ran a single CPU box for a few minutes. The system usage went down to around 60%, but the system was noticeably slower. Any ideas? Regards, Dan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
hundreds of sockets stuck in TIME_WAIT
I noticed on a very high traffic'd webserver, I have just over 4000 sockets stuck in the TIME_WAIT state. Ideally, I want to bend the RFC a bit and close the descriptor before it hits that state, or, ignore the 2MSL wait when it enters that state. I take it there is no sysctl switch to trigger this, so, am I going kernel diving? -Dan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Segfault in longjmp() ?
The machine is a SMP 3.0-RELEASE box. A heavily threaded program is segfaulting in the longjmp() function. Any ideas what would cause this? Regards, Dan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: security: what does OpenBSD have, that FreeBSD doesn't have.
| One of my plans is to merge all of these changes into our tree (along with all | the other minor changes/manpage corrections, etc). | | Longer term, I'd like to work on porting some of their kernel code like | randomized sin_port selection and TCP initial sequence numbering, probably | hidden behind sysctl knobs (defaulting to off to keep people happy). I think that would be a great idea. I'd be willing spare a few hours on a weekend to help out with this. -Dan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Database holywars?
Greetings, I've taken up a project that will rely very heavily on remote database access. Naturally, the choice as to which database engine to use is a crucial one. I'd like to stay away from the commercial database suites (i.e. Oracle) for the time being, however I will eventually move to it once the database grows to over 100M records. In the meantime however, I'm debating heavily between MySQL and Berkeley DB with a multi-threaded socket frontend. Suggestions and comments? Dan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Database holywars?
| I'd like to stay away from the commercial database suites (i.e. Oracle) for | the time being, however I will eventually move to it once the database grows | to over 100M records. In the meantime however, I'm debating heavily between | MySQL and Berkeley DB with a multi-threaded socket frontend. | | Suggestions and comments? | | What's more important, flexibility to make changes, or speed? Anything | that implements sql has to be far slower, but if you make many changes, | you're going to heavily regret choosing a set of C language functions | as the base of your DB. I think a proper equilibrium between the two would be most desirable, but, if I had to choose one over the other it would definately be speed. The actual structure of the database isn't going to change much, if at all, I would imagine. Assuming it changes once a year, writing a conversion program to read in the old structure and write out the new one doesn't seem quite so horrendous. On the other hand, its a lot more annoying than a simple ALTER .. ADD statement. :-) Dan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Database holywars?
| ¿Have you considered PostgreSQL? It is on the ports collection, and is a | heavy duty database engine, with transactions, subqueries (only partial | support), etc. Version 6.5 will be released in about two weeks, and it | adds MVCC (multi-version concurrency control), which will improve a lot | its multi-user capabilities. And, I know of some projects that are using | it for multi-GB databases. I've been using it for or student database | for more than two years (since version 6.0), and am quite happy with | it. See www.postgresql.org for more information. If I recall correctly, isn't postgresql *based* off of the Berkeley DB engine? -Dan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: VAIO F270, ep0 and -current
| : | if (ioctl(sp-fd, PIOCSDRV, drv)) {
|
| Do you have any cards that work? Are you 100% positive that your
| kernel and pccardd match? ENOTTY is returned only when the pccard
| driver doesn't know about the ioctl.
|
| Warner
The steps I take are as follows:
i) cvsup
ii) make/make install usr.sbin/pccard
iii) copy new pccard.conf into place
iv) build and reboot new kernel
If I've forgotten a step, please let me know.
Thanks,
--
Dan Moschuk ([EMAIL PROTECTED])
"Cure for global warming: One giant heatsink and dual fans!"
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: VAIO F270, ep0 and -current
| You need to make sure that you are compiling against the right kernel | headers. Not that I'm saying that you are, just making sure. | | Warner Doh! Are my cheeks red. After rebuilding /usr/include, and recompiling pccard all is well. Thanks! -- Dan Moschuk ([EMAIL PROTECTED]) "Cure for global warming: One giant heatsink and dual fans!" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
