Re: bluetooth

[Duncan Barclay]

Hi

I might be worth talking to the people at

http://www.blueaid.com/

Bill Munday has written and architected a number of the Bluetooth stacks
various vendors use. He does free consulting and knows a _lot_ of people
in the Bluetooth world. He is likely to know about other Bluetooth
efforts for Linux.

I can also help out with concepts/overviews etc. I have designed RFICs
for Bluetooth and am part of the SIG writing version 1.2 of the standard
(and no, I didn't do any of version 1.1 so don't hassle me!).

Duncan

On 04-Oct-01 Maksim Yevmenkin wrote:
> 
>> Is anyone working on bluetooth drivers and accompanying userland programs
>> (bluetooth equivalents of wicontrol, etc.) ?
> 
> ok :) i'm actually working on BlueTooth stack for FreeBSD. so far
> i have some code that implements basic functionality for HCI layer.
> the implementation is based on Netgraph and supposed to be completely 
> optional. 
> 
> thanks,
> max
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 

---

Duncan Barclay  | God smiles upon the little children,
[EMAIL PROTECTED]   | the alcoholics, and the permanently stoned.
[EMAIL PROTECTED]| Steven King

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

Re: bluetooth

[John Kozubik]

I found my cards at pricewatch.com - just type bluetooth into the top
search textbox - you should see 3com and xircom cards come up for $120 -
$150.

-
John Kozubik - [EMAIL PROTECTED] - http://www.kozubik.com



On Thu, 4 Oct 2001, Nicolai Petri wrote:

> Hi Warner,
> 
> I've seen cards for sale on http://www.digianswer.dk (Motorola's Bluetooth
> center), the price is 200$ for a retail pccard.
> 
> Best regards,
> - Nicolai Petri
> 
> - Original Message -
> From: "Warner Losh" <[EMAIL PROTECTED]>
> To: "John Kozubik" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Thursday, October 04, 2001 3:08 AM
> Subject: Re: bluetooth
> 
> 
> > In message <[EMAIL PROTECTED]> John
> Kozubik writes:
> > : Is anyone working on bluetooth drivers and accompanying userland
> programs
> > : (bluetooth equivalents of wicontrol, etc.) ?
> >
> > I tried to get a bluetooth pcmcia card, but I haven't been able to win
> > one on ebay or find one availble through more normal channels.
> >
> > I've also had no luck finding datasheets on the bluetooth stuff, but
> > to be honest I haven't tried too hard.
> >
> > Warner
> >
> > 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
> 


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

Re: bluetooth

[Maksim Yevmenkin]

Duncan

> I might be worth talking to the people at
> 
> http://www.blueaid.com/

Thanks for the info!
 
> Bill Munday has written and architected a number of the Bluetooth stacks
> various vendors use. He does free consulting and knows a _lot_ of people
> in the Bluetooth world. He is likely to know about other Bluetooth
> efforts for Linux.

Again thanks for the name :) As far as Linux concern, i'm aware of two
BlueTooth stacks for Linux

1) AXIS OpenBT stack (http://sourceforge.net/projects/openbt/)
2) Bluez (http://bluez.sourceforge.net/) 
(i actually know the Bluez author. Great programmer, we use
to work together.)
 
> I can also help out with concepts/overviews etc. I have designed RFICs
> for Bluetooth and am part of the SIG writing version 1.2 of the standard
> (and no, I didn't do any of version 1.1 so don't hassle me!).

Well, i would like to take this opportunity and tell a little bit more
about current status :) If anyone feels that it is not appropriate place
or time please let me know.

[...]

> > the implementation is based on Netgraph and supposed to be completely
> > optional.

The current design goals are:

1) Minimal changes to FreeBSD kernel code. It should be possible
   to maintain stack outside of FreeBSD code if required.
2) Stack must be optional. Do not want it - do not use it.
3) Stack must be flexible. Parts of the stack must be replaceable.
4) Stack must provide access to all protocol layers.
5) Try to avoid (if possible) kernel threads and try to 
   reduce or eliminate extra overhead on synchronization.
