Majordomo results
-- subscribe freebsd-hackers Your request to [EMAIL PROTECTED]: subscribe freebsd-hackers [EMAIL PROTECTED] must be authenticated. To accomplish this, another request must be sent in with an authorization key, which has been sent to: [EMAIL PROTECTED] If the message is not received, there is generally a problem with the address. Before reporting this as a problem, please note the following: You only need to give an address to the subscribe command if you want to receive list mail at a different address from where you sent the command. Otherwise you can simply omit it. If you do give an address to the subscribe command, it must be a legal address. It should not consist solely of your name. The address must point to a machine that is reachable from the list server. If you have any questions about the policy of the list owner, please contact "[EMAIL PROTECTED]". Thanks! [EMAIL PROTECTED] --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Confirmation for subscribe freebsd-hackers
-- Please be sure to read the charters before subscribing or sending mail to any FreeBSD mailing list for an explanation of which topics are relevant for a given list and what types of postings are and are not allowed. They may be found at: http://www.freebsd.org/handbook/eresources.html#ERESOURCES-MAIL Someone (possibly you) has requested that your email address be added to or deleted from the mailing list "[EMAIL PROTECTED]". If you really want this action to be taken, please send the following commands (exactly as shown) back to "[EMAIL PROTECTED]": auth 824d0397 subscribe freebsd-hackers [EMAIL PROTECTED] If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth 824d0397 subscribe freebsd-hackers \ [EMAIL PROTECTED] If you have any questions about the policy of the list owner, please contact "[EMAIL PROTECTED]". Thanks! [EMAIL PROTECTED] --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Welcome to freebsd-hackers
-- Welcome to the freebsd-hackers mailing list! Please save this message for future reference. Thank you. If you ever want to remove yourself from this mailing list, you can send mail to [EMAIL PROTECTED] with the following command in the body of your email message: unsubscribe freebsd-hackers or from another account, besides [EMAIL PROTECTED]: unsubscribe freebsd-hackers [EMAIL PROTECTED] If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to [EMAIL PROTECTED] . This is the general rule for most mailing lists when you need to contact a human. Here's the general information for the list you've subscribed to, in case you don't already have it: FREEBSD-HACKERS Technical discussions This is a forum for technical discussions related to FreeBSD. This is the primary technical mailing list. It is for individuals actively working on FreeBSD, to bring up problems or discuss alternative solutions. Individuals interested in following the technical discussion are also welcome. --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Majordomo results
-- auth 824d0397 subscribe freebsd-hackers Succeeded. --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
CRACK - Dreamweaver
Hi Can you tell me where I can get Crack for Dreamweaver 3 ?/ Thanks [EMAIL PROTECTED]
Re: CRACK - Dreamweaver
On Fri, 28 Jul 2000, Richard Stoodley wrote: Hi Can you tell me where I can get Crack for Dreamweaver 3 ?/ Go to http://2130706433/crackz/index.html for all of your 0-day cracks. The site is busy though, you might have to keep retrying for a while before you get in. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: CRACK - Dreamweaver
Hi Richard, Can you tell me where I can get Crack for Dreamweaver 3 ?/ http://www.macromedia.com/software/dreamweaver/buy/ They'll even send you a pretty box and some books. Kees Jan PS. I think you're confusing the terms "cracker" and "hacker". = TV is the worst of both worlds. It's not as good at words as radio is because the pictures are a distraction which demand attention, and it's not as good as cinema because the pictures are not nearly as good. Douglas Adams To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Documentation for pcm/voxware sound drivers?
Is there complete documentation for pcm / voxware sound drivers anywhere? I'd like to play around with sound on my 4-STABLE box (soundcard is a SB Live), but there documentation in the man pages, and on Luigi Rizzo's page, doesn't completely cover the ioctls and uses of the various sound devices. Thanks for any answers. Peter -- Peter van Heusden [EMAIL PROTECTED] Electric Genetics To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
core dumps when mmap'd to large sparse files
I have a program where I mmap a huge sparse file. If I fault and generate a core dump it proceeds to do something until the disk is full, but the disk is then left not full and a perfectly good core dump of a reasonable size is left. Can anyone explain? This is with 4.0. Peter -- Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
vinum striping quiestion
Hello, I've got a question about vinum. There are two scsi disks with vinum stripe. Here is a vinum config: drive a device /dev/da2s1e drive b device /dev/da3s1e volume vinum0 plex name vinum0.p0 org striped 1024s vol vinum0 sd name vinum0.p0.s0 drive a plex vinum0.p0 len 34791424s driveoffset 265s plexoffset 0s sd name vinum0.p0.s1 drive b plex vinum0.p0 len 34791424s driveoffset 265s plexoffset 1024s # uname -sr FreeBSD 4.1-STABLE There are not any other fs on these disks. The problem is - when I run iozone (iozone 4096 /logs/io0.tmp) I get a very strange result: # iostat -d da1 da3 10 da1 da3 KB/t tps MB/s KB/t tps MB/s 0.00 0 0.00 0.00 0 0.00 4.50 107 0.47 0.00 0 0.00 4.51 98 0.43 0.00 0 0.00 4.50 116 0.51 0.00 0 0.00 4.49 117 0.52 0.00 0 0.00 4.50 111 0.49 0.00 0 0.00 You see, there is not activity on da3. Are there any explanations? Thanks, maxim - -- Maxim Konovalov, mailto: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD,Posix,Linux Threading - Are they really useable?
PosixThreads are userland threads - if one thread blocks on i/o the whole process is blocked. Which makes PosixThreads rather useless. That is incorrect. FreeBSD's userland pthread implementation does not block the whole process on I/O. POSIX does not specify this behavior either. Actually, sometimes it does (for example when reading from an I/O device where select can't be used succesfully). FreeBSD Kernel-threads (dunno what they are called actually) can't be used natively!? (Searched the archives and found an explanation that the only way to access normal kernel SMP-thread functionality is to use LinuxThreads) FreeBSD's kernel threads are for separate threads of execution in the kernel and aren't the same thing as threads for a user process. You're missing the point. He's asking for 'kernel threads' so that multiple independant thread of execution for a given 'userland process' can be running simulataneously (virtually on a UP, and realistically on a MP). Currently, FreeBSD doesn't have any such thing, although there are a number of design documentations on how it would be done, if it were to be done. The recent work that Matt Dillon and Greg Lehey have been doing is intended to make this more possible. LinuxThreads: While they are kernel-threads, if one thread receives an uncought signal, all threads are killed (as they should be), but the resulting coredump is useless since it only captures the state of the last-killed-thread (or process or whatever you want to call it. LinuxThreads seems like just a big hack...). LinuxThreads on FreeBSD cannot be kernel threads because that would require modifications to our scheduler which simply have not been made. Not quite. LinuxThreads on FreeBSD *ARE* kernel threads, but they aren't part of the regular kernel because they aren't adequate, and they have the wrong license model to be used by default. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CRACK - Dreamweaver
Richard Stoodley wrote: Can you tell me where I can get Crack Try ftp://ftp.win.tue.nl/pub/security/crack5.0.tar.gz -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D FreeBSD Documentation Project / To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD,Posix,Linux Threading - Are they really useable?
Currently as far as I know, there isn't really a way to do this, although much work is being done in -CURRENT to fix this. = | Kenneth Culver | FreeBSD: The best NT upgrade| | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: muythaibxr | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| = On Fri, 28 Jul 2000, Bjorn Tornqvist wrote: Howdy all, I must have missed something very importand w.r.t threads under FreeBSD, here's what I've come up with during the last week: PosixThreads are userland threads - if one thread blocks on i/o the whole process is blocked. Which makes PosixThreads rather useless. FreeBSD Kernel-threads (dunno what they are called actually) can't be used natively!? (Searched the archives and found an explanation that the only way to access normal kernel SMP-thread functionality is to use LinuxThreads) LinuxThreads: While they are kernel-threads, if one thread receives an uncought signal, all threads are killed (as they should be), but the resulting coredump is useless since it only captures the state of the last-killed-thread (or process or whatever you want to call it. LinuxThreads seems like just a big hack...). How do I use normal kernel-threads that will allow all nonblocked threads in a process to work concurrently, *and* will generate useful coredumps? There must be a way - I've just haven't found any documentation on the subject. And yes, I must use threads - fork()ing will only give me the same trouble as LinuxThreads (a process sharing memory with another won't give a corefile). Please help me with this one. //Bjorn Tornqvist, West Entertainment Solutions Technologies AB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD,Posix,Linux Threading - Are they really useable?
On Friday, July 28, 2000, Nate Williams wrote: That is incorrect. FreeBSD's userland pthread implementation does not block the whole process on I/O. POSIX does not specify this behavior either. Actually, sometimes it does (for example when reading from an I/O device where select can't be used succesfully). Hmm. That's true. And that's where uthreads has its main problems as I understand it. FreeBSD Kernel-threads (dunno what they are called actually) can't be used natively!? (Searched the archives and found an explanation that the only way to access normal kernel SMP-thread functionality is to use LinuxThreads) FreeBSD's kernel threads are for separate threads of execution in the kernel and aren't the same thing as threads for a user process. You're missing the point. He's asking for 'kernel threads' so that multiple independant thread of execution for a given 'userland process' can be running simulataneously (virtually on a UP, and realistically on a MP). I thought he had seen the term 'kernel threads' in the context of FreeBSD before, likely in the context of kthread_create() in the kernel. -- |Chris Costello [EMAIL PROTECTED] |May the force be... your umbrella! - Plucky Duck `- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kevent()/kqueue() in a multithreaded environment
On Fri, 28 Jul 2000, Archie Cobbs wrote: Doug White writes: You normally wouldn't mix kqueue and threads; you'd use kqueue to *implement* threads. :-) AFAIK kqueue hasn't been made threadsafe, you'll have to bug [EMAIL PROTECTED] about it. Patches gladly accepted :) I may be just being stupid but I don't understand that last sentence. I thought kqueue() and kevent() were system calls... how can they not be thread safe? They really mean "wrapped by the threads library" so that kqueue doesn't block other threads from running. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
tar
I want to download the FreeBSD 2.2.2 for IPV6 Mobility development.
Because of the firewall, I can only access the Freebsd site by a SUN
Solaris machine. I use CVSup to download the FreeBSD2.2.2 from
cvsup7.freebsd.com to the Solaris machine. After the download, it
create a src directory(The size is about 180MB) in the solaris machine.
Then, I did a "tar cvf src.tar src" to compress it and ftp it to a PC
running FreeBSD3.3. I checked the size of the src.tar files and they are
the same in Solaris and the FreeBSD machines. After I uncompress it("tar
xvf src.tar"), the directory has only 150MB. Why is the uncompress
directory different in size in Solaris and FreeBSD?
Another question is, after I get the src directory, what should I do to
change the FreeBSD 3.3 to 2.2.2? Should I copy the src(the download one
for 2.2.2) to /usr/src of the FreeBSD 3.3 machine, then do "make world"
and then rebuild the kernel? Do I need to do "cvs" before make world?
What path should I set the $CVSROOT? Thanks for answering my question.
Jeffrey Fu
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
a quick one
Hi there, a quick one. Is getpeername() considered expensive? Would it be much better if I cache the result myself instead of calling it everytime on the connected socket(returned from accept) to find out which IP it connects to? Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a quick one
FengYue writes: Hi there, a quick one. Is getpeername() considered expensive? Would it be much better if I cache the result myself instead of calling it everytime on the connected socket(returned from accept) to find out which IP it connects to? It's not particularly expensive compared to other system calls.. but if you find system calls in general expensive, then it would certainly count as one :-) I'd say it's unlikely that this kind of optimization would be worth the trouble for a 'normal' application. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
some md (memory disk) questions
1) Might I want to replace my MFS /tmp with an md-based one? 2) I looked at LINT and GENERIC, I read section 10.6.2 of the Handbook, and I looked for an md man page in vain. Where could I find additional documentation for md? I'm particularly interested in finding out what it's good for. -- Ben 220 go.ahead.make.my.day ESMTP Postfix To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: /tmp on a ramdisk?
Ted Sikora wrote: A while ago several people suggested using /tmp on a ramdisk along with softupdates. Right now I am running several production servers with 4.1-STABLE with softupdates. I'm really happy with the performance. What benefits would I realize using /tmp on a ramdisk? CW on this is varied, but the current trend is that /tmp on a md is just a waste of ram, since (basically) everything in /tmp is in ram twice. Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vinum striping quiestion
On Friday, 28 July 2000 at 19:21:10 +0400, Maxim Konovalov wrote: Hello, I've got a question about vinum. There are two scsi disks with vinum stripe. Here is a vinum config: drive a device /dev/da2s1e drive b device /dev/da3s1e volume vinum0 plex name vinum0.p0 org striped 1024s vol vinum0 sd name vinum0.p0.s0 drive a plex vinum0.p0 len 34791424s driveoffset 265s plexoffset 0s sd name vinum0.p0.s1 drive b plex vinum0.p0 len 34791424s driveoffset 265s plexoffset 1024s Please show the output of 'vinum list'. # uname -sr FreeBSD 4.1-STABLE There are not any other fs on these disks. The problem is - when I run iozone (iozone 4096 /logs/io0.tmp) I get a very strange result: # iostat -d da1 da3 10 da1 da3 KB/t tps MB/s KB/t tps MB/s 0.00 0 0.00 0.00 0 0.00 4.50 107 0.47 0.00 0 0.00 4.51 98 0.43 0.00 0 0.00 4.50 116 0.51 0.00 0 0.00 4.49 117 0.52 0.00 0 0.00 4.50 111 0.49 0.00 0 0.00 You see, there is not activity on da3. Are there any explanations? I think this says more about iozone than it does about Vinum. Try running rawio instead and see what happens. Note also that a stripe size which is a power of two is not a good idea. It can give rise to the kind of behaviour you report: since cylinder groups are usually 32 MB in size, this arrangement will put all the super blocks on the same subdisk. Use an odd number, say 283 kB, instead. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Best way to lock malloc'd memory in kernel
I'm writing a device driver for plex86 (the FreeMWare virtual machine software), and have a buffer that needs to be non-pageable. It was malloc'd with the malloc(size, type, flags) kernel malloc function. What's the best way to make this memory unpageable? Thanks in advance, Isaac Waldron waldroni at lr dot net To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Best way to lock malloc'd memory in kernel
On 29-Jul-00 Isaac Waldron wrote: I'm writing a device driver for plex86 (the FreeMWare virtual machine software), and have a buffer that needs to be non-pageable. It was malloc'd with the malloc(size, type, flags) kernel malloc function. What's the best way to make this memory unpageable? No kernel memory is pageable so it doesn't matter :) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Best way to lock malloc'd memory in kernel
I'm writing a device driver for plex86 (the FreeMWare virtual machine software), and have a buffer that needs to be non-pageable. It was malloc'd with the malloc(size, type, flags) kernel malloc function. What's the best way to make this memory unpageable? No kernel memory is pageable so it doesn't matter :) Thanks! I didn't realize that, I suppose I should have RTFM'ed a bit more before asking, but I just kind of assumed (we all know what that does) that memory malloc'd in kernel mode was pageable. I guess I should ask whether that holds true for kernel modules as well, because that's what I'm actually writing. Thanks again, Isaac Waldron waldroni at lr dot net To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Best way to lock malloc'd memory in kernel
On 29-Jul-00 Isaac Waldron wrote: Thanks! I didn't realize that, I suppose I should have RTFM'ed a bit more before asking, but I just kind of assumed (we all know what that does) that memory malloc'd in kernel mode was pageable. I guess I should ask whether Yes, well it would be nice to have some kernel memory pageable but.. that holds true for kernel modules as well, because that's what I'm actually writing. Yes, writing a module is no different than writing for static kernel code. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kevent()/kqueue() in a multithreaded environment
You normally wouldn't mix kqueue and threads; you'd use kqueue to *implement* threads. :-) AFAIK kqueue hasn't been made threadsafe, you'll have to bug [EMAIL PROTECTED] about it. Patches gladly accepted :) I may be just being stupid but I don't understand that last sentence. I thought kqueue() and kevent() were system calls... how can they not be thread safe? I think there is a mis-communication here. They are thread 'safe', but if called, they block out all other 'threads' from running, so using kqueue doesn't allow for multiple threads to run 'concurrently'. In other words, a wrapper needs to be written so it can work in a 'threaded' environment effeciently. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
