Re: multilingual boot.flp for 4.3-RELEASE
At 07 May 2001 02:06:49 +0900, CHOI Junho wrote: > > All messages(localization/), help files(sysinstall/), and other > release texts(texts/) is updated to 4.3-RELEASE. Please enable Korean. > > Have fun! I've put the updated version at ftp://daemon.jp.freebsd.org/pub/FreeBSD-jp/I18N-flp/4.3-RELEASE/20010507/ > p.s. one question - should I translate LOCALIZE.TXT? It exists only in > the form of English. You don't have to translate it, but of course, if you translate it to Korean, I will put it at texts/ko/. > And please add my name to LOCALIZE.TXT... > > Renewal of Korean message to 4.3 > > o CHOI Junho <[EMAIL PROTECTED]> Done. -- Tatsumi Hosokawa <[EMAIL PROTECTED]> http://www.sm.rim.or.jp/~hosokawa/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
sysctl(8) and opaque MIB entries
Hi folks, Is there a good reason why sysctl(8) won't display _any_ output for opaque MIB entries named as arguments? I'm specifically interested in kern.proc.all. I can ``sysctl -A | grep kern.proc.all'', but it's weird that neither of these two do anything useful: sysctl -A kern.proc.all sysctl kern.proc.all Is there some sound reason for this, or am I just lost on the fringes of what sysctl(8) was designed for? Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Getting peer credentials on a unix domain socket
On 7 May 2001, Dag-Erling Smorgrav wrote: > Alfred Perlstein <[EMAIL PROTECTED]> writes: > > The silly part of it is that the socket's initial credentials > > might be different than the holder's credentials. > > That's a feature, just like you can open /dev/io as root, then drop > root privs and do direct I/O to your heart's content even if you're no > longer root. > > DES That feature is undesireable in some places, however. As an example, sockets passed from a daemon running as root to child processes as nobody still have root privs on the sockets. As such, you can't use sbsize limiting or ipfw's uid-based tracking on apache and presumably any other root spawning, priv dropping daemons. Patching the net code to drop the privs to match those of the accepting connection was easy, though I didn't test enough to check if it broke the /dev/io case or others. Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sysctl(8) and opaque MIB entries
Sheldon Hearn <[EMAIL PROTECTED]> writes: > Is there a good reason why sysctl(8) won't display _any_ output for > opaque MIB entries named as arguments? Yes it will, with -X. The interesting question is why there isn't an option to make it display just one variable in hex, and why it doesn't print a message when it omits printing an opaque variable. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sysctl(8) and opaque MIB entries
On 07 May 2001 18:51:22 +0200, Dag-Erling Smorgrav wrote: > Yes it will, with -X. The interesting question is why there isn't an > option to make it display just one variable in hex, and why it doesn't > print a message when it omits printing an opaque variable. Do you think it'd be okay to allow an argument to -a and -A that specifies the sysctl node from which to descend? Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sysctl(8) and opaque MIB entries
Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes:
> Sheldon Hearn <[EMAIL PROTECTED]> writes:
> > Is there a good reason why sysctl(8) won't display _any_ output for
> > opaque MIB entries named as arguments?
> Yes it will, with -X. The interesting question is why there isn't an
> option to make it display just one variable in hex, and why it doesn't
> print a message when it omits printing an opaque variable.
Here's a patch that:
1) introduces the -x option, which makes opaque variables visible.
2) allows variables to be set without the -w option.
3) undocuments the now-superfluous -w option.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
Index: sysctl.8
===
RCS file: /home/ncvs/src/sbin/sysctl/sysctl.8,v
retrieving revision 1.31
diff -u -r1.31 sysctl.8
--- sysctl.8 2001/02/01 16:32:12 1.31
+++ sysctl.8 2001/05/07 17:21:58
@@ -40,14 +40,11 @@
.Nd get or set kernel state
.Sh SYNOPSIS
.Nm
-.Op Fl bNn
-.Ar name ...
+.Op Fl bNnx
+.Ar name Ns Op = Ns Ar value
+.Ar ...
.Nm
-.Op Fl bNn
-.Fl w
-.Ar name Ns = Ns Ar value ...
-.Nm
-.Op Fl bNn
+.Op Fl bNnx
.Fl aAX
.Sh DESCRIPTION
The
@@ -69,10 +66,10 @@
flag; for the opaque values,
information about the format and the length is printed in addition the first
few bytes is dumped in hex.
-.It Fl X
+.It Fl X
Same as
.Fl A
-except the entire value of opaque variables is hexdumped.
+.Fl x .
.It Fl N
Show only variable names, not their values.
.It Fl n
@@ -87,17 +84,8 @@
Force the value of the variable(s) to be output in raw, binary
format. No names are printed and no terminating newlines are output.
This is mostly useful with a single variable.
-.It Fl w Xo
-.Ar name Ns = Ns Ar value ...
-.Xc
-Set the MIB
-.Ar name
-to the new
-.Ar value .
-If just a MIB style
-.Ar name
-is given,
-the corresponding value is retrieved.
+.It Fl x
+Display opaque variables (in hex).
.El
.Pp
The information available from
Index: sysctl.c
===
RCS file: /home/ncvs/src/sbin/sysctl/sysctl.c,v
retrieving revision 1.31
diff -u -r1.31 sysctl.c
--- sysctl.c 2001/01/14 19:08:58 1.31
+++ sysctl.c 2001/05/07 17:10:44
@@ -58,7 +58,7 @@
#include
#include
-static int Aflag, aflag, bflag, Nflag, nflag, wflag, Xflag;
+static int Aflag, aflag, bflag, Nflag, nflag, xflag;
static int oidfmt(int *, int, char *, u_int *);
static void parse(char *);
@@ -70,12 +70,10 @@
usage(void)
{
- (void)fprintf(stderr, "%s\n%s\n%s\n%s\n%s\n",
- "usage: sysctl [-bNn] variable ...",
- " sysctl [-bNn] -w variable=value ...",
- " sysctl [-bNn] -a",
- " sysctl [-bNn] -A",
- " sysctl [-bNn] -X");
+ (void)fprintf(stderr, "%s\n%s\n%s\n",
+ "usage: sysctl [-bxNn] variable[=value] ...",
+ " sysctl [-bxNn] -a",
+ " sysctl [-bxNn] -A");
exit(1);
}
@@ -86,7 +84,7 @@
setbuf(stdout,0);
setbuf(stderr,0);
- while ((ch = getopt(argc, argv, "AabNnwX")) != -1) {
+ while ((ch = getopt(argc, argv, "AabNnwxX")) != -1) {
switch (ch) {
case 'A':
Aflag = 1;
@@ -104,10 +102,14 @@
nflag = 1;
break;
case 'w':
- wflag = 1;
+ /* compatibility */
break;
+ case 'x':
+ xflag = 1;
+ break;
case 'X':
- Xflag = Aflag = 1;
+ /* backwards compatibility */
+ xflag = Aflag = 1;
break;
default:
usage();
@@ -116,7 +118,7 @@
argc -= optind;
argv += optind;
- if ((wflag && (Aflag || aflag)) || (Nflag && nflag))
+ if (Nflag && nflag)
usage();
if (Aflag || aflag)
exit (sysctl_all(0, 0));
@@ -146,17 +148,12 @@
bufp = buf;
snprintf(buf, BUFSIZ, "%s", string);
if ((cp = strchr(string, '=')) != NULL) {
- if (!wflag)
- errx(2, "must specify -w to set variables");
*strchr(buf, '=') = '\0';
*cp++ = '\0';
while (isspace(*cp))
cp++;
newval = cp;
newsize = strlen(cp);
- } else {
- if (wflag)
- usage();
}
len = name2oid(bufp, mib);
@@ -166,7 +163,7 @@
if (oidfmt(mib, len, 0, &kind))
err(1, "couldn't find format of oid '%s'", bufp);
- if (!wflag) {
+ if (newval == NULL) {
if ((kind & CTLTYPE) == CTLTYPE_NODE) {
sysctl_all(mib, len);
} else {
@@ -468,14 +465,14 @@
}
/* FALL THROUGH */
default:
- if (!Aflag)
+ if (!Aflag && !xflag)
return (1);
if (!nflag)
printf("%s: ", name);
printf("Format:%s Length:%d Dump:0x", fmt, len);
while (len--) {
printf("%02x", *p++);
- if (Xflag || p < val+16)
+ if (xflag || p < val+16)
continue;
printf("...");
break;
Re: sysctl(8) and opaque MIB entries
Sheldon Hearn <[EMAIL PROTECTED]> writes: > On 07 May 2001 18:51:22 +0200, Dag-Erling Smorgrav wrote: > > Yes it will, with -X. The interesting question is why there isn't an > > option to make it display just one variable in hex, and why it doesn't > > print a message when it omits printing an opaque variable. > Do you think it'd be okay to allow an argument to -a and -A that > specifies the sysctl node from which to descend? Have you tried e.g. 'sysctl hw' lately? DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sysctl(8) and opaque MIB entries
On Mon, May 07, 2001 at 07:24:39PM +0200, Dag-Erling Smorgrav wrote: > Sheldon Hearn <[EMAIL PROTECTED]> writes: > > On 07 May 2001 18:51:22 +0200, Dag-Erling Smorgrav wrote: > > > Yes it will, with -X. The interesting question is why there isn't an > > > option to make it display just one variable in hex, and why it doesn't > > > print a message when it omits printing an opaque variable. > > Do you think it'd be okay to allow an argument to -a and -A that > > specifies the sysctl node from which to descend? > > Have you tried e.g. 'sysctl hw' lately? How about e.g. 'sysctl -a hw', which still shows *all* MIB's? At least on ref5 as of this very moment.. [roam@ref5:~]$ sysctl -a hw | fgrep . | cut -d. -f 1 | sort -u cshumway@ref5 debug hw jail kern machdep net p1003_1b user vfs vm [roam@ref5:~]$ (well, so my filter wasn't exact; but still, it does *not* limit the output to hw.* MIB's..) G'luck, Peter -- I had to translate this sentence into English because I could not read the original Sanskrit. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sysctl(8) and opaque MIB entries
In message <[EMAIL PROTECTED]>, Sheldon Hearn writes: > > >On 07 May 2001 18:51:22 +0200, Dag-Erling Smorgrav wrote: > >> Yes it will, with -X. The interesting question is why there isn't an >> option to make it display just one variable in hex, and why it doesn't >> print a message when it omits printing an opaque variable. > >Do you think it'd be okay to allow an argument to -a and -A that >specifies the sysctl node from which to descend? You mean like # sysctl vfs.devfs vfs.devfs.noverflow: 32768 vfs.devfs.generation: 116 vfs.devfs.inodes: 116 vfs.devfs.topinode: 118 :-) -- 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: sysctl(8) and opaque MIB entries
On Mon, May 07, 2001 at 07:43:39PM +0200, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Sheldon Hearn writes: > > > > > >On 07 May 2001 18:51:22 +0200, Dag-Erling Smorgrav wrote: > > > >> Yes it will, with -X. The interesting question is why there isn't an > >> option to make it display just one variable in hex, and why it doesn't > >> print a message when it omits printing an opaque variable. > > > >Do you think it'd be okay to allow an argument to -a and -A that > >specifies the sysctl node from which to descend? > > You mean like > > # sysctl vfs.devfs > vfs.devfs.noverflow: 32768 > vfs.devfs.generation: 116 > vfs.devfs.inodes: 116 > vfs.devfs.topinode: 118 > > :-) As I pointed out in another message, yes, he meant like that, but with the -a or -A option. G'luck, Peter -- This sentence was in the past tense. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sysctl(8) and opaque MIB entries
Peter Pentchev <[EMAIL PROTECTED]> writes: > How about e.g. 'sysctl -a hw', which still shows *all* MIB's? > At least on ref5 as of this very moment.. Yes, because '-a' means 'show all non-opaque' and 'hw' is ignored. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sysctl(8) and opaque MIB entries
On Mon, May 07, 2001 at 07:52:15PM +0200, Dag-Erling Smorgrav wrote: > Peter Pentchev <[EMAIL PROTECTED]> writes: > > How about e.g. 'sysctl -a hw', which still shows *all* MIB's? > > At least on ref5 as of this very moment.. > > Yes, because '-a' means 'show all non-opaque' and 'hw' is ignored. OK, so I slipped up; so how about this: [roam@ref5 ~]$ sysctl -A hw | fgrep . | cut -d. -f 1 | sort -u cshumway@ref5 debug hw jail kern machdep net p1003_1b user vfs vm [roam@ref5 ~]$ sysctl -X hw | fgrep . | sed 's/\..*//' | sort -u cshumway@ref5 debug hw jail kern machdep net p1003_1b user vfs vm [roam@ref5 ~]$ G'luck, Peter -- What would this sentence be like if pi were 3? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sysctl(8) and opaque MIB entries
Peter Pentchev <[EMAIL PROTECTED]> writes: > On Mon, May 07, 2001 at 07:52:15PM +0200, Dag-Erling Smorgrav wrote: > > Peter Pentchev <[EMAIL PROTECTED]> writes: > > > How about e.g. 'sysctl -a hw', which still shows *all* MIB's? > > Yes, because '-a' means 'show all non-opaque' and 'hw' is ignored. > OK, so I slipped up; so how about this: Yes, what about this? It's still the exact same thing, the -A and -X options are variants of the -a option. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Q: porting a driver from linux to freebsd.
Robert Suetterlin wrote: > > Hello! > > I asked this already on freebsd-questions and was suggested to ask on this list, too. > > I have a linux driver for a video grabber card (dfg/bw1 from 'the imaging >source'). This card does not use a well bt848 or similar chip. I would like to >transfer this driver to freebsd. > > I do understand how the driver works under linux and I will explain below. I have >also read articles on newbus, some netbsd docs, several freebsd manpages and the >sources of meteor.c. I know in principle how to do a driver under freebsd. But I >never did it before and wanted to get some expertise on how to do it best. Also look at the sample driver in /usr/share/examples/drivers/make_device_drive.sh in -current (4.x is way out of date) > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: no keyboard
On 05-May-01 Alfred Perlstein wrote: > * Ceri Storey <[EMAIL PROTECTED]> [010505 11:59] wrote: >> On Sat, May 05, 2001 at 08:54:18PM +0200, Ingo Flaschberger wrote: >> > > Note : this is a way to kill your keyboard : an AT keyboard is not >> > > hot-plug compatible >> > >> > i have never killed a keyboard with un / plugging. >> > at linux it works. >> Well, it works, until your keyboard does actually break :) > > It can actually fry the entire motherboard. I doubt linux can > prevent that. > > FreeBSD 4.3 allows hotswap again. It never disallowed it, it is simply a flag for the atkbd(4) driver. You can always tweak it by turning off flag 0x1 on the atkbd0 device via a custom kernel or using a userconfig script. However, by default keyboards are actually probed and not assumed present on 4.3, so hotplug of a keyboard if the keyboard was not plugged in in 4.3 will not work out of the box. Note that hotplug of USB will work. A real fix would be to have the atkbdc0 driver attach a atkbd0 device in the case that a keyboard interrupt comes in (i.e. on the first keypress after plugging in the keyboard). -- 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
(no subject)
subscribe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Realy LARGE TCP/IP Window Size?
I am working on a FreeBSD device driver for my Co's GSN adapter and need to be able to set my TCP/IP window size to 512KB (or perhaps more). I have tried doing this with sysctl: root@sebulba:p0 /root> sysctl -w net.inet.tcp.recvspace=524288 net.inet.tcp.recvspace: 131072 -> 524288 root@sebulba:p0 /root> sysctl -w net.inet.tcp.sendspace=524288 net.inet.tcp.sendspace: 131072 -> 524288 and although the sysctl happily takes the specification, when I attempt an ftp command I get: root@sebulba:p0 /root> ftp 192.168.1.2 ftp: socket: No buffer space available This is on a FreeBSD 4.0-stable system: FreeBSD sebulba.vieo.com 4.0-STABLE FreeBSD 4.0-STABLE #202: Mon May 7 15:09:46 CDT 2001 [EMAIL PROTECTED]:/usr/src/sys/compile/GPXTEST i386 Anybody have any ideas what I need to do to get this to work? Thanks, Bob -- Bob Willcox Living your life is a task so difficult, [EMAIL PROTECTED]it has never been attempted before. Austin, TX -- Unknown To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Realy LARGE TCP/IP Window Size?
On Mon, May 07, 2001 at 16:20:05 -0500, Bob Willcox wrote: > > I am working on a FreeBSD device driver for my Co's GSN adapter and need > to be able to set my TCP/IP window size to 512KB (or perhaps more). I > have tried doing this with sysctl: > > root@sebulba:p0 /root> sysctl -w net.inet.tcp.recvspace=524288 > net.inet.tcp.recvspace: 131072 -> 524288 > root@sebulba:p0 /root> sysctl -w net.inet.tcp.sendspace=524288 > net.inet.tcp.sendspace: 131072 -> 524288 > > and although the sysctl happily takes the specification, when I attempt > an ftp command I get: > > root@sebulba:p0 /root> ftp 192.168.1.2 > ftp: socket: No buffer space available > > This is on a FreeBSD 4.0-stable system: > > FreeBSD sebulba.vieo.com 4.0-STABLE FreeBSD 4.0-STABLE #202: Mon May 7 15:09:46 CDT >2001 [EMAIL PROTECTED]:/usr/src/sys/compile/GPXTEST i386 > > Anybody have any ideas what I need to do to get this to work? sysctl -w net.inet.tcp.rfc1323=1 You need that to be able to set your window size to anything over 64K. I think there's an rc.conf knob to do that so you don't have to tweak it manually every time. You really don't want to use ftp to test bandwidth. Use netperf instead. It is located in ports/benchmarks. You might also be interested in the zero copy patches. See: http://people.FreeBSD.org/~ken/zero_copy/ The latest patches aren't linked off the page, they're available here: http://people.FreeBSD.org/~ken/zero_copy/zero_copy.diffs.20010124 Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FPU exception, kernel panic
Sun, May 06, 2001 at 17:14:08, rakshe (Rohit Rakshe) wrote about "Re: FPU exception,
kernel panic":
(I cannot even guarantree 50% this is the same problem, but...)
There were some reports in current@ about incorrect usage of i586_bzero()
which uses FPU for zero-filling. It generated random kernel panics mainly
on K6-2, also on P5-MMX and similars. You can try to disable such bzero,
but IMHO it is reasonable to upgrade to 4.3-RELEASE (RELENG_4_3) first.
> I guessed I asked too much. Can someone please tell me just this:
>
> "How do I translate 48 bit address (segment descriptor:offset) to a
> linear address which gdb can understand ?"
> >
> > I modified some TCP and UDP code in FreeBSD 4.1 and suddenly started
> > getting (almost repeatable) kernel panics. This is how it looks like
> > from remote gdb:
> >
> > (kgdb) bt
> > #0 0xc0192e58 in panic (fmt=0xc035c076 "npxintr from nowhere") at
> > ../../kern/kern_shutdown.c:550
> > #1 0xc0303c6c in npx_intr (dummy=0x0) at ../../i386/isa/npx.c:721
> > #2 0xc02e1052 in Xfpu ()
> > #3 0xc019824d in softclock () at ../../kern/kern_timeout.c:131
> > .
> > .
> > .
> > (kgdb) list
> > 126 } else {
> > 127 c->c_flags =
> > 128 (c->c_flags &
> > ~CALLOUT_PENDING);
> > 129 }
> > 130 splx(s);
> > 131 c_func(c_arg);
> > 132 s = splhigh();
> > 133 steps = 0;
> > 134 c = nextsoftcheck;
> > 135 }
> > .
> > .
> > .
> > (kgdb)
> > #1 0xc0303c6c in npx_intr (dummy=0x0) at ../../i386/isa/npx.c:721
> > 721 panic("npxintr from nowhere");
> > (kgdb) p npxproc
> > $5 = 0
> > (kgdb) p npx_exists
> > $6 = 1 '\001'
> > .
> > .
> > .
> > (kgdb) info all-registers
> > eax0x12 18
> > ecx0xc03a60a0 -1069916000
> > edx0x40 4194304
> > ebx0xcbc56540 -876255936
> > esp0xc0361354 0xc0361354
> > ebp0xc0361410 0xc0361410
> > esi0x40 4194304
> > edi0x40 4194304
> > eip0xc019824d 0xc019824d
> > eflags 0x346838
> > cs 0x8 8
> > ss 0x10 16
> > ds 0x400010 4194320
> > es 0x10 16
> > fs 0x0 0
> > gs 0x0 0
> > (kgdb) info float
> > status 0xc8f5: exceptions: INVALID DIVZ UNDERF LOS FPSTACK; flags: 1000;
> > top 1
> > control 0x6620: compute to 53 bits; round DOWN; mask: LOS;
> > warning: reserved bits on: 0x6000
> >
> > last instruction: opcode 0x2825; pc 0x71a4:0x2824c316; operand
> > 0xf800:0x8176640
> > regno tag msb lsb value
> > %st(7)valid 08179a802825 Denormal (0 as a double)
> > %st(6)valid 71a42824c316 Unnormal (NaN)
> > %st(5)valid 08176640282571a42824 Unnormal (NaN)
> > %st(4)valid c8910818f9380818f800 Unnormal (NaN)
> > %st(3)valid 282571a42824c316bfbf Unnormal (NaN)
> > %st(2)valid e82808176620089c3000 Unnormal (NaN)
> > %st(1)valid 003200010001 Denormal (0 as a double)
> > %st(0) => valid 00240818f800 Denormal (0 as a double)
> >
> >
> > So, this means that there was a FPU exception in kernel, right ?
> >
> > 1. The code which I added in kernel does not use any floats. So I am
> > wondering why this problem should happen at all.
> >
> > 2. pc register in FPU should give address of the instruction which caused
> > this exception, right ?
> >
> > 3. If yes, how do I translate this 48 bit address in a linear address
> > which gdb can understand ?
/netch
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: FPU exception, kernel panic
On Mon, May 07, 2001 at 08:32:06AM +0300, Valentin Nechayev wrote: > Sun, May 06, 2001 at 17:14:08, rakshe (Rohit Rakshe) wrote about "Re: FPU >exception, kernel panic": > > (I cannot even guarantree 50% this is the same problem, but...) > There were some reports in current@ about incorrect usage of i586_bzero() > which uses FPU for zero-filling. It generated random kernel panics mainly > on K6-2, also on P5-MMX and similars. You can try to disable such bzero, > but IMHO it is reasonable to upgrade to 4.3-RELEASE (RELENG_4_3) first. This problem should not happen in 4.X as it is a side effect of the SMP-NG stuff in -current. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Realy LARGE TCP/IP Window Size?
On Mon, May 07, 2001 at 04:20:05PM -0500, Bob Willcox wrote: > root@sebulba:p0 /root> ftp 192.168.1.2 > ftp: socket: No buffer space available One possibility is that your process limits for sbsize are too low. You could check what it says in login.conf. (I note that our tcsh doesn't support sbsize as a limit...) David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Realy LARGE TCP/IP Window Size?
On Mon, May 07, 2001 at 10:52:47PM +0100, David Malone wrote: > On Mon, May 07, 2001 at 04:20:05PM -0500, Bob Willcox wrote: > > root@sebulba:p0 /root> ftp 192.168.1.2 > > ftp: socket: No buffer space available > > One possibility is that your process limits for sbsize are > too low. You could check what it says in login.conf. > > (I note that our tcsh doesn't support sbsize as a limit...) > > David. My limits command says: root@sebulba:p1 /usr/src/sys/i386/conf> limits Resource limits (current): cputime infinity secs filesize infinity kb datasize 524288 kb stacksize 65536 kb coredumpsize infinity kb memoryuseinfinity kb memorylocked infinity kb maxprocesses 2067 openfiles4136 sbsize infinity bytes So I would presume that it isn't the limiting factor. Thanks, Bob -- Bob Willcox Living your life is a task so difficult, [EMAIL PROTECTED]it has never been attempted before. Austin, TX -- Unknown To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Realy LARGE TCP/IP Window Size?
On Mon, May 07, 2001 at 04:45:31PM -0500, Bob Willcox wrote: > On Mon, May 07, 2001 at 03:38:02PM -0600, Kenneth D. Merry wrote: > > On Mon, May 07, 2001 at 16:20:05 -0500, Bob Willcox wrote: > > > > > > I am working on a FreeBSD device driver for my Co's GSN adapter and need > > > to be able to set my TCP/IP window size to 512KB (or perhaps more). I > > > have tried doing this with sysctl: > > > > > > root@sebulba:p0 /root> sysctl -w net.inet.tcp.recvspace=524288 > > > net.inet.tcp.recvspace: 131072 -> 524288 > > > root@sebulba:p0 /root> sysctl -w net.inet.tcp.sendspace=524288 > > > net.inet.tcp.sendspace: 131072 -> 524288 > > > > > > and although the sysctl happily takes the specification, when I attempt > > > an ftp command I get: > > > > > > root@sebulba:p0 /root> ftp 192.168.1.2 > > > ftp: socket: No buffer space available > > > > > > This is on a FreeBSD 4.0-stable system: > > > > > > FreeBSD sebulba.vieo.com 4.0-STABLE FreeBSD 4.0-STABLE #202: Mon May 7 15:09:46 >CDT 2001 [EMAIL PROTECTED]:/usr/src/sys/compile/GPXTEST i386 > > > > > > Anybody have any ideas what I need to do to get this to work? > > > > sysctl -w net.inet.tcp.rfc1323=1 > > > > You need that to be able to set your window size to anything over 64K. I > > think there's an rc.conf knob to do that so you don't have to tweak it > > manually every time. > > Thanks, I'll give this a try. I tried setting the above sysctl but that didn't have any effect on the problem. Through a binary search of send and recv space settings I was able to determine that anything over 227 KB (232448 bytes) fails when I attempt to open a TCP socket. Bob [snip] > > > > > Ken > > -- > > Kenneth Merry > > [EMAIL PROTECTED] > > -- > Bob Willcox Living your life is a task so difficult, > [EMAIL PROTECTED]it has never been attempted before. > Austin, TX -- Unknown -- Bob Willcox Living your life is a task so difficult, [EMAIL PROTECTED]it has never been attempted before. Austin, TX -- Unknown To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Realy LARGE TCP/IP Window Size?
On Mon, May 07, 2001 at 17:15:20 -0500, Bob Willcox wrote: > On Mon, May 07, 2001 at 04:45:31PM -0500, Bob Willcox wrote: > > On Mon, May 07, 2001 at 03:38:02PM -0600, Kenneth D. Merry wrote: > > > On Mon, May 07, 2001 at 16:20:05 -0500, Bob Willcox wrote: > > > > > > > > I am working on a FreeBSD device driver for my Co's GSN adapter and need > > > > to be able to set my TCP/IP window size to 512KB (or perhaps more). I > > > > have tried doing this with sysctl: > > > > > > > > root@sebulba:p0 /root> sysctl -w net.inet.tcp.recvspace=524288 > > > > net.inet.tcp.recvspace: 131072 -> 524288 > > > > root@sebulba:p0 /root> sysctl -w net.inet.tcp.sendspace=524288 > > > > net.inet.tcp.sendspace: 131072 -> 524288 > > > > > > > > and although the sysctl happily takes the specification, when I attempt > > > > an ftp command I get: > > > > > > > > root@sebulba:p0 /root> ftp 192.168.1.2 > > > > ftp: socket: No buffer space available > > > > > > > > This is on a FreeBSD 4.0-stable system: > > > > > > > > FreeBSD sebulba.vieo.com 4.0-STABLE FreeBSD 4.0-STABLE #202: Mon May 7 >15:09:46 CDT 2001 [EMAIL PROTECTED]:/usr/src/sys/compile/GPXTEST i386 > > > > > > > > Anybody have any ideas what I need to do to get this to work? > > > > > > sysctl -w net.inet.tcp.rfc1323=1 > > > > > > You need that to be able to set your window size to anything over 64K. I > > > think there's an rc.conf knob to do that so you don't have to tweak it > > > manually every time. > > > > Thanks, I'll give this a try. > > > I tried setting the above sysctl but that didn't have any effect on the > problem. Through a binary search of send and recv space settings I was > able to determine that anything over 227 KB (232448 bytes) fails when I > attempt to open a TCP socket. You probably also need: sysctl -w kern.ipc.maxsockbuf=2097152 Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Realy LARGE TCP/IP Window Size?
On Mon, May 07, 2001 at 04:17:53PM -0600, Kenneth D. Merry wrote: > On Mon, May 07, 2001 at 17:15:20 -0500, Bob Willcox wrote: > > On Mon, May 07, 2001 at 04:45:31PM -0500, Bob Willcox wrote: > > > On Mon, May 07, 2001 at 03:38:02PM -0600, Kenneth D. Merry wrote: > > > > On Mon, May 07, 2001 at 16:20:05 -0500, Bob Willcox wrote: > > > > > > > > > > I am working on a FreeBSD device driver for my Co's GSN adapter and need > > > > > to be able to set my TCP/IP window size to 512KB (or perhaps more). I > > > > > have tried doing this with sysctl: > > > > > > > > > > root@sebulba:p0 /root> sysctl -w net.inet.tcp.recvspace=524288 > > > > > net.inet.tcp.recvspace: 131072 -> 524288 > > > > > root@sebulba:p0 /root> sysctl -w net.inet.tcp.sendspace=524288 > > > > > net.inet.tcp.sendspace: 131072 -> 524288 > > > > > > > > > > and although the sysctl happily takes the specification, when I attempt > > > > > an ftp command I get: > > > > > > > > > > root@sebulba:p0 /root> ftp 192.168.1.2 > > > > > ftp: socket: No buffer space available > > > > > > > > > > This is on a FreeBSD 4.0-stable system: > > > > > > > > > > FreeBSD sebulba.vieo.com 4.0-STABLE FreeBSD 4.0-STABLE #202: Mon May 7 >15:09:46 CDT 2001 [EMAIL PROTECTED]:/usr/src/sys/compile/GPXTEST i386 > > > > > > > > > > Anybody have any ideas what I need to do to get this to work? > > > > > > > > sysctl -w net.inet.tcp.rfc1323=1 > > > > > > > > You need that to be able to set your window size to anything over 64K. I > > > > think there's an rc.conf knob to do that so you don't have to tweak it > > > > manually every time. > > > > > > Thanks, I'll give this a try. > > > > > > I tried setting the above sysctl but that didn't have any effect on the > > problem. Through a binary search of send and recv space settings I was > > able to determine that anything over 227 KB (232448 bytes) fails when I > > attempt to open a TCP socket. > > You probably also need: > > sysctl -w kern.ipc.maxsockbuf=2097152 It looks like this did it!! Unfortunately, the adapter is now cratering. Something more for the hardware guys to do I guess. :-) Thanks Kenneth. Bob > > Ken > -- > Kenneth Merry > [EMAIL PROTECTED] -- Bob Willcox Living your life is a task so difficult, [EMAIL PROTECTED]it has never been attempted before. Austin, TX -- Unknown To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
bridging on specific devices
Hello, I'm using 4.2 release and i need bridging. Luigi tells in the manpage that the option to select specific devices for bridging is still in development. Does anybody know how far this work is done in 4.3 stable ? I need this feature very urgently, and all of my experiments with net.link.ether.bridge_cfg didn't work because the bridge was either completely deactived or active on all interface and not just the desired ones. Regards, Marco -- Mit freundlichen Gruessen, Marco Wertejuk Computer/Internet/Security-Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FPU exception, kernel panic
Valentin Nechayev <[EMAIL PROTECTED]> writes: > (I cannot even guarantree 50% this is the same problem, but...) > There were some reports in current@ about incorrect usage of i586_bzero() > which uses FPU for zero-filling. It generated random kernel panics mainly > on K6-2, also on P5-MMX and similars. You can try to disable such bzero, > but IMHO it is reasonable to upgrade to 4.3-RELEASE (RELENG_4_3) first. 1) this bug only occurs on -CURRENT systems that have interrupt preemption enabled (i.e. anything newer than february) 2) the symptoms are nowhere near what's described here anyway - you'd see the kernel stack getting smashed, not an FPU exception. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: bridging on specific devices
> Hello, > > I'm using 4.2 release and i need bridging. > Luigi tells in the manpage that the option > to select specific devices for bridging is > still in development. > > Does anybody know how far this work is done > in 4.3 stable ? it works on 4.3-RELEASE cheers luigi > I need this feature very urgently, and all > of my experiments with net.link.ether.bridge_cfg > didn't work because the bridge was either > completely deactived or active on all > interface and not just the desired ones. > > Regards, > Marco > > -- > Mit freundlichen Gruessen, > Marco Wertejuk > Computer/Internet/Security-Services > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Question about building source
Am I correct in assuming that: $ cd /usr/src $ make installworld DESTDIR=/vol1/FreeBSD will install the entire OS into /vol1/FreeBSD? Has anyone ever tried this? ;) -- Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED] >>> The opinions expressed above are entirely my own <<< "Man is the only creature that refuses to be what he is." --Albert Camus To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Displaying options for current NFS mounts
What happened to this patch/this discussion? To remind everyone, the issue was to print specific file-system specific mount options as in dima@spike% /sbin/mount -vt nfs pid295@spike:/host on /host (nfs, v2, udp, hard, intr) pid295@spike:/st on /st (nfs, v2, udp, hard, intr) instead of just dima@spike% /sbin/mount -vt nfs pid295@spike:/host on /host (nfs) pid295@spike:/st on /st (nfs) Gerald On Sun, 25 Mar 2001, Dima Dorfman wrote: >Boris Popov <[EMAIL PROTECTED]> writes: >> This is not a bikeshed, but sysctl is the wrong interface to do >> this. Use VFSs/VOPs instead. This isn't a big problem with passing string >> from kernel to userland. > > I like your idea of using the extattr interface. It isn't a perfect > match, since ideally this would be a VFS operation, but it works quite > well. The only modifications required are to mount(8) to try to get > this attribute, and then to any filesystem which wishes to support it. > > Below is a patch which makes the necessary changes to mount(8), and > adds support for this to NFS. It's amazingly simple, and doesn't > interfere with anything else (i.e., you don't have to rebuild half the > world to use it). The only thing I don't like is that the "mountopts" > and "mountopts_verbose" constants aren't macroized, but that can be > easily solved (I just didn't know where to put them). With it, > mount(8) outputs stuff like this: > > dima@spike% /sbin/mount -vt nfs > pid295@spike:/host on /host (nfs, v2, udp, hard, intr) > pid295@spike:/st on /st (nfs, v2, udp, hard, intr) > bazooka:/a on /.amd/bazooka/host/a (nfs, nodev, nosuid, v3, tcp, hard, intr) > bazooka:/b on /.amd/bazooka/host/b (nfs, nodev, nosuid, v3, tcp, hard, intr) > > Comments? Suggestions? > > Thanks in advance > > Dima Dorfman > [EMAIL PROTECTED] > > P.S. Would anyone have a fit if I wrote man pages for > extattr_get_file, extattr_set_file, and extattr_delete_file? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
picoBSD
Where is the picoBSD source code ? Can i compile for ARM processor ? Best Regards Michael Trimarchi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Question about building source
dave> $ cd /usr/src dave> $ make installworld DESTDIR=/vol1/FreeBSD dave> will install the entire OS into /vol1/FreeBSD? Yes (or it should be). dave> Has anyone ever tried this? ;) You should have already seen the result that uses "make installworld DESTDIR=/what/ever" -- FreeBSD distribution itself :-) -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