6) Stack must provide option to configure each unit in "special"
   way to work around possible hardware bugs.
7) Try to stay within Netgraph infrastructure and reuse most
   of Netgraph tools (ngctl etc).

i want to do something different rather than "classic" network
stack. That is why i decided to try Netgraph framework. It is
highly experimental code (proof of concept, if you will :)

So far things looks like this. Please note i'm still working
on this and there might be other "oop"es and "gotcha"s :) 

   x x
   | |   User  space
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
   | | Kernel   /
   | sco | acl  \
+--V-V--+   /
|   | cmd   \
|   Netgraph HCI node   <---/--> "btd"
|   |   \daemon.
+--^+   / Controls BlueTooth
   | drv\ unit
   |
   |
   | right Kernel space / User space
+--V+   \
|   |---/-->
|  Netgraph "tee" node  |  righ2left\"btdump"
|   |---/-->  utility
+--^+  left2right   \ Dumps all packets
   | left   / "a-la" tcpdump
   |
   |
   | hook
+--V+
|   |
| BlueTooth unit driver | 
| (Netgraph node)   |
|   |
+---+

New instance of a HCI node are created for each BlueTooth unit. 
The participating nodes are connected as described above. The
HCI node exports three hooks:

1) acl - ACL data (Data)
2) sco - SCO data (Voice)
3) cmd - special hook that allows to send HCI commands to the unit.

All HCI commands and events are mapped to Netgraph control 
messages. One HCI command/event - one control message. The "tee" 
node is used to provide access to raw data and if this is not 
required may be omitted.

The current model is one user space process per BlueTooth unit.
However it might be converted to thread per process model.
Control daemon "btd" is responsible for initialization and 
control of the unit. When daemon starts it sends set of HCI 
commands to recognize unit and then sends another set of HCI 
commands to perform actual intialization. Results are reported
back in form of Netgraph control messages. The initialization
sequence may vary depending on specific unit (to work around
possible hardware bugs) and daemon must decide if it was 
successful or not. 

The control daemon also may implement additional features 
such as management of pin codes and link keys etc.

In the near future there will be L2CAP node that will be
attached to "acl" hook. But for now it is possible to
implement L2CAP procotol as user space daemon, and then
convert it to Netgraph node. The same is true for RFCOMM,
SDP and TCP (Telephony Control Protocol :) nodes.

thanks,
max

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

grep memory footage

[Guido van Rooij]

When fgrepping a huge file (say 10GB) for a non-existing string,
fgrep's memory size skyrockets. At a certain point in time its SIZE was 391M
(RSS was about 30MB) and the system got rather unreponsive. The
string was about 12 bytes big, and we fail to see why grep would
need so much.

Is there a good explanation for this?

-Guido

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

Re: VM: file swapping (this time in libc): patch

[Vladimir Dozen]

ehlo.

  I was told that diff format I used is unappropriate for most cases,
  so I redo it in unified (-u) format.

  Purpose: to allow developers of large applications to use system
  memory allocation routines for allocating in mmap()ed file
  instead of writing own ones. Also, allow to run applications that
  may use huge amount of memory (like Gimp) without reconfiguring 
  swap.
  
  Patch description: the patch implements file-backed memory 
  allocation for regular malloc() routine. If 'F' flag is set
  in malloc options, instead of doing mmap(MAP_ANON), malloc()
  maps regions from temporal file. File is growed as neccessary,
  and new regions are mapped from the same file.

  Details: to avoid using two methods of allocation (brk() and mmap()) in
  the same file, regular allocation altered to use mmap(). This
  is done by writing emulators (brk_emulator() and sbrk_emulator()).
  File allocator uses single descriptor (usually fd==512). File is
  created in directory specified by $SWAPDIR, $TMPDIR or "/tmp"
  (in this order). $SWAPDIR is introduced since often people use
  memory file system for /tmp. Temporal file is unlinked after
  creation, so it will be deleted automatically at exit.

  Informal testing shows no performance hit comparing with old-style
  brk() allocation, and small hit when using file-backed allocation.

  Here the patch (made on 4.3-RELEASE-p20)
