R: [tcpdump-workers] Re: Re: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
On 2000-12-08 00:38 -0800, Guy Harris [EMAIL PROTECTED] wrote: (Both FreeBSD and OpenBSD have the maximum buffer size for BPF as 512KB in the top of the CVS tree; NetBSD still has it as 32K.) You can change both the default and maximum BPF buffer sizes at run time (affecting an subsequent open()) in FreeBSD: # sysctl -w debug.bpf_bufsize=32768 debug.bpf_maxbufsize=4194304 makes the default buffer size 32K and limits the size to 4MB, for example. Notice however that in pcap-bpf.c, pcap_open_live() forces the buffer size to 32K through an IOCTL. This means that the sysctl is overridden if BPF is used throug libpcap. Loris. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: eye-candy hack - warp_saver changing direction :)
OK, OK, I *promise* I'll think twice before posting next time :)
Here's a revised patch - a kern.warp_period = 0 signifies no direction
change, for those who prefer the old behavior.
G'luck,
Peter
--
This sentence no verb.
Patch against -current:
Index: src/sys/modules/syscons/warp/warp_saver.c
===
RCS file: /home/ncvs/src/sys/modules/syscons/warp/warp_saver.c,v
retrieving revision 1.9
diff -u -r1.9 warp_saver.c
--- src/sys/modules/syscons/warp/warp_saver.c 2000/06/25 09:39:11 1.9
+++ src/sys/modules/syscons/warp/warp_saver.c 2000/12/11 14:00:29
@@ -35,6 +35,7 @@
#include sys/syslog.h
#include sys/consio.h
#include sys/fbio.h
+#include sys/sysctl.h
#include dev/fb/fbreg.h
#include dev/fb/splashreg.h
@@ -58,19 +59,35 @@
/* the rest is zero-filled by the compiler */
};
+static int warp_dir = 1, warp_period = 1;
+SYSCTL_INT(_kern, OID_AUTO, warp_dir, CTLFLAG_RW, warp_dir, 0, "")
+SYSCTL_INT(_kern, OID_AUTO, warp_period, CTLFLAG_RW, warp_period, 0, "")
+
static void
-warp_update(void)
+warp_update(int *pdir, int period)
{
int i, j, k, n;
+static int cur_state = 0;
for (i = 1, k = 0, n = SPP*8; i 5; i++, n /= 2)
for (j = 0; j n; j++, k++) {
vid[star[k]] = 0;
- star[k] += i;
- if (star[k] SCRW*SCRH)
- star[k] -= SCRW*SCRH;
+ if (*pdir) {
+ star[k] += i;
+ if (star[k] SCRW*SCRH)
+ star[k] -= SCRW*SCRH;
+ } else {
+ star[k] -= i;
+ if (star[k] 0)
+ star[k] += SCRW*SCRH;
+ }
vid[star[k]] = i;
}
+
+if ((period 0) (++cur_state = period)) {
+ *pdir = !*pdir;
+ cur_state = 0;
+}
}
static int
@@ -94,7 +111,7 @@
}
/* update display */
- warp_update();
+ warp_update(warp_dir, warp_period);
} else {
blanked = 0;
...
.. and against 4.2-STABLE..
Index: src/sys/modules/syscons/warp/warp_saver.c
===
RCS file: /home/ncvs/src/sys/modules/syscons/warp/warp_saver.c,v
retrieving revision 1.7.2.1
diff -u -r1.7.2.1 warp_saver.c
--- src/sys/modules/syscons/warp/warp_saver.c 2000/05/10 16:26:47 1.7.2.1
+++ src/sys/modules/syscons/warp/warp_saver.c 2000/12/11 13:58:14
@@ -36,6 +36,7 @@
#include sys/consio.h
#include sys/fbio.h
#include sys/random.h
+#include sys/sysctl.h
#include dev/fb/fbreg.h
#include dev/fb/splashreg.h
@@ -59,19 +60,35 @@
/* the rest is zero-filled by the compiler */
};
+static int warp_dir = 1, warp_period = 1;
+SYSCTL_INT(_kern, OID_AUTO, warp_dir, CTLFLAG_RW, warp_dir, 0, "")
+SYSCTL_INT(_kern, OID_AUTO, warp_period, CTLFLAG_RW, warp_period, 0, "")
+
static void
-warp_update(void)
+warp_update(int *pdir, int period)
{
int i, j, k, n;
+static int cur_state = 0;
for (i = 1, k = 0, n = SPP*8; i 5; i++, n /= 2)
for (j = 0; j n; j++, k++) {
vid[star[k]] = 0;
- star[k] += i;
- if (star[k] SCRW*SCRH)
- star[k] -= SCRW*SCRH;
+ if (*pdir) {
+ star[k] += i;
+ if (star[k] SCRW*SCRH)
+ star[k] -= SCRW*SCRH;
+ } else {
+ star[k] -= i;
+ if (star[k] 0)
+ star[k] += SCRW*SCRH;
+ }
vid[star[k]] = i;
}
+
+if ((period 0) (++cur_state = period)) {
+ *pdir = !*pdir;
+ cur_state = 0;
+}
}
static int
@@ -95,7 +112,7 @@
}
/* update display */
- warp_update();
+ warp_update(warp_dir, warp_period);
} else {
blanked = 0;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Partial start on pci + serial/parallel cards
On Fri, Dec 08, 2000 at 11:13:12PM -0700, Warner Losh wrote: OK. I have a partial start on the serial/parallel cards. It isn't attaching anything yet, but should give people an idea on the direction I'd like to head. As part of this work, I'll likely remove pci attachment of sio, and change it to puc. puc is the name NetBSD uses (I snagged the tables and some code from NetBSD's puc driver, btw) so I kept using it. I'll also need to add puc attachments to sio and ppc drivers. What will actually happened to them, especially ppc? Currently, ppc is isa dependent so why should we change the DRIVER_MODULE directive to attach to puc? Nicholas -- [EMAIL PROTECTED] Alcôve - Open Source Software Engineer - http://www.alcove.fr To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
eye-candy hack - warp_saver changing direction :)
So.. if anybody else is using the warp screen saver, here's a little patch
to make it reverse direction from time to time; as my boss put it, "I don't
know about you, but an hour of your screen rolling over to the right makes
me dizzy." :)
This one defines two sysctl's - kern.warp_dir (zero to roll to the left,
non-zero to roll the other way), and kern.warp_period (number of iterations
before changing direction). The warp_period is measured in.. seconds, isn't
it - how often the saver is called to do its dance..
Attached are patches against -current and 4.2-STABLE; hope this does not
look too ugly :)
G'luck,
Peter
--
"yields falsehood, when appended to its quotation." yields falsehood, when appended to
its quotation.
Patch against -current:
Index: src/sys/modules/syscons/warp/warp_saver.c
===
RCS file: /home/ncvs/src/sys/modules/syscons/warp/warp_saver.c,v
retrieving revision 1.9
diff -u -r1.9 warp_saver.c
--- src/sys/modules/syscons/warp/warp_saver.c 2000/06/25 09:39:11 1.9
+++ src/sys/modules/syscons/warp/warp_saver.c 2000/12/11 14:00:29
@@ -35,6 +35,7 @@
#include sys/syslog.h
#include sys/consio.h
#include sys/fbio.h
+#include sys/sysctl.h
#include dev/fb/fbreg.h
#include dev/fb/splashreg.h
@@ -58,19 +59,35 @@
/* the rest is zero-filled by the compiler */
};
+static int warp_dir = 1, warp_period = 1;
+SYSCTL_INT(_kern, OID_AUTO, warp_dir, CTLFLAG_RW, warp_dir, 0, "")
+SYSCTL_INT(_kern, OID_AUTO, warp_period, CTLFLAG_RW, warp_period, 0, "")
+
static void
-warp_update(void)
+warp_update(int *pdir, int period)
{
int i, j, k, n;
+static int cur_state = 0;
for (i = 1, k = 0, n = SPP*8; i 5; i++, n /= 2)
for (j = 0; j n; j++, k++) {
vid[star[k]] = 0;
- star[k] += i;
- if (star[k] SCRW*SCRH)
- star[k] -= SCRW*SCRH;
+ if (*pdir) {
+ star[k] += i;
+ if (star[k] SCRW*SCRH)
+ star[k] -= SCRW*SCRH;
+ } else {
+ star[k] -= i;
+ if (star[k] 0)
+ star[k] += SCRW*SCRH;
+ }
vid[star[k]] = i;
}
+
+if (++cur_state = period) {
+ *pdir = !*pdir;
+ cur_state = 0;
+}
}
static int
@@ -94,7 +111,7 @@
}
/* update display */
- warp_update();
+ warp_update(warp_dir, warp_period);
} else {
blanked = 0;
...
...and against 4.2-STABLE..
Index: src/sys/modules/syscons/warp/warp_saver.c
===
RCS file: /home/ncvs/src/sys/modules/syscons/warp/warp_saver.c,v
retrieving revision 1.7.2.1
diff -u -r1.7.2.1 warp_saver.c
--- src/sys/modules/syscons/warp/warp_saver.c 2000/05/10 16:26:47 1.7.2.1
+++ src/sys/modules/syscons/warp/warp_saver.c 2000/12/11 13:58:14
@@ -36,6 +36,7 @@
#include sys/consio.h
#include sys/fbio.h
#include sys/random.h
+#include sys/sysctl.h
#include dev/fb/fbreg.h
#include dev/fb/splashreg.h
@@ -59,19 +60,35 @@
/* the rest is zero-filled by the compiler */
};
+static int warp_dir = 1, warp_period = 1;
+SYSCTL_INT(_kern, OID_AUTO, warp_dir, CTLFLAG_RW, warp_dir, 0, "")
+SYSCTL_INT(_kern, OID_AUTO, warp_period, CTLFLAG_RW, warp_period, 0, "")
+
static void
-warp_update(void)
+warp_update(int *pdir, int period)
{
int i, j, k, n;
+static int cur_state = 0;
for (i = 1, k = 0, n = SPP*8; i 5; i++, n /= 2)
for (j = 0; j n; j++, k++) {
vid[star[k]] = 0;
- star[k] += i;
- if (star[k] SCRW*SCRH)
- star[k] -= SCRW*SCRH;
+ if (*pdir) {
+ star[k] += i;
+ if (star[k] SCRW*SCRH)
+ star[k] -= SCRW*SCRH;
+ } else {
+ star[k] -= i;
+ if (star[k] 0)
+ star[k] += SCRW*SCRH;
+ }
vid[star[k]] = i;
}
+
+if (++cur_state = period) {
+ *pdir = !*pdir;
+ cur_state = 0;
+}
}
static int
@@ -95,7 +112,7 @@
}
/* update display */
- warp_update();
+ warp_update(warp_dir, warp_period);
} else {
blanked = 0;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: eye-candy hack - warp_saver changing direction :)
Peter Pentchev [EMAIL PROTECTED] writes: This one defines two sysctl's - kern.warp_dir (zero to roll to the left, non-zero to roll the other way), and kern.warp_period (number of iterations before changing direction). The warp_period is measured in.. seconds, isn't it - how often the saver is called to do its dance.. kern.* is not the right place for this. It should go in user.*, unless that is reserved for userland, in which case a subtree of kern.* is probably the Right Thing. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: eye-candy hack - warp_saver changing direction :)
On Mon, Dec 11, 2000 at 05:01:22PM +0100, Dag-Erling Smorgrav wrote: Peter Pentchev [EMAIL PROTECTED] writes: This one defines two sysctl's - kern.warp_dir (zero to roll to the left, non-zero to roll the other way), and kern.warp_period (number of iterations before changing direction). The warp_period is measured in.. seconds, isn't it - how often the saver is called to do its dance.. kern.* is not the right place for this. It should go in user.*, unless that is reserved for userland, in which case a subtree of kern.* is probably the Right Thing. Yes, I was wondering about user.*, but I decided it was reserved for userland. OK, I'll put it in a subtree. How does kern.ss.warp.* sound? Or kern.saver.warp.*? Or maybe even kern.syscons.saver.warp.*? (oif!) G'luck, Peter -- You have, of course, just begun reading the sentence that you have just finished reading. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: eye-candy hack - warp_saver changing direction :)
On Mon, Dec 11, 2000 at 06:03:46PM +0200, Peter Pentchev wrote: On Mon, Dec 11, 2000 at 05:01:22PM +0100, Dag-Erling Smorgrav wrote: Peter Pentchev [EMAIL PROTECTED] writes: This one defines two sysctl's - kern.warp_dir (zero to roll to the left, non-zero to roll the other way), and kern.warp_period (number of iterations before changing direction). The warp_period is measured in.. seconds, isn't it - how often the saver is called to do its dance.. kern.* is not the right place for this. It should go in user.*, unless that is reserved for userland, in which case a subtree of kern.* is probably the Right Thing. Yes, I was wondering about user.*, but I decided it was reserved for userland. OK, I'll put it in a subtree. How does kern.ss.warp.* sound? Or kern.saver.warp.*? Or maybe even kern.syscons.saver.warp.*? (oif!) Well, I can't quite make it work with a kern.* sysctl subtree.. It's obvious that this has something to do with SYSCTL_DECL(), but - how? :) I currently have these in my warp_saver.c (just kern.saver for simplicity): SYSCTL_DECL(_kern_saver); SYSCTL_INT(_kern_saver, OID_AUTO, dir, CTLFLAG_RW, warp_dir, 0, "") SYSCTL_INT(_kern_saver, OID_AUTO, step, CTLFLAG_RW, warp_step, 0, "") SYSCTL_INT(_kern_saver, OID_AUTO, period, CTLFLAG_RW, warp_period, 0, "") It builds and installs fine, and then: [root@ringworld:v0 /usr/mysrc/sys/modules/syscons/warp]# make load /sbin/kldload -v ./warp_saver.ko link_elf: symbol sysctl__kern_saver_children undefined kldload: can't load ./warp_saver.ko: Exec format error *** Error code 1 Stop in /usr/mysrcx/sys/modules/syscons/warp. [root@ringworld:v0 /usr/mysrc/sys/modules/syscons/warp]# Apparently I'm missing something.. whine Help? /whine G'luck, Peter -- If wishes were fishes, the antecedent of this conditional would be true. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/sys/vm vm_pageout.c
:I feel like a dolt here, but could you run these deltas by :me or alc? : :Shouldn't it be using bogus_page here? : :-- :-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] Let me respond to -hackers here. My commit comment isn't that good. Lets say you have a normal filesystem (1K frag, 8K block), and a small 2K file. The struct buf associated with the file will only have a b_bufsize of 2K (rather then 8K) in this case. Now lets say you mmap() the file shared + R/W. The mmap()ing will cause the VM page backing the buffer to be made all valid (m-valid = VM_PAGE_BITS_ALL). Now lets say you dirty the page via the mmap, by writing to memory. This will cause a VM fault which will make the underlying page all dirty (m-dirty = VM_PAGE_BITS_ALL). This is all correct so far. But now the filesystem comes along and flushes the underlying filesystem buffer. This will sync the page to the filesystem, which is what we want. But remember, the file is only 2K! So the end of the I/O operation only 'cleans' the first 2K of the page, leaving m-dirty = 0xFC. The page is truely completely 'clean', but it's still left marked dirty from the VM system's point of view. Now vm_object_page_clean() comes along and says 'look! A page without a filesystem buffer that's dirty. I need to flush it'. Which it does. My KASSERT was asserting that the page had to be fully dirty, and under normal circumstances it has to be. Until we fix how the filesystem deals with backing pages in the fragment case, I have to take that part of the KASSERT out. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: eye-candy hack - warp_saver changing direction :)
Peter Pentchev [EMAIL PROTECTED] writes: SYSCTL_DECL(_kern_saver); SYSCTL_DECL is for declaring a node that's defined elsewhere. You should use the following instead: SYSCTL_NODE(_kern, OID_AUTO, saver, CTLFLAG_RW, NULL, "Screensavers"); There's no substitute for reading src/sys/sys/sysctl.h. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kqueue microbenchmark results
Dan Kegel wrote: ... Don't jump to conclusions. He's honestly trying to understand what the optimal interface would be. Let him catch up. Help him understand the requirements which motivated the kqueue design and why his proposed system call does not meet them. His role right now is to keep the kernel as simple as possible. You need to prove that his proposed interface is simpler than possible :-) A simple way to keep the kernel simple: http://linuxtoday.com/news_story.php3?ltsn=2000-12-09-013-20-NW-GN-KN :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
SCTP implementation and pccard.conf change for Cisco 802.11B 340 series cards
I am currently at IETF 49, where I have moved from my old wi card to the new Cisco 342, which is an an card, since Cisco acquired them. The 342 does 128-bit or less encryption at 11 meg, thus it was a worthy investment. However, pccard.conf does not have an entry for the card, since it was JUST released. The appropriate entry is: #Cisco 340 series 802.11B wireless NICs card "Cisco Systems" "340 Series Wireless LAN Adapter" config 0x5 "an" ? insert /etc/pccard_ether $device remove /sbin/ifconfig $device delete This allows the Cisco 34x cards to work, including the 342. One caveat, however...I haven't looked at the source, yet, but it is pretty safe to assume that 128-bit at 11meg support is not in the driver. I will take a look at this when I have some spare time, but since I am currently tied up with writing SCTP reference code for a linux kernel (this was not my choice...it is my job), I may not have a ton of time for a bit of time. If anyone can work on this, it'd be appreciated. On a second note, I am willing to lead the SCTP implementation team for FBSD, if there is not already one in place. We will be releasing the first developer's release of the SCTP reference code (it will not be complete, but it currently works, and still will) on January 19th, 2001. At that point, we should be able to get the implementation under way. Have a good day, -Taz To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: eye-candy hack - warp_saver changing direction :)
On Mon, Dec 11, 2000 at 06:03:00PM +0100, Dag-Erling Smorgrav wrote:
Peter Pentchev [EMAIL PROTECTED] writes:
SYSCTL_DECL(_kern_saver);
SYSCTL_DECL is for declaring a node that's defined elsewhere. You
should use the following instead:
SYSCTL_NODE(_kern, OID_AUTO, saver, CTLFLAG_RW, NULL, "Screensavers");
There's no substitute for reading src/sys/sys/sysctl.h.
Yes, mea culpa :(
All right then, here's a revised patch that:
- adds a kern.saver.* sysctl subtree in syscons.c (I *think* this belongs
there, it's not each and every screensaver's job to define the global
sysctl tree);
- defines 8 directions instead of just 2;
- adds 4 sysctl's:
warp_dir - current movement direction;
warp_step - increment to warp_dir on each direction change;
warp_period - how long before a direction change;
warp_random - boolean flag for random direction changes.
If warp_period is 0, then each warp_period steps, the direction is
changed by the following rules:
- if warp_random is non-zero, the new direction is random;
- if warp_random is zero, warp_dir = (warp_dir + warp_step) modulo 8.
The 'standard' behavior is achieved by:
warp_dir=0 warp_period=0
The currently default behavior (go round and round and round) is:
warp_dir=0 warp_step=1 warp_period=100 warp_random=0
Left-and-right behavior:
warp_dir=0 warp_step=4 warp_period=1000 warp_random=0
Random walk:
warp_period=100 warp_random=1
G'luck,
Peter
--
If I were you, who would be reading this sentence?
Patch against -current:
Index: src/sys/dev/syscons/syscons.c
===
RCS file: /home/ncvs/src/sys/dev/syscons/syscons.c,v
retrieving revision 1.349
diff -u -r1.349 syscons.c
--- src/sys/dev/syscons/syscons.c 2000/12/08 21:49:55 1.349
+++ src/sys/dev/syscons/syscons.c 2000/12/11 18:19:04
@@ -120,6 +120,8 @@
SYSCTL_INT(_machdep, OID_AUTO, enable_panic_key, CTLFLAG_RW, enable_panic_key,
0, "");
+SYSCTL_NODE(_kern, OID_AUTO, saver, CTLFLAG_RW, NULL, "Console screensavers")
+
#define SC_CONSOLECTL 255
#define VIRTUAL_TTY(sc, x) (SC_DEV((sc), (x))-si_tty)
Index: src/sys/modules/syscons/warp/warp_saver.c
===
RCS file: /home/ncvs/src/sys/modules/syscons/warp/warp_saver.c,v
retrieving revision 1.9
diff -u -r1.9 warp_saver.c
--- src/sys/modules/syscons/warp/warp_saver.c 2000/06/25 09:39:11 1.9
+++ src/sys/modules/syscons/warp/warp_saver.c 2000/12/11 18:20:04
@@ -35,6 +35,7 @@
#include sys/syslog.h
#include sys/consio.h
#include sys/fbio.h
+#include sys/sysctl.h
#include dev/fb/fbreg.h
#include dev/fb/splashreg.h
@@ -58,19 +59,60 @@
/* the rest is zero-filled by the compiler */
};
+static int warp_dirs[8] = {
+1, /* E */
+SCRW+1,/* SE */
+SCRW, /* S */
+SCRW-1,/* SW */
+-1,/* W */
+-SCRW-1, /* NW */
+-SCRW, /* N */
+-SCRW+1/* NE */
+};
+#define WARP_DIRCNT(sizeof(warp_dirs)/sizeof(warp_dirs[0]))
+
+static int warp_dir = 0, warp_step = 1, warp_period = 100;
+static int warp_random = 0;
+
+/* Make use of syscons's screen saver subtree.. */
+SYSCTL_DECL(_kern_saver);
+/* Add our sysctls there */
+SYSCTL_INT(_kern_saver, OID_AUTO, warp_dir, CTLFLAG_RW, warp_dir, 0, "")
+SYSCTL_INT(_kern_saver, OID_AUTO, warp_step, CTLFLAG_RW, warp_step, 0, "")
+SYSCTL_INT(_kern_saver, OID_AUTO, warp_period, CTLFLAG_RW, warp_period, 0, "")
+SYSCTL_INT(_kern_saver, OID_AUTO, warp_random, CTLFLAG_RW, warp_random, 0, "")
+
static void
-warp_update(void)
+warp_update(int *pdir, int step, int period)
{
int i, j, k, n;
+static int cur_state = 0;
for (i = 1, k = 0, n = SPP*8; i 5; i++, n /= 2)
for (j = 0; j n; j++, k++) {
vid[star[k]] = 0;
- star[k] += i;
- if (star[k] SCRW*SCRH)
+
+ /* calculate the new position */
+ star[k] += warp_dirs[*pdir]*i;
+ /* do not fall off the screen */
+ if (star[k] = SCRW*SCRH)
star[k] -= SCRW*SCRH;
+ else if (star[k] 0)
+ star[k] += SCRW*SCRH;
+
vid[star[k]] = i;
}
+
+if ((period 0) (++cur_state = period)) {
+ cur_state = 0;
+
+ /* hope gcc is smart enough to optimize the %-by-power-of-two.. */
+ /* (not that the random() call is less of a bottleneck :) */
+ if (warp_random)
+ *pdir = random() % WARP_DIRCNT;
+ else
+ *pdir = (*pdir + step) % WARP_DIRCNT;
+}
}
static int
@@ -94,7 +136,7 @@
}
/* update display */
- warp_update();
+ warp_update(warp_dir, warp_step, warp_period);
} else {
blanked = 0;
..
..and against 4.2-STABLE..
Index: src/sys/dev/syscons/syscons.c
===
RCS file:
Re: SCTP implementation and pccard.conf change for Cisco 802.11B 340 series cards
Any others at IETF? I am not far from where it's being held and getting a mini-freebswd group together for food would rule ;) Email me off list if you're there! On Mon, 11 Dec 2000, Jonathan "Taz" Mischo wrote: I am currently at IETF 49, where I have moved from my old wi card to the new Cisco 342, which is an an card, since Cisco acquired them. The 342 does 128-bit or less encryption at 11 meg, thus it was a worthy investment. However, pccard.conf does not have an entry for the card, since it was JUST released. The appropriate entry is: #Cisco 340 series 802.11B wireless NICs card "Cisco Systems" "340 Series Wireless LAN Adapter" config 0x5 "an" ? insert /etc/pccard_ether $device remove /sbin/ifconfig $device delete This allows the Cisco 34x cards to work, including the 342. One caveat, however...I haven't looked at the source, yet, but it is pretty safe to assume that 128-bit at 11meg support is not in the driver. I will take a look at this when I have some spare time, but since I am currently tied up with writing SCTP reference code for a linux kernel (this was not my choice...it is my job), I may not have a ton of time for a bit of time. If anyone can work on this, it'd be appreciated. On a second note, I am willing to lead the SCTP implementation team for FBSD, if there is not already one in place. We will be releasing the first developer's release of the SCTP reference code (it will not be complete, but it currently works, and still will) on January 19th, 2001. At that point, we should be able to get the implementation under way. Have a good day, -Taz To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message *-. | Andrew R. Reiter | [EMAIL PROTECTED] | "It requires a very unusual mind | to undertake the analysis of the obvious" -- A.N. Whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCTP implementation and pccard.conf change for Cisco 802.11B 340 series cards
In message [EMAIL PROTECTED] Jonathan "\"Taz\"" Mischo writes: : #Cisco 340 series 802.11B wireless NICs : card "Cisco Systems" "340 Series Wireless LAN Adapter" : config 0x5 "an" ? : insert /etc/pccard_ether $device : remove /sbin/ifconfig $device delete This already appears to be in -current. Thanks for the entry none the less. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: eye-candy hack - warp_saver changing direction :)
unsubscribe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCTP implementation and pccard.conf change for Cisco 802.11B 340series cards
Jonathan \"Taz\" Mischo writes: | I am currently at IETF 49, where I have moved from my old wi card to the | | new Cisco 342, which is an an card, since Cisco acquired them. The 342 | does 128-bit or less encryption at 11 meg, thus it was a worthy | investment. However, pccard.conf does not have an entry for the card, | since it was JUST released. The appropriate entry is: | | #Cisco 340 series 802.11B wireless NICs | card "Cisco Systems" "340 Series Wireless LAN Adapter" | config 0x5 "an" ? | insert /etc/pccard_ether $device | remove /sbin/ifconfig $device delete It's in -stable and maybe 4.2 | This allows the Cisco 34x cards to work, including the 342. One | caveat, however...I haven't looked at the source, yet, but it is pretty | safe to assume that 128-bit at 11meg support is not in the driver. I Well you are sort-of right ... look at -current and it's there. Patches for stable are at http://www.ambrisko.com/doug/an.patch.wep3 for the latest greatest stuff. Several people have this code in use for a while. I've been collecting patches and posting diff's at my website and sending announces to mobile. With the latest diff's I haven't heard of any new wishes or problems. Archie just commited the patches to -current and should MFC fairly soon. BTW I just remembered a bug in that you can't do the ancontrol stuff unless you ifconfig the interface. I need to look at this. I forgot about it a long time ago when I just worked around it so it doesn't bite me .. except when I just setup a machine. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: R: [tcpdump-workers] Re: Re: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
On 2000-12-11 10:49 +0100, Loris Degioanni [EMAIL PROTECTED] wrote: # sysctl -w debug.bpf_bufsize=32768 debug.bpf_maxbufsize=4194304 makes the default buffer size 32K and limits the size to 4MB, for example. Notice however that in pcap-bpf.c, pcap_open_live() forces the buffer size to 32K through an IOCTL. This means that the sysctl is overridden if BPF is used throug libpcap. Yes, you are of course correct mentioning that ! The override used to up the buffer size from the kernel default of 4KB to 32KB, but now that the default has become 32KB, we probably should use the default as is and leave the user the option of choosing a different default by means of sysctl ... Regards, STefan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Top not showing CPU utilization?
I am running FreeBSd 4.2 on machine with 2 Pentium II CPU's When I run "top", it shows my processes with 0.00% CPU Is there a problem with top, or my machine?? last pid: 34959; load averages: 0.10, 0.06, 0.05up 8+05:27:27 21:05:14 41 processes: 1 running, 40 sleeping CPU states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 0.0% idle Mem: 30M Active, 350M Inact, 41M Wired, 16M Cache, 61M Buf, 64M Free Swap: 1000M Total, 1000M Free PID USERNAME PRI NICE SIZERES STATE C TIME WCPUCPU COMMAND 90620 root 2 0 15640K 14836K poll 1 24:30 0.00% 0.00% named 138 root 2 0 1040K 764K select 0 2:16 0.00% 0.00% inetd 40816 root 2 -10 2516K 1796K select 0 2:16 0.00% 0.00% sendmail 115 root 2 0 924K 616K select 1 1:45 0.00% 0.00% syslogd 1787 root 2 0 1128K 760K select 0 0:36 0.00% 0.00% radiusd 44789 root 2 0 2064K 1600K select 0 0:30 0.00% 0.00% httpd 85714 root 2 0 5176K 4068K select 0 0:18 0.00% 0.00% perl 2711 root 2 0 2256K 1240K select 0 0:15 0.00% 0.00% telnetd 1786 root 2 0 1068K 676K select 0 0:12 0.00% 0.00% radiusd 150 root 2 0 2404K 1380K select 1 0:11 0.00% 0.00% sshd 140 root 10 0 960K 704K nanslp 1 0:06 0.00% 0.00% cron thanks, Chuck Rock EPC To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
aio stable
Hi, we have some programs using aio_*being ported to FreeBSD, I heard that aio in FreeBSD is not very stable, but what is its problem? can anyone tell me, and we may avoid it. Regards, XuYifeng
Re: aio stable
* xuyifeng [EMAIL PROTECTED] [001211 21:08] wrote: Hi, we have some programs using aio_* being ported to FreeBSD, I heard that aio in FreeBSD is not very stable, but what is its problem? can anyone tell me, and we may avoid it. It should be stable now, Alan Cox has done a lot of work on it. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: aio stable
I'm using 4.2 stable, but why does LINT say that there are some stable issue? is it document bug? XuYifeng - Original Message - From: Alfred Perlstein [EMAIL PROTECTED] To: xuyifeng [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, December 12, 2000 1:31 PM Subject: Re: aio stable * xuyifeng [EMAIL PROTECTED] [001211 21:08] wrote: Hi, we have some programs using aio_* being ported to FreeBSD, I heard that aio in FreeBSD is not very stable, but what is its problem? can anyone tell me, and we may avoid it. It should be stable now, Alan Cox has done a lot of work on it. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message ¡Iì¹» ®Þ±éݨ¥¶Ý¢jçH:+éì¹» ®Þ~·nÇaiÉ ®È§¶¡Ü¨~Ø^ë,j
Re: aio stable
* xuyifeng [EMAIL PROTECTED] [001211 22:31] wrote:
I'm using 4.2 stable, but why does LINT say that there are some stable issue? is it
document bug?
as far as i know, yes.
XuYifeng
- Original Message -
From: Alfred Perlstein [EMAIL PROTECTED]
To: xuyifeng [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, December 12, 2000 1:31 PM
Subject: Re: aio stable
* xuyifeng [EMAIL PROTECTED] [001211 21:08] wrote:
Hi,
we have some programs using aio_* being ported to FreeBSD,
I heard that aio in FreeBSD is not very stable, but what is
its problem? can anyone tell me, and we may avoid it.
It should be stable now, Alan Cox has done a lot of work on it.
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
N
'²æìr¸{û Ù[h¨èÚ£ñkyàRú+û§²æìr¸yúÞy» þêìþ)í
æèw* ¶¦zË
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
