Re: Optimal UFS parameters
In message [EMAIL PROTECTED], A G F Keahan writes: What parameters should I choose for a large (say, 60 or 80Gb) filesystem? I remember a while ago someone (phk?) conducted a survey, but nothing seems to have come of it. In the meantime, the capacity of an average hard drive has increased tenfold, and the defaults have become even less reasonable. What's the current consensus of opinion? newfs -b ? -f ? -c ? Right now I tend to use: -b 16384 -f 4096 -c 159 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Optimal UFS parameters
* Poul-Henning Kamp [EMAIL PROTECTED] [001207 00:12] wrote: In message [EMAIL PROTECTED], A G F Keahan writes: What parameters should I choose for a large (say, 60 or 80Gb) filesystem? I remember a while ago someone (phk?) conducted a survey, but nothing seems to have come of it. In the meantime, the capacity of an average hard drive has increased tenfold, and the defaults have become even less reasonable. What's the current consensus of opinion? newfs -b ? -f ? -c ? Right now I tend to use: -b 16384 -f 4096 -c 159 I know you're pretty busy, but any chance of getting this into sysinstall? Maybe hindged on the size of the partition? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Optimal UFS parameters
: : Right now I tend to use: : : -b 16384 -f 4096 -c 159 : :I know you're pretty busy, but any chance of getting this into :sysinstall? Maybe hindged on the size of the partition? : :-- :-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] :"I have the heart of a child; I keep it in a jar on my desk." It would be nice to up the default cylinders/group in sysinstall for larger partitions (anything over 8GB). I wouldn't up it to 159 as a default, but 32 would be a whole lot better then the current default 16, especially for fsck times. I think the default fragment/block should still be 1K/8K, even though I use 2K/16K on my own partitions. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Optimal UFS parameters
:In message [EMAIL PROTECTED], A G F Keahan writes: :What parameters should I choose for a large (say, 60 or 80Gb) :filesystem? I remember a while ago someone (phk?) conducted a survey, :but nothing seems to have come of it. In the meantime, the capacity of :an average hard drive has increased tenfold, and the defaults have :become even less reasonable. : :What's the current consensus of opinion? : :newfs -b ? -f ? -c ? : :Right now I tend to use: : : -b 16384 -f 4096 -c 159 : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 :[EMAIL PROTECTED] | TCP/IP since RFC 956 I think Bruce swears by 4K (page-sized) fragments. Not a bad way to go. I use 2K because I (and others) put in so much hard work to fix all the little niggling bugs in the VM system related to partial page validation and, damn it, I intend to use those features! -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Optimal UFS parameters
In message [EMAIL PROTECTED], Alfred Perlstein writes: Right now I tend to use: -b 16384 -f 4096 -c 159 I know you're pretty busy, but any chance of getting this into sysinstall? Maybe hindged on the size of the partition? sysinstall supports you changing the args to newfs, it has for a long time. The default lives in the options screen. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Optimal UFS parameters
* Poul-Henning Kamp [EMAIL PROTECTED] [001207 00:25] wrote: In message [EMAIL PROTECTED], Alfred Perlstein writes: Right now I tend to use: -b 16384 -f 4096 -c 159 I know you're pretty busy, but any chance of getting this into sysinstall? Maybe hindged on the size of the partition? sysinstall supports you changing the args to newfs, it has for a long time. The default lives in the options screen. I know that, I meant making it automagically scale as Matt suggested. I'd do it, but I don't really have a grasp on the optimal parameters to set based on FS size. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Shared Memory
Could anyone enlighten me on how to set the amount of shared memory? I'd like that info for FreeBSD 2.2.2, 3.x, 4.x Thanks... William Carlsson Second Line Support Teligent Nordic AB P.O. Box 213 S-149 21 Nynäshamn SWEDEN Telephone: +46 - 8 - 59 99 11 92 eMail: [EMAIL PROTECTED] http://www.teligent.se "And then it comes to be that the soothing light at the end of your tunnel was just a freight train, comin' your way." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Optimal UFS parameters
It would be nice to up the default cylinders/group in sysinstall for larger partitions (anything over 8GB). I wouldn't up it to 159 as a default, but 32 would be a whole lot better then the Well, if somebody wants to figure out the best defaults, they're easily set in sysinstall/label.c:new_part(); just calcuate the values dynamically rather than copying in the contents of VAR_NEWFS_ARGS. I'm sure it'd be a snap for a bunch of bright guys like you. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Optimal UFS parameters
In message [EMAIL PROTECTED], Alfred Perlstein writes: I'd do it, but I don't really have a grasp on the optimal parameters to set based on FS size. So far I don't see any indication here (or elsewhere) that anybody has that grasp. I guess that is really a testimony to FFS/UFS's qualites... The main thing is that you significantly reduce your fsck time if you reduce the number of inodes. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm_pageout_scan badness
Matt Dillon wrote: One possible fix would be to have the kernel track cache hits and misses on a file and implement a heuristic from those statistics which is used to reduce the 'initial page weighting' for pages read-in from the 'generally uncacheable file'. This would cause the kernel to reuse those cache pages more quickly and prevent it from throwing away (reusing) cache pages associated with more cacheable files like the .index and .hash files. I don't have time to do this now, but it's definitely something I am going to keep in mind for a later release. That sounds very, very clever. In fact, it sounds so clever I keep wondering what is the huge flaw with it. :-) Still, promising, to say the least. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] "The bronze landed last, which canceled that method of impartial choice." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Optimal UFS parameters
In message [EMAIL PROTECTED], Alfred Perlstein writes: So far I don't see any indication here (or elsewhere) that anybody has that grasp. I guess that is really a testimony to FFS/UFS's qualites... The main thing is that you significantly reduce your fsck time if you reduce the number of inodes. Oh, your tunables just reduce the number of inodes? That may come as a suprise to people that are using the larger disks to store images and web/ftp stuff. No they don't, I mainly reduce the number of cylinder-groups. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm_pageout_scan badness
Matt Dillon wrote: You may be able to achieve an effect very similar to mlock(), but runnable by the 'news' user without hacking the kernel, by writing a quick little C program to mmap() the two smaller history files and then madvise() the map using MADV_WILLNEED in a loop with a sleep(15). Keeping in mind that expire may recreate those files, the program should unmap, close(), and re-open()/mmap/madvise the descriptors every so often (like once a minute). You shouldn't have to access the underlying pages but that would also have a similar effect. If you do, use a volatile pointer so GCC doesn't optimize the access out of the loop. e.g. Err... wouldn't it be better to write a quick little C program that mlocked the files? It would need suid, sure, but as a small program without user input it wouldn't have security problems. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] "The bronze landed last, which canceled that method of impartial choice." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Support for Syba pci multi i/o card?
If there aren't any patches I might look at adding support for it. Probably only the serial ports, because that is what I need. I would like some advice on how to do it though. I had a look at the sio driver and it has support for a few pci cards, but it looks like they are single serial port cards and not dual or quad. So how should I go about getting the sio probe and attach to do more than one serial port per pci card? As Warner suggested, you probably want to create a "bus-like" device that looks to the sio/ppc drivers like an ISA bus, and then forcibly attach the relevant sio/ppc instances as children of this device. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: free() not freing pagedirs pages.
On 6 Dec, Matt Dillon wrote:
:
:OK. In fact my problem was just a printf that allocated a buffer via
:__smakebuf at the very last moment (when all memory was allocated).
:This prevent free() to give back all previous pages up to this one. The
:problem was _not_ in malloc.c.
:
:Anyway, i learned a lot from hacking the source to catch the caller.
:Thanks.
:
:RN.
:IhM
Not to mention library routines which might malloc() something and
keep it around.
I find that the best way to allocate a large chunk of memory is to
use mmap( ... MAP_ANON ... ). That way you have complete control
over the memory. You need only page-align the request size
(getpagesize() helps there). You can then manage the memory with
madvise(), and free it completely with munmap().
-Matt
Well, I may think using this solution if it remains portable between
Unixes. I finally tracked down the problem, after suppressing the
reason to call __smakebuf and tooling malloc.c.
What happens is that malloc() uses the pages to store pginfo chains. If
all memory is used, it allocates high addresses pages and (seems
to) keeps these pages when all memory have been freed().
Here is a case: In the following example, about 60 Mbytes have been
allocated then freed. Only one structure remains allocated at the very
beginning of the memory (It is the first one allocated).
page_dir size is 69632 bytes (17408 entries).
Quiet all page_dir entries are either MALLOC_NOT_MINE (mainly backed
to system, at end of page_dir) or MALLOC_FREE:
(gdb) p *page_dir@17408
$33 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x815b000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1,
0x2, 0x3 repeats 19 times, 0x1 repeats 65 times, 0x815b000,
0x1 repeats 111 times, 0x81cb000, 0x1 repeats 416 times, 0x836c000,
0x1 repeats 675 times, 0x861, 0x1 repeats 3228 times, 0x92ad000,
0x1 repeats 1181 times, 0x974b000, 0x1 repeats 587 times, 0x9997000,
0x1 repeats 1238 times, 0x9e6e000, 0x1 repeats 8398 times,
0x0 repeats 1468 times}
Here is the chain if non-magic entries:
(gdb) p *page_dir[5]
$22 = {next = 0x81cb000, page = 0x815b000, size = 32, shift = 5, free = 121,
total = 127, bits = {4294963088}}
(gdb) p *page_dir[5]-next
$23 = {next = 0x836c000, page = 0x81cb000, size = 32, shift = 5, free = 126,
total = 127, bits = {4294967294}}
(gdb) p *page_dir[5]-next-next
$24 = {next = 0x861, page = 0x836c000, size = 32, shift = 5, free = 126,
total = 127, bits = {4294967294}}
(gdb) p *page_dir[5]-next-next-next
$25 = {next = 0x92ad000, page = 0x861, size = 32, shift = 5, free = 125,
total = 127, bits = {4294901758}}
(gdb) p *page_dir[5]-next-next-next-next
$26 = {next = 0x974b000, page = 0x92ad000, size = 32, shift = 5, free = 126,
total = 127, bits = {4294967294}}
(gdb) p *page_dir[5]-next-next-next-next-next
$27 = {next = 0x9997000, page = 0x974b000, size = 32, shift = 5, free = 126,
total = 127, bits = {4294967294}}
(gdb) p *page_dir[5]-next-next-next-next-next-next
$28 = {next = 0x9e6e000, page = 0x9997000, size = 32, shift = 5, free = 126,
total = 127, bits = {4294967294}}
(gdb) p *page_dir[5]-next-next-next-next-next-next-next
$29 = {next = 0x0, page = 0x9e6e000, size = 32, shift = 5, free = 126,
total = 127, bits = {4294967294}}
So the program appears as a memory hog on the 'top' view, from a
user perspective. I agree that letting malloc madvise() usage hints of
pages to the kernel would prevent/help swapping but it is difficult to
explain in comprehensible words to many customers.
Thanks for any hint about this situation.
RN.
IhM
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: free() not freing pagedirs pages.
Remy Nonnenmacher [EMAIL PROTECTED] writes: Well, I may think using this solution if it remains portable between Unixes. It's perfectly portable, with one small variation - on BSD systems, you pass -1 instead of a file descriptor, while on SysV systems, you pass a descriptor to /dev/zero (or was it /dev/null?) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: free() not freing pagedirs pages.
Dag-Erling Smorgrav [EMAIL PROTECTED] writes: Remy Nonnenmacher [EMAIL PROTECTED] writes: Well, I may think using this solution if it remains portable between Unixes. It's perfectly portable, with one small variation - on BSD systems, you pass -1 instead of a file descriptor, while on SysV systems, you pass a descriptor to /dev/zero (or was it /dev/null?) FWIW, I just did some tests - mmap()'ing /dev/zero works on FreeBSD as well, and mapping the same fd multiple times gives you separate areas, so you don't need a new fd for each. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Optimal UFS parameters
Matt Dillon [EMAIL PROTECTED] wrote: The default filesystem parameters are: newfs -f 1024 -b 8192 -i 8192 -c 16 ... -i 4096 -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: free() not freing pagedirs pages.
In message [EMAIL PROTECTED], Remy Nonnenmacher wr ites: Well, I may think using this solution if it remains portable between Unixes. I finally tracked down the problem, after suppressing the reason to call __smakebuf and tooling malloc.c. Please examine the 'H' option to malloc. This does a much better job. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
mount_smbfs read_error
I've mount Win2k share, and for some reason there were read_error that cause REBOOT on my box. -- Dimitar Peikov Programmer Analyst "We Build e-Business" RILA Solutions 27 Building, Acad.G.Bonchev Str. 1113 Sofia, Bulgaria phone: (+359 2) 9797320 phone: (+359 2) 9797300 fax: (+359 2) 9733355 http://www.rila.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: free() not freing pagedirs pages.
On 7 Dec, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Remy Nonnenmacher wr ites: Well, I may think using this solution if it remains portable between Unixes. I finally tracked down the problem, after suppressing the reason to call __smakebuf and tooling malloc.c. Please examine the 'H' option to malloc. This does a much better job. I agree about the hints, but as i said at the end of my previous mail, this is hardly a clean-bill winning response against a customer sighting a 30/40 Mbytes 'top' column ;). RN. ItM To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: free() not freing pagedirs pages.
Please examine the 'H' option to malloc. This does a much better job. I agree about the hints, but as i said at the end of my previous mail, this is hardly a clean-bill winning response against a customer sighting a 30/40 Mbytes 'top' column ;). Top is not a very good indicator of memory use. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kqueue microbenchmark results
On Wed, Oct 25, 2000 at 05:01:17PM -0500, Jonathan Lemon wrote: I'd love to do that, but am not quite sure how I'd go about it. If you read the l-k mailing list, you'll see Linus calling kqueue "overengineered", and what he is proposing is something that is definitely not well thought out. Maybe Alexander Viro could help? He often follows what's happening in the BSD world and seems to do lots of good VFS type work in the Linux world. Matt Dillon recently worked with him on the file discriptor locking patches he committed. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Iomega ZIP boot problem
No answer from the -questions list, so I figured I'd try here. I'm encountering difficulties booting from a 250MB Iomega ZIP drive. The ZIP drive is installed as the primary master IDE. There's a UFS filesystem on /dev/afd0a. At the boot prompt, I enter boot: 0:ad(0,a)kernel afd0? is of course not an option here. Since the ZIP is configured in the BIOS to emulate an IDE HD, I take a stab. The kernel loads properly, devices are detected as per usual. At the stage where the root filesystem is remounted r/w, I get the following: CAPTURE> afd0: 239MB IOMEGA ZIP 250 ATAPI> [239/64/32] at ata0-master using PIO3 Mounting root from ufs:ad0s1a Root mount failed: 6 Mounting root from ufs:ad0sa Root mount failed: 6 Manual root filesystem specification: fstype>:device> Mount device> using filesystem fstype> eg. ufs:/dev/da0s1a ? List valid disk boot devices empty line> Abort manual input mountroot> /dev/afd0a Mounting root from /dev/afd0a Root mount failed: 22 mountroot> ufs:/dev/afd0a Mounting root from ufs:/dev/afd0a spec_getpages:(#afd/0) IO read failure: (error=0) bp 0xc1c78438 vp 0xc5ae1d40 size: 53248, resid: 32768, a_count: 53248, valid: 0x0 nread: 20480, reqpage: 7, pindex: 51, pcount: 13 vm_fault: pager read error, pid 1 (init) Nov 28 10:31:15 init: setlogin() failed: Bad address spec_getpages:(#afd/0) IO read failure: (error=0) bp 0xc1c78438 vp 0xc5ae1d40 size: 57344, resid: 32768, a_count: 57344, valid: 0x0 nread: 24576, reqpage: 7, pindex: 73, pcount: 14 vm_fault: pager read error, pid 6 (sh) pid 6 (sh), uid 0: exited on signal 11 Nov 28 10:31:16 init: /bin/sh on /etc/rc terminated abnormally, going to single user mode Enter full pathname of shell or RETURN for /sbin/sh: /CAPTURE> As you can see, manually selecting "/dev/afd0a" seems to be a valid option. However, once / is mounted, I get a series of read errors. There's more, though. If I hit "enter" a few times, it manages to execute /bin/sh and give me a prompt. At this point, most any command I type that isn't a shell builtin results in a few inital read failures followed by any number of successful operations. For example, if I tried to 'newfs' a partition, the first two attempts fail, and then I can 'newfs' as many partitions as I need. Seems like a caching issue, as if the latency of the drive exceeds the driver's expectation. This should not be an issue if it's using the "afd" driver. I'm wondering if this kind of operation is even supported? There don't seem to be any problems with the drive or the media, I can read and write files w/o errors with the drive mounted on a running system. Has anyone done this sort of thing successfully? If so, what am I missing? Thanks in advance... -Mark To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Shared Memory
In local.freebsd.hackers you write: Could anyone enlighten me on how to set the amount of shared memory? If you mean the wretched System V IPCs, the parameters are in LINT. Search for "SHM". I'd like that info for FreeBSD 2.2.2, 3.x, 4.x The parameters only have descriptive comments in 4.2, but I think they are the same in all releases (they're in LINT in RELENG_2 from '98 at least). $.02, /Mikko P.S. Hmm... there seems to be writable sysctl values (e.g. kern.ipc.shmmax). Maybe a kernel recompile isn't needed anymore. -- Mikko Työläjä[EMAIL PROTECTED] RSA Security To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: free() not freing pagedirs pages.
: :Dag-Erling Smorgrav [EMAIL PROTECTED] writes: : Remy Nonnenmacher [EMAIL PROTECTED] writes: : Well, I may think using this solution if it remains portable between : Unixes. : It's perfectly portable, with one small variation - on BSD systems, : you pass -1 instead of a file descriptor, while on SysV systems, you : pass a descriptor to /dev/zero (or was it /dev/null?) : :FWIW, I just did some tests - mmap()'ing /dev/zero works on FreeBSD as :well, and mapping the same fd multiple times gives you separate areas, :so you don't need a new fd for each. : :DES :-- :Dag-Erling Smorgrav - [EMAIL PROTECTED] There are three ways to use mmap() to allocate memory: #1 MAP_ANON, when supported, should be used. #2 /dev/zero, when supported, should be used (tends to be more portable then MAP_ANON). #3 Create a temporary file, hold the descriptor, remove() the file, ftruncate() to the proper length, then mmap using MAP_PRIVATE. And then you can close the descriptor. This actually takes up *NO* filesystem space, since it's a private map. You can also keep the descriptor around and allocate/free chunks using mmap()/munmap() out of it. Just remember that you have to ftruncate() the file to be big enough to 'hold' your mmap ranges. This tends to be the most portable. Which of the three one uses depends on the OS. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pipe
On Wed, Dec 06, 2000 at 09:50:55AM +0100, Dag-Erling Smorgrav wrote: "G. Adam Stanislav" [EMAIL PROTECTED] writes: On Tue, Dec 05, 2000 at 06:11:06PM +0100, Dag-Erling Smorgrav wrote: The second and third sentences of the second paragraph (the one that starts on line 23), as well as the entire eighth paragraph (that starts on line 45), address the questions you asked in your previous mail. I know it addresses it. Unfortunately, I didn't understand a word of it. I don't see how it could get any clearer. [...] If addr is zero, an address will be selected by the system. The actual starting address of the region is returned. NAME mmap - map files or devices into memory [...] doesn't immediately shout "You can use this function to allocate memory as well". Perhaps mmap - allocate memory, or map files or devices into memory would be better? In addition, mmap isn't listed in the SEE ALSO for malloc(3), nor is it listed in memory(3). mmap() is listed in malloc(3), but only in an error message. N -- Internet connection, $19.95 a month. Computer, $799.95. Modem, $149.95. Telephone line, $24.95 a month. Software, free. USENET transmission, hundreds if not thousands of dollars. Thinking before posting, priceless. Somethings in life you can't buy. For everything else, there's MasterCard. -- Graham Reed, in the Scary Devil Monastery To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm_pageout_scan badness
: :Matt Dillon wrote: : : You may be able to achieve an effect very similar to mlock(), but : runnable by the 'news' user without hacking the kernel, by : writing a quick little C program to mmap() the two smaller history : files and then madvise() the map using MADV_WILLNEED in a loop : with a sleep(15). Keeping in mind that expire may recreate those : files, the program should unmap, close(), and re-open()/mmap/madvise the : descriptors every so often (like once a minute). You shouldn't have : to access the underlying pages but that would also have a similar : effect. If you do, use a volatile pointer so GCC doesn't optimize : the access out of the loop. e.g. : :Err... wouldn't it be better to write a quick little C program that :mlocked the files? It would need suid, sure, but as a small program :without user input it wouldn't have security problems. : :-- :Daniel C. Sobral (8-DCS) :[EMAIL PROTECTED] :[EMAIL PROTECTED] mlock()ing is dangerous when used on a cyclic file. If you aren't careful you can run your system out of memory. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Optimal UFS parameters
In message [EMAIL PROTECTED] Matt Dillon writes: : : -b 16384 -f 4096 -c 159 : I think Bruce swears by 4K (page-sized) fragments. Not a bad : way to go. I use 2K because I (and others) put in so much hard work : to fix all the little niggling bugs in the VM system related to partial : page validation and, damn it, I intend to use those features! At the other end of the spectrum, 32M [sic] and 64M [sic] disks work well with -b 4096 -f 512 -c 10 But I tend to do what phk has done with the large -c flags on my insanely-sized, rediculously-cheap XXG IDE drives. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ptrace(PT_GETDBREGS) message in remote debugging
Thanks. I tried this on FreeBSD 4.2-Release (because I do not have a
stable or current), but I failed:
# make
Warning: Object directory not changed from original
/usr/src/gnu/usr.bin/binutils/gdb
cc: ../libbfd/libbfd.a: No such file or directory
cc: ../libopcodes/libopcodes.a: No such file or directory
cc: ../libiberty/libiberty.a: No such file or directory
*** Error code 1
Stop in /usr/src/gnu/usr.bin/binutils/gdb.
What should I do?
-Zhihui
On Wed, 6 Dec 2000, Brian Dean wrote:
Index: freebsd-nat.c
===
RCS file:
/usr00/FreeBSD/mirror/ncvs/src/gnu/usr.bin/binutils/gdb/i386/freebsd-nat.c,v
retrieving revision 1.21.4.2
diff -u -r1.21.4.2 freebsd-nat.c
--- freebsd-nat.c 2000/08/22 12:28:19 1.21.4.2
+++ freebsd-nat.c 2000/12/07 00:31:52
@@ -478,14 +478,16 @@
{
struct dbreg dbr;
extern int inferior_pid;
-
+
if (inferior_pid != 0 core_bfd == NULL)
{
int pid = inferior_pid ((1 17) - 1); /* XXX extract pid from tid */
-
+
if (ptrace(PT_GETDBREGS, pid, (caddr_t)dbr, 0) == -1)
{
- perror("ptrace(PT_GETDBREGS) failed");
+ /* don't complain on ESRCH, assume we are debugging a remote target */
+ if (errno != ESRCH)
+ perror("ptrace(PT_GETDBREGS) failed");
return 0;
}
#if WATCHPOINT_DEBUG 1
@@ -520,7 +522,10 @@
if (ptrace(PT_GETDBREGS, pid, (caddr_t)dbr, 0) == -1)
{
- perror("ptrace(PT_GETDBREGS) failed");
+ /* don't complain on ESRCH, assume we are debugging a remote target */
+ if (errno != ESRCH)
+ perror("ptrace(PT_GETDBREGS) failed");
+
return 0;
}
@@ -615,7 +620,9 @@
if (ptrace(PT_GETDBREGS, pid, (caddr_t)dbr, 0) == -1)
{
- perror("ptrace(PT_GETDBREGS) failed");
+ /* don't complain on ESRCH, assume we are debugging a remote target */
+ if (errno != ESRCH)
+ perror("ptrace(PT_GETDBREGS) failed");
return 0;
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: ptrace(PT_GETDBREGS) message in remote debugging
On Thu, Dec 07, 2000 at 03:30:51PM -0500, Zhiui Zhang wrote: Thanks. I tried this on FreeBSD 4.2-Release (because I do not have a stable or current), but I failed: # make Warning: Object directory not changed from original /usr/src/gnu/usr.bin/binutils/gdb cc: ../libbfd/libbfd.a: No such file or directory cc: ../libopcodes/libopcodes.a: No such file or directory cc: ../libiberty/libiberty.a: No such file or directory *** Error code 1 Stop in /usr/src/gnu/usr.bin/binutils/gdb. What should I do? Hmmm, looks like you haven't built world on this machine. No worries, just do this: % cd /usr/src/gnu/usr.bin/binutils % (cd libbfd make) % (cd libopcodes make) % (cd libiberty make) % (cd gdb make make install) This should build the missing libs and then gdb should link correctly. -Brian -- Brian Dean [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Optimal UFS parameters
: :In message [EMAIL PROTECTED] Matt Dillon writes: :: :-b 16384 -f 4096 -c 159 :: I think Bruce swears by 4K (page-sized) fragments. Not a bad :: way to go. I use 2K because I (and others) put in so much hard work :: to fix all the little niggling bugs in the VM system related to partial :: page validation and, damn it, I intend to use those features! : :At the other end of the spectrum, 32M [sic] and 64M [sic] disks work :well with : -b 4096 -f 512 -c 10 : :But I tend to do what phk has done with the large -c flags on my :insanely-sized, rediculously-cheap XXG IDE drives. : :Warner Well, too-large a C/G will result in greater file fragmentation, because FFS can't manage the file layouts in the cylinder groups as well. The default of 16 is definitely too little. 100+ is probably too much. Something in the middle will be about right. The fragmentation value returned by fsck would be an interesting number to publish. 'fsck -n /dev/...' on an idle fs (you don't have to unmount it). Anything over 3% fragmentation is a problem. Something like /usr will typically be in the 1-3% range. A large partition that is still half empty should be in the 0.0-0.5% range. A combination of a larger C/G (meaning fewer groups on the disk) and fewer inodes (a higher -i value) will dramatically decrease fsck times. After a certain point, though, continuing to increase C/G will not effect the fsck times. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Support for Syba pci multi i/o card?
In message [EMAIL PROTECTED] Mike Smith writes: : If there aren't any patches I might look at adding support for it. Probably : only the serial ports, because that is what I need. I would like some advice : on how to do it though. I had a look at the sio driver and it has support : for a few pci cards, but it looks like they are single serial port cards : and not dual or quad. So how should I go about getting the sio probe and : attach to do more than one serial port per pci card? : : As Warner suggested, you probably want to create a "bus-like" device that : looks to the sio/ppc drivers like an ISA bus, and then forcibly attach : the relevant sio/ppc instances as children of this device. sio doesn't care what bus it attaches to, so long as it can get its resources. ppc still has some isa specific calls in it, but those map to bus generic ones so would just work. I've been holding off working on this until I saw what haked out of the bus unification work that Matt Dodd has been working on. I think he's mostly done, but I wasn't sure enough of that to proceed. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ptrace(PT_GETDBREGS) message in remote debugging
Your patch works for me on FreeBSD 4.2-Release. Thanks. -Zhihui On Thu, 7 Dec 2000, Brian Dean wrote: On Thu, Dec 07, 2000 at 03:30:51PM -0500, Zhiui Zhang wrote: Thanks. I tried this on FreeBSD 4.2-Release (because I do not have a stable or current), but I failed: # make Warning: Object directory not changed from original /usr/src/gnu/usr.bin/binutils/gdb cc: ../libbfd/libbfd.a: No such file or directory cc: ../libopcodes/libopcodes.a: No such file or directory cc: ../libiberty/libiberty.a: No such file or directory *** Error code 1 Stop in /usr/src/gnu/usr.bin/binutils/gdb. What should I do? Hmmm, looks like you haven't built world on this machine. No worries, just do this: % cd /usr/src/gnu/usr.bin/binutils % (cd libbfd make) % (cd libopcodes make) % (cd libiberty make) % (cd gdb make make install) This should build the missing libs and then gdb should link correctly. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Optimal UFS parameters
This is a interesting topic (to me, anyway), and is one of the things that often gets overlooked by those of us with less experience. Rather than getting into a long discussion about modifying the newfs defaults across the board, what if the newfs options used were based on the size of the FS? There could be a simple rule in sysinstall that increased the newfs options from their default values if the defaults meant there would be more an x number of inodes and cg's. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Kernel question (detecting a user log-on)
Hi Hackers, I'm wondering about two things, how does the kernel detect that a user logs on a tty, and what should I know if I was to write a kernel module that detects it (And does something about it)? Must I read the TCP in-packets for port 23 and detect if a user logged on? I'm pretty unsure about this.. I know it could easier be implemented in userland by reading the _PATH_UTMP file, but I'm more interested in doing it in kernel space. Thanks in advance -- Torbjorn Kristoffersen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Support for Syba pci multi i/o card?
In message [EMAIL PROTECTED], Warner Losh writes: In message [EMAIL PROTECTED] Mike Smith writes: : If there aren't any patches I might look at adding support for it. Probably : only the serial ports, because that is what I need. I would like some advice : on how to do it though. I had a look at the sio driver and it has support : for a few pci cards, but it looks like they are single serial port cards : and not dual or quad. So how should I go about getting the sio probe and : attach to do more than one serial port per pci card? : : As Warner suggested, you probably want to create a "bus-like" device that : looks to the sio/ppc drivers like an ISA bus, and then forcibly attach : the relevant sio/ppc instances as children of this device. sio doesn't care what bus it attaches to, so long as it can get its resources. ppc still has some isa specific calls in it, but those map to bus generic ones so would just work. I've been holding off working on this until I saw what haked out of the bus unification work that Matt Dodd has been working on. I think he's mostly done, but I wasn't sure enough of that to proceed. There is a PR already with a patch for some multiport cards... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Support for Syba pci multi i/o card?
In message 92918.976225307@critter Poul-Henning Kamp writes: : There is a PR already with a patch for some multiport cards... Yes. I'm aware of that patch... But I don't like it because it doesn't use the multiio pseudo-bus thing that I talked about. Bruce also has some style concerns with it :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Packet Header Filtering
We are about to begin a little project that has the following requiremnet. Perform IP packet filtering in the following way : i) look at an ip packet header. If some conditions are met let the packet pass otherwise reject the packet. ii) Look at ip packet headers of established connections and when certain conditions are met tear down the connection. Obviously this isn't the kind of thing we will be using the usual firewall software, at least not as I understand the software. What I want to know from you FreeBSD hackers is: i) if anyone has done something similar do you have any advice. ii) Anyone know where I should start hacking. Would it be best to try to hack the firewall code or the ipforwarding code Any such advise would be helpful. Alwyn Goodloe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCIOCGETCONF/PCIOCREAD requires write permission?
As I recall, Matthew Jacob wrote: Agreed. Thanks for spotting this, Andrew. No, we should not let users read PCI registers in such a fashion that will cauase the system to crash. Ok, I guess just because it's the holiday season, I feel like opening a can of worms. I thought the space staked out by the *BSD gang was approximately this: NetBSD - the least amount of platform-specific code possible; run on most anything OpenBSD - pro-active security, bullet-proof from attacks FreeBSD - best performing on the Intel PC platform If that's accurate (and it may not be), then how concerned should we be about the Alpha port? Isn't Alpha (and SPARC, etc) the space stake out by the NetBSD gang? I'm not trying to foster a war here. There seems to be enough of that anyway. But unless this PCI register reading thingie is an issue for i386 boxen (and I don't think it is) we shouldn't cripple functionality on the i386 for the Alpha. Has the core group ever weighed in on this? Does the BSDi merger change any of the FreeBSD focus with regard to other hardware architectures? -crl -- Chad R. Larson (CRL15) 602-953-1392 Brother, can you paradigm? [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] DCF, Inc. - 14623 North 49th Place, Scottsdale, Arizona 85254-2207 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Optimal UFS parameters
How frequently do people fsck? -- TJ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCIOCGETCONF/PCIOCREAD requires write permission?
In message [EMAIL PROTECTED] "Chad R. Larson" writes: : Has the core group ever weighed in on this? Does the BSDi merger : change any of the FreeBSD focus with regard to other hardware : architectures? Core, per se, hasn't. There's a very strong history in this project that if a port is supported, breaking it is unacceptible. FreeBSD has moved beyond intel only, and we need to deal with that, even if there are things we can get away with on i386 and can't on other platforms. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
(Hurm Wintendo outperforming unix???!?? Something's improper about this, and it ought to be fixed... :-) Comments? Other OS numbers: more recent FreeBSD versions? Solaris? Tru64? Optimization patches? Can those OO MSDN lobotomies actually be good things? Hurm... The Italian gauntlet has been thrown down --dr :-) url: http://netgroup-serv.polito.it/winpcap/docs/performance.htm Performance and tests 1. Packet Capture Driver Performance The main goal of a packet capture driver are performance. This means low use of system resources (memory and processor) but also low probability of loosing packets. The following main parameters influence the performances of the capture process: the efficiency of the filter, size of the packet buffer, the number of bytes copied and the number of system call that needs to be executed by the application. 1. The efficiency of the packet filter is a very important parameter, because the filter must be applied to every incoming packet (i.e. thousands of times per second). The packet capture driver uses the fast and highly optimized BPF filter (for more details about the performances of BPF filter, see [McCanne and Jacobson 1993]), whose virtual-processor architecture is suited for modern computers architectures. 2. More optimized packet filters have been developed after the original BPF. The more interesting for this kind of applications are MPF [13], and BPF+ [12]. The packet capture driver does not offer at the moment the advenced features of these two filters. It could be very useful to include in the driver the possibility to efficiently handle similar filters in a way similar to MPF. 3. Kernel buffer's size is the parameter that influences the number of packet loss during a capture; a bigger buffer means lower loss probability. Since the correct size of the buffer is a very subjective parameter and depends on various factors like network speed or machine characteristics, the packet capture driver offers a dynamic buffer that can be set to any size whenever the user wants to do that. In this way it is possible to set very big buffers on machines with an huge amount of RAM. Notice however that the buffer is freed when the driver's instance is closed, therefore the memory is used by the driver only during the capture process (i.e. when really needed). 4. Performances are strongly influenced by the number of bytes that need to be copied by the system. This task can absorb a lot of processor time and buffer memory. To overcome the problem, the packet capture driver applies the filter to an incoming packet as soon as it arrives to the system: the packet is filtered when it is still in the NIC driver's memory, without copying it. This means that no copy is needed to filter the packet. The filter tells how many bytes of the packets are needed by the user-level application (for example WinDump needs only the first 68 bytes of each packet). The packet capture driver copies only this amount of bytes (instead of the whole packet) to the circular buffer. This is very important also because reduces the space occupied by the packet in the circular buffer that is used more efficiently. The selected packet is then copied to the user-level application during a read system call. Summarizing, there are two copies of the cut packet, none of the entire packet that is equivalent of the number of copies done by the UNIX version. 5. Each read system call implies a context switch from user-mode (ring 3) to kernel-mode (ring 0) plus another another to return to user-mode. This process is notoriously slow and can influence the capture performances. Since a user-level application might want to look at every packet on the network and the time between packets can be only a few microseconds, it is not possible to do a read system call for each packet. The packet capture driver collects the data from several packets and copies it to the application's buffers in a single read call. The number of packets copied is not fixed and depends on the dimension of the application's buffer that will receive the packets: the driver detects the size of this buffer, and copies packets to it until it's full. Therefore, it is possible to decrease the number of system calls increasing the size of the application's read buffer. 2. Tests This Section aims at giving some indications about the performance of the capture process on various operating systems. Results obtained under the various Windows platforms have been compared with the ones provided by BPF/libpcap/TCPdump in FreeBSD 3.3 in order to determine the goodness of our implementation. 2.1 Testbed The testbed (shown in next figure) involves two PCs directly connected by means of a Fast Ethernet link. This assures the isolation of the testbed from external sources (our LAN), allowing accurate tests. A Windows NT workstation using the 'TG' tool (available into the developer's pack) based on the packet capture device
Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
* Dragos Ruiu [EMAIL PROTECTED] [001207 21:18] wrote: (Hurm Wintendo outperforming unix???!?? Something's improper about this, and it ought to be fixed... :-) Comments? Other OS numbers: more recent FreeBSD versions? Solaris? Tru64? Optimization patches? Can those OO MSDN lobotomies actually be good things? Hurm... The Italian gauntlet has been thrown down --dr :-) url: http://netgroup-serv.polito.it/winpcap/docs/performance.htm I'm looking at this, FreeBSD seems to better on all accounts except writing the packets to disk. Can any of the winpcap people explain exactly how they measured the disk performance? The graph's title is: "WinDump performance" under the section called "WinDump capture performance". I'm very curious how they managed to run "windump" on FreeBSD. I'd also be interested in at least getting a copy of their emulator. :) Honestly, it really looks like the fault lies with the way tcpdump writes to disk and not with FreeBSD. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
On Thu, Dec 07, 2000 at 09:47:20PM -0800, Matt Dillon wrote:
Looking at the data I would guess that they
are appending to a file using write()'s on a packet-by-packet basis
Unlikely, given that they're using "tcpdump", which, with the "-w" flag,
writes using standard I/O, and doesn't do "fflush()"es on a
packet-by-packet basis.
or with a redirect from tcpdump on a shell line,
Assuming, as I suspect is the case, that they're using the same command
on the OSes in question (or using "tcpdump" on FreeBSD and "windump" on
Windows), that's also unlikely - it's just "{tcp,win}dump -w test.acp".
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: [tcpdump-workers] Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
On Thu, Dec 07, 2000 at 09:06:04PM -0800, Dragos Ruiu wrote: (Hurm Wintendo outperforming unix???!?? Something's improper about this, and it ought to be fixed... :-) Comments? Other OS numbers: more recent FreeBSD versions? Solaris? Tru64? Optimization patches? As an experiment, changing BPF_MAXBUFSIZE to 1MB, and changing libpcap to use a 1MB buffer, on FreeBSD? (That might help the "whole packet dumped" test.) Somehow measuring how large the byte count in the capture file "write()" calls in FreeBSD and "WriteFile()" calls are? (FreeBSD is probably doing 8K writes, assuming it's writing to an 8K/1K file system; I don't know what block size the MSVC++ version of the standard I/O library uses, but it might well use bigger chunks than 8K.) Can those OO MSDN lobotomies actually be good things? I'm not sure the parts of the OS that are actually involved are particularly object-oriented; I have the impression most of the COM, etc. stuff lives well up in userland on Windows. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
On Thu, Dec 07, 2000 at 09:47:20PM -0800, Matt Dillon wrote: Looking at the data I would guess that they are appending to a file using write()'s on a packet-by-packet basis Or, as per my other mail, perhaps using, on Windows, a version of the standard I/O library that does bigger writes, hence fewer system calls. (That might require a bigger kernel buffer in the capture mechanism to keep the capture buffer from overflowing whilst you're busy copying data to file pages in the write, but, in fact, WinPcap is using a 1MB kernel buffer on Windows, rather than the 32K buffer that's used on FreeBSD.) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
On Thu, Dec 07, 2000 at 11:38:09PM -0800, Matt Dillon wrote: It amounts to the same thing, since -w does nothing more then an fopen(..."w"). You get a pidly 8K buffer out of that, and it isn't even double buffered. But I think the last poster had it right... if the bpf buffer size was not changed from the default 4096, just about anything can interrupt the packet flow. (If "the last poster" suggested cranking up BPF_MAXBUFSIZE, that was me.) libpcap's default in FreeBSD 3.4 is 32768, not 4096 - 4096 is the kernel's default, but libpcap overrides that - but that's still significantly lower than 1MB. I'm curious whether there's any compelling reason why you can't do an SIOCSBLEN on a device that's already been attached to an interface; perhaps it could do a "bpf_detachd()" if it was attached to an interface, and then do a "bpf_attachd()" after changing the size. However, that would work only on systems with a modified kernel; an alternative would be to add an variant of "pcap_open_live()" that took a buffer size argument, which could be made to work on existing BSD systems (as well as many other systems - including Windows :-)). That wouldn't help, though, unless BPF_MAXBUFSIZE were cranked up; it's 524288 in 4.x - that happened in delta 1.21: Revision 1.21 / (download) - annotate - [select for diffs], Sat Jan 15 19:46:12 2000 UTC (10 months, 3 weeks ago) by phk CVS Tags: RELENG_4_BP Branch point for: RELENG_4 Changes since 1.20: +2 -2 lines Diff to previous 1.20 (colored) |The hard limit for the BPF buffer size is 32KB, which appears too low |for high speed networks (even at 100Mbit/s this corresponds to 1/300th |of a second). The default buffer size is 4KB, but libpcap and ipfilter |both override this (using the BIOCSBLEN ioctl) and allocate 32KB. | |The following patch adds an sysctl for bpf_maxbufsize, similar to the |one for bpf_bufsize that you added back in December 1995. I choose to |make the default for this limit 512KB (the value suggested by NFR). so it might be interesting to retry the tests on a 4.x system, with the 32768 in pcap-bpf.c changed to 524288. It might also be interesting to try throwing a "setvbuf()" call into libpcap, to crank up the standard I/O buffer size (although on systems with small kernel buffers in the capture mechanism, a large write *might* take enough time that you could fill up and then overflow that buffer). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: More on BTX halted / crashes trying to use -stable /boot/loader
At 16:02 -0800 12/7/00, Jim Browne wrote: When TFTP tries to open a file, it is expecting struct open_file member f_devdata to be a pointer to a socket number. When currdev is "pxe", that assumption is correct. When currdev is "disk*", that assumption is incorrect. Specifically, tftp.c does: tftpfile-iodesc = io = socktodesc(*(int *) (f-f_devdata)); In my case, that often winds up making tftpfile-iodesc = 0. That parameter is later passed in tftp_makereq to sendrecv as the iodesc, which via sendudp (and possibly the ARP functions) winds up calling netif_put. netif_put derefs the bogus iodesc to get a function pointer for the put function of the network interface and calls it. WHAM. QED. :) How does this look? *** tftp.c Thu Dec 7 16:20:02 2000 --- tftp2.c Thu Dec 7 16:20:55 2000 *** tftp_open(path, f) *** 257,260 --- 257,262 tftpfile-iodesc = io = socktodesc(*(int *) (f-f_devdata)); + if (io == NULL) + return (EINVAL); io-destip = servip; tftpfile-off = 0; (I suppose I could have included this earlier. Ugh.) Jim Browne[EMAIL PROTECTED] "We lost our lease. You lose culture" - sign on SF Arts Comission Bldg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: More on BTX halted / crashes trying to use -stable /boot/loader
This is probably an OK workaround. I think that there's something fundamentally wrong with the 'net' filesystems getting called for an open against a disk device, but I've paged out all the libstand state and I can't get it back fast enough to comment more usefully. 8( BTW Jim, the stuff you're working on sounds really cool. Thanks for taking it on! At 16:02 -0800 12/7/00, Jim Browne wrote: When TFTP tries to open a file, it is expecting struct open_file member f_devdata to be a pointer to a socket number. When currdev is "pxe", that assumption is correct. When currdev is "disk*", that assumption is incorrect. Specifically, tftp.c does: tftpfile-iodesc = io = socktodesc(*(int *) (f-f_devdata)); In my case, that often winds up making tftpfile-iodesc = 0. That parameter is later passed in tftp_makereq to sendrecv as the iodesc, which via sendudp (and possibly the ARP functions) winds up calling netif_put. netif_put derefs the bogus iodesc to get a function pointer for the put function of the network interface and calls it. WHAM. QED. :) How does this look? *** tftp.c Thu Dec 7 16:20:02 2000 --- tftp2.c Thu Dec 7 16:20:55 2000 *** tftp_open(path, f) *** 257,260 --- 257,262 tftpfile-iodesc = io = socktodesc(*(int *) (f-f_devdata)); + if (io == NULL) + return (EINVAL); io-destip = servip; tftpfile-off = 0; (I suppose I could have included this earlier. Ugh.) Jim Browne[EMAIL PROTECTED] "We lost our lease. You lose culture" - sign on SF Arts Comission Bldg -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: More on BTX halted / crashes trying to use -stable/boot/loader
At 17:44 -0800 12/7/00, Mike Smith wrote: This is probably an OK workaround. I think that there's something fundamentally wrong with the 'net' filesystems getting called for an open against a disk device, but I've paged out all the libstand state and I can't get it back fast enough to comment more usefully. 8( A "better" thing to do would be for tftp_open to check the dv_type of the struct devsw member of struct open_file to see if it is a network device. However, stand.h has a comment stating that the dv_type member of struct devsw is an "opaque type constant, arch-dependant". Since tftp.c is in the arch-neutral libstand(3), I figured it would be bad for tftp.c to gain knowledge of the "opaque" db_type field. Regardless, the check I added should be there as it was an uncovered error condition. BTW Jim, the stuff you're working on sounds really cool. Thanks for taking it on! Apparently I am a glutton for punishment. Expect more bugfix patches in the near future. Jim Browne[EMAIL PROTECTED] "We lost our lease. You lose culture" - sign on SF Arts Comission Bldg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: More on BTX halted / crashes trying to use -stable /boot/loader
Regardless, the check I added should be there as it was an uncovered error condition. ... and I just realised I deleted your patch. D'oh! BTW Jim, the stuff you're working on sounds really cool. Thanks for taking it on! Apparently I am a glutton for punishment. Expect more bugfix patches in the near future. Heh. If you're interested in maintaining this, maybe we need to get you commit access... -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: More on BTX halted / crashes trying to use -stable /boot/loader
:I've already looked at this, investigating a problem reported in :connection with PR 21559. I'll probably sort it out in the next day :or two, unless someone else gets there first. : :-- :Robert Nordier : :[EMAIL PROTECTED] :[EMAIL PROTECTED] That'd be great. When you have a patch, if you email it to me I will test it on a box that I know crashes on the currennt problem. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: More on BTX halted / crashes trying to use -stable /boot/loader
Matt Dillon wrote: I sure would appreciate it if one of the bootstrap gurus could take a look at what happens when the tftp open routine is called from a normal disk-based /boot/loader! I've already looked at this, investigating a problem reported in connection with PR 21559. I'll probably sort it out in the next day or two, unless someone else gets there first. -- Robert Nordier [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: More on BTX halted / crashes trying to use -stable/boot/loader
At 00:13 -0800 12/7/00, Mike Smith wrote: The option works wonderfully for /boot/pxeboot. But it turns out that the normal /boot/loader, when compiled with the above option, will crash horribly whenever it tries to open() a file and can't find it in the UFS filesystem on disk... it falls through the filesystem list until it hits the tftp FS and BEWM. Explosion. I sure would appreciate it if one of the bootstrap gurus could take a look at what happens when the tftp open routine is called from a normal disk-based /boot/loader! Probably hits an uninitialised function vector; this would be a good catch for someone looking to learn a bit about the loader and libstand. Devsw "pxedisk" treats struct open_file member f_devdata as a pointer to a socket number[1]. Other devsw drivers treat f_devdata as a pointer to a struct i386_devdesc[2]. When you boot via PXE, sys/boot/i386/loader/main.c sets the current device to "pxedisk". If you do not boot via PXE, your current device is likely to be some take on "disk". When TFTP tries to open a file, it is expecting struct open_file member f_devdata to be a pointer to a socket number. When currdev is "pxe", that assumption is correct. When currdev is "disk*", that assumption is incorrect. Specifically, tftp.c does: tftpfile-iodesc = io = socktodesc(*(int *) (f-f_devdata)); In my case, that often winds up making tftpfile-iodesc = 0. That parameter is later passed in tftp_makereq to sendrecv as the iodesc, which via sendudp (and possibly the ARP functions) winds up calling netif_put. netif_put derefs the bogus iodesc to get a function pointer for the put function of the network interface and calls it. WHAM. QED. :) I happen to be knee deep in this code right now as I am adding two things: support for booting from a flash based FS and porting the netboot Ethernet drivers to work under libstand(3) so I can use loader(8) with an AMD LANCE compatible chip. I was lurking until my code was finished, but your problem (which I was debugging today for my own configuration) is a good opportunity to speak up. I think the correct solution is to not overload f_devdata. Perhaps another field should be added to struct open_file specifically for a socket number and perhaps some error checking code is in order? :) I have to have my code working yesterday, so I'll keep plugging along on a solution. I'll email patches when finished. However, there are others who are far more familiar with this code than I, so pointers are appreciated especially from Alpha aware people. (I haven't even looked at the Alpha version of loader(8).) [1] sys/boot/i386/libi386/pxe.c function pxe_open towards the bottom. Actually, pxe.c just overwrites what is likely a pointer to a i386_devdesc that was allocated by i386_parsedev (i.e. memory leak). [2] sys/boot/i386/libi386/devicename.c function i386_parsedev On a final note: why is netif_drivers defined in pxe.c rather than conf.c? I'm currently working around that with a Makefile define, but I really think the defition of netif_drivers belongs in conf.c, especially if one is to have more than one netif_driver compiled into the binary (i.e. "pxe" and "ether") Jim Browne[EMAIL PROTECTED] "We lost our lease. You lose culture" - sign on SF Arts Comission Bldg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: More on BTX halted / crashes trying to use -stable /boot/loa
On 08-Dec-00 Jim Browne wrote: At 16:02 -0800 12/7/00, Jim Browne wrote: When TFTP tries to open a file, it is expecting struct open_file member f_devdata to be a pointer to a socket number. When currdev is "pxe", that assumption is correct. When currdev is "disk*", that assumption is incorrect. Specifically, tftp.c does: tftpfile-iodesc = io = socktodesc(*(int *) (f-f_devdata)); In my case, that often winds up making tftpfile-iodesc = 0. That parameter is later passed in tftp_makereq to sendrecv as the iodesc, which via sendudp (and possibly the ARP functions) winds up calling netif_put. netif_put derefs the bogus iodesc to get a function pointer for the put function of the network interface and calls it. WHAM. QED. :) How does this look? *** tftp.c Thu Dec 7 16:20:02 2000 --- tftp2.c Thu Dec 7 16:20:55 2000 *** tftp_open(path, f) *** 257,260 --- 257,262 tftpfile-iodesc = io = socktodesc(*(int *) (f-f_devdata)); + if (io == NULL) + return (EINVAL); io-destip = servip; tftpfile-off = 0; (I suppose I could have included this earlier. Ugh.) Looks fine to me.. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