===
--- malloc.c.oldTue Oct  2 12:52:25 2001
+++ malloc.cThu Oct  4 20:05:52 2001
@@ -97,7 +97,7 @@
 #include 
 #include 
 #include 
-
+
 /*
  * This structure describes a page worth of chunks.
  */
@@ -245,9 +245,6 @@
 #define UTRACE(a,b,c)
 #endif /* HAS_UTRACE */
 
-/* my last break. */
-static void *malloc_brk;
-
 /* one location cache for free-list holders */
 static struct pgfree *px;
 
@@ -262,6 +259,7 @@
mmap(0, (size), PROT_READ|PROT_WRITE, MAP_ANON|MAP_PRIVATE, \
MMAP_FD, 0);
 
+
 /*
  * Necessary function declarations
  */
@@ -297,6 +295,167 @@
 }
 
 /*
+ * file swap options
+ */
+static int   malloc_file_swap;
+static char* malloc_file_swap_dir;
+static int   malloc_file_swap_num;
+static int   malloc_file_swap_fd;
+static int   malloc_file_swap_offset;
+static int   malloc_file_swap_size;
+
+/* 
+ * mmap-based brk/sbrk emulation
+ */
+static char *malloc_brk;
+static char* sbrk_emulation(int incr)
+{
+  if( incr == 0 ) return malloc_brk;
+  wrterror("unsupported sbrk argument");
+};
+
+/**
+ * brk emulation
+ *
+ * note that return value is different from brk!
+ * @result 0 allocation failed, ptr -- start of new block
+ * @param new_brk desired location of new top of heap
+ *  
+ */
+static char* brk_emulation(char* new_brk)
+{
+  char* p;
+  char  buf[4096];
+  int   filegrow,wr,blocksize;
+  int   stage;
+  int   tmp_fd;
+  
+  /* size of requested block */
+  blocksize = new_brk-malloc_brk;
+  
+  /* increase heap size */
+  if( blocksize > 0 )
+  {
+if( malloc_file_swap )
+{
+  /* create file at first call */
+  if( malloc_file_swap_num == 0 )
+  {
+/* where to put swap file */
+if( !malloc_file_swap_dir ) malloc_file_swap_dir = getenv("SWAPDIR");
+if( !malloc_file_swap_dir ) malloc_file_swap_dir = getenv("TMPDIR");
+if( !malloc_file_swap_dir ) malloc_file_swap_dir = "/tmp";
+  
+/* generate random file name and open it */
+do
+{
+  snprintf(buf,sizeof(buf),"%s/%08x.swap",
+   malloc_file_swap_dir,malloc_file_swap_num);
+  malloc_file_swap_num *= 11;
+  malloc_file_swap_num += 13;
+  malloc_file_swap_fd = open(buf,O_CREAT|O_EXCL|O_RDWR|O_NOFOLLOW,0600);
+}
+while( malloc_file_swap_fd < 0 && errno == EEXIST );
+if( malloc_file_swap_fd < 0 ) return 0;
+
+/* 
+ * some shell scripts (GNU configure?) can be
+ * unhappy if we use descriptor 4 or 5; also qmail-send
+ * uses descriptors up to 6 in normal mode.
+ * so we dup descriptor into large enough and close original
+ */
+tmp_fd = 512;
+while( tmp_fd >= 0 && dup2(malloc_file_swap_fd,tmp_fd) < 0 ) tmp_fd--;
+if( tmp_fd < 0 ) return 0;
+close(malloc_file_swap_fd);
+malloc_file_swap_fd = tmp_fd;
+
+/* unlink file to autoremove it at last reference lost */
+unlink(buf);
+  }
+  
+  if( malloc_file_swap_offset+blocksize > malloc_file_swap_size )
+  {
+/* fill tail of file with zeroes */
+memset(buf,0,sizeof(buf));
+
+/* 
+ * grow file
+ * critical grow: 
+ *   allocate requested size; if any error happens here, 
+ *   whole allocation fails;
+ * supplemental grow: 
+ *   pre-allocate one more megabyte; errors are ignored
+ */
+for( stage=0; stage<2; stage++ )
+{
+  if( stage == 0 ) fi

RE: [xine-user] xine on freebsd?

[Heiko Schaefer]

Hey everyone,

> > Also, are you sure that you have enough shared memory on the freebsd box?
> By
> > default the amount of shm you can use is fairly small, and if you use
> GNOME it
> > will easily eat it all.
>
> I can't agree with this statement more.  Gnome/GTK is a pig on SHM, and the
> FreeBSD default make relatively low amounts of memory and segments
> available.  There are various kernel options and tunables that can be set to
> ajust this.

is there anything expect for

kern.ipc.shmmax=67108864
kern.ipc.shmall=32768

that is worth looking into !?

xine's documentation says to set these values already for a very long
time, as without such a setting xine won't run at all.

Heiko


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

64bit Ethernet Card (if_sf driver)

[Bsdguru]

I've been testing the adaptec 64044 card (if_sf driver) which is a 64bit 
66Mhz 4 port ethernet. I can have come to one of two conclusions:

1) the card sucks
2) the driver sucks

or both. A 32bit Dlink 4 port card outperforms it by a wide margin, as do 
32bit eepro100s. "wide margin" being defined as about 40%.

Given that bus resources are not easily measureable..Im quoting cpu usage for 
handling the same number of pps. But its pretty difficult to justify using a 
64bit slot and rather expensive card with such lousy performance. I cant even 
justify the bus-bandwidth saving with a card that cant route more than 
250Mb/s.

I guess my question has to do with whether the board is just a dog or the 
driver needs substantial optimization. The folks at adaptec aren't dopes 
generally, so I cant imagine that they chose a chipset that was so inferior 
to the one on their 32bit adapter (which uses the same as the Dlink).

Anyone with experience or ideas?

Bryan



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

Re: grep memory footage

[Mike Smith]

> 
> When fgrepping a huge file (say 10GB) for a non-existing string,
> fgrep's memory size skyrockets. At a certain point in time its SIZE was 391M
> (RSS was about 30MB) and the system got rather unreponsive. The
> string was about 12 bytes big, and we fail to see why grep would
> need so much.
> 
> Is there a good explanation for this?

It's a known bug in grep; there are probably a bunch of PRs outstanding 
on it.  We need grep to be updated.

-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
   V I C T O R Y   N O T   V E N G E A N C E



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

Re: grep memory footage

[Ruslan Ermilov]

On Thu, Oct 04, 2001 at 11:49:49AM -0700, Mike Smith wrote:
> > 
> > When fgrepping a huge file (say 10GB) for a non-existing string,
> > fgrep's memory size skyrockets. At a certain point in time its SIZE was 391M
> > (RSS was about 30MB) and the system got rather unreponsive. The
> > string was about 12 bytes big, and we fail to see why grep would
> > need so much.
> > 
> > Is there a good explanation for this?
> 
> It's a known bug in grep; there are probably a bunch of PRs outstanding 
> on it.  We need grep to be updated.
> 
The sad thing is that GNU Grep has recently lost his maintainer.
Let me know if you want additional details.


Cheers,
-- 
Ruslan Ermilov  Oracle Developer/DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age

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

GA621 ?

[DOROVSKOY,IGOR (A-Portsmouth,ex1)]

Is anyone got running Netgear gigabit nic GA621 in 4.4?

cheers,
Igor

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

Re: ALT- (Was: how to make 'for' understand two words as asingleargumen)

[Michael Sinz]

Dag-Erling Smorgrav wrote:
> 
> Michael Sinz <[EMAIL PROTECTED]> writes:
> > BTW - How does your system represent a file with 0xA0 in it?  An ls on
> > FreeBSD 4.4-Stable seems to show it as:
> >
> > -rw-r--r--  1 msinz  msinz   0 Oct  3 12:00 foo?bar
> >
> > Interesting - not what I would have expected but I think "non-printables"
> > are replaced by the "?" when ls runs.
> >
> > Even more interesting is this:
> >
> > -rw-r--r--  1 msinz  msinz   0 Oct  3 12:00 foo?bar
> > -rw-r--r--  1 msinz  msinz   1 Oct  3 12:05 foo?bar
> >
> 
> This is only "interesting" (in the sense in which you seem to use the
> word) to someone who has not read the ls(1) manual page, and does not
> know of the -q and -B options...

This was within the context of alt-space replacing spaces in file names.
As things stand now, it is not even easily usable as the main tool used
to list the files in a directory does not show it correctly.  (As far as
the non-printables, I agree that LS is supposed to do, but is non-breaking
space really a non-printable?)

-- 
Michael Sinz  Worldgate Communications  [EMAIL PROTECTED]
A master's secrets are only as good as
the master's ability to explain them to others.

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

Re: grep memory footage

[Guido van Rooij]

On Thu, Oct 04, 2001 at 11:49:49AM -0700, Mike Smith wrote:
> 
> It's a known bug in grep; there are probably a bunch of PRs outstanding 
> on it.  We need grep to be updated.
> 

>From looking at the source, it seems that the lates version still
seems to have the same problem.

The problem seems to be in grep.c:grep(), where the variable save
seems to ever increase. But the code is so amazingly hairy that I
cannot figure out why.

-Guido

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

[Q] Information on fb/vesa mode programming

[Jonathan Belson]

Hiya


I've been trying to find out some information on programming the
fb/vesa interface, eg. set_video_mode() and friends.

>From the few examples I've seen, it appears that you have to
muck about with banks rather than use a pointer to linear
frame buffer (logo_saver.c, splash.c).  Is there no way to
access the fb linearly?

Does anyone know of any resources giving more information
on fb programming?

Thanks,


--
C-YA
Jon



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

Re: if_sf bug

[Bsdguru]

In a message dated 10/04/2001 2:30:51 PM Eastern Daylight Time, 
[EMAIL PROTECTED] writes:

> > > All the interfaces do that.  If you want to make an invisible interface,
>  > > configure it with IP 0.0.0.0.
>  > 
>  > I believe 'ifconfig foo0 up' is sufficient.
>  
>  Confirming data point:  "ifconfig dc0 up" allowed tcpdump in promiscuous
>  mode when I tried it.
>  
Thats because the dc driver doesnt have the bug that im talking about :-)

B

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

Re: ALT- (Was: how to make 'for' understand two words as asingleargumen)

[Greg Shenaut]

In message <89efc3b204df3107d1@[192.168.1.4]>, Michael Sinz cleopede:
>This was within the context of alt-space replacing spaces in file names.
>As things stand now, it is not even easily usable as the main tool used
>to list the files in a directory does not show it correctly.  (As far as
>the non-printables, I agree that LS is supposed to do, but is non-breaking
>space really a non-printable?)

  touch "altspace" "regularspace"

  env LANG=fr_FR.ISO_8859-1 ls
  alt space
  regular space

  env LANG= ls
  alt?space
  regular space

I believe that most (not quite all) character sets in which 0xa0
is defined at all use it for unbreakable space.  (But it is not
defined in 7-bit ASCII, which is the FreeBSD default.)

Greg Shenaut

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

Re: [Q] Information on fb/vesa mode programming

[Mike Smith]

> I've been trying to find out some information on programming the
> fb/vesa interface, eg. set_video_mode() and friends.

Try the Vesa 3.0 document (google is your friend).

> From the few examples I've seen, it appears that you have to
> muck about with banks rather than use a pointer to linear
> frame buffer (logo_saver.c, splash.c).  Is there no way to
> access the fb linearly?

The video memory organisation varies from mode to mode.  The splash
code tries to work with several different organisations, including the
lowest-common-denominator banked/interleaved modes.

> Does anyone know of any resources giving more information
> on fb programming?

Most DOS games/graphics books should at least try to discuss the use
of VESA video modes.

Regards,
Mike

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

Re: 64bit Ethernet Card (if_sf driver)

[Doug Ambrisko]

[EMAIL PROTECTED] writes:
| I've been testing the adaptec 64044 card (if_sf driver) which is a 64bit 
| 66Mhz 4 port ethernet. I can have come to one of two conclusions:
| 
| 1) the card sucks
| 2) the driver sucks
| 
| or both. A 32bit Dlink 4 port card outperforms it by a wide margin, as do 
| 32bit eepro100s. "wide margin" being defined as about 40%.
| 
| Given that bus resources are not easily measureable..Im quoting cpu usage for 
| handling the same number of pps. But its pretty difficult to justify using a 
| 64bit slot and rather expensive card with such lousy performance. I cant even 
| justify the bus-bandwidth saving with a card that cant route more than 
| 250Mb/s.
| 
| I guess my question has to do with whether the board is just a dog or the 
| driver needs substantial optimization. The folks at adaptec aren't dopes 
| generally, so I cant imagine that they chose a chipset that was so inferior 
| to the one on their 32bit adapter (which uses the same as the Dlink).
| 
| Anyone with experience or ideas?

