Re: FreeBSD performing worse than Linux?
In message: [EMAIL PROTECTED] Matthew Dillon [EMAIL PROTECTED] writes: : I think that has been fixed. Try it. It doesn't lag for me. The : turn-around echo of the keystroke should be pushed out instantly. Yes. Keep in mind that you only need to enable this when you have unacked data. Otherwise, NODELAY doesn't buy you anything. I routinely go over non-NODELAY links and haven't seen a huge problem except when modems were involved that liked to freak out. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD performing worse than Linux?
Louis A. Mamakos wrote: Disabling Nagle's algorithm for no good reason has very poor scaling behavior. This is what happens when TCP_NODELAY is enabled on a socket. Disabling Nagle's algorithm for a good reason would still result in the observed failure, however. If you look at the work function for most network elements, the part that runs out of gas first is per-packet forwarding performance. Sure, you need to have adequate bus bandwidth to move stuff through a box, but it's performing per-packet forwarding operations and policy which is the resource that's most difficult to make more of. I think this is true for toy routers based on PC platform as well as high-end boxes like the Cisco 12000 series. Juniper managed adequate forwarding performance using specialized ASIC implementions in the forwarding path. Of this statement, I'm sure; in my day job at UUNET, I talk to all the major backbone router vendors, and forwarding performance (and also reasonable routing protocol implementions) is a show-stopper requirement they labor mightily over. PCI is sufficient to keep a Gigabit interface saturated, even without going to jumbograms. I have personally saturated such an interface. PCI-X will scale to 8 Gigabits. So here was have a mechanism with wonderful properties - it's a trivial yet clever implementation of a self tuning mechanism to prevent tinygrams from being generated by a TCP without all manner of complicated timers. It give great performance on LAN and other high-speed interconnects where remote echo type applications are demanding, yet over long delay paths where remote echo is gonna suck no matter what you do, it automatically aggregates packets. As a bandwidth provider, UUNET is more concerned with aggregate throughput; this means it cares more about the moving average of packets getting through than it does about *my* packets getting through. When it comes to a conflict of interest, you will understand my preferences are for my own interests... 8-). Nagle's algorithm and Van Jacobson's slow-start algorithm allowed the Internet to survive over congested paths. And they did so with a bunch of self-tuning behavior independent of the bandwidth*delay product of the path the connection was running over. It was and is amazing stuff. Yes, I'm well aware of bandwidth delay product calculations; it's the primary mechanism behind the rate halving algorithm I keep pointing to (Hoe, Jacobson). 8-). It's also the primary limitation on connection speed (remember that it was my FreeBSD machine that was able to get to 1.6M connections, with standard sockets). Likewise, the original problem in this thread is likely caused by some part of the USB Ethernet implementation having inadequate per-packet resources. It's probably not about the number of bytes, but the number of transactions. You see here a modern reimplementation of essentially the same problem that the 3COM 3C501 ISA ethernet card had 15 years ago - back to back packets were consistantly dropped because of the poor per-packet buffering implementation. It was absolutely repeatable. Clearly. I think that's well established, since no one has squawked about the FreeBSD USB driver or the PC USB hardware being slower than the dongle USB hardware... Sure, it's legal to generate streams of tinygrams and not use Nagle's algorithm to aggregate the sender's traffic, but it's just plain rude and on low bandwidth links, it sucks because of all the extra 40 byte headers you're carrying around. I understand this. But Nagle is not the only mechanism which would fix the problem. Given that it's *intentionally* possible *and permitted* to turn Nagle off (via TCP_NODELAY), it makes sense to look at another mechanism that is not succeptible to being turned off. I'm sure TCP_NODELAY got added because it sounds REALLY C00L to make the interactive thing go better. But clearly people don't understand the impact of turning on the cleverly named option and how it probably doesn't really improve things. I'm pretty sure it got added to address interactive response on intrinsically small packets; telnet was probably the number one reason, but interactive responsiveness of small requests over TCP, such as non-pipelined HTTP requests, SMTP server responses, FTP control channel traffic, and other protocols benefit significantly from turning Nagle off. Nagle almost suggests it, in the original paper. Since OpenSSH incredibly bloats payload, it's much less necessary to get performance as it would be out of Telnet, though you will likely see least common multiples of the MTU cause occasionaly burstiness. Probably in this case, it would make sense to increase the decay rate of the timer based on the amount of data that is pending, relative to the MTU: defeat Nagle when the pipe is full, and partially defeat it down to, say, the pipe being half full. Thus large streams not ending on MTU boundaries would not
Re: FreeBSD performing worse than Linux?
M. Warner Losh wrote: In message: [EMAIL PROTECTED] Matthew Dillon [EMAIL PROTECTED] writes: : I think that has been fixed. Try it. It doesn't lag for me. The : turn-around echo of the keystroke should be pushed out instantly. Yes. Keep in mind that you only need to enable this when you have unacked data. Otherwise, NODELAY doesn't buy you anything. I routinely go over non-NODELAY links and haven't seen a huge problem except when modems were involved that liked to freak out. My experience agrees with David's. It makes sense to set TCP_NODELAY on the client, still, if the payload is still small enough after encryption. On the server side, it makes less sense. The server side TCP_NODELAY is the problem in this case, since it is the client, not the server, which is on the slow side of a USB dongle, FWIW. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Running out of bufferspace
[ root@hera:~ ] # truss mount -t smbfs //drwilco@ceres/D$ /ceres/d_drive/
readlink(/etc/malloc.conf,0xbfbffa94,63) ERR#2 'No such file or
directory'
--SNIP--
fork() = 3331 (0xd03)
smbfs: can't get server address: syserr = No buffer space available
SIGNAL 20
wait4(0xd03,0xbfbff088,0x0,0x0) = 3331 (0xd03)
exit(0x1) process exit, rval = 256
This of course is useless, since mount fork()s and mount_smbfs does the
real stuff which isn't visible
So here's the real deal. (After using my device once and not running out of
bufferspace on that run)
[ root@hera:~ ] # truss mount_smbfs //drwilco@ceres/C$ /ceres/c_drive/
---SNIP---
ioctl(3,SIOCGIFADDR,0x8051440) = 0 (0x0)
ioctl(3,SIOCGIFNETMASK,0x8051440)= 0 (0x0)
ioctl(3,SIOCGIFFLAGS,0x8051460) ERR#6 'Device not configured'
ioctl(3,SIOCGIFFLAGS,0x8051480) ERR#6 'Device not configured'
ioctl(3,SIOCGIFFLAGS,0x80514a0) ERR#6 'Device not configured'
ioctl(3,SIOCGIFFLAGS,0x80514c0) ERR#6 'Device not configured'
ioctl(3,SIOCGIFFLAGS,0x80514e0) ERR#6 'Device not configured'
close(3) = 0 (0x0)
socket(0x2,0x2,0x0) = 3 (0x3)
setsockopt(0x3,0x,0x20,0xbfbfeef8,0x4) = 0 (0x0)
bind(0x3,{ AF_INET 192.168.0.1:0 },16) = 0 (0x0)
sendto(0x3,0x8050010,0x32,0x0,0x804f024,0x10)= 50 (0x32)
select(0x4,0xbfbfee8c,0xbfbfee0c,0xbfbfed8c,0xbfbfed74) = 0 (0x0)
sendto(0x3,0x8050010,0x32,0x0,0x804f024,0x10)= 50 (0x32)
select(0x4,0xbfbfee8c,0xbfbfee0c,0xbfbfed8c,0xbfbfed74) = 0 (0x0)
sendto(0x3,0x8050010,0x32,0x0,0x804f024,0x10)= 50 (0x32)
select(0x4,0xbfbfee8c,0xbfbfee0c,0xbfbfed8c,0xbfbfed74) = 0 (0x0)
sendto(0x3,0x8050010,0x32,0x0,0x804f024,0x10)= 50 (0x32)
select(0x4,0xbfbfee8c,0xbfbfee0c,0xbfbfed8c,0xbfbfed74) = 0 (0x0)
close(3) = 0 (0x0)
socket(0x2,0x2,0x0) = 3 (0x3)
setsockopt(0x3,0x,0x20,0xbfbfeef8,0x4) = 0 (0x0)
bind(0x3,{ AF_INET 192.168.0.1:0 },16) = 0 (0x0)
sendto(0x3,0x8050010,0x32,0x0,0x804f024,0x10)= 50 (0x32)
select(0x4,0xbfbfee8c,0xbfbfee0c,0xbfbfed8c,0xbfbfed74) = 0 (0x0)
sendto(0x3,0x8050010,0x32,0x0,0x804f024,0x10)ERR#55 'No buffer space
available'
close(3) = 0 (0x0)
mount_smbfs: write(2,0xbfbfe884,13) = 13 (0xd)
can't get server addresswrite(2,0xbfbfe8a4,24) =
24 (0x18)
: syserr = No buffer space available
write(2,0xbfbfe874,37) = 37 (0x25)
sigprocmask(0x1,0x2805cbe0,0xbfbff0ac) = 0 (0x0)
sigprocmask(0x3,0x2805cbf0,0x0) = 0 (0x0)
exit(0x1) process exit, rval = 256
So again... which buffer(s) could this be, and how do I check its/their status?
Doc
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Running out of bufferspace
In a message dated 12/31/01 11:52:47 PM Eastern Standard Time, [EMAIL PROTECTED] writes: Thing is, my mbufs are fine, peak is 1/3rd of max. I also use sowriteable() to check if it's safe to send, and sbspace() tells me I have the full 128K sndbuf that I configured available. So I have 2 questions... 1) which buffers are there that I can run out of here and where can I check their status? 2) Should I free() the uio I get from userspace after I have passed it to the sosend? Just note that no buffers often means that the queue is full, not that you are out of system buffers. You may be chasing a ghost. Dennis To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD performing worse than Linux?
Remember also that Matt recently shot Reno for performance reasons Actually, it was turned back on less than 72 hours later, when he found/fixed a bug in NewReno. It was only off for a little bit, and only in -stable. , when compared to Linux, when he should probably have simply cranked initial window size to 3 (Jacobson) and added piggy-back ACKs (Mogul). See above. You need to pay more attention to what's going on. :) Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
The Hurd
Hi About a month ago, I wrote this mailing-list asking if the FreeBSD developers had analysed and learned from the Solaris and Linux kernel. I got some good answers (thank you), but now I have one more question. From the 27/12 too the 29/12 I was at the CCC congress and attended a lecture called Unix Redesigned. It was Neal H Walfield who talked about The Hurd: http://www.gnu.org/software/hurd http://www.debian.org/ports/hurd So my question is: Will FreeBSD take a good look at the Hurd? I know the last Hurd release was in 1997, but within this year a new release will be made. I don't expect FreeBSD to rewrite the whole kernel, but just too use some of the things or make a combination. Fx now users can have more id's and deamons run as null. I know that this will take a lot of work, but I don't have the programming knowledge too make these changes myself, but when I am finished with my computer education I will financially support FreeBSD and ofcourse write some programs. Until then all I can do is make FreeBSD aware of other alternativs and thereby insuring that FreeBSD is in front (some of the hurds way of doing things are the way of the future, but overall FreeBSD is still better, but can learn a few thing from the hurd). Best regards Rafter PS: If a more badly written version of this mail have already been send, then i apologize for that. -- Get your free email from www.linuxmail.org Powered by Outblaze To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Re: Re: userland program panics freebsd 4.3
On 2001-12-31 11:31 -0500, Michael Scheidell [EMAIL PROTECTED] wrote:
(The second method, used only if there is no PROCFS, is to call
kill(PID, 0), which will check if a signal could be delivered.
That method should probably be prefered to the reading of procfs
anyway, since the latter takes 5 system calls instead of a single
one in the case of kill() ...)
would this patch fix it on the nessus side?, and it SEEMS to be faster.
also, several 'core dumps' listed on nessusd.messages werein fact programs
that also were listed as finished.
@@ -898,6 +898,9 @@
if(!pid)
return 0;
+#ifndef FREEBSD
+## panics FREEBSD 4.3 and 4.4, might be fixed in FREEBSD 4.5
+
/*
* First method : attempt to open /proc/pid
* (we first check that we can open /proc/ourpid because
@@ -917,6 +920,7 @@
else return 0;
}
+#endif
Yes, this will fix the port. But I'm not sure, whether the code that
will be used instead of reading /proc/pid could not be improved:
/*
* Second method, we attempt to use kill. But first, we
* wait() for the process, just in case it's a zombie.
*/
for(i=0,ret=1;(i100) (ret 0);i++)
ret = waitpid(pid, NULL, WNOHANG);
return kill(pid, 0) == 0;
Instead of the for loop, I'd rather have:
while(waitpid(pid, NULL, WNOHANG) == EINTR)
/* do nothing */;
return kill(pid, 0) == 0;
That way only a return code of EINTR will casue a retry of waitpid(),
while all other values rather indicate that waitpid() can not succeed,
no matter it is called with the same parameter set.
In fact, I'm not sure that the waitpid() call is required at all, since
there are places where children are being waited for ...
(And, looking at uses of waitpid(), I think some other loops should also
be changed as shown above, see for example wait_for_children() in file
nessusd/pluginlaunch.c).
My suggested patch to nessusd/utils.c (combining the #ifndef __FreeBSD__
and my change to the waitpid() loop, diff against nessus-1.1.11):
--- nessusd/utils.c~Mon Dec 17 16:11:42 2001
+++ nessusd/utils.c Tue Jan 1 19:48:27 2002
@@ -887,10 +887,10 @@
process_alive(pid)
pid_t pid;
{
+#ifndef __FreeBSD__
char procname[255];
DIR * dir;
- int ret;
- int i;
+#endif
/*
* Invalid argument
@@ -898,6 +898,7 @@
if(!pid)
return 0;
+#ifndef __FreeBSD__
/*
* First method : attempt to open /proc/pid
* (we first check that we can open /proc/ourpid because
@@ -916,13 +917,14 @@
}
else return 0;
}
+#endif
/*
* Second method, we attempt to use kill. But first, we
* wait() for the process, just in case it's a zombie.
*/
- for(i=0,ret=1;(i100) (ret 0);i++)
-ret = waitpid(pid, NULL, WNOHANG);
+ while(waitpid(pid, NULL, WNOHANG) == EINTR)
+/* do nothing */;
return kill(pid, 0) == 0;
}
(Note: This code has not been tested in a large network, but just in my
home LAN consisting of two machines ...)
Regards, STefan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: userland program panics freebsd 4.3
Stefan Esser wrote: Instead of the for loop, I'd rather have: while(waitpid(pid, NULL, WNOHANG) == EINTR) This should be while (waitpid(pid, NULL, WNOHANG) 0 errno == EINTR) /* do nothing */; return kill(pid, 0) == 0; -- John Rochester Software Architect, Merus Software Ltd. Tel: +44 7870 174690http://merus.co.uk To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: The Hurd
On Tuesday 01 January 2002 20:14, Rafter Man wrote: So my question is: Will FreeBSD take a good look at the Hurd? I tried the Hurd in 1999 and wasn't very impressed, just downloaded the H2 ISO but haven't tried it yet. The only thing that makes the Hurd look like Unix is the POSIX compat layer. The advantages of a microkernel vs (pseudo) monolothic are well known, as well as disadvantages. Of course I can't speak for the FreeBSD developers but IMHO there's very little, if anything, that can be taken from Hurd and imported into FreeBSD (or Unix in general). Yes, you can ran a BSD server on top of Mach (MacOS X) but it's not the same as Hurd does. I would find it far more interesting to take some Plan9 ideas than the ones that could be taken from Hurd. It seems like the only reason that project is alive is to satisfy RMS' ego :-) Err, did I say that? Nervermind. Cheers, -- Miguel Mendez - [EMAIL PROTECTED] EnergyHQ :: http://energyhq.homeip.net FreeBSD - The power to serve! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: The Hurd
Hi, Sorry for jumping in here. I'm not really a FreeBSD developer, but I've been following the project for quite a long time. Rafter Man [EMAIL PROTECTED] wrote: [Whether FreeBSD does or will take ideas and features from Hurd] I think the FreeBSD developers are well aware of useful things in many other operating systems. In today's world, you cannot successfully write a general-purpose operating system without looking at the other players. This includes the guys from the UNIX camp (Solaris, Linux), but also others, even Windows. (If everything else fails, Windows can at least be used as an example of how to _not_ do things.) If Hurd has something useful to share, then why not? Wether a certain feature will be adopted depends on a lot of things, though. First of all, there has to be someone willing to learn and spend time writing code. This is probably the biggest problem for a free open-source project: manpower. And I don't mean people who want to code something up for fun, but people who are willing to work hard and do things that are not necessarily fun, such as reading dusty papers, learn how to use existing interfaces, reading and adhering to style guides that don't match your own style, writing documentation (manpages) etc. Just out of curiosity: Which particular features of Hurd would you like to see incorporated in FreeBSD? If you can name them, they could be discussed, and maybe someone even picks them up and actually does something. Another possibility is to file a PR (feature request), but you should only do that if you're really sure that FreeBSD does not already have the feature in question or something equivalent. Fx now users can have more id's and deamons run as null. I'm sorry I don't quite understand. If you mean that the number of processes that a user is allowed to run can be limited: You can already do that in FreeBSD. You might want to read the login.conf(5) manpage, and particularly the resource limits section. Regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. All that we see or seem is just a dream within a dream (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: The Hurd
Please wrap your postings at 72 characters. Hurd, as I know, derived some of it's code from the Mach program. And so does FreeBSD with it's VM (and I don't know what else). I don't see why FreeBSD should support Hurd, etc. Hurd is a micro-kernel based system, and quite a significant portion of the code would need to be rewritten to make portions of FreeBSD and Hurd to be intermixed. Leave aside performance improvements and stability issues. I also cannot see the logic in continuation of the Hurd - we don't want more OSes or kernels or bells and whistles - we just want better stuff; ones that will keep pace with the improvements in hardware capabilities. Like FreeBSD and Linux. Also, licensing is an issue - majority of the the Hurd source code carries the GPL (and the CMU and Utah licenses too, if I'm not wrong). GPL conflicts with FreeBSD's artistic license. And finally, IIRC, there is already a project called xMach, which is AFAIK a derivative of both FreeBSD and Mach (somebody please correct me). On Wed, 2 Jan 2002, Rafter Man wrote: Hi About a month ago, I wrote this mailing-list asking if the FreeBSD developers had analysed and learned from the Solaris and Linux kernel. I got some good answers (thank you), but now I have one more question. From the 27/12 too the 29/12 I was at the CCC congress and attended a lecture called Unix Redesigned. It was Neal H Walfield who talked about The Hurd: http://www.gnu.org/software/hurd http://www.debian.org/ports/hurd So my question is: Will FreeBSD take a good look at the Hurd? I know the last Hurd release was in 1997, but within this year a new release will be made. I don't expect FreeBSD to rewrite the whole kernel, but just too use some of the things or make a combination. Fx now users can have more id's and deamons run as null. I know that this will take a lot of work, but I don't have the programming knowledge too make these changes myself, but when I am finished with my computer education I will financially support FreeBSD and ofcourse write some programs. Until then all I can do is make FreeBSD aware of other alternativs and thereby insuring that FreeBSD is in front (some of the hurds way of doing things are the way of the future, but overall FreeBSD is still better, but can learn a few thing from the hurd). Best regards Rafter PS: If a more badly written version of this mail have already been send, then i apologize for that. -- -ASR - (`-''-/).___..--''`-._ (\ Maximum Throughput Inc. `6_ 6 ) `-. ( ).`-.__.`)Montreal, Canada. (_Y_.)' ._ ) `._ `. ``-..-' mailto: [EMAIL PROTECTED] _..`--'_..-_/ /--'_.' ,' http://www.rajekar.org (il),-'' (li),' ((!.-' http://www.max-t.com - You will be recognized and honored as a community leader. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Running out of bufferspace
At 11:42 1-1-2002 -0500, [EMAIL PROTECTED] wrote: Just note that no buffers often means that the queue is full, not that you are out of system buffers. You may be chasing a ghost. Well a queue should be cleaned shouldn't it? The mount_smbfs fails even hours after I run the stresstest on my device. And which queue exactly are we talking about, and where/how do I check its status? Thanx, Doc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: The Hurd
Rafter Man wrote: [ ... ] but now I have one more question. From the 27/12 too the 29/12 I was at the CCC congress and attended a lecture called Unix Redesigned. It was Neal H Walfield who talked about The Hurd: [ ... ] So my question is: Will FreeBSD take a good look at the Hurd? Your focus appears to be on security, so you should really look at the POSIX 1e effors currently underway in the FreeBSD community. However, I'll try to be more general... Hurd is a multiserver running on top of MACH. FreeBSD already has an unencumbered single server version that runs on top of MACH, and MAC OS X is already a multiserver implementation. As a general comment, MACH is a dead horse. The problem is that it contains significantly more protection domain crossing than it should in order to communicate between OS components, and for each crossing, you pay a hefty penalty. During develeopement, it would be useful to have the ability to seperate the component you are developing into its own address space, but really, Chorus is a better model. Though 4G RAM machines are increasingly common, statistical memory protection approaches are still quite valid for doing this type of work on 64 bit architectures: even with a full 4G of RAM, program only have a 1 in 4 billion chance of finding a valid byte of memory through random accident. So despite the fact that I am quite impressed with MAC OS X, it is really somewhat of a blind alley, according to current work in CS. I think a much better project to learn from would be Choices: http://choices.cs.uiuc.edu/ There are also several lesser known capabilities-based OS projects (the license on them is commercially restricted), and they are capable of dealing with the Capabilities Security Model bootstrap process, and are self checkpointing to the extent that you could have your dog kick out the plug, plug the machine in again, and be up and running where you were in a matter of seconds. At one point in time, John Dyson, the original author of the FreeBSD unified VM and buffer cache code (not to belittle the excellent work done by Matt, Alfred, and others) was talking about a project to write a drop-in-replacement SMP kernel that was designed for SMP from the ground up. I personally never joined this effort, because John wanted to cop out on doing kernel preemption, which is necessary for hard real time, and for high granularity SMP and node migration of processes (for example, in a NUMA cluster, rather than an Intel model SMP system). I think that many of us are aware and up to date on the most recent research. In fact, I would say that there are a fair number of us who believe that FreeBSD is about a decade and a half or more behind the state of the art; but since there is not an infinite amount of time, and we have day jobs, we can't fix everything over night. There are some lessons that can be taken from HURD, but there are other projects and products which have already taken those lessons, and pushed them much farther than HURD has considered pushing them. It is much better to learn from them, instead, rather than learning the same lessons from HURD directly, and reinventing the wheel as a result. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: The Hurd
Ashutosh S. Rajekar [EMAIL PROTECTED] writes: [...] GPL conflicts with FreeBSD's artistic license. [...] FreeBSD is actually licensed under a much less restrictive license, the BSD license. See any source file out of src/gnu for details. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: The Hurd
Terry Lambert wrote: [ ... ] PS: See also: http://www.eros-os.org/ http://icl.cs.utk.edu/publications/tech_reports/2000/ut-cs-00-445.pdf http://www2.tunes.org/Review/OSes.html -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
kernel panic on boot with 4G RAM
Howdy! I need an NFS server with 4G ram. When I boot a 4.5-PRE kernel it panics during the boot process, not always at the same place though. My first instinct is bad hardware because of the lack of consistency in panic location, however I was wondering if there were some issues with kernel tuning for machines with large memory that I should be aware of. This machine boots OK with 3G or less. Here is a trace and panic with kernel config etc... So... hardware or kernel config or kernel bug??? Your help is greatly appreciated. -steve 12: page fault while in kernel mode fault virtual address = 0x45d3 fault code = supervisor write, page not present instruction pointer = 0x8:0xc01f5688 stack pointer = 0x10:0xefaf7e84 frame pointer = 0x10:0xefaf7e88 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 6 (sh) interrupt mask = net bio cam kernel: type 12 trap, code=0 Stopped at vm_page_unqueue_nowakeup+0x40: decl0(%eax) db trace vm_page_unqueue_nowakeup(c179ce84,e77245e0,e7727e80,80bb000,efaf9000) at vm_page_unqueue_nowakeup+0x40 vm_fault(e7727e80,80bb000,3,8,e77245e0) at vm_fault+0x236 trap_pfault(efaf7fa8,1,80bbc4c,0,80bc1d8) at trap_pfault+0x96 trap(2f,2f,2f,80c1000,80bc1d8) at trap+0x1d3 calltrap() at calltrap+0x11 --- trap 0xc, eip = 0x8050dfa, esp = 0xbfbffbdc, ebp = 0xbfbffc04 --- and another panic: vm_page_remove(): page not found in hash Debugger(panic) Stopped at Debugger+0x34: movb$0,in_Debugger.426 db trace Debugger(c022419b) at Debugger+0x34 panic(c0237de0,c17a64c0,efb03e20,c01f5bf4,c17a64c0) at panic+0x70 vm_page_remove(c17a64c0,c17a64c0) at vm_page_remove+0x73 vm_page_free_toq(c17a64c0) at vm_page_free_toq+0x90 vm_object_collapse(c026cf00) at vm_object_collapse+0x198 vm_object_deallocate(c026c900) at vm_object_deallocate+0x170 vm_map_entry_delete(e7727d00,c0265d10,e7727d00,bfc0,0) at vm_map_entry_delete+0x33 vm_map_delete(e7727d00,0,bfc0,e7727d00,1) at vm_map_delete+0x171 vm_map_remove(e7727d00,0,bfc0,e7727d6c,0,bfc0) at vm_map_remove+0x6a exit1(e77242a0,0,efb03fa0,c020e1da,e77242a0) at exit1+0x220 exit1(e77242a0,efb03f80,,0,8072968) at exit1 syscall2(2f,2f,2f,8072968,0) at syscall2+0x166 Xint0x80_syscall() at Xint0x80_syscall+0x25 These are boot up messages Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.5-PRERELEASE #0: Mon Dec 31 13:33:03 EST 2001 [EMAIL PROTECTED]:/usr/local/4.5/src/sys/compile/NFS Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 797475848 Hz CPU: Pentium III/Pentium III Xeon/Celeron (797.48-MHz 686-class CPU) Origin = GenuineIntel Id = 0x686 Stepping = 6 Features=0x387fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,PN,MMX,FXSR,SSE real memory = 4227858432 (4128768K bytes) avail memory = 4120342528 (4023772K bytes) Preloaded elf kernel kernel.4.5.test at 0xc02bc000. Pentium Pro MTRR support enabled Using $PIR table, 10 entries at 0xc00f51e0 npx0: math processor on motherboard npx0: INT 16 interface pcib0: ServerWorks NB6635 3.0LE host to PCI bridge on motherboard pci0: PCI bus on pcib0 pci0: ATI Mach64-GR graphics accelerator at 1.0 irq 0 fxp0: Intel Pro 10/100B/100+ Ethernet port 0xd400-0xd43f mem 0xfe90-0xfe9f,0xfeafe000-0xfeafefff irq 10 at device 4.0 on pci0 fxp0: Ethernet address 00:e0:81:01:bf:ca inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1: Intel Pro 10/100B/100+ Ethernet port 0xd000-0xd03f mem 0xfe70-0xfe7f,0xfeafd000-0xfeafdfff irq 9 at device 5.0 on pci0 fxp1: Ethernet address 00:e0:81:01:bf:cb inphy1: i82555 10/100 media interface on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: ServerWorks IB6566 PCI to ISA bridge at device 15.0 on pci0 isa0: ISA bus on isab0 pci0: Unknown PCI ATA controller at 15.1 pci0: OHCI USB controller at 15.2 irq 0 pcib1: ServerWorks NB6635 3.0LE host to PCI bridge on motherboard pci1: PCI bus on pcib1 sym0: 1010-33 port 0xe400-0xe4ff mem 0xfebd8000-0xfebd9fff,0xfebe-0xfebe03ff irq 15 at device 6.0 on pci1 sym0: Symbios NVRAM, ID 7, Fast-80, LVD, parity checking sym0: open drain IRQ line driver, using on-chip SRAM sym0: using LOAD/STORE-based firmware. sym0: handling phase mismatch from SCRIPTS. sym1: 1010-33 port 0xe800-0xe8ff mem 0xfebf-0xfebf1fff,0xfebf8000-0xfebf83ff irq 11 at device 6.1 on pci1 sym1: Symbios NVRAM, ID 7, Fast-80, LVD, parity checking sym1: open drain IRQ line driver, using on-chip SRAM sym1: using LOAD/STORE-based firmware. sym1: handling phase mismatch from SCRIPTS. orm0: Option ROMs at iomem
Re: Running out of bufferspace
Rogier R. Mulhuijzen wrote: At 11:42 1-1-2002 -0500, [EMAIL PROTECTED] wrote: Just note that no buffers often means that the queue is full, not that you are out of system buffers. You may be chasing a ghost. Well a queue should be cleaned shouldn't it? The mount_smbfs fails even hours after I run the stresstest on my device. And which queue exactly are we talking about, and where/how do I check its status? Transmit queue depths are administratively limited. Consider that the default is ~16k (there was some discussion about upping this recently, which I think would be unwise). So a server with would be limited to 125,000 connections, if all transmit and receive queues were full, and there were a total 4G of RAM dedicated to nothing other than buffers. In practice, you can only sustain ~64k connections without memory overcommit or window size adjustment of some kind (overcommit works in this case, so long as you know what you are ddoing, and understand queueing theory). The problem you are running into is that your device is not draining the transmit queue fast enough. One way around this is to simply limk mbufs onto the transmit queue (ignore the limits). Another is the sysctl for send space, which will let you up it to any number you want (but you can run out of real memory and deadlock, if you set the administrative limit so that it is effectively unlimited). If you are hitting this limit, you should look at how your device operates. It would be a good idea to batch up your requests, for example (e.g. like the interrupt coelescing built into the Tigon II and Tigon III card drivers and firmware, or like the soft interrupt coelescing patches I posted for a number of network drivers a while back). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: kernel panic on boot with 4G RAM
Steve Shorter wrote: I need an NFS server with 4G ram. When I boot a 4.5-PRE kernel it panics during the boot process, not always at the same place though. My first instinct is bad hardware because of the lack of consistency in panic location, however I was wondering if there were some issues with kernel tuning for machines with large memory that I should be aware of. This machine boots OK with 3G or less. You really need to change the allocation of swap page descriptors in /sys/i386/machdep.c (among other things). I personally suggest compiling your kernel with 3G KVA/1G User, instead of the default of 1G KVA/3G User. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Re: userland program panics freebsd 4.3
On 2002-01-01 19:59 +, John Rochester [EMAIL PROTECTED] wrote: Stefan Esser wrote: Instead of the for loop, I'd rather have: while(waitpid(pid, NULL, WNOHANG) == EINTR) This should be while (waitpid(pid, NULL, WNOHANG) 0 errno == EINTR) Yes, obviously ... ;-) STefan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Running out of bufferspace
In a message dated 01/01/2002 4:20:06 PM Eastern Standard Time, [EMAIL PROTECTED] writes: Just note that no buffers often means that the queue is full, not that you are out of system buffers. You may be chasing a ghost. Well a queue should be cleaned shouldn't it? The mount_smbfs fails even hours after I run the stresstest on my device. And which queue exactly are we talking about, and where/how do I check its status? I think that fact that you still see the problem hours later indicates that some internal device doesnt have a process to revisit the queue once you've filled it. You can do the same thing fairly easily with a trafic generator that uses raw socketscheck the ifp-if_snd.ifq_len for the device you are sending on db To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: kernel panic on boot with 4G RAM
On Tue, Jan 01, 2002 at 02:01:28PM -0800, Terry Lambert wrote: Steve Shorter wrote: I need an NFS server with 4G ram. When I boot a 4.5-PRE kernel it panics during the boot process, not always at the same place though. My first instinct is bad hardware because of the lack of consistency in panic location, however I was wondering if there were some issues with kernel tuning for machines with large memory that I should be aware of. This machine boots OK with 3G or less. You really need to change the allocation of swap page descriptors in /sys/i386/machdep.c (among other things). Is this a trivial change? I don't know much about FreeBSD kernel internals but can edit source with some guidance OR can these changes be effected in the kernel config? How about changing NKPT in sys/i386/include/pmap.h to something bigger? .. like 60? What other things should be done to tune a high memory machine, or to get it to boot. I personally suggest compiling your kernel with 3G KVA/1G User, instead of the default of 1G KVA/3G User. Ok. This can be done with options KVA_PAGES=768 What about the other KVA stuff in kernel config options VM_BCACHE_SIZE_MAX= The comments in LINT mention that this is capped at 260M effecting 1G of ram. Should this be increased with machines with 4G? thanx - steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
huge MFREE() macro?
I noticed a bunch of routines use MFREE() instead of m_free() (which
just calls MFREE()). MFREE() is a huge macro.
textdata bss dec hex filename
1986399 252380 145840 2384619 2462eb kernel
textdata bss dec hex filename
1983343 252380 145840 2381563 2456fb kernel
We save about 3K. Any problems with this? Maybe also MFC to -stable
to save some bytes?
(The #if 0's wouldn't be in a commit, I'd actually delete the code)
Also, if you do a search for XXX, I think there was an MFREE in there
that should have been an m_freem(). Could someone check that?
The patch is against -stable.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
Index: kern/uipc_socket.c
===
RCS file: /home/ncvs/src/sys/kern/uipc_socket.c,v
retrieving revision 1.68.2.17
diff -u -r1.68.2.17 uipc_socket.c
--- kern/uipc_socket.c 1 Dec 2001 21:32:42 - 1.68.2.17
+++ kern/uipc_socket.c 2 Jan 2002 06:01:40 -
@@ -782,7 +782,10 @@
m = m-m_next;
} else {
sbfree(so-so_rcv, m);
+ so-so_rcv.sb_mb = m_free(m);
+#if 0
MFREE(m, so-so_rcv.sb_mb);
+#endif
m = so-so_rcv.sb_mb;
}
}
@@ -803,7 +806,10 @@
m-m_next = 0;
m = so-so_rcv.sb_mb;
} else {
+#if 0
MFREE(m, so-so_rcv.sb_mb);
+#endif
+ so-so_rcv.sb_mb = m_free(m);
m = so-so_rcv.sb_mb;
}
}
@@ -867,8 +873,13 @@
so-so_rcv.sb_mb = m = m-m_next;
*mp = (struct mbuf *)0;
} else {
+#if 0
MFREE(m, so-so_rcv.sb_mb);
+#endif
+ so-so_rcv.sb_mb = m = m_free(m);
+#if 0
m = so-so_rcv.sb_mb;
+#endif
}
if (m)
m-m_nextpkt = nextrecord;
Index: kern/uipc_socket2.c
===
RCS file: /home/ncvs/src/sys/kern/uipc_socket2.c,v
retrieving revision 1.55.2.10
diff -u -r1.55.2.10 uipc_socket2.c
--- kern/uipc_socket2.c 27 Dec 2001 18:36:10 - 1.55.2.10
+++ kern/uipc_socket2.c 2 Jan 2002 06:10:20 -
@@ -782,7 +782,7 @@
register struct sockbuf *sb;
register int len;
{
- register struct mbuf *m, *mn;
+ register struct mbuf *m;
struct mbuf *next;
next = (m = sb-sb_mb) ? m-m_nextpkt : 0;
@@ -802,13 +802,19 @@
}
len -= m-m_len;
sbfree(sb, m);
+#if 0
MFREE(m, mn);
m = mn;
+#endif
+ m = m_free(m);
}
while (m m-m_len == 0) {
sbfree(sb, m);
+#if 0
MFREE(m, mn);
m = mn;
+#endif
+ m = m_free(m);
}
if (m) {
sb-sb_mb = m;
@@ -825,15 +831,18 @@
sbdroprecord(sb)
register struct sockbuf *sb;
{
- register struct mbuf *m, *mn;
+ register struct mbuf *m;
m = sb-sb_mb;
if (m) {
sb-sb_mb = m-m_nextpkt;
do {
sbfree(sb, m);
+#if 0
MFREE(m, mn);
m = mn;
+#endif
+ m = m_free(m);
} while (m);
}
}
Index: net/if_ppp.c
===
RCS file: /home/ncvs/src/sys/net/if_ppp.c,v
retrieving revision 1.67.2.1
diff -u -r1.67.2.1 if_ppp.c
--- net/if_ppp.c11 Sep 2001 09:49:54 - 1.67.2.1
+++ net/if_ppp.c2 Jan 2002 06:03:07 -
@@ -1381,9 +1381,13 @@
if (m-m_len = M_TRAILINGSPACE(mp)) {
bcopy(mtod(m, u_char *), mtod(mp, u_char *) + mp-m_len, m-m_len);
mp-m_len += m-m_len;
+#if 0
MFREE(m, mp-m_next);
- } else
+#endif
+ mp-m_next = m_free(m);
+ } else {
mp-m_next = m;
+ }
m = mp;
ilen += hlen - xlen;
Index: net/if_sl.c
===
RCS file: /home/ncvs/src/sys/net/if_sl.c,v
retrieving revision 1.84.2.1
diff -u -r1.84.2.1 if_sl.c
--- net/if_sl.c 26 Dec 2000 02:22:57 - 1.84.2.1
+++ net/if_sl.c 2 Jan 2002 06:10:31 -
@@ -548,7 +548,6 @@
register u_char *cp;
register struct ip *ip;
int s;
- struct mbuf *m2;
u_char bpfbuf[SLTMAX +
Audio burning problem with LG CED-8080B
Hackers, first of all i apologize for posting this in -hackers. it really belongs to -questions, but i saw similar messages in -questions and there was not much response. the problem is very simple: i can not burn audio CDs with my LG CED-8080B internal IDE drive and bunrcd. but here is a small detail: the drive _will_not_ burn audio track if next writable LBA _is_equal_ to zero :( however, if (and only if) next writable LBA _not_equal_ to zero, the drive _will_ burn audio track just fine. for now i have to put really small ISO image on the first track and then burn audio tracks :( some CD players get very upset because of this :( no such problem with data CDs. everything works just fine. please find attached file with more information. if somebody could explain what is going that would be great. thanks, max p.s. there is a similar PR in the database (http://www.freebsd.org/cgi/query-pr.cgi?pr=27893) # uname -a FreeBSD fly.private.org 4.4-STABLE FreeBSD 4.4-STABLE #0: Sun Oct 28 01:15:59 PDT 2001 [EMAIL PROTECTED]:/usr/src/sys/compile/FLY i386 # burncd -f /dev/acd0c -s 1 -t audio track1.cda fixate next writeable LBA 0 writing from file track1.cda size 269032 KB only wrote -1 of 37632 bytes fixating CD, please wait.. burncd: ioctl(CDRIOCCLOSEDISK): Input/output error # dmesg Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.4-STABLE #0: Sun Oct 28 01:15:59 PDT 2001 [EMAIL PROTECTED]:/usr/src/sys/compile/FLY Calibrating clock(s) ... TSC clock: 400915491 Hz, i8254 clock: 1193201 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method CPU: Pentium II/Pentium II Xeon/Celeron (400.91-MHz 686-class CPU) Origin = GenuineIntel Id = 0x652 Stepping = 2 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 67108864 (65536K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x002cb000 - 0x03ff7fff, 64147456 bytes (15661 pages) avail memory = 62685184 (61216K bytes) bios32: Found BIOS32 Service Directory header at 0xc00fdad0 bios32: Entry = 0xfdae0 (c00fdae0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xdb01 pnpbios: Found PnP BIOS data at 0xc00f7700 pnpbios: Entry = f:6f1e Rev = 1.0 Other BIOS signatures found: ACPI: Preloaded elf kernel kernel at 0xc02a4000. Pentium Pro MTRR support enabled pci_open(1):mode 1 addr port (0x0cf8) is 0x8084 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=162110b9) Using $PIR table, 6 entries at 0xc00f7e20 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge on motherboard found- vendor=0x10b9, dev=0x1621, revid=0x05 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[10]: type 1, range 32, base e000, size 26 found- vendor=0x10b9, dev=0x5247, revid=0x01 class=06-04-00, hdrtype=0x01, mfdev=0 subordinatebus=1secondarybus=1 found- vendor=0x10b9, dev=0x1533, revid=0xb4 class=06-01-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 found- vendor=0x100b, dev=0x0020, revid=0x00 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=7 map[10]: type 1, range 32, base dc00, size 8 map[14]: type 1, range 32, base dfffe000, size 12 found- vendor=0x10b9, dev=0x5229, revid=0x20 class=01-01-fa, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=0 map[20]: type 1, range 32, base ffa0, size 4 found- vendor=0x1317, dev=0x0985, revid=0x11 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=9 map[10]: type 1, range 32, base de00, size 8 map[14]: type 1, range 32, base dc00, size 10 pci0: PCI bus on pcib0 pcib1: AcerLabs M5247 PCI-PCI(AGP Supported) bridge at device 1.0 on pci0 found- vendor=0x1002, dev=0x475a, revid=0x3a class=03-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=0 map[10]: type 1, range 32, base de00, size 24 map[14]: type 1, range 32, base cc00, size 8 map[18]: type 1, range 32, base dfeff000, size 12 pci1: PCI bus on pcib1 pci1: ATI Mach64-GZ graphics accelerator (vendor=0x1002, dev=0x475a) at 0.0 irq 0 isab0: AcerLabs M1533 portable PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 sis0: NatSemi DP83815 10/100BaseTX port 0xdc00-0xdcff mem 0xdfffe000-0xdfffefff irq 7 at device 14.0 on pci0 sis0: Ethernet address: 00:02:e3:22:2f:28 miibus0: MII bus
