Re: Weird path MTU autodiscovery problem in 4.5-RELEASE
Is the server filtering out ICMP traffic with ipfw or something? Alexey Luckyanchikov wrote: 14:06:48.477578 server.7 client.1371: . 1437:2897(1460) ack 10001 win 65535 (DF) (ttl 64, id 25428, len 1500) ^^^ Server send packet with size 1500 bytes 14:06:48.682558 router server: icmp: client unreachable - need to frag (mtu 1476) for server.7 client.1371: [|tcp] (DF) (ttl 61, id 25428, len 1500) (ttl 253, id 2491, len 56) ^^ Router say to server that he must to decrease packet size 14:07:04.477857 server.7 client.1371: . 1437:2897(1460) ack 10001 win 65535 (DF) (ttl 64, id 52781, len 1500) ^ But server ignore this information and still send 1500 bytes packets What's the result of 'sysctl net.inet.tcp.path_mtu_discovery' ?? Not that I can imagine, at the moment, what would set it to 0 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Can't build unoptimized/debugging kernel
Doug White said on Feb 1, 2002 at 12:28:34: On FreeBSD 4-stable (cvsupped Jan 31 at around 13:40 GMT) I'm unable to build an unoptimized debugging kernel. The kernel builds fine with COPTFLAGS=-O -pipe but with COPTFLAGS=-g (or -g -pipe) I get the following error. I get the same error without optimization and without -g. That's not the way to enable a debugging kernel. Set makeoptions -g in the kernel configuration file, config, make depend, make, make install. OK, will try. See the Handbook section on debugging crash dumps for more information. Hm, that section seems to have disappeared from the present handbook. The version on my hard disk (a bit old) says configure the kernel with config -g. I was using the make buildkernel/make installkernel procedure so I thought the make.conf file would be the right way... Also, I was getting the above error with or without the -g flag, if I didn't specify optimisation. Is the kernel meant to be built always with -O or above? - Rahul To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: trouble with vn device in 4.5-R?
In local.freebsd.stable you write: Hello. I upgrade my FreeBSD from 4.4-stable to 4.5-release. When I'm trying to compile my kernel with `pseudo-device vn' option, while compiling kernel, I have an errors messages. Is this a known bug? I need vn driver for makeing an ISO image... So piece of log: ... linux_proto.h:517: `linux_stack_t' undeclared here (not in a function) Delete your object tree before compiling (known problem: see /usr/src/UPDATING). Besides, there is no need to rebuild the kernel to get vn support - it is a loadable module. $.02, /Mikko -- Mikko Työläjä[EMAIL PROTECTED] RSA Security To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
4.5-Release kernel locking hard after 30 minutes
I tried to upgrade from 4.4-R to 4.5-R via CVSUP. Kernel compiled and installed fine (as generic, but includes ipfilter and stripped down to eliminate unnecessary devices). I started doing a buildworld, but after 30 mins of heavy compiling the machine locked solid - a hard reset required to recover. Never seen this before. I booted back to 4.4R Kernel and all is well again. PC is Asus Cuple-VM mobo (82C686B southbridge), 256Mb, integrated graphics, 60Gb IBM HD, 400MHz celeron, 2xFA311 NIC. Uptime is weeks with 4.4R under heavy usage (only tweaking the kernel has required a reboot). Suggestions of how to attack the 4.5 lockup problem? Neil To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: *_enable=YES behavior is bogus
At 6:36 PM +0100 2/1/02, Erik Trulsson wrote: Consider that the actual code in the various rc* start scripts is in most cases of the form: if foo_enable==yes do stuff else do nothing Let me approach this from a different angle. Several people have tried to argue this by proposing various What if? scenarios. Let me also do that. Let us say that we did happen to decide that for all 'foo_enable' options in rc.conf, a setting of 'foo_enable=no' does in fact mean that the service 'foo' will NOT be running at the end of the boot-up process. Maybe some company offers us a million dollars if we will just guarantee that, and we think of all the good programmers we could pay for that million dollars, so we all agree to standardize on this definition of 'enable=no' If we decided to do that, then as a *practical* matter, how many of the current options in rc.conf would need to be changed? I don't mean if we need to cover the case where someone renames /usr/sbin/lpd to /bin/echo, what would we need to do?. I mean, given any default installation of the base operating system (no ports), and any valid kernel configuration, in what cases of 'enable' would we really *have* to add some lines to those 'else' clauses that you quoted? In the case of lpd_enable, as a *practical* matter, there would be no need to write additional code. There is no kernel setting which automatically turns on lpd support, and if 'lpd_enable=yes' does not *start* /usr/sbin/lpd, then we do know that the lpd program is not running. I don't have time to look into it now, but I expect that is true for all of the other 'enable' options. As a *practical* reality, I expect that the firewall_enable option is the only one where we do need to write code to implement the 'enable=no' case as I described it. People will argue that this is special, because it's a kernel option! Lpd would behave exactly the same way, *if* it were a kernel option!. All fine and good, *if* it were true, but irrelevant to my What if? question. Of the current foo_enable options, which options would we need to change *right now* to support the definition of 'enable=no' that some people think is logical? [mind you, I don't actually know the answer to that question, but I just got a phone call and need to leave right now... So, I am breaking the first rule of a good lawyer, in that I am asking a question that I don't already know the answer to. :-) ] -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: trouble with vn device in 4.5-R?
This is a known issue that is not specific to vn being in the kernel. Check /usr/src/UPDATING there's a comment in there with the solution. It's also been beaten to death in the mailing list archives over the past month or so :) --Chris Dennis S.Davidoff said: Hello. I upgrade my FreeBSD from 4.4-stable to 4.5-release. When I'm trying to compile my kernel with `pseudo-device vn' option, while compiling kernel, I have an errors messages. Is this a known bug? I need vn driver for makeing an ISO image... So piece of log: ... linux_proto.h:517: `linux_stack_t' undeclared here (not in a function) linux_proto.h:517: syntax error before `)' linux_sysent.c:21: sizeof applied to an incomplete type linux_sysent.c:21: warning: built-in function `exit' used without declaration linux_sysent.c:21: warning: cast discards qualifiers from pointer target type *** Error code 1 Stop in /usr/src/sys/modules/linux. *** Error code 1 Full detailed log file and kernel config is aviable on http://wild.1system.ru/k Where I'm go wrong? P.S. Wating for an answer. Thanks. -- Den. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message -- Chris I'll defend to the death your right to say that, but I never said I'd listen to it! -- Tom Galloway with apologies to Voltaire To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: mount the same filesystem read-only on multiple boxes, and read-write on one ?
Hejsa Jesper! %s wrote on %.3s, %lld Sep 1993 The application would be a usenet news setup, where the overview and/or spool would be mounted like this. Ewww. I'm not thinking too clearly, which is nothing new, but wouldn't one be also wanting to use synchronous (rw) mounts for something like this, in addition to not caching reads? I know nothing about how softupdates may play into the equation. I mean, it was a beauteous thing to stand in front of news-feed02 and wonder if it was still online, until many seconds later, a disk light would wink as it weaseled its way towards the top (shut UP about my cheating already). Somehow I can't imagine that every one of the 20-some news articles per second it received were being sent to the disk immediately. I'd also wonder about mmap()ed data, not that I know much about it. One may recall many many months back where one of my goals with FreeBSD was to use mmap() in a way to cause an absolute minimum of disk access to and from a random-access file. I'm going to assume that the overview and spool are large, append files, which makes life easier. Basically the thing I worry about is that both the overview and spool reflect accurately on disk, that which the kernel wants to toss to disk, immediately, lest the read-only slaves lose synchronization and present a messed-up view to readers. Buffering and caching sound like your enemies. Though probably nowhere near as severely as on some news swervers I've had the misfortune of reading from. (But Jesper, I thought you had given up news long ago, like me, to do Something Useful with your life ;-) barry bouwsma, ex-newsbastard To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: *_enable=YES behavior is bogus
Oh. Damn. Someone *added* freebsd-current to this thread without removing freebsd-stable. Several people have requested that we stop discussing this on freebsd-stable, and I *thought* I was only sending my recent messages to the one mailing list. I do not particularly care which mailing list this discussion is on, but I really think we should pick one mailing list and keep it on only one list. Peoples' nerves are frazzled enough already about this topic without having to see this on two mailing lists! I'm sending this message only to stable, with the hint being that maybe we should debate the topic only on -current, as several others have suggested/requested. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: problems CVS updating from 4.3 to 4.4 and 4.5
On Fri, Feb 01, 2002 at 04:06:34PM -0500, Michael Scheidell wrote: Tried CVS update from 4.3 REL to 4.4 REL. (RELENG_4_4) make update fine make buildworld fine make installmost complained about bad option (-b) in install did man install on 4.3 system, no -b option did man install on 4.4 system found -b option copied over 4.4 install to 4.3 system, make installmost worked. nothing in UPDATING about this. I believe this was fixed in 4.4-STABLE. Kris msg41027/pgp0.pgp Description: PGP signature
Re: Weird path MTU autodiscovery problem in 4.5-RELEASE
On Fri, Feb 01, 2002 at 02:53:26PM +0200, Alexey Luckyanchikov wrote: Hello, I have such network topology: ++++++ | Server | MTU 1500 | Router | MTU 1476 | Client | ++++++ [snip] 14:06:48.682558 router server: icmp: client unreachable - need to frag (mtu 1476) for server.7 client.1371: [|tcp] (DF) (ttl 61, id 25428, len 1500) (ttl 253, id 2491, len 56) ^^ Router say to server that he must to decrease packet size Is router the same IP address that server has as the route to client? That is, there aren't any aliases on router's interface with server making problems? -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