I can just confirm your observations.  I found that having it in a 64bit
slot or 32bit made no difference.  I hope it is a driver problem since
Adaptec was selling a DEC based 4 port card that they got when they 
bought Cogent.  I find it hard to believe that they would replace that
with a poorer performance card that probably cost them more to make.

Doug A.

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

Re: 64bit Ethernet Card (if_sf driver)

[Andrew Gallatin]

[EMAIL PROTECTED] writes:
 > 
 > Anyone with experience or ideas?
 > 

Because of the aligment constraints of the card, its copying every
single packet the driver recvs.  This is required on alpha (and
possibly other platforms) to prevent an unlaligned access.  In a
forwarding situation on an x86, it is suboptimal.

Try making the m_devget in the rcv handler conditional on !i386 (see
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/nge/if_nge.c.diff?r1=1.13.2.2&r2=1.13.2.3
for an example of how to change this)

I'd be interestd to hear (quantitatively) how much your perf changes.

Drew

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

NFS swap and locking

[David Gilbert]

If you've been following the situation, we have many diskless nodes
that swap over NFS.  We're using a patch (kindly provided to us) that
allows swapon to specify a string to mount NFS swap after boot.  I've
been told (and it looks like) that it calls the same set of functions
that the nfs swap option in the kernel would glean from DHCP, were we
using that route.

