Re: Question about building source

2001-05-07 Thread Makoto MATSUSHITA


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



picoBSD

2001-05-07 Thread Trimarchi Michael

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: Displaying options for current NFS mounts

2001-05-07 Thread Gerald Pfeifer

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



Question about building source

2001-05-07 Thread Dave Hayes

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: bridging on specific devices

2001-05-07 Thread Luigi Rizzo

> 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



Re: FPU exception, kernel panic

2001-05-07 Thread Dag-Erling Smorgrav

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



bridging on specific devices

2001-05-07 Thread Marco Wertejuk

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: Realy LARGE TCP/IP Window Size?

2001-05-07 Thread Bob Willcox

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



Re: Realy LARGE TCP/IP Window Size?

2001-05-07 Thread Kenneth D. Merry

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?

2001-05-07 Thread Bob Willcox

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?

2001-05-07 Thread Bob Willcox

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?

2001-05-07 Thread David Malone

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: FPU exception, kernel panic

2001-05-07 Thread David Malone

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: FPU exception, kernel panic

2001-05-07 Thread Valentin Nechayev

 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: Realy LARGE TCP/IP Window Size?

2001-05-07 Thread Kenneth D. Merry

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



Realy LARGE TCP/IP Window Size?

2001-05-07 Thread Bob Willcox


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



(no subject)

2001-05-07 Thread Francois Zellinger

subscribe

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: no keyboard

2001-05-07 Thread John Baldwin


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



Re: Q: porting a driver from linux to freebsd.

2001-05-07 Thread Julian Elischer

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: sysctl(8) and opaque MIB entries

2001-05-07 Thread Dag-Erling Smorgrav

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: sysctl(8) and opaque MIB entries

2001-05-07 Thread Peter Pentchev

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

2001-05-07 Thread Dag-Erling Smorgrav

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

2001-05-07 Thread Peter Pentchev

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

2001-05-07 Thread Poul-Henning Kamp

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

2001-05-07 Thread Peter Pentchev

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

2001-05-07 Thread Dag-Erling Smorgrav

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

2001-05-07 Thread Dag-Erling Smorgrav

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

2001-05-07 Thread Sheldon Hearn



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

2001-05-07 Thread Dag-Erling Smorgrav

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: Getting peer credentials on a unix domain socket

2001-05-07 Thread Mike Silbersack


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



sysctl(8) and opaque MIB entries

2001-05-07 Thread Sheldon Hearn


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: multilingual boot.flp for 4.3-RELEASE

2001-05-07 Thread Tatsumi Hosokawa

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