That's the background.

Now, if I configure a swap-backed md disk (another patch we received)
on the system and use it heavily with a particular application I get a 
locking panic from process id 4 (bufdaemon).

panic: lockmgr pid 4 not exclusive lock holder unlocking 520

Any ideas?

Dave.

-- 

|David Gilbert, Velocet Communications.   | Two things can only be |
|Mail:   [EMAIL PROTECTED] |  equal if and only if they |
|http://www.velocet.net/~dgilbert |   are precisely opposite.  |
=GLO

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

4.4-stable, savecore and integer overflow in get_dumpsize()

[mki]

It appears that get_dumpsize is b0rked in that the following
returns a negative number for systems with large memory/swap 
configs:

void
get_dumpsize()
{
int kdumpsize;

/* Read the dump size. */
DumpRead(dumpfd, &kdumpsize, sizeof(kdumpsize),
(off_t)(dumplo + ok(dump_nl[X_DUMPSIZE].n_value)), L_SET);
dumpsize = kdumpsize * getpagesize();
}


the dumpsize = kdumpsize * getpagesize() produces a negative
number when kdumpsize = 1032192; resulting in savecore exiting without
actually performing the dump in save_core().

Here's the patch to address it:

--- savecore.c.old  Thu Oct  4 16:22:16 2001
+++ savecore.c  Thu Oct  4 16:25:07 2001
@@ -601,7 +601,7 @@
/* Read the dump size. */
DumpRead(dumpfd, &kdumpsize, sizeof(kdumpsize),
(off_t)(dumplo + ok(dump_nl[X_DUMPSIZE].n_value)), L_SET);
-   dumpsize = kdumpsize * getpagesize();
+   dumpsize = (off_t) kdumpsize * (off_t) getpagesize();
 }
 
 /*

can someone please commit this fix?  

thanks
-mohan


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

chroot

[Thierry Black]

hello...
 
I am writing one simple network server, and can make the daemon and network code work ok, but I want my server to chroot during the initialization.  The problem is this server by design is designed to be installed and run by normal users, and chroot() can only be called by superuser. Because normal users might compile & install it, the server cant be made suid root. (I know normal procedure is to run as root, chroot and drop privileges, but that wont work).
 
I have 2 questions:
Why can superuser only use chroot()? (What if normal users could only chroot() to directories in current chroot() environment?)
 
Is there anything I can do to restrict directory acacess in my program, or simulate chroot in some other way?
 
If possible I want my solution to work on otehr bsd platforms as much as possible too.
 
thank you
 
 
 
thierry
 Get your FREE download of MSN Explorer at http://explorer.msn.com

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

odd behaviour from loader/kernel

[Julian Elischer]

Running 4.4-RELEASE


I have a kernel with the cyclades driver (cy) which I want 
to use on several machines. On on eof the machines however, having
that kernel with no cyclades card results in a page fault in cyprobe().
The simple answer is to just disable the cy driver.. (I really don't
want a separate kernel for this machine)

If I boot -c I can type "dis cy0"
and all works sweet. But I can't be there to type that all the time.
I've tried adding 
hint.cy.0.disabled="1" to both
loader .conf and /boot/device.hints (which didn't exist before)
but when I do a boot -c I see that it is still enabled, and the system
still crashes during boot. It appears that this is a 5.x feature.
(gee how we forget)

Is there something I need to do to get thes dammned device to disable?
Is there somethign I can type in a file somewhere?, Which file?
what do I type at the boot loader prompt to disable the device?
(can I do that? other than boot -c. disable cy0)

Julian



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

Re: [answer] odd behaviour from loader/kernel

[Julian Elischer]

oh hell.. now that I posted this I remembered how it's done in 4.x
(kernel.conf)
ignore this..

On Thu, 4 Oct 2001, Julian Elischer wrote:

> 
> Running 4.4-RELEASE
> 
> 
> I have a kernel with the cyclades driver (cy) which I want 
> to use on several machines. On on eof the machines however, having
> that kernel with no cyclades card results in a page fault in cyprobe().
> The simple answer is to just disable the cy driver.. (I really don't
> want a separate kernel for this machine)
> 
> If I boot -c I can type "dis cy0"
> and all works sweet. But I can't be there to type that all the time.
> I've tried adding 
> hint.cy.0.disabled="1" to both
> loader .conf and /boot/device.hints (which didn't exist before)
> but when I do a boot -c I see that it is still enabled, and the system
> still crashes during boot. It appears that this is a 5.x feature.
> (gee how we forget)
> 
> Is there something I need to do to get thes dammned device to disable?
> Is there somethign I can type in a file somewhere?, Which file?
> what do I type at the boot loader prompt to disable the device?
> (can I do that? other than boot -c. disable cy0)
> 
> Julian
> 
> 
> 
> 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

strnstr(3) - New libc function for review

[Mike Barcroft]

[BCC'd to -hackers for additional comments.]

Hello,
I would appreciate comments/reviews of the following new addition to
libc.  It is largely based off the current strstr(3) implementation.

Patch attached and also available at:
http://people.FreeBSD.org/~mike/patches/strnstr.diff


Best regards,
Mike Barcroft


strnstr.diff

Add a new libc function, strnstr(3), which allows one to limit the
number of characters that are searched.  This is especially useful
with file operations and non-NUL terminated strings.

Index: lib/libc/string/Makefile.inc
===
RCS file: /cvs/src/lib/libc/string/Makefile.inc,v
retrieving revision 1.23
diff -u -r1.23 Makefile.inc
--- lib/libc/string/Makefile.inc31 Jul 2001 16:34:52 -  1.23
+++ lib/libc/string/Makefile.inc5 Oct 2001 00:30:43 -
@@ -10,6 +10,7 @@
memcpy.c memmove.c memset.c rindex.c strcasecmp.c strcat.c strchr.c \
strcmp.c strcoll.c strcpy.c strcspn.c strdup.c strerror.c \
strlcat.c strlcpy.c strlen.c strmode.c strncat.c strncmp.c strncpy.c \
+   strnstr.c \
strpbrk.c strrchr.c strsep.c strsignal.c strspn.c strstr.c strtok.c \
strxfrm.c swab.c wcscat.c wcschr.c wcscmp.c wcscpy.c wcscspn.c \
wcslcat.c wcslcpy.c wcslen.c wcsncat.c wcsncmp.c wcsncpy.c wcspbrk.c \
@@ -36,6 +37,7 @@
 MLINKS+=strerror.3 perror.3 strerror.3 sys_errlist.3 strerror.3 sys_nerr.3
 MLINKS+=strlcpy.3 strlcat.3
 MLINKS+=strtok.3 strtok_r.3
+MLINKS+=strstr.3 strnstr.3
 MLINKS+=wmemchr.3 wmemcmp.3 wmemchr.3 wmemcpy.3 \
wmemchr.3 wmemmove.3 wmemchr.3 wmemset.3 \
wmemchr.3 wcscat.3 wmemchr.3 wcschr.3 \
--- /dev/null   Thu Oct  4 21:11:00 2001
+++ lib/libc/string/strnstr.c   Thu Oct  4 20:37:01 2001
@@ -0,0 +1,70 @@
+/*-
+ * Copyright (c) 2001 Mike Barcroft <[EMAIL PROTECTED]>
+ * Copyright (c) 1990, 1993
+ * The Regents of the University of California.  All rights reserved.
+ *
+ * This code is derived from software contributed to Berkeley by
+ * Chris Torek.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. All advertising materials mentioning features or use of this software
+ *must display the following acknowledgement:
+ * This product includes software developed by the University of
+ * California, Berkeley and its contributors.
+ * 4. Neither the name of the University nor the names of its contributors
+ *may be used to endorse or promote products derived from this software
+ *without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#include 
+__RCSID("@(#)strstr.c  8.1 (Berkeley) 6/4/93");
+__FBSDID("$FreeBSD$");
+
+#include 
+
+/*
+ * Find the first occurrence of find in s, where the search is limited to the
+ * first slen characters of s.
+ */
+char *
+strnstr(s, find, slen)
+   const char *s;
+   const char *find;
+   size_t slen;
+{
+   char c, sc;
+   size_t len;
+
+   if ((c = *find++) != '\0') {
+   len = strlen(find);
+   do {
+   do {
+   if ((sc = *s++) == '\0' || slen-- < 1)
+   return (NULL);
+   } while (sc != c);
+   if (len > slen)
+   return (NULL);
+   } while (strncmp(s, find, len) != 0);
+   s--;
+   }
+   return ((char *)s);
+}
Index: lib/libc/string/strstr.3
===
RCS file: /cvs/src/lib/libc/string/strstr.3,v
retrieving revision 1.7
diff -u -r1.7 strstr.3
--- lib/libc/string/strstr.31 Oct 2001 16:09:00 -   1.7
+++ lib/libc/string/strstr.35 Oct 2001 01:18: