Re: mbuf leakage in NFSv3 writes, possbile?
"David E. Cross" wrote: > > Well, I just -STABLED the server to see if it fixed it, but I was certainly > running out. the server had only 3000-ish mbuf chains, and it would go > through > them all in a day. Well, have you tried increasing the number of available mbufs and see if you reach a point of stability? Assuming you have enough physical ram you could do 15k mbufs on -Stable without a problem. Check LINT for the nmbclusters option if you need help with it. Good luck, Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD: the stealth OS?
> > "There's a lot of things that Linux is 'better' at, and a > > lot of things FreeBSD is 'better' at, and a lot of those > > things can easily fluctuate on a daily or weekly basis," > > said Fuller, who maintains a Linux vs BSD Web page. > > "Thus, any definitive narrow statement that can be made > > is usually obsolete before anyone hears it.". > > > > Perfect! > > Thank you, my fans! Please leave your monetary contributions in the hat > on your way out;> Where is the hat? I saw Julian running off with it a couple of e-mails ago. Nick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SURVEY: Sound cards that work under FreeBSD
Here's the information about the sound card I am working with: > 1) The sound card make and model/chipset. Please be as specific as you can with >board rev numbers if possible. Please include wether the card is ISA or PCI. My sound card is a SBPCI128 by Creative Labs. > 2) FreeBSD version(s) it was tested with. List *all* versions of FreeBSD for >which you can verify that the sound card does/doesn't work (don't include >-BETA or -SNAP releases but dates on -STABLE and -CURRENT branches are >welcome). I only used the card with FreeBSD 3.2 > 3) Appropriate lines from your kernel config file / PNP setup. i.e. what did >you have to do to get this card working? Did you need patches not committed >to a particular branch (if so URLs would be welcome)? Do you use OSS drivers >instead? The only line I had to add to my kernel config file was: device pcm0 at isa? port ? tty irq 10 drq 1 flags 0x0 (This causes a message "pcm0 not found" to appear at boot time but just ignoring it seems to be o.k. - allthough I would prefer not to see it, at all.) > 4) Sample dmesg output for properly configured device. Show the world what >boot messages relate to the device after properly configured. These are the messages that appear previous to the message "pcm0 not found": es1: rev 0x01 int a irq 5 on pci0.9.0 pcm1: using I/O space register mapping at 0xe400 > 5) Miscellaneous notes. State anything "not obvious" to the casual FreeBSD >user. Good examples might be, "volume is 0 by default, use mixer(1) to >adjust at boot time," or "sh MAKEDEV snd1 for the 1st device, not snd0." I had to build the audio device snd1: # cd /dev # sh MKDEV snd1 and to use the mixer to set the volume to another value than 0. I use the following script /usr/local/etc/rc.d/mixer.sh at boot time: #!/bin/sh /usr/sbin/mixer vol 60:60 pcm 60:60 cd 60:60 > 6) Is it OK to publish your e-mail address / name as the contributor of this >information? You may type in an anti-spam version of your e-mail address >below if you would like that option instead. Well, I guess, I should not be listed as the contributor, because I catched these information out of the mailing lists and would prefer the original poster to appear as the contributor. Cheers, Dirk To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM & LDAP in FreeBSD, and userfs too.
On Thu, 22 Jul 1999, John Polstra wrote: > > On Thu, Jul 22, 1999 at 04:59:59PM +0700, Max Khon wrote: > > > > > > PAM is also "using masses of weird shared objects" but nevertheless it's > > > quite usable > > > > By statically linked binaries? > > Our PAM implementation works for static binaries too. See the > sources for the gory details. Basically it creates a library that > includes all the possible modules, and selects the right one at > runtime. There's some linker set magic involved. This means you can't add in a new module without recompiling the static library, correct? That seems to defeat the purpose of PAM being modular for the static case :-( Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
usb keyboard setup -or- HELP!
hi, i'm running 4.0-current on a dual p2-333 box. i run X, and am looking for help in setting up a usb keyboard for use with FreeBSD/Xfree86. if anyone has this running, i could use the help in setting it up. also, this keyboard has a ps2 mouse connector. does the mouse get recognized as a usb mouse? jim -- All opinions expressed are mine, if you| "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" -- Inet: jbry...@tfs.netAX.25: kc5...@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant -- HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM & LDAP in FreeBSD, and userfs too.
In article <19990722111605.c49...@palmerharvey.co.uk>, Dominic Mitchell wrote: > On Thu, Jul 22, 1999 at 04:59:59PM +0700, Max Khon wrote: > > > > PAM is also "using masses of weird shared objects" but nevertheless it's > > quite usable > > By statically linked binaries? Our PAM implementation works for static binaries too. See the sources for the gory details. Basically it creates a library that includes all the possible modules, and selects the right one at runtime. There's some linker set magic involved. Concerning "masses of weird shared objects," you'd really better get used to it. It was the wave of the future 10 years ago. It's not going away. Dynamic linking provides flexibility and modularity that you just can't get from static linking. John -- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: mbuf leakage in NFSv3 writes, possbile?
"David E. Cross" wrote: > > Well, I just -STABLED the server to see if it fixed it, but I was certainly > running out. the server had only 3000-ish mbuf chains, and it would go through > them all in a day. Well, have you tried increasing the number of available mbufs and see if you reach a point of stability? Assuming you have enough physical ram you could do 15k mbufs on -Stable without a problem. Check LINT for the nmbclusters option if you need help with it. Good luck, Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
usb keyboard setup -or- HELP!
hi, i'm running 4.0-current on a dual p2-333 box. i run X, and am looking for help in setting up a usb keyboard for use with FreeBSD/Xfree86. if anyone has this running, i could use the help in setting it up. also, this keyboard has a ps2 mouse connector. does the mouse get recognized as a usb mouse? jim -- All opinions expressed are mine, if you| "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" -- Inet: [EMAIL PROTECTED]AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant -- HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM & LDAP in FreeBSD, and userfs too.
In article <[EMAIL PROTECTED]>, Dominic Mitchell <[EMAIL PROTECTED]> wrote: > On Thu, Jul 22, 1999 at 04:59:59PM +0700, Max Khon wrote: > > > > PAM is also "using masses of weird shared objects" but nevertheless it's > > quite usable > > By statically linked binaries? Our PAM implementation works for static binaries too. See the sources for the gory details. Basically it creates a library that includes all the possible modules, and selects the right one at runtime. There's some linker set magic involved. Concerning "masses of weird shared objects," you'd really better get used to it. It was the wave of the future 10 years ago. It's not going away. Dynamic linking provides flexibility and modularity that you just can't get from static linking. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
On Thu, 22 Jul 1999, Adrian Filipi-Martin wrote: > I know a lot of people like the ASUS P2B boards, but I've noticed a > tendency for the systems to reset occasionally when plugging in a keyboard. > I've seen this with both FreeBSD and NT, so I'm considering it a property > of the board. If this is a PS/2 style keyboard, don't plug and unplug them when the host is powered up. The PS/2 style stuf seems to be very sensitive to that sort of thing. If it was a USB keyboard doing that... then that would be odd. - alex You wear guilt, like shackles on your feet, Like a halo in reverse - Depeche Mode To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
On Thu, 22 Jul 1999, Vincent Poy wrote: > On Thu, 22 Jul 1999, Adrian Filipi-Martin wrote: > > > I've had great results with the Tyan 1836DLUAN/Thunder 100's. > > I've got several boxes with 1GB of RAM and dual 450's humming along. For > > comparison one system with less memory and a SuperMicro board but identical > > system software has had a couple of wierd spontaneous reboots over the last > > few months. > > Cool... Is 1GB of ram really needed? We used to run a 64 meg > system then 128 meg and then 384 meg, it doesn't seem to do much even for > a heavily loaded ISP Server. Not really. The customer whose box this is chose this much memory because his previous server was a 256MB UltraSparc that was swamped all the time with a load of 6 to 7. The real problem was poor CGI programming. I made them fix them. Now it toodles along with ridiculously low loads. All the websites and the mysql db fit in core. ;-) Adrian -- [ adr...@ubergeeks.com -- Ubergeeks Consulting -- http://www.ubergeeks.com/ ] To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
On Thu, 22 Jul 1999, Adrian Filipi-Martin wrote: > I know a lot of people like the ASUS P2B boards, but I've noticed a > tendency for the systems to reset occasionally when plugging in a keyboard. > I've seen this with both FreeBSD and NT, so I'm considering it a property > of the board. If this is a PS/2 style keyboard, don't plug and unplug them when the host is powered up. The PS/2 style stuf seems to be very sensitive to that sort of thing. If it was a USB keyboard doing that... then that would be odd. - alex You wear guilt, like shackles on your feet, Like a halo in reverse - Depeche Mode To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
On Thu, 22 Jul 1999, Vincent Poy wrote: > On Thu, 22 Jul 1999, Adrian Filipi-Martin wrote: > > > I've had great results with the Tyan 1836DLUAN/Thunder 100's. > > I've got several boxes with 1GB of RAM and dual 450's humming along. For > > comparison one system with less memory and a SuperMicro board but identical > > system software has had a couple of wierd spontaneous reboots over the last > > few months. > > Cool... Is 1GB of ram really needed? We used to run a 64 meg > system then 128 meg and then 384 meg, it doesn't seem to do much even for > a heavily loaded ISP Server. Not really. The customer whose box this is chose this much memory because his previous server was a 256MB UltraSparc that was swamped all the time with a load of 6 to 7. The real problem was poor CGI programming. I made them fix them. Now it toodles along with ridiculously low loads. All the websites and the mysql db fit in core. ;-) Adrian -- [ [EMAIL PROTECTED] -- Ubergeeks Consulting -- http://www.ubergeeks.com/ ] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposed substitution for ACLs
Daniel C. Sobral wrote:
>
> Sergey Babkin wrote:
> >
> > I want to propose a simple substitution for ACLs. No, here
> > is no patch yet but I'm ready and willing to do it. The reason
> > why I want to discuss it first is that this is a Political Thing.
> > And if the Core Team decides that it's a Bad Thing, I suppose
> > it will never get commited to the system. Because of this I
> > would like to see some encouraging signs from the Core Team
> > before implementing it.
>
> Do whatever you want: as a fs layer.
Speaking about the fs layers, can you please advise me on the current
state of nullfs ? Is it working now ? I have checked GNATS about this
and did not quite understood whether the results of a lengthly
discussion in there on this subject were ever committed.
On the other hand, I'm not sure whether implementing it as an FS
layer is a good idea. It is certainly possible to do by snooping
at the getattr/setattr calls but IMHO it will mean completely bypassing
the VOP_ACCESS of the underlying filesystem what may be not good.
On the other hand the changes to ufs_assess() seem to be quite small
and cover all the UFS type filesystems, such as FFS and EXT2FS.
Of course yet another option is to create one more fs type with all
the operations in the filesystem switch the same as for FFS except
for ufs_access().
What would be your recommendation ? Thanks!
Here is the proposed patch (made against 3.2). If it will be
considered OK I'll write some man page and LINT kernel entry too.
I'm not sure whether the sysctl sub-node vfs.ufs is really neccessary
but it seems to be logical.
-- cut here -
*** /sys/ufs/ufs/ufs_vnops.c1999/07/15 14:50:53 1.1
--- /sys/ufs/ufs/ufs_vnops.c1999/07/22 18:16:28
***
*** 57,62
--- 57,63
#include
#include
#include
+ #include
#include
#include
***
*** 104,109
--- 105,128
static int ufsspec_read __P((struct vop_read_args *));
static int ufsspec_write __P((struct vop_write_args *));
+ #ifdef ENABLE_UFS_COMMONID
+ /*
+ * Sysctl variables to control the unified user and
+ * group ID space.
+ * commonid is the lowest ID from which the common UID/GID space starts
+ * MINCOMMONID is the minimal value, if commonid is lower then the
+ * common ID space is disabled
+ */
+
+ #define MINCOMMONID 100
+
+ SYSCTL_NODE(_vfs, OID_AUTO, ufs, CTLFLAG_RW, 0, "Local Unix-type
filesystems");
+ static int commonid=0;
+ SYSCTL_INT(_vfs_ufs, OID_AUTO, commonid, CTLFLAG_RW, &commonid, 0,
+ "Lowest ID for the common GID/UID space");
+
+ #endif
+
union _qcvt {
int64_t qcvt;
int32_t val[2];
***
*** 339,344
--- 360,382
mask |= S_IWUSR;
return ((ip->i_mode & mask) == mask ? 0 : EACCES);
}
+
+ #ifdef ENABLE_UFS_COMMONID
+ /* if the common UID/GID is enabled check the groups against the file
UID */
+ if (commonid >= MINCOMMONID && ip->i_uid >= commonid) {
+ for (i = 0, gp = cred->cr_groups; i < cred->cr_ngroups;
+ i++, gp++)
+ if (ip->i_uid == *gp) {
+ if (mode & VEXEC)
+ mask |= S_IXUSR;
+ if (mode & VREAD)
+ mask |= S_IRUSR;
+ if (mode & VWRITE)
+ mask |= S_IWUSR;
+ return ((ip->i_mode & mask) == mask ? 0 :
EACCES);
+ }
+ }
+ #endif
/* Otherwise, check the groups. */
for (i = 0, gp = cred->cr_groups; i < cred->cr_ngroups; i++, gp++)
--- cut here
-SB
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
On Thu, 22 Jul 1999, Doug wrote: > On Wed, 21 Jul 1999, Vincent Poy wrote: > > > Greetings everyone, > > > > What are the current good motherboards for FreeBSD for the pentium > > II and III? I know on the Pentium, it was the ASUS board but for the > > PII/PIII, is the Abit the better board? Also, I was wondering what is the > > fastest Celeron chip that can be overclocked to run at 100Mhz FSB? Does > > it matter if it's Slot 1 or PPGA based? Thanks. > > At work we're having good results with an Intel N440BX > motherboard. It's a dual cpu board, running 2 PIII 500's like a champ. It > also has the ability to redirect all console output (like boot/bios > messages, etc.) to a serial console. It comes with a built in Etherexpress > Pro 100+ as well. Cool... I thought the Intel motherboards weren't that good compared to other brands.. > I have an Asus P2B at home that I've run my Celeron 300A > overclocked to 450 since the first of the year with no problems (and BIG > fans). Hmmm, what kinda fans did you use and where can one get those? Is the 300A overclocked as fast as a regular PII 450Mhz? Cheers, Vince - vi...@mcestate.com - vi...@gaianet.net __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M & C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Filesystem question...
On Thu, 22 Jul 1999, Ronald G. Minnich wrote: > On Fri, 23 Jul 1999, Kris Kennaway wrote: > > Well, if you're running it as a kernel module then obviously you need root > > permissions to load it. If it's running as a userland process, then > > there's no reason why you can't run it as a user. mount presumably > > wouldn't care as long as you had access rights to the underlying objects > > (mountpoint + stacking layer process). > > well, you'll have to tell me more. (i have to get my freebsd source tree > back :-) ) > > Are you saying that as an ordinary user I can mount something on top of > /tmp, for example? If the vfs.usermount sysctl is 1, and you have appropriate access to the thing you're trying to mount (block device, etc). > Is the suser() check still in the mount system call?
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
On Wed, 21 Jul 1999, Vincent Poy wrote: > Greetings everyone, > > What are the current good motherboards for FreeBSD for the pentium > II and III? I know on the Pentium, it was the ASUS board but for the > PII/PIII, is the Abit the better board? Also, I was wondering what is the > fastest Celeron chip that can be overclocked to run at 100Mhz FSB? Does > it matter if it's Slot 1 or PPGA based? Thanks. At work we're having good results with an Intel N440BX motherboard. It's a dual cpu board, running 2 PIII 500's like a champ. It also has the ability to redirect all console output (like boot/bios messages, etc.) to a serial console. It comes with a built in Etherexpress Pro 100+ as well. I have an Asus P2B at home that I've run my Celeron 300A overclocked to 450 since the first of the year with no problems (and BIG fans). HTH, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposed substitution for ACLs
Daniel C. Sobral wrote:
>
> Sergey Babkin wrote:
> >
> > I want to propose a simple substitution for ACLs. No, here
> > is no patch yet but I'm ready and willing to do it. The reason
> > why I want to discuss it first is that this is a Political Thing.
> > And if the Core Team decides that it's a Bad Thing, I suppose
> > it will never get commited to the system. Because of this I
> > would like to see some encouraging signs from the Core Team
> > before implementing it.
>
> Do whatever you want: as a fs layer.
Speaking about the fs layers, can you please advise me on the current
state of nullfs ? Is it working now ? I have checked GNATS about this
and did not quite understood whether the results of a lengthly
discussion in there on this subject were ever committed.
On the other hand, I'm not sure whether implementing it as an FS
layer is a good idea. It is certainly possible to do by snooping
at the getattr/setattr calls but IMHO it will mean completely bypassing
the VOP_ACCESS of the underlying filesystem what may be not good.
On the other hand the changes to ufs_assess() seem to be quite small
and cover all the UFS type filesystems, such as FFS and EXT2FS.
Of course yet another option is to create one more fs type with all
the operations in the filesystem switch the same as for FFS except
for ufs_access().
What would be your recommendation ? Thanks!
Here is the proposed patch (made against 3.2). If it will be
considered OK I'll write some man page and LINT kernel entry too.
I'm not sure whether the sysctl sub-node vfs.ufs is really neccessary
but it seems to be logical.
-- cut here -
*** /sys/ufs/ufs/ufs_vnops.c1999/07/15 14:50:53 1.1
--- /sys/ufs/ufs/ufs_vnops.c1999/07/22 18:16:28
***
*** 57,62
--- 57,63
#include
#include
#include
+ #include
#include
#include
***
*** 104,109
--- 105,128
static int ufsspec_read __P((struct vop_read_args *));
static int ufsspec_write __P((struct vop_write_args *));
+ #ifdef ENABLE_UFS_COMMONID
+ /*
+ * Sysctl variables to control the unified user and
+ * group ID space.
+ * commonid is the lowest ID from which the common UID/GID space starts
+ * MINCOMMONID is the minimal value, if commonid is lower then the
+ * common ID space is disabled
+ */
+
+ #define MINCOMMONID 100
+
+ SYSCTL_NODE(_vfs, OID_AUTO, ufs, CTLFLAG_RW, 0, "Local Unix-type filesystems");
+ static int commonid=0;
+ SYSCTL_INT(_vfs_ufs, OID_AUTO, commonid, CTLFLAG_RW, &commonid, 0,
+ "Lowest ID for the common GID/UID space");
+
+ #endif
+
union _qcvt {
int64_t qcvt;
int32_t val[2];
***
*** 339,344
--- 360,382
mask |= S_IWUSR;
return ((ip->i_mode & mask) == mask ? 0 : EACCES);
}
+
+ #ifdef ENABLE_UFS_COMMONID
+ /* if the common UID/GID is enabled check the groups against the file UID */
+ if (commonid >= MINCOMMONID && ip->i_uid >= commonid) {
+ for (i = 0, gp = cred->cr_groups; i < cred->cr_ngroups;
+ i++, gp++)
+ if (ip->i_uid == *gp) {
+ if (mode & VEXEC)
+ mask |= S_IXUSR;
+ if (mode & VREAD)
+ mask |= S_IRUSR;
+ if (mode & VWRITE)
+ mask |= S_IWUSR;
+ return ((ip->i_mode & mask) == mask ? 0 : EACCES);
+ }
+ }
+ #endif
/* Otherwise, check the groups. */
for (i = 0, gp = cred->cr_groups; i < cred->cr_ngroups; i++, gp++)
--- cut here
-SB
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
On Thu, 22 Jul 1999, Doug wrote: > On Wed, 21 Jul 1999, Vincent Poy wrote: > > > Greetings everyone, > > > > What are the current good motherboards for FreeBSD for the pentium > > II and III? I know on the Pentium, it was the ASUS board but for the > > PII/PIII, is the Abit the better board? Also, I was wondering what is the > > fastest Celeron chip that can be overclocked to run at 100Mhz FSB? Does > > it matter if it's Slot 1 or PPGA based? Thanks. > > At work we're having good results with an Intel N440BX > motherboard. It's a dual cpu board, running 2 PIII 500's like a champ. It > also has the ability to redirect all console output (like boot/bios > messages, etc.) to a serial console. It comes with a built in Etherexpress > Pro 100+ as well. Cool... I thought the Intel motherboards weren't that good compared to other brands.. > I have an Asus P2B at home that I've run my Celeron 300A > overclocked to 450 since the first of the year with no problems (and BIG > fans). Hmmm, what kinda fans did you use and where can one get those? Is the 300A overclocked as fast as a regular PII 450Mhz? Cheers, Vince - [EMAIL PROTECTED] - [EMAIL PROTECTED] __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M & C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Filesystem question...
On Thu, 22 Jul 1999, Ronald G. Minnich wrote: > On Fri, 23 Jul 1999, Kris Kennaway wrote: > > Well, if you're running it as a kernel module then obviously you need root > > permissions to load it. If it's running as a userland process, then > > there's no reason why you can't run it as a user. mount presumably > > wouldn't care as long as you had access rights to the underlying objects > > (mountpoint + stacking layer process). > > well, you'll have to tell me more. (i have to get my freebsd source tree > back :-) ) > > Are you saying that as an ordinary user I can mount something on top of > /tmp, for example? If the vfs.usermount sysctl is 1, and you have appropriate access to the thing you're trying to mount (block device, etc). > Is the suser() check still in the mount system call? >From vfs_syscalls.c: if (usermount == 0 && (error = suser(p))) return (error); usermount is tuned by the vfs.usermount sysctl and defaults to 0. Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
On Wed, 21 Jul 1999, Vincent Poy wrote: > Greetings everyone, > > What are the current good motherboards for FreeBSD for the pentium > II and III? I know on the Pentium, it was the ASUS board but for the > PII/PIII, is the Abit the better board? Also, I was wondering what is the > fastest Celeron chip that can be overclocked to run at 100Mhz FSB? Does > it matter if it's Slot 1 or PPGA based? Thanks. At work we're having good results with an Intel N440BX motherboard. It's a dual cpu board, running 2 PIII 500's like a champ. It also has the ability to redirect all console output (like boot/bios messages, etc.) to a serial console. It comes with a built in Etherexpress Pro 100+ as well. I have an Asus P2B at home that I've run my Celeron 300A overclocked to 450 since the first of the year with no problems (and BIG fans). HTH, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
New patch fpr uipc_socket.c (was Squid - a bug in src/sys/kern/uipc_socket.c)
I believe this will solve the previously reported problems.
With the original patch if I set net.inet.tcp.sendspace=63 and tried
to run xterm from that machine to my local workstation, I got an X error.
If I set sendspace=31 the xterm process just locked up and did nothing
until I ^C'd it.
machine A machine B
w/modified kernel w/unmodified kernel
(sysctl's on this machine)
xterm run on A --> display is on B
With this patch I can set net.inet.tcp.sendspace to anything (63, 31, 1,
whatever I want) and the xterm will still run. And yes, the xterm is
amazingly slow when I set net.inet.tcp.sendspace to 1 :-)
This patch is relative to -CURRENT but should also work with -STABLE.
-Matt
Index: uipc_socket.c
===
RCS file: /home/ncvs/src/sys/kern/uipc_socket.c,v
retrieving revision 1.60
diff -u -r1.60 uipc_socket.c
--- uipc_socket.c 1999/06/17 23:54:47 1.60
+++ uipc_socket.c 1999/07/22 23:08:38
@@ -413,7 +413,8 @@
register struct mbuf *m;
register long space, len, resid;
int clen = 0, error, s, dontroute, mlen;
- int atomic = sosendallatonce(so) || top;
+ int atomic = sosendallatonce(so) || top;/* required atomicy */
+ int try_atomic = atomic;/* requested atomicy */
if (uio)
resid = uio->uio_resid;
@@ -518,6 +519,7 @@
mlen = MCLBYTES;
len = min(min(mlen, resid), space);
} else {
+ try_atomic = 1; /* try to optimize */
nopages:
len = min(min(mlen, resid), space);
/*
@@ -541,7 +543,7 @@
top->m_flags |= M_EOR;
break;
}
- } while (space > 0 && atomic);
+ } while (space > 0 && try_atomic);
if (dontroute)
so->so_options |= SO_DONTROUTE;
s = splnet(); /* XXX */
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: IDE breakage
Julian Elischer wrote: > > My fault > > I accidentally replaced a PAGE_MASK with a PAGE_SIZE. > the resulting bug only changes teh behaviour on unaligned pages > which are only possible on the raw device. > (e.g. fsck) > > the Cyrix 5530 we used to test has a bug where we cannot do unalligned > transfers by DMA anyhow, so we never hit this bug.. > > fixed in -current > will be fixxed in -stable when I reintroduce the patch... Bad Programmer! No doughnuts! ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
On Thu, 22 Jul 1999, Adrian Filipi-Martin wrote: > On Wed, 21 Jul 1999, Vincent Poy wrote: > > > Greetings everyone, > > > > What are the current good motherboards for FreeBSD for the pentium > > II and III? I know on the Pentium, it was the ASUS board but for the > > PII/PIII, is the Abit the better board? Also, I was wondering what is the > > fastest Celeron chip that can be overclocked to run at 100Mhz FSB? Does > > it matter if it's Slot 1 or PPGA based? Thanks. > > I know a lot of people like the ASUS P2B boards, but I've noticed a > tendency for the systems to reset occasionally when plugging in a keyboard. > I've seen this with both FreeBSD and NT, so I'm considering it a property > of the board. I haven't seen anyone use a ASUS PII board but it seems like everyone is using ABIT boards for some reason for FreeBSD. I have a ASUS XP55T2P4 w/P233MMX on it and 128 megs of ram and while it works fine in FreeBSD... It seems to act weird in Windows95. I have some EIDE Mode 3 and mode 2 drives in the system and with the BIOS setting of PIO mode Auto, it works fine until I added the Maxtor Mode 4 HDD. This is when defining everything as auto would start up win95 half way and say things are corrupted so I had to manually set it to mode 3, 3, 2, 2 before things worked. And then the funny thing is that even with the 400Watt PC Power & Cooling Power Supply, in Win95, at certain times, when I click on something, it's like the machine did a hard reset Seems like the board works better with FreeBSD than Win95. > I've had great results with the Tyan 1836DLUAN/Thunder 100's. > I've got several boxes with 1GB of RAM and dual 450's humming along. For > comparison one system with less memory and a SuperMicro board but identical > system software has had a couple of wierd spontaneous reboots over the last > few months. Cool... Is 1GB of ram really needed? We used to run a 64 meg system then 128 meg and then 384 meg, it doesn't seem to do much even for a heavily loaded ISP Server. Cheers, Vince - vi...@mcestate.com - vi...@gaianet.net __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M & C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: InterMezzo: Project for kernel/FS hackers
I'm working with intermezzo now. It's interesting. Note that the VFS is quite simple, and defines a simple kernel-user channel which maps VFS ops to requests on an IPC channel. The possibilities are endless ... A freebsd port would be nice. Maybe you could use v9fs as a starting point. ron To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: mbuf leakage in NFSv3 writes, possbile?
Well, I just -STABLED the server to see if it fixed it, but I was certainly running out. the server had only 3000-ish mbuf chains, and it would go through them all in a day. -- David Cross | email: cro...@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: mbuf leakage in NFSv3 writes, possbile?
:I have 2 NFS servers. One is primarily read-only, the other read-write, they :service the same clients (the read-only services more). They are (were) of :the same build. I have a problem on the read/write server where it chews :through mbuf clusters (it goes through about 3k in a day). Especially late :at night the machine is not busy. And now it is also not busy, yet every :minute or so it goes through a few mbuf clusters. The rate is about 108 :minutes for 300 clusters. Does it sound reasonable that there is a mbuf leak :in the NFS code somewhere? : :-- :David Cross | email: cro...@cs.rpi.edu The server side caches mbuf chains to hold replies to NFS requests. This is done because it is quite common for requests to be repeated. The question is whether you are simply seeing the effect of this caching, or whether you have an actual mbuf leak. Does the mbuf usage / memory usage stabilize after a while or do you actually run out? -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
mbuf leakage in NFSv3 writes, possbile?
I have 2 NFS servers. One is primarily read-only, the other read-write, they service the same clients (the read-only services more). They are (were) of the same build. I have a problem on the read/write server where it chews through mbuf clusters (it goes through about 3k in a day). Especially late at night the machine is not busy. And now it is also not busy, yet every minute or so it goes through a few mbuf clusters. The rate is about 108 minutes for 300 clusters. Does it sound reasonable that there is a mbuf leak in the NFS code somewhere? -- David Cross | email: cro...@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
New patch fpr uipc_socket.c (was Squid - a bug in src/sys/kern/uipc_socket.c)
I believe this will solve the previously reported problems.
With the original patch if I set net.inet.tcp.sendspace=63 and tried
to run xterm from that machine to my local workstation, I got an X error.
If I set sendspace=31 the xterm process just locked up and did nothing
until I ^C'd it.
machine A machine B
w/modified kernel w/unmodified kernel
(sysctl's on this machine)
xterm run on A --> display is on B
With this patch I can set net.inet.tcp.sendspace to anything (63, 31, 1,
whatever I want) and the xterm will still run. And yes, the xterm is
amazingly slow when I set net.inet.tcp.sendspace to 1 :-)
This patch is relative to -CURRENT but should also work with -STABLE.
-Matt
Index: uipc_socket.c
===
RCS file: /home/ncvs/src/sys/kern/uipc_socket.c,v
retrieving revision 1.60
diff -u -r1.60 uipc_socket.c
--- uipc_socket.c 1999/06/17 23:54:47 1.60
+++ uipc_socket.c 1999/07/22 23:08:38
@@ -413,7 +413,8 @@
register struct mbuf *m;
register long space, len, resid;
int clen = 0, error, s, dontroute, mlen;
- int atomic = sosendallatonce(so) || top;
+ int atomic = sosendallatonce(so) || top;/* required atomicy */
+ int try_atomic = atomic;/* requested atomicy */
if (uio)
resid = uio->uio_resid;
@@ -518,6 +519,7 @@
mlen = MCLBYTES;
len = min(min(mlen, resid), space);
} else {
+ try_atomic = 1; /* try to optimize */
nopages:
len = min(min(mlen, resid), space);
/*
@@ -541,7 +543,7 @@
top->m_flags |= M_EOR;
break;
}
- } while (space > 0 && atomic);
+ } while (space > 0 && try_atomic);
if (dontroute)
so->so_options |= SO_DONTROUTE;
s = splnet(); /* XXX */
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: RE: Squid - a bug in src/sys/kern/uipc_socket.c
::It's been committed before, and broke many things (X and CVSup come to ::mind). I have it compiled in locally on a few machines but it's ::definitely not suitable for general distribution until a solution is ::found that doesn't break applications. :: ::Jason Young ::accessUS Chief Network Engineer : :Hmm.. it doesn't look like anyone tracked down why it was breaking :applications after it was backed out the fist time - July last year :looking at the CVS logs. : : -Matt Looking at the code more closely, a failure can occur if the amount of data is larger then so->so_snd.sb_hiwat. This situation looks like it can occur if the socket buffer fills up (the sender is faster then the receiver). The solution would be to have a slightly more involved patch. Have a 'tryatomic' variable which is set based on this particular situation and then use it to mean 'atomic' in those cases where no error would occur. I am going to try to reproduce the failure with the original patch and will work up a new patch that fixes it if it winds up being what I think it will be. -Matt To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: RE: Squid - a bug in src/sys/kern/uipc_socket.c
: :It's been committed before, and broke many things (X and CVSup come to :mind). I have it compiled in locally on a few machines but it's :definitely not suitable for general distribution until a solution is :found that doesn't break applications. : :Jason Young :accessUS Chief Network Engineer Hmm.. it doesn't look like anyone tracked down why it was breaking applications after it was backed out the fist time - July last year looking at the CVS logs. -Matt To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: IDE breakage
Julian Elischer wrote: > > My fault > > I accidentally replaced a PAGE_MASK with a PAGE_SIZE. > the resulting bug only changes teh behaviour on unaligned pages > which are only possible on the raw device. > (e.g. fsck) > > the Cyrix 5530 we used to test has a bug where we cannot do unalligned > transfers by DMA anyhow, so we never hit this bug.. > > fixed in -current > will be fixxed in -stable when I reintroduce the patch... Bad Programmer! No doughnuts! ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
On Thu, 22 Jul 1999, Adrian Filipi-Martin wrote: > On Wed, 21 Jul 1999, Vincent Poy wrote: > > > Greetings everyone, > > > > What are the current good motherboards for FreeBSD for the pentium > > II and III? I know on the Pentium, it was the ASUS board but for the > > PII/PIII, is the Abit the better board? Also, I was wondering what is the > > fastest Celeron chip that can be overclocked to run at 100Mhz FSB? Does > > it matter if it's Slot 1 or PPGA based? Thanks. > > I know a lot of people like the ASUS P2B boards, but I've noticed a > tendency for the systems to reset occasionally when plugging in a keyboard. > I've seen this with both FreeBSD and NT, so I'm considering it a property > of the board. I haven't seen anyone use a ASUS PII board but it seems like everyone is using ABIT boards for some reason for FreeBSD. I have a ASUS XP55T2P4 w/P233MMX on it and 128 megs of ram and while it works fine in FreeBSD... It seems to act weird in Windows95. I have some EIDE Mode 3 and mode 2 drives in the system and with the BIOS setting of PIO mode Auto, it works fine until I added the Maxtor Mode 4 HDD. This is when defining everything as auto would start up win95 half way and say things are corrupted so I had to manually set it to mode 3, 3, 2, 2 before things worked. And then the funny thing is that even with the 400Watt PC Power & Cooling Power Supply, in Win95, at certain times, when I click on something, it's like the machine did a hard reset Seems like the board works better with FreeBSD than Win95. > I've had great results with the Tyan 1836DLUAN/Thunder 100's. > I've got several boxes with 1GB of RAM and dual 450's humming along. For > comparison one system with less memory and a SuperMicro board but identical > system software has had a couple of wierd spontaneous reboots over the last > few months. Cool... Is 1GB of ram really needed? We used to run a 64 meg system then 128 meg and then 384 meg, it doesn't seem to do much even for a heavily loaded ISP Server. Cheers, Vince - [EMAIL PROTECTED] - [EMAIL PROTECTED] __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M & C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Squid - a bug in src/sys/kern/uipc_socket.c
Maybe it could be made a sysctl knob...
On Thu, 22 Jul 1999, Jason Young wrote:
>
> It's been committed before, and broke many things (X and CVSup come to
> mind). I have it compiled in locally on a few machines but it's
> definitely not suitable for general distribution until a solution is
> found that doesn't break applications.
>
> Jason Young
> accessUS Chief Network Engineer
>
>
> > -Original Message-
> > From: owner-freebsd-hack...@freebsd.org
> > [mailto:owner-freebsd-hack...@freebsd.org]on Behalf Of
> > Matthew Dillon
> > Sent: Thursday, July 22, 1999 3:57 PM
> > To: Papezik Milon
> > Cc: hack...@freebsd.org
> > Subject: Re: Squid - a bug in src/sys/kern/uipc_socket.c
> >
> >
> > This isn't really a bug since this is a TCP connection.
> > TCP makes
> > no guarentees that atomic writes will show up as atomic
> > reads, and
> > the squid code shouldn't be making that assumption.
> >
> > On the otherhand, the proposed fix appears to be an
> > excellent performance
> > optimization. It is basically only turning 'atomic' on
> > for relatively
> > small writes, which should be a win for a receiver
> > whether over a
> > localhost connection or a real network. I can't
> > imagine that it would
> > cause a performance loss in any other situation -- it
> > might result in
> > a slightly smaller-then-full-sized TCP packet
> > occassionally in a stream
> > but that's about it.
> >
> > I think committing this would be beneficial. Would
> > someone w/ commit
> > privs care to review and then commit this bit?
> >
> > -Matt
> > Matthew Dillon
> >
> >
> > :Hi,
> > :
> > :please don't kill me if it's "well known issue":
> > :
> > :I've found that there is a report on Squid site, which
> > :describes a problem with FreeBSD IPC and includes suggested fix.
> > :I verified that this suggested fix is not included in 3.2-RELEASE.
> > :
> > :I wonder, if it is really a bug, as I cannot find it in PR
> > database.
> > :
> > :Could someone please comment on this report/bug/suggested fix
> > :and if/when the fix could/will be submited?
> > :
> > :original URL:
> > :http://squid.nlanr.net/Squid/FAQ/FAQ-14.html#ss14.2
> > :
> > : Thanks in advance,
> > : Milon
> > :--
> > :pape...@pvt.net
> > :
> > :
> > : bug report and suggested fix -
> > :mbuf size
> > :
> > :We noticed an odd thing with some of Squid's interprocess
> > communication.
> > :Often, output from the dnsserver processes would NOT be read in one
> > :chunk. With full debugging, it looks like this:
> > :
> > :1998/04/02 15:18:48| comm_select: FD 46 ready for reading
> > :1998/04/02 15:18:48| ipcache_dnsHandleRead: Result from
> > DNS ID 2 (100
> > :bytes)
> > :1998/04/02 15:18:48| ipcache_dnsHandleRead: Incomplete reply
> > :other processing occurs...
> > :1998/04/02 15:18:48| comm_select: FD 46 ready for reading
> > :1998/04/02 15:18:48| ipcache_dnsHandleRead: Result from DNS ID 2 (9
> > :bytes)
> > :1998/04/02 15:18:48| ipcache_parsebuffer: parsing:
> > :$name www.karup.com
> > :$h_name www.karup.inter.net
> > :$h_len 4
> > :$ipcount 2
> > :38.15.68.128
> > :38.15.67.128
> > :$ttl 2348
> > :$end
> > :
> > :Interestingly, it is very common to get only 100 bytes on the first
> > :read. When two read() calls are required, this adds
> > additional latency
> > :to the overall request. On our caches running Digital
> > Unix, the median
> > :dnsserver response time was measured at 0.01 seconds. On
> > our FreeBSD
> > :cache, however, the median latency was 0.10 seconds.
> > :
> > :Here is a simple patch to fix the bug:
> > :
> > :===
> > :RCS file: /home/ncvs/src/sys/kern/uipc_socket.c,v
> > :retrieving revision 1.40
> > :retrieving revision 1.41
> > :diff -p -u -r1.40 -r1.41
> > :--- src/sys/kern/uipc_socket.c 1998/05/15 20:11:30 1.40
> > :+++ /home/ncvs/src/sys/kern/uipc_socket.c 1998/07/06
> > 19:27:14
> > :1.41
> > :@@ -31,7 +31,7 @@
> > : * SUCH DAMAGE.
> > : *
> > : * @(#)uipc_socket.c 8.3 (Berkeley) 4/15/94
> > :- * $Id: FAQ.sgml,v 1.75 1999/07/06 16:07:36 wessels Exp $
> > :+ * $Id: FAQ.sgml,v 1.75 1999/07/06 16:07:36 wessels Exp $
> > : */
> > :
> > : #include
> > :@@ -491,6 +491,7 @@ restart:
> > :mlen = MCLBYTES;
> > :len = min(min(mlen, resid), space);
> > :} else {
> > :+ atomic = 1;
> > : nopages:
> > :len = min(min(mlen, resid), space);
> >
> >
> >
> > To Unsubscribe: send mail to majord...@freebsd.org
> > with "unsubscribe freebsd-hackers" in the body of the message
> >
>
>
>
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-hackers" in the body of the message
>
To Unsubs
InterMezzo: Project for kernel/FS hackers
Hi chaps, Not entirely sure which list to post this too, so I figured that -hackers was probably most appropriate. Has anyone had the chance to look at InterMezzo, website at http://www.inter-mezzo.org/ It's main claim to fame is that it allows disconnected operation. For example, you could have a server export a home directory to a laptop, then unplug the laptop from the network, and go and edit/add/delete files from the home directory stored on the laptop. When the laptop is then plugged back in to the network, the filesystem automatically (as far as possible) integrates the changes). Coda (which already has a FreeBSD port) also does this, as well as a few other things. However, Coda is much more heavyweight than InterMezzo, and therefore easier to understand -- in particular, Coda seems to have (according to one of the Coda developers) a marked preference for exporting whole filesystems, InterMezzo allows you to export individual directory trees. Anyway, if any aspiring kernel hackers are looking for a project, that might be a fun one. The only implementation at the moment is for Linux. Cheers, N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <37514...@cs.colorado.edu> To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
RE: Squid - a bug in src/sys/kern/uipc_socket.c
It's been committed before, and broke many things (X and CVSup come to
mind). I have it compiled in locally on a few machines but it's
definitely not suitable for general distribution until a solution is
found that doesn't break applications.
Jason Young
accessUS Chief Network Engineer
> -Original Message-
> From: owner-freebsd-hack...@freebsd.org
> [mailto:owner-freebsd-hack...@freebsd.org]on Behalf Of
> Matthew Dillon
> Sent: Thursday, July 22, 1999 3:57 PM
> To: Papezik Milon
> Cc: hack...@freebsd.org
> Subject: Re: Squid - a bug in src/sys/kern/uipc_socket.c
>
>
> This isn't really a bug since this is a TCP connection.
> TCP makes
> no guarentees that atomic writes will show up as atomic
> reads, and
> the squid code shouldn't be making that assumption.
>
> On the otherhand, the proposed fix appears to be an
> excellent performance
> optimization. It is basically only turning 'atomic' on
> for relatively
> small writes, which should be a win for a receiver
> whether over a
> localhost connection or a real network. I can't
> imagine that it would
> cause a performance loss in any other situation -- it
> might result in
> a slightly smaller-then-full-sized TCP packet
> occassionally in a stream
> but that's about it.
>
> I think committing this would be beneficial. Would
> someone w/ commit
> privs care to review and then commit this bit?
>
> -Matt
> Matthew Dillon
>
>
> :Hi,
> :
> :please don't kill me if it's "well known issue":
> :
> :I've found that there is a report on Squid site, which
> :describes a problem with FreeBSD IPC and includes suggested fix.
> :I verified that this suggested fix is not included in 3.2-RELEASE.
> :
> :I wonder, if it is really a bug, as I cannot find it in PR
> database.
> :
> :Could someone please comment on this report/bug/suggested fix
> :and if/when the fix could/will be submited?
> :
> :original URL:
> :http://squid.nlanr.net/Squid/FAQ/FAQ-14.html#ss14.2
> :
> : Thanks in advance,
> : Milon
> :--
> :pape...@pvt.net
> :
> :
> : bug report and suggested fix -
> :mbuf size
> :
> :We noticed an odd thing with some of Squid's interprocess
> communication.
> :Often, output from the dnsserver processes would NOT be read in one
> :chunk. With full debugging, it looks like this:
> :
> :1998/04/02 15:18:48| comm_select: FD 46 ready for reading
> :1998/04/02 15:18:48| ipcache_dnsHandleRead: Result from
> DNS ID 2 (100
> :bytes)
> :1998/04/02 15:18:48| ipcache_dnsHandleRead: Incomplete reply
> :other processing occurs...
> :1998/04/02 15:18:48| comm_select: FD 46 ready for reading
> :1998/04/02 15:18:48| ipcache_dnsHandleRead: Result from DNS ID 2 (9
> :bytes)
> :1998/04/02 15:18:48| ipcache_parsebuffer: parsing:
> :$name www.karup.com
> :$h_name www.karup.inter.net
> :$h_len 4
> :$ipcount 2
> :38.15.68.128
> :38.15.67.128
> :$ttl 2348
> :$end
> :
> :Interestingly, it is very common to get only 100 bytes on the first
> :read. When two read() calls are required, this adds
> additional latency
> :to the overall request. On our caches running Digital
> Unix, the median
> :dnsserver response time was measured at 0.01 seconds. On
> our FreeBSD
> :cache, however, the median latency was 0.10 seconds.
> :
> :Here is a simple patch to fix the bug:
> :
> :===
> :RCS file: /home/ncvs/src/sys/kern/uipc_socket.c,v
> :retrieving revision 1.40
> :retrieving revision 1.41
> :diff -p -u -r1.40 -r1.41
> :--- src/sys/kern/uipc_socket.c 1998/05/15 20:11:30 1.40
> :+++ /home/ncvs/src/sys/kern/uipc_socket.c 1998/07/06
> 19:27:14
> :1.41
> :@@ -31,7 +31,7 @@
> : * SUCH DAMAGE.
> : *
> : * @(#)uipc_socket.c 8.3 (Berkeley) 4/15/94
> :- * $Id: FAQ.sgml,v 1.75 1999/07/06 16:07:36 wessels Exp $
> :+ * $Id: FAQ.sgml,v 1.75 1999/07/06 16:07:36 wessels Exp $
> : */
> :
> : #include
> :@@ -491,6 +491,7 @@ restart:
> :mlen = MCLBYTES;
> :len = min(min(mlen, resid), space);
> :} else {
> :+ atomic = 1;
> : nopages:
> :len = min(min(mlen, resid), space);
>
>
>
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-hackers" in the body of the message
>
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: InterMezzo: Project for kernel/FS hackers
I'm working with intermezzo now. It's interesting. Note that the VFS is quite simple, and defines a simple kernel-user channel which maps VFS ops to requests on an IPC channel. The possibilities are endless ... A freebsd port would be nice. Maybe you could use v9fs as a starting point. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mbuf leakage in NFSv3 writes, possbile?
Well, I just -STABLED the server to see if it fixed it, but I was certainly running out. the server had only 3000-ish mbuf chains, and it would go through them all in a day. -- David Cross | email: [EMAIL PROTECTED] Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mbuf leakage in NFSv3 writes, possbile?
:I have 2 NFS servers. One is primarily read-only, the other read-write, they :service the same clients (the read-only services more). They are (were) of :the same build. I have a problem on the read/write server where it chews :through mbuf clusters (it goes through about 3k in a day). Especially late :at night the machine is not busy. And now it is also not busy, yet every :minute or so it goes through a few mbuf clusters. The rate is about 108 :minutes for 300 clusters. Does it sound reasonable that there is a mbuf leak :in the NFS code somewhere? : :-- :David Cross | email: [EMAIL PROTECTED] The server side caches mbuf chains to hold replies to NFS requests. This is done because it is quite common for requests to be repeated. The question is whether you are simply seeing the effect of this caching, or whether you have an actual mbuf leak. Does the mbuf usage / memory usage stabilize after a while or do you actually run out? -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Will FreeBSD ever see native IPv6 ??
According to John Hay: > in their TODO for the past few months, I can't find anything that > indicates that they or anyone else is working on it. They may be, but I assure you they're working on it. Problem is they also have day jobs and some part of integration is complicated by export controls (the NRL code is more advanced IPsec-wise than our japanese friends). -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #72: Mon Jul 12 08:26:43 CEST 1999 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
mbuf leakage in NFSv3 writes, possbile?
I have 2 NFS servers. One is primarily read-only, the other read-write, they service the same clients (the read-only services more). They are (were) of the same build. I have a problem on the read/write server where it chews through mbuf clusters (it goes through about 3k in a day). Especially late at night the machine is not busy. And now it is also not busy, yet every minute or so it goes through a few mbuf clusters. The rate is about 108 minutes for 300 clusters. Does it sound reasonable that there is a mbuf leak in the NFS code somewhere? -- David Cross | email: [EMAIL PROTECTED] Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: RE: Squid - a bug in src/sys/kern/uipc_socket.c
::It's been committed before, and broke many things (X and CVSup come to ::mind). I have it compiled in locally on a few machines but it's ::definitely not suitable for general distribution until a solution is ::found that doesn't break applications. :: ::Jason Young ::accessUS Chief Network Engineer : :Hmm.. it doesn't look like anyone tracked down why it was breaking :applications after it was backed out the fist time - July last year :looking at the CVS logs. : : -Matt Looking at the code more closely, a failure can occur if the amount of data is larger then so->so_snd.sb_hiwat. This situation looks like it can occur if the socket buffer fills up (the sender is faster then the receiver). The solution would be to have a slightly more involved patch. Have a 'tryatomic' variable which is set based on this particular situation and then use it to mean 'atomic' in those cases where no error would occur. I am going to try to reproduce the failure with the original patch and will work up a new patch that fixes it if it winds up being what I think it will be. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposal for new syscall to close files
:Hi, : : I like this approach. I have a number of often spawned daemon :processes that could benefit from this. One of the last process :we debugged where we had unwanted open filedescriptors was in :programs invoked by the cvs loginfo script. : : For naming convention considerations, I might suggest 'closeall' :or 'closefdset' or something similar... at least have 'close' in :name... :-) Well, when I weight the benefit of the savings in overhead for a single syscall verses a close() loop, and when I weigh the seriousness of introducing a syscall that would not be portable to other operating systems, and if I also take into account the work required to deal with descriptors after forking a daemon well, I don't think that adding a new syscall would be worth the relatively minor benefit nor do I think the improvement in performance would be noticeable. The benefit isn't great enough to warrent a new syscall in my view. I've written a number of forking daemons, most noteable my web server and my Diablo news transit system. I just don't think the reduced overhead would be noticeable over simply calling close(), and I didn't have any problems keeping track of which file descriptors to close in Diablo (and there could be 100+ descriptors). Keep in mind that after a fork these descriptors have a ref count > 1, meaning that the close() syscall is almost free. If you assume 5uS/close you are still talking quite a bit less then a millisecond to close a hundred descriptors. And that's pretty much the worst case I can think of. -Matt To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: RE: Squid - a bug in src/sys/kern/uipc_socket.c
: :It's been committed before, and broke many things (X and CVSup come to :mind). I have it compiled in locally on a few machines but it's :definitely not suitable for general distribution until a solution is :found that doesn't break applications. : :Jason Young :accessUS Chief Network Engineer Hmm.. it doesn't look like anyone tracked down why it was breaking applications after it was backed out the fist time - July last year looking at the CVS logs. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Squid - a bug in src/sys/kern/uipc_socket.c
Maybe it could be made a sysctl knob...
On Thu, 22 Jul 1999, Jason Young wrote:
>
> It's been committed before, and broke many things (X and CVSup come to
> mind). I have it compiled in locally on a few machines but it's
> definitely not suitable for general distribution until a solution is
> found that doesn't break applications.
>
> Jason Young
> accessUS Chief Network Engineer
>
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of
> > Matthew Dillon
> > Sent: Thursday, July 22, 1999 3:57 PM
> > To: Papezik Milon
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: Squid - a bug in src/sys/kern/uipc_socket.c
> >
> >
> > This isn't really a bug since this is a TCP connection.
> > TCP makes
> > no guarentees that atomic writes will show up as atomic
> > reads, and
> > the squid code shouldn't be making that assumption.
> >
> > On the otherhand, the proposed fix appears to be an
> > excellent performance
> > optimization. It is basically only turning 'atomic' on
> > for relatively
> > small writes, which should be a win for a receiver
> > whether over a
> > localhost connection or a real network. I can't
> > imagine that it would
> > cause a performance loss in any other situation -- it
> > might result in
> > a slightly smaller-then-full-sized TCP packet
> > occassionally in a stream
> > but that's about it.
> >
> > I think committing this would be beneficial. Would
> > someone w/ commit
> > privs care to review and then commit this bit?
> >
> > -Matt
> > Matthew Dillon
> > <[EMAIL PROTECTED]>
> >
> > :Hi,
> > :
> > :please don't kill me if it's "well known issue":
> > :
> > :I've found that there is a report on Squid site, which
> > :describes a problem with FreeBSD IPC and includes suggested fix.
> > :I verified that this suggested fix is not included in 3.2-RELEASE.
> > :
> > :I wonder, if it is really a bug, as I cannot find it in PR
> > database.
> > :
> > :Could someone please comment on this report/bug/suggested fix
> > :and if/when the fix could/will be submited?
> > :
> > :original URL:
> > :http://squid.nlanr.net/Squid/FAQ/FAQ-14.html#ss14.2
> > :
> > : Thanks in advance,
> > : Milon
> > :--
> > :[EMAIL PROTECTED]
> > :
> > :
> > : bug report and suggested fix -
> > :mbuf size
> > :
> > :We noticed an odd thing with some of Squid's interprocess
> > communication.
> > :Often, output from the dnsserver processes would NOT be read in one
> > :chunk. With full debugging, it looks like this:
> > :
> > :1998/04/02 15:18:48| comm_select: FD 46 ready for reading
> > :1998/04/02 15:18:48| ipcache_dnsHandleRead: Result from
> > DNS ID 2 (100
> > :bytes)
> > :1998/04/02 15:18:48| ipcache_dnsHandleRead: Incomplete reply
> > :other processing occurs...
> > :1998/04/02 15:18:48| comm_select: FD 46 ready for reading
> > :1998/04/02 15:18:48| ipcache_dnsHandleRead: Result from DNS ID 2 (9
> > :bytes)
> > :1998/04/02 15:18:48| ipcache_parsebuffer: parsing:
> > :$name www.karup.com
> > :$h_name www.karup.inter.net
> > :$h_len 4
> > :$ipcount 2
> > :38.15.68.128
> > :38.15.67.128
> > :$ttl 2348
> > :$end
> > :
> > :Interestingly, it is very common to get only 100 bytes on the first
> > :read. When two read() calls are required, this adds
> > additional latency
> > :to the overall request. On our caches running Digital
> > Unix, the median
> > :dnsserver response time was measured at 0.01 seconds. On
> > our FreeBSD
> > :cache, however, the median latency was 0.10 seconds.
> > :
> > :Here is a simple patch to fix the bug:
> > :
> > :===
> > :RCS file: /home/ncvs/src/sys/kern/uipc_socket.c,v
> > :retrieving revision 1.40
> > :retrieving revision 1.41
> > :diff -p -u -r1.40 -r1.41
> > :--- src/sys/kern/uipc_socket.c 1998/05/15 20:11:30 1.40
> > :+++ /home/ncvs/src/sys/kern/uipc_socket.c 1998/07/06
> > 19:27:14
> > :1.41
> > :@@ -31,7 +31,7 @@
> > : * SUCH DAMAGE.
> > : *
> > : * @(#)uipc_socket.c 8.3 (Berkeley) 4/15/94
> > :- * $Id: FAQ.sgml,v 1.75 1999/07/06 16:07:36 wessels Exp $
> > :+ * $Id: FAQ.sgml,v 1.75 1999/07/06 16:07:36 wessels Exp $
> > : */
> > :
> > : #include
> > :@@ -491,6 +491,7 @@ restart:
> > :mlen = MCLBYTES;
> > :len = min(min(mlen, resid), space);
> > :} else {
> > :+ atomic = 1;
> > : nopages:
> > :len = min(min(mlen, resid), space);
> >
> >
> >
> > 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
InterMezzo: Project for kernel/FS hackers
Hi chaps, Not entirely sure which list to post this too, so I figured that -hackers was probably most appropriate. Has anyone had the chance to look at InterMezzo, website at http://www.inter-mezzo.org/ It's main claim to fame is that it allows disconnected operation. For example, you could have a server export a home directory to a laptop, then unplug the laptop from the network, and go and edit/add/delete files from the home directory stored on the laptop. When the laptop is then plugged back in to the network, the filesystem automatically (as far as possible) integrates the changes). Coda (which already has a FreeBSD port) also does this, as well as a few other things. However, Coda is much more heavyweight than InterMezzo, and therefore easier to understand -- in particular, Coda seems to have (according to one of the Coda developers) a marked preference for exporting whole filesystems, InterMezzo allows you to export individual directory trees. Anyway, if any aspiring kernel hackers are looking for a project, that might be a fun one. The only implementation at the moment is for Linux. Cheers, N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Squid - a bug in src/sys/kern/uipc_socket.c
It's been committed before, and broke many things (X and CVSup come to
mind). I have it compiled in locally on a few machines but it's
definitely not suitable for general distribution until a solution is
found that doesn't break applications.
Jason Young
accessUS Chief Network Engineer
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> Matthew Dillon
> Sent: Thursday, July 22, 1999 3:57 PM
> To: Papezik Milon
> Cc: [EMAIL PROTECTED]
> Subject: Re: Squid - a bug in src/sys/kern/uipc_socket.c
>
>
> This isn't really a bug since this is a TCP connection.
> TCP makes
> no guarentees that atomic writes will show up as atomic
> reads, and
> the squid code shouldn't be making that assumption.
>
> On the otherhand, the proposed fix appears to be an
> excellent performance
> optimization. It is basically only turning 'atomic' on
> for relatively
> small writes, which should be a win for a receiver
> whether over a
> localhost connection or a real network. I can't
> imagine that it would
> cause a performance loss in any other situation -- it
> might result in
> a slightly smaller-then-full-sized TCP packet
> occassionally in a stream
> but that's about it.
>
> I think committing this would be beneficial. Would
> someone w/ commit
> privs care to review and then commit this bit?
>
> -Matt
> Matthew Dillon
> <[EMAIL PROTECTED]>
>
> :Hi,
> :
> :please don't kill me if it's "well known issue":
> :
> :I've found that there is a report on Squid site, which
> :describes a problem with FreeBSD IPC and includes suggested fix.
> :I verified that this suggested fix is not included in 3.2-RELEASE.
> :
> :I wonder, if it is really a bug, as I cannot find it in PR
> database.
> :
> :Could someone please comment on this report/bug/suggested fix
> :and if/when the fix could/will be submited?
> :
> :original URL:
> :http://squid.nlanr.net/Squid/FAQ/FAQ-14.html#ss14.2
> :
> : Thanks in advance,
> : Milon
> :--
> :[EMAIL PROTECTED]
> :
> :
> : bug report and suggested fix -
> :mbuf size
> :
> :We noticed an odd thing with some of Squid's interprocess
> communication.
> :Often, output from the dnsserver processes would NOT be read in one
> :chunk. With full debugging, it looks like this:
> :
> :1998/04/02 15:18:48| comm_select: FD 46 ready for reading
> :1998/04/02 15:18:48| ipcache_dnsHandleRead: Result from
> DNS ID 2 (100
> :bytes)
> :1998/04/02 15:18:48| ipcache_dnsHandleRead: Incomplete reply
> :other processing occurs...
> :1998/04/02 15:18:48| comm_select: FD 46 ready for reading
> :1998/04/02 15:18:48| ipcache_dnsHandleRead: Result from DNS ID 2 (9
> :bytes)
> :1998/04/02 15:18:48| ipcache_parsebuffer: parsing:
> :$name www.karup.com
> :$h_name www.karup.inter.net
> :$h_len 4
> :$ipcount 2
> :38.15.68.128
> :38.15.67.128
> :$ttl 2348
> :$end
> :
> :Interestingly, it is very common to get only 100 bytes on the first
> :read. When two read() calls are required, this adds
> additional latency
> :to the overall request. On our caches running Digital
> Unix, the median
> :dnsserver response time was measured at 0.01 seconds. On
> our FreeBSD
> :cache, however, the median latency was 0.10 seconds.
> :
> :Here is a simple patch to fix the bug:
> :
> :===
> :RCS file: /home/ncvs/src/sys/kern/uipc_socket.c,v
> :retrieving revision 1.40
> :retrieving revision 1.41
> :diff -p -u -r1.40 -r1.41
> :--- src/sys/kern/uipc_socket.c 1998/05/15 20:11:30 1.40
> :+++ /home/ncvs/src/sys/kern/uipc_socket.c 1998/07/06
> 19:27:14
> :1.41
> :@@ -31,7 +31,7 @@
> : * SUCH DAMAGE.
> : *
> : * @(#)uipc_socket.c 8.3 (Berkeley) 4/15/94
> :- * $Id: FAQ.sgml,v 1.75 1999/07/06 16:07:36 wessels Exp $
> :+ * $Id: FAQ.sgml,v 1.75 1999/07/06 16:07:36 wessels Exp $
> : */
> :
> : #include
> :@@ -491,6 +491,7 @@ restart:
> :mlen = MCLBYTES;
> :len = min(min(mlen, resid), space);
> :} else {
> :+ atomic = 1;
> : nopages:
> :len = min(min(mlen, resid), space);
>
>
>
> 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: Squid - a bug in src/sys/kern/uipc_socket.c
This isn't really a bug since this is a TCP connection. TCP makes
no guarentees that atomic writes will show up as atomic reads, and
the squid code shouldn't be making that assumption.
On the otherhand, the proposed fix appears to be an excellent performance
optimization. It is basically only turning 'atomic' on for relatively
small writes, which should be a win for a receiver whether over a
localhost connection or a real network. I can't imagine that it would
cause a performance loss in any other situation -- it might result in
a slightly smaller-then-full-sized TCP packet occassionally in a stream
but that's about it.
I think committing this would be beneficial. Would someone w/ commit
privs care to review and then commit this bit?
-Matt
Matthew Dillon
:Hi,
:
:please don't kill me if it's "well known issue":
:
:I've found that there is a report on Squid site, which
:describes a problem with FreeBSD IPC and includes suggested fix.
:I verified that this suggested fix is not included in 3.2-RELEASE.
:
:I wonder, if it is really a bug, as I cannot find it in PR database.
:
:Could someone please comment on this report/bug/suggested fix
:and if/when the fix could/will be submited?
:
:original URL:
:http://squid.nlanr.net/Squid/FAQ/FAQ-14.html#ss14.2
:
: Thanks in advance,
: Milon
:--
:pape...@pvt.net
:
:
: bug report and suggested fix -
:mbuf size
:
:We noticed an odd thing with some of Squid's interprocess communication.
:Often, output from the dnsserver processes would NOT be read in one
:chunk. With full debugging, it looks like this:
:
:1998/04/02 15:18:48| comm_select: FD 46 ready for reading
:1998/04/02 15:18:48| ipcache_dnsHandleRead: Result from DNS ID 2 (100
:bytes)
:1998/04/02 15:18:48| ipcache_dnsHandleRead: Incomplete reply
:other processing occurs...
:1998/04/02 15:18:48| comm_select: FD 46 ready for reading
:1998/04/02 15:18:48| ipcache_dnsHandleRead: Result from DNS ID 2 (9
:bytes)
:1998/04/02 15:18:48| ipcache_parsebuffer: parsing:
:$name www.karup.com
:$h_name www.karup.inter.net
:$h_len 4
:$ipcount 2
:38.15.68.128
:38.15.67.128
:$ttl 2348
:$end
:
:Interestingly, it is very common to get only 100 bytes on the first
:read. When two read() calls are required, this adds additional latency
:to the overall request. On our caches running Digital Unix, the median
:dnsserver response time was measured at 0.01 seconds. On our FreeBSD
:cache, however, the median latency was 0.10 seconds.
:
:Here is a simple patch to fix the bug:
:
:===
:RCS file: /home/ncvs/src/sys/kern/uipc_socket.c,v
:retrieving revision 1.40
:retrieving revision 1.41
:diff -p -u -r1.40 -r1.41
:--- src/sys/kern/uipc_socket.c 1998/05/15 20:11:30 1.40
:+++ /home/ncvs/src/sys/kern/uipc_socket.c 1998/07/06 19:27:14
:1.41
:@@ -31,7 +31,7 @@
: * SUCH DAMAGE.
: *
: * @(#)uipc_socket.c 8.3 (Berkeley) 4/15/94
:- * $Id: FAQ.sgml,v 1.75 1999/07/06 16:07:36 wessels Exp $
:+ * $Id: FAQ.sgml,v 1.75 1999/07/06 16:07:36 wessels Exp $
: */
:
: #include
:@@ -491,6 +491,7 @@ restart:
:mlen = MCLBYTES;
:len = min(min(mlen, resid), space);
:} else {
:+ atomic = 1;
: nopages:
:len = min(min(mlen, resid), space);
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
SURVEY: Sound cards that work under FreeBSD
Hello all, I'm working with Nik Clayton to update FAQ 3.15 to give a more comprehensive list of sound cards known to work with FreeBSD. That's why I'm sending out this template to this list. Please take the time to fill it out with information regarding your sound card so that we can compile a better list for posterity. I will do my best to keep the list current as FreeBSD evolves (please send to me or cc: me along with the list--it'll be easier to filter responses than grabbing them out of -hackers-digest :). Please be as specific about makes, models, chipsets, etc. as you can. The author of the first mail received regarding a specific sound card will be listed as the contributor of that information (unless he/she does not want his/her e-mail address listed :). Please note also that I would like information about sound cards that do NOT work (as of yet) under FreeBSD if anyone has experience with them. Hopefully, this will go well and we will be able to branch out into other pieces of supported/non-supported hardware in the future. Thank you. Survey: --- 1) The sound card make and model/chipset. Please be as specific as you can with board rev numbers if possible. Please include wether the card is ISA or PCI. 2) FreeBSD version(s) it was tested with. List *all* versions of FreeBSD for which you can verify that the sound card does/doesn't work (don't include -BETA or -SNAP releases but dates on -STABLE and -CURRENT branches are welcome). 3) Appropriate lines from your kernel config file / PNP setup. i.e. what did you have to do to get this card working? Did you need patches not committed to a particular branch (if so URLs would be welcome)? Do you use OSS drivers instead? 4) Sample dmesg output for properly configured device. Show the world what boot messages relate to the device after properly configured. 5) Miscellaneous notes. State anything "not obvious" to the casual FreeBSD user. Good examples might be, "volume is 0 by default, use mixer(1) to adjust at boot time," or "sh MAKEDEV snd1 for the 1st device, not snd0." 6) Is it OK to publish your e-mail address / name as the contributor of this information? You may type in an anti-spam version of your e-mail address below if you would like that option instead. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | John Reynolds CEG, CCE, Next Generation Flows, HLA | | Intel Corporation MS: CH6-210 Phone: 480-554-9092 pgr: 868-6512 | | jreyn...@sedona.ch.intel.com http://www-aec.ch.intel.com/~jreynold/ | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Will FreeBSD ever see native IPv6 ??
According to John Hay: > in their TODO for the past few months, I can't find anything that > indicates that they or anyone else is working on it. They may be, but I assure you they're working on it. Problem is they also have day jobs and some part of integration is complicated by export controls (the NRL code is more advanced IPsec-wise than our japanese friends). -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 4.0-CURRENT #72: Mon Jul 12 08:26:43 CEST 1999 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposal for new syscall to close files
I am not sure I see a need for this syscall... julian On Thu, 22 Jul 1999, Peter Jeremy wrote: > "John W. DeBoskey" wrote: > > I like this approach. I have a number of often spawned daemon > >processes that could benefit from this. > I don't suppose that you have any statistics showing that the > for (i = 3; i < getdtablesize(); i++) close(i); > approach would be too slow? > > > For naming convention considerations, I might suggest 'closeall' > >or 'closefdset' or something similar... at least have 'close' in > >name... :-) > > I'm not really keen on the name either - but I couldn't think of > anything better. `closeall' isn't really descriptive since it doesn't > close all the FDs. `closefdset' suggests (to me, anyway) the opposite > behaviour: ie closing the FDs specified in the passed fd_set, instead > of closing everything else. > > Peter > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
rndcontrol and SMP
rndcontrol doesn't work very well for SMP systems. I have a system here
with IRQs 16 and 18 for Ethernet and SCSI:
fxp0: rev 0x05 int a irq 18 on
pci0.10.0
ahc0: rev 0x00 int a irq 16 on pci0.12.0
and I'd like to use these with rndcontrol. However, the ioctl chokes on
IRQ >= 16. From i386/i386/mem.c:
/*
* XXX the data is 16-bit due to a historical botch, so we use
* magic 16's instead of ICU_LEN and can't support 24 interrupts
* under SMP.
*/
intr = *(int16_t *)data;
if (cmd != MEM_RETURNIRQ && (intr < 0 || intr >= 16))
return (EINVAL);
What is needed to make this support a more sensible number of IRQs?
Also, rndcontrol naturally returns an error message, which could have
been better:
rndcontrol: rndcontrol: Invalid argument
rndcontrol uses warn() with argv[0] as the argument - but warn() is
documented to always print the program name. So it gets doubled. Below
is a patch against 3.2-STABLE to make it slightly more intelligent, so
we get an error message like this instead:
rndcontrol: setting irq 16: Invalid argument
Steinar Haug, Nethelp consulting, sth...@nethelp.no
--
*** rndcontrol.c.orig Mon Oct 13 13:08:47 1997
--- rndcontrol.cThu Jul 22 22:06:52 1999
***
*** 76,82
printf("%s: setting irq %d\n", argv[0],
irq);
result = ioctl(fd, MEM_SETIRQ, (char *)&irq);
if (result == -1) {
! warn("%s", argv[0]);
return (1);
}
break;
--- 76,82
printf("%s: setting irq %d\n", argv[0],
irq);
result = ioctl(fd, MEM_SETIRQ, (char *)&irq);
if (result == -1) {
! warn("setting irq %d", irq);
return (1);
}
break;
***
*** 86,92
printf("%s: clearing irq %d\n",
argv[0], irq);
result = ioctl(fd, MEM_CLEARIRQ, (char *)&irq);
if (result == -1) {
! warn("%s", argv[0]);
return (1);
}
break;
--- 86,92
printf("%s: clearing irq %d\n",
argv[0], irq);
result = ioctl(fd, MEM_CLEARIRQ, (char *)&irq);
if (result == -1) {
! warn("clearing irq %d", irq);
return (1);
}
break;
***
*** 98,104
if (verbose) {
result = ioctl(fd, MEM_RETURNIRQ, (char *)&irq);
if (result == -1) {
! warn("%s", argv[0]);
return (1);
}
printf("%s: interrupts in use:", argv[0]);
--- 98,104
if (verbose) {
result = ioctl(fd, MEM_RETURNIRQ, (char *)&irq);
if (result == -1) {
! warn("");
return (1);
}
printf("%s: interrupts in use:", argv[0]);
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: Will FreeBSD ever see native IPv6 ??
they ARE doing it, but they haven't got the merged TCP stack quite right they are not publically anouncing anything till it works... On Thu, 22 Jul 1999, John Hay wrote: > Are you just teasing or are you serious? > > I searched through their site (again), but except for being mentioned > in their TODO for the past few months, I can't find anything that > indicates that they or anyone else is working on it. They may be, but > it isn't visible anywhere where I have looked. It would be nice if > there was some place to follow their progress, because I'm also one > of the people that would like to see IPv6 integrated into FreeBSD. > > John > -- > John Hay -- john@mikom.csir.co.za > > > > > FreeBSD will have native IPV6 within a matter of weeks at this stage.. > > the code is being readied as we speak. see www.kame.net . 3 sets of > > developers for FreeBSD IPV6 have merged their efforts and the result of > > this should be available by the end of summer (Northern). (which isn't > > far away now..) > > > > On Wed, 21 Jul 1999, David O'Brien wrote: > > > > > So is FreeBSD *EVER* going to see native IPv6 ?? > > > I attended a talk by a group of Intrusion Detection researchers. They > > > were basing their research on FreeBSD because they needed divert > > > sockets and found FreeBSD worked perfectly for this in this respect. > > > However, once they needed IPv6 and IPsec guess what happened??? They > > > moved to Linux and now have such a time investment in their custom kernel > > > hacks FreeBSD will never be an option for them again. > > > > > > NetBSD and OpenBSD get more and more coverage from IPv6/IPsec > > > capabilities every day. FreeBSD has lost considerable ground if we want > > > to be a platform of choice for network and security researchers. > > > > > > Now ever LSOF has IPv6 support for NetBSD and OpenBSD... > > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposal for new syscall to close files
:Hi, : : I like this approach. I have a number of often spawned daemon :processes that could benefit from this. One of the last process :we debugged where we had unwanted open filedescriptors was in :programs invoked by the cvs loginfo script. : : For naming convention considerations, I might suggest 'closeall' :or 'closefdset' or something similar... at least have 'close' in :name... :-) Well, when I weight the benefit of the savings in overhead for a single syscall verses a close() loop, and when I weigh the seriousness of introducing a syscall that would not be portable to other operating systems, and if I also take into account the work required to deal with descriptors after forking a daemon well, I don't think that adding a new syscall would be worth the relatively minor benefit nor do I think the improvement in performance would be noticeable. The benefit isn't great enough to warrent a new syscall in my view. I've written a number of forking daemons, most noteable my web server and my Diablo news transit system. I just don't think the reduced overhead would be noticeable over simply calling close(), and I didn't have any problems keeping track of which file descriptors to close in Diablo (and there could be 100+ descriptors). Keep in mind that after a fork these descriptors have a ref count > 1, meaning that the close() syscall is almost free. If you assume 5uS/close you are still talking quite a bit less then a millisecond to close a hundred descriptors. And that's pretty much the worst case I can think of. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
You can hijack the MAC address after the CAM table (not ARP cache) times out for the switches. However, you can't just listen to their traffic unless you're on a span port (and span ports don't always work correctly). VLANing has a number of goals, of which you are listing only one. Another is to permit any net to appear on any switch within the switch fabric. VLANs are usually used in a form that spans multiple switches, not just using VLANs on a single switch. At an installation I put together in India, we used VLANs to allow us to better use IP addresses in a strange physical layout. When we were building out our New Site Architecture at Cisco in San Jose, we used VLANs to cut down the number of routing components necessary and further to take advantage of Layer 3 short-cutting in a number of spots around the buildings. On Wed, 21 Jul 1999 00:33:31 PDT, Sendmail channeled Matthew Dillon saying: > The switch routes traffic based on its ARP cache. While you cannot > easily monitor another port's traffic, you can take over its MAC address > and steal its traffic. > > Cisco VLANs perform a different function. Remember that a logical ethern et > segment is typically routed by a single network route. For example, > a class C or a subnetted class C. The catalyst allows you to throw > machines into different VLAN buckets which, in addition to the better > security, allows you to assign separate subnets to each bucket. The > switch itself doesn't care, but this can reduce global ARP traffic > significantly. Catalysts can have hundreds of ports stuffed into them. (ex-of Cisco Systems) | Kenton A. Hoover | shib...@marchordie.org | | Private Citizen || | San Francisco, California || |= http://www.shockwave.org/~shibumi | | A non-vegetarian anti-abortionist is a contradiction in terms. | | -- Phyllis Schlafly| To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Squid - a bug in src/sys/kern/uipc_socket.c
This isn't really a bug since this is a TCP connection. TCP makes
no guarentees that atomic writes will show up as atomic reads, and
the squid code shouldn't be making that assumption.
On the otherhand, the proposed fix appears to be an excellent performance
optimization. It is basically only turning 'atomic' on for relatively
small writes, which should be a win for a receiver whether over a
localhost connection or a real network. I can't imagine that it would
cause a performance loss in any other situation -- it might result in
a slightly smaller-then-full-sized TCP packet occassionally in a stream
but that's about it.
I think committing this would be beneficial. Would someone w/ commit
privs care to review and then commit this bit?
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
:Hi,
:
:please don't kill me if it's "well known issue":
:
:I've found that there is a report on Squid site, which
:describes a problem with FreeBSD IPC and includes suggested fix.
:I verified that this suggested fix is not included in 3.2-RELEASE.
:
:I wonder, if it is really a bug, as I cannot find it in PR database.
:
:Could someone please comment on this report/bug/suggested fix
:and if/when the fix could/will be submited?
:
:original URL:
:http://squid.nlanr.net/Squid/FAQ/FAQ-14.html#ss14.2
:
: Thanks in advance,
: Milon
:--
:[EMAIL PROTECTED]
:
:
: bug report and suggested fix -
:mbuf size
:
:We noticed an odd thing with some of Squid's interprocess communication.
:Often, output from the dnsserver processes would NOT be read in one
:chunk. With full debugging, it looks like this:
:
:1998/04/02 15:18:48| comm_select: FD 46 ready for reading
:1998/04/02 15:18:48| ipcache_dnsHandleRead: Result from DNS ID 2 (100
:bytes)
:1998/04/02 15:18:48| ipcache_dnsHandleRead: Incomplete reply
:other processing occurs...
:1998/04/02 15:18:48| comm_select: FD 46 ready for reading
:1998/04/02 15:18:48| ipcache_dnsHandleRead: Result from DNS ID 2 (9
:bytes)
:1998/04/02 15:18:48| ipcache_parsebuffer: parsing:
:$name www.karup.com
:$h_name www.karup.inter.net
:$h_len 4
:$ipcount 2
:38.15.68.128
:38.15.67.128
:$ttl 2348
:$end
:
:Interestingly, it is very common to get only 100 bytes on the first
:read. When two read() calls are required, this adds additional latency
:to the overall request. On our caches running Digital Unix, the median
:dnsserver response time was measured at 0.01 seconds. On our FreeBSD
:cache, however, the median latency was 0.10 seconds.
:
:Here is a simple patch to fix the bug:
:
:===
:RCS file: /home/ncvs/src/sys/kern/uipc_socket.c,v
:retrieving revision 1.40
:retrieving revision 1.41
:diff -p -u -r1.40 -r1.41
:--- src/sys/kern/uipc_socket.c 1998/05/15 20:11:30 1.40
:+++ /home/ncvs/src/sys/kern/uipc_socket.c 1998/07/06 19:27:14
:1.41
:@@ -31,7 +31,7 @@
: * SUCH DAMAGE.
: *
: * @(#)uipc_socket.c 8.3 (Berkeley) 4/15/94
:- * $Id: FAQ.sgml,v 1.75 1999/07/06 16:07:36 wessels Exp $
:+ * $Id: FAQ.sgml,v 1.75 1999/07/06 16:07:36 wessels Exp $
: */
:
: #include
:@@ -491,6 +491,7 @@ restart:
:mlen = MCLBYTES;
:len = min(min(mlen, resid), space);
:} else {
:+ atomic = 1;
: nopages:
:len = min(min(mlen, resid), space);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
SURVEY: Sound cards that work under FreeBSD
Hello all, I'm working with Nik Clayton to update FAQ 3.15 to give a more comprehensive list of sound cards known to work with FreeBSD. That's why I'm sending out this template to this list. Please take the time to fill it out with information regarding your sound card so that we can compile a better list for posterity. I will do my best to keep the list current as FreeBSD evolves (please send to me or cc: me along with the list--it'll be easier to filter responses than grabbing them out of -hackers-digest :). Please be as specific about makes, models, chipsets, etc. as you can. The author of the first mail received regarding a specific sound card will be listed as the contributor of that information (unless he/she does not want his/her e-mail address listed :). Please note also that I would like information about sound cards that do NOT work (as of yet) under FreeBSD if anyone has experience with them. Hopefully, this will go well and we will be able to branch out into other pieces of supported/non-supported hardware in the future. Thank you. Survey: --- 1) The sound card make and model/chipset. Please be as specific as you can with board rev numbers if possible. Please include wether the card is ISA or PCI. 2) FreeBSD version(s) it was tested with. List *all* versions of FreeBSD for which you can verify that the sound card does/doesn't work (don't include -BETA or -SNAP releases but dates on -STABLE and -CURRENT branches are welcome). 3) Appropriate lines from your kernel config file / PNP setup. i.e. what did you have to do to get this card working? Did you need patches not committed to a particular branch (if so URLs would be welcome)? Do you use OSS drivers instead? 4) Sample dmesg output for properly configured device. Show the world what boot messages relate to the device after properly configured. 5) Miscellaneous notes. State anything "not obvious" to the casual FreeBSD user. Good examples might be, "volume is 0 by default, use mixer(1) to adjust at boot time," or "sh MAKEDEV snd1 for the 1st device, not snd0." 6) Is it OK to publish your e-mail address / name as the contributor of this information? You may type in an anti-spam version of your e-mail address below if you would like that option instead. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | John Reynolds CEG, CCE, Next Generation Flows, HLA | | Intel Corporation MS: CH6-210 Phone: 480-554-9092 pgr: 868-6512 | | [EMAIL PROTECTED] http://www-aec.ch.intel.com/~jreynold/ | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposal for new syscall to close files
I am not sure I see a need for this syscall... julian On Thu, 22 Jul 1999, Peter Jeremy wrote: > "John W. DeBoskey" <[EMAIL PROTECTED]> wrote: > > I like this approach. I have a number of often spawned daemon > >processes that could benefit from this. > I don't suppose that you have any statistics showing that the > for (i = 3; i < getdtablesize(); i++) close(i); > approach would be too slow? > > > For naming convention considerations, I might suggest 'closeall' > >or 'closefdset' or something similar... at least have 'close' in > >name... :-) > > I'm not really keen on the name either - but I couldn't think of > anything better. `closeall' isn't really descriptive since it doesn't > close all the FDs. `closefdset' suggests (to me, anyway) the opposite > behaviour: ie closing the FDs specified in the passed fd_set, instead > of closing everything else. > > Peter > > > 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: IDE breakage
My fault I accidentally replaced a PAGE_MASK with a PAGE_SIZE. the resulting bug only changes teh behaviour on unaligned pages which are only possible on the raw device. (e.g. fsck) the Cyrix 5530 we used to test has a bug where we cannot do unalligned transfers by DMA anyhow, so we never hit this bug.. fixed in -current will be fixxed in -stable when I reintroduce the patch... julian On Thu, 22 Jul 1999 sth...@nethelp.no wrote: > > I'm experiencing serious problems with DMA (even normal DMA, not UDMA) > > on recent versions of -STABLE. Here's an excerpt from messages; kernel > > #3 is a recent -STABLE (yesterday's sources), while kernel #2 is > > 3.2-RELEASE. The config file for both is identical. > > I can confirm problems with DMA from IDE disks in -STABLE. The problems > seem to have been introduced in > > $Id: ide_pci.c,v 1.28.2.1 1999/07/20 22:58:20 julian Exp $ > > And the effect for me is that the system stops in singleuser mode, with > a "DMA failure" message. This is on a 440BX/PII-350 system. > > Reverting to 1.28 (from 17. January 1999) fixes the problems. > > Please back out 1.28.2.1, at least in -STABLE. > > Steinar Haug, Nethelp consulting, sth...@nethelp.no > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD: the stealth OS?
On Thu, Jul 22, 1999 at 09:51:38AM -0700, a little birdie told me that Matthew Dillon remarked > > I love the quote by Matthew Fuller at the end: > > "There's a lot of things that Linux is 'better' at, and a > lot of things FreeBSD is 'better' at, and a lot of those > things can easily fluctuate on a daily or weekly basis," > said Fuller, who maintains a Linux vs BSD Web page. > "Thus, any definitive narrow statement that can be made > is usually obsolete before anyone hears it.". > > Perfect! Thank you, my fans! Please leave your monetary contributions in the hat on your way out;> -- Matthew Fuller (MF4839) |fulle...@over-yonder.net Unix Systems Administrator |fulle...@futuresouth.com Specializing in FreeBSD |http://www.over-yonder.net/ FutureSouth Communications |ISPHelp ISP Consulting "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
rndcontrol and SMP
rndcontrol doesn't work very well for SMP systems. I have a system here
with IRQs 16 and 18 for Ethernet and SCSI:
fxp0: rev 0x05 int a irq 18 on pci0.10.0
ahc0: rev 0x00 int a irq 16 on pci0.12.0
and I'd like to use these with rndcontrol. However, the ioctl chokes on
IRQ >= 16. From i386/i386/mem.c:
/*
* XXX the data is 16-bit due to a historical botch, so we use
* magic 16's instead of ICU_LEN and can't support 24 interrupts
* under SMP.
*/
intr = *(int16_t *)data;
if (cmd != MEM_RETURNIRQ && (intr < 0 || intr >= 16))
return (EINVAL);
What is needed to make this support a more sensible number of IRQs?
Also, rndcontrol naturally returns an error message, which could have
been better:
rndcontrol: rndcontrol: Invalid argument
rndcontrol uses warn() with argv[0] as the argument - but warn() is
documented to always print the program name. So it gets doubled. Below
is a patch against 3.2-STABLE to make it slightly more intelligent, so
we get an error message like this instead:
rndcontrol: setting irq 16: Invalid argument
Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
--
*** rndcontrol.c.orig Mon Oct 13 13:08:47 1997
--- rndcontrol.cThu Jul 22 22:06:52 1999
***
*** 76,82
printf("%s: setting irq %d\n", argv[0], irq);
result = ioctl(fd, MEM_SETIRQ, (char *)&irq);
if (result == -1) {
! warn("%s", argv[0]);
return (1);
}
break;
--- 76,82
printf("%s: setting irq %d\n", argv[0], irq);
result = ioctl(fd, MEM_SETIRQ, (char *)&irq);
if (result == -1) {
! warn("setting irq %d", irq);
return (1);
}
break;
***
*** 86,92
printf("%s: clearing irq %d\n", argv[0], irq);
result = ioctl(fd, MEM_CLEARIRQ, (char *)&irq);
if (result == -1) {
! warn("%s", argv[0]);
return (1);
}
break;
--- 86,92
printf("%s: clearing irq %d\n", argv[0], irq);
result = ioctl(fd, MEM_CLEARIRQ, (char *)&irq);
if (result == -1) {
! warn("clearing irq %d", irq);
return (1);
}
break;
***
*** 98,104
if (verbose) {
result = ioctl(fd, MEM_RETURNIRQ, (char *)&irq);
if (result == -1) {
! warn("%s", argv[0]);
return (1);
}
printf("%s: interrupts in use:", argv[0]);
--- 98,104
if (verbose) {
result = ioctl(fd, MEM_RETURNIRQ, (char *)&irq);
if (result == -1) {
! warn("");
return (1);
}
printf("%s: interrupts in use:", argv[0]);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Will FreeBSD ever see native IPv6 ??
they ARE doing it, but they haven't got the merged TCP stack quite right they are not publically anouncing anything till it works... On Thu, 22 Jul 1999, John Hay wrote: > Are you just teasing or are you serious? > > I searched through their site (again), but except for being mentioned > in their TODO for the past few months, I can't find anything that > indicates that they or anyone else is working on it. They may be, but > it isn't visible anywhere where I have looked. It would be nice if > there was some place to follow their progress, because I'm also one > of the people that would like to see IPv6 integrated into FreeBSD. > > John > -- > John Hay -- [EMAIL PROTECTED] > > > > > FreeBSD will have native IPV6 within a matter of weeks at this stage.. > > the code is being readied as we speak. see www.kame.net . 3 sets of > > developers for FreeBSD IPV6 have merged their efforts and the result of > > this should be available by the end of summer (Northern). (which isn't > > far away now..) > > > > On Wed, 21 Jul 1999, David O'Brien wrote: > > > > > So is FreeBSD *EVER* going to see native IPv6 ?? > > > I attended a talk by a group of Intrusion Detection researchers. They > > > were basing their research on FreeBSD because they needed divert > > > sockets and found FreeBSD worked perfectly for this in this respect. > > > However, once they needed IPv6 and IPsec guess what happened??? They > > > moved to Linux and now have such a time investment in their custom kernel > > > hacks FreeBSD will never be an option for them again. > > > > > > NetBSD and OpenBSD get more and more coverage from IPv6/IPsec > > > capabilities every day. FreeBSD has lost considerable ground if we want > > > to be a platform of choice for network and security researchers. > > > > > > Now ever LSOF has IPv6 support for NetBSD and OpenBSD... > > > > > 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
rtprio and fifo's
I know the evils associated with using rtprio, but I have a real real-time application that needs to service data very quickly when it is needed from a piece of hardware. This daemon reads from a special device. The driver's read handler puts it to sleep, and wakes it back up when an interrupt comes in. Other processes communicate with this daemon using fifo's. (They send it packetized commands, and every once in a while through the loop it checks the fifo for data). According to my Stevens book here, fifo and pipe writes are guaranteed to be atomic, as long as the write is less than PIPE_BUF. (which is 512 bytes here). Unless I'm using rtprio, this is true. Apparently I'm somehow stealing execution away from the child processes during their write() in the middle of it. Occasionally, when I should be reading 192 bytes in from the fifo, i'll do one read of 89 bytes, and another of 103. This wasn't hard to code around, I just kept a buffer, and only processed it when I had a complete packet. However, about once every 6-8 hours, the daemon will get stuck in 'sbwait', and no amount of kicking it will make it wake back up. If I don't use rtprio, this doesn't happen, but the process becomes too slow to work. Has anyone run into this before, or does anyone have any suggestions on how I might fix this? I may try SYSV style message queues next, if I"m not able to fix the fifo problem. Kevin To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
You can hijack the MAC address after the CAM table (not ARP cache) times out for the switches. However, you can't just listen to their traffic unless you're on a span port (and span ports don't always work correctly). VLANing has a number of goals, of which you are listing only one. Another is to permit any net to appear on any switch within the switch fabric. VLANs are usually used in a form that spans multiple switches, not just using VLANs on a single switch. At an installation I put together in India, we used VLANs to allow us to better use IP addresses in a strange physical layout. When we were building out our New Site Architecture at Cisco in San Jose, we used VLANs to cut down the number of routing components necessary and further to take advantage of Layer 3 short-cutting in a number of spots around the buildings. On Wed, 21 Jul 1999 00:33:31 PDT, Sendmail channeled Matthew Dillon saying: > The switch routes traffic based on its ARP cache. While you cannot > easily monitor another port's traffic, you can take over its MAC address > and steal its traffic. > > Cisco VLANs perform a different function. Remember that a logical ethern et > segment is typically routed by a single network route. For example, > a class C or a subnetted class C. The catalyst allows you to throw > machines into different VLAN buckets which, in addition to the better > security, allows you to assign separate subnets to each bucket. The > switch itself doesn't care, but this can reduce global ARP traffic > significantly. Catalysts can have hundreds of ports stuffed into them. (ex-of Cisco Systems) | Kenton A. Hoover | [EMAIL PROTECTED] | | Private Citizen || | San Francisco, California || |= http://www.shockwave.org/~shibumi | | A non-vegetarian anti-abortionist is a contradiction in terms. | | -- Phyllis Schlafly| To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IDE breakage
My fault I accidentally replaced a PAGE_MASK with a PAGE_SIZE. the resulting bug only changes teh behaviour on unaligned pages which are only possible on the raw device. (e.g. fsck) the Cyrix 5530 we used to test has a bug where we cannot do unalligned transfers by DMA anyhow, so we never hit this bug.. fixed in -current will be fixxed in -stable when I reintroduce the patch... julian On Thu, 22 Jul 1999 [EMAIL PROTECTED] wrote: > > I'm experiencing serious problems with DMA (even normal DMA, not UDMA) > > on recent versions of -STABLE. Here's an excerpt from messages; kernel > > #3 is a recent -STABLE (yesterday's sources), while kernel #2 is > > 3.2-RELEASE. The config file for both is identical. > > I can confirm problems with DMA from IDE disks in -STABLE. The problems > seem to have been introduced in > > $Id: ide_pci.c,v 1.28.2.1 1999/07/20 22:58:20 julian Exp $ > > And the effect for me is that the system stops in singleuser mode, with > a "DMA failure" message. This is on a 440BX/PII-350 system. > > Reverting to 1.28 (from 17. January 1999) fixes the problems. > > Please back out 1.28.2.1, at least in -STABLE. > > Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] > > > 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: FreeBSD: the stealth OS?
On Thu, Jul 22, 1999 at 09:51:38AM -0700, a little birdie told me that Matthew Dillon remarked > > I love the quote by Matthew Fuller at the end: > > "There's a lot of things that Linux is 'better' at, and a > lot of things FreeBSD is 'better' at, and a lot of those > things can easily fluctuate on a daily or weekly basis," > said Fuller, who maintains a Linux vs BSD Web page. > "Thus, any definitive narrow statement that can be made > is usually obsolete before anyone hears it.". > > Perfect! Thank you, my fans! Please leave your monetary contributions in the hat on your way out;> -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ FutureSouth Communications |ISPHelp ISP Consulting "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Squid - a bug in src/sys/kern/uipc_socket.c
Hi,
please don't kill me if it's "well known issue":
I've found that there is a report on Squid site, which
describes a problem with FreeBSD IPC and includes suggested fix.
I verified that this suggested fix is not included in 3.2-RELEASE.
I wonder, if it is really a bug, as I cannot find it in PR database.
Could someone please comment on this report/bug/suggested fix
and if/when the fix could/will be submited?
original URL:
http://squid.nlanr.net/Squid/FAQ/FAQ-14.html#ss14.2
Thanks in advance,
Milon
--
pape...@pvt.net
bug report and suggested fix -
mbuf size
We noticed an odd thing with some of Squid's interprocess communication.
Often, output from the dnsserver processes would NOT be read in one
chunk. With full debugging, it looks like this:
1998/04/02 15:18:48| comm_select: FD 46 ready for reading
1998/04/02 15:18:48| ipcache_dnsHandleRead: Result from DNS ID 2 (100
bytes)
1998/04/02 15:18:48| ipcache_dnsHandleRead: Incomplete reply
other processing occurs...
1998/04/02 15:18:48| comm_select: FD 46 ready for reading
1998/04/02 15:18:48| ipcache_dnsHandleRead: Result from DNS ID 2 (9
bytes)
1998/04/02 15:18:48| ipcache_parsebuffer: parsing:
$name www.karup.com
$h_name www.karup.inter.net
$h_len 4
$ipcount 2
38.15.68.128
38.15.67.128
$ttl 2348
$end
Interestingly, it is very common to get only 100 bytes on the first
read. When two read() calls are required, this adds additional latency
to the overall request. On our caches running Digital Unix, the median
dnsserver response time was measured at 0.01 seconds. On our FreeBSD
cache, however, the median latency was 0.10 seconds.
Here is a simple patch to fix the bug:
===
RCS file: /home/ncvs/src/sys/kern/uipc_socket.c,v
retrieving revision 1.40
retrieving revision 1.41
diff -p -u -r1.40 -r1.41
--- src/sys/kern/uipc_socket.c 1998/05/15 20:11:30 1.40
+++ /home/ncvs/src/sys/kern/uipc_socket.c 1998/07/06 19:27:14
1.41
@@ -31,7 +31,7 @@
* SUCH DAMAGE.
*
* @(#)uipc_socket.c 8.3 (Berkeley) 4/15/94
- * $Id: FAQ.sgml,v 1.75 1999/07/06 16:07:36 wessels Exp $
+ * $Id: FAQ.sgml,v 1.75 1999/07/06 16:07:36 wessels Exp $
*/
#include
@@ -491,6 +491,7 @@ restart:
mlen = MCLBYTES;
len = min(min(mlen, resid), space);
} else {
+ atomic = 1;
nopages:
len = min(min(mlen, resid), space);
/*
Another technique which may help, but does not fix the bug, is to
increase the kernel's mbuf size. The default is 128 bytes. The MSIZE
symbol is defined in
/usr/include/machine/param.h. However, to change it we added this line
to our kernel configuration file:
options MSIZE="256"
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD: the stealth OS?
Matthew Dillon wrote: > > :Cool with the geeks beecause it's "unknown". > : > :http://www.msnbc.com/news/292376.asp > : > :Len > > I love the quote by Matthew Fuller at the end: > > "There's a lot of things that Linux is 'better' at, and a > lot of things FreeBSD is 'better' at, and a lot of those > things can easily fluctuate on a daily or weekly basis," > said Fuller, who maintains a Linux vs BSD Web page. > "Thus, any definitive narrow statement that can be made > is usually obsolete before anyone hears it.". I guess he didn't manage to get in touch with Terry. We spoke at length on Tuesday; I'm astonished how fast this came out. The writer was a DefCon for the first time; that was the first time HE had heard of BSD, and was relatively astonished to discover what a large and thriving community it is. I'd like to point out a quote from the March Daemon's Advocate at this point: ...the BSD community is just about reaching the size to be noted by the popular computing press, at least in the USA, and that what little they know of us is good. We must strive to keep this positive viewpoint. We're just finally starting to get our OWN press, where WE are the lead item and compared to Linux, rather than the other way around. This is helped by the fact that, as you can see in the MSNBC article, BSD users rarely claim that BSD is the solution to every problem on the planet, but rather just a good tool to solve problems that are commonly encountered. I am dissappointed he didn't include my plug for companies embedding BSD in products, though. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
rtprio and fifo's
I know the evils associated with using rtprio, but I have a real real-time application that needs to service data very quickly when it is needed from a piece of hardware. This daemon reads from a special device. The driver's read handler puts it to sleep, and wakes it back up when an interrupt comes in. Other processes communicate with this daemon using fifo's. (They send it packetized commands, and every once in a while through the loop it checks the fifo for data). According to my Stevens book here, fifo and pipe writes are guaranteed to be atomic, as long as the write is less than PIPE_BUF. (which is 512 bytes here). Unless I'm using rtprio, this is true. Apparently I'm somehow stealing execution away from the child processes during their write() in the middle of it. Occasionally, when I should be reading 192 bytes in from the fifo, i'll do one read of 89 bytes, and another of 103. This wasn't hard to code around, I just kept a buffer, and only processed it when I had a complete packet. However, about once every 6-8 hours, the daemon will get stuck in 'sbwait', and no amount of kicking it will make it wake back up. If I don't use rtprio, this doesn't happen, but the process becomes too slow to work. Has anyone run into this before, or does anyone have any suggestions on how I might fix this? I may try SYSV style message queues next, if I"m not able to fix the fifo problem. Kevin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Squid - a bug in src/sys/kern/uipc_socket.c
Hi,
please don't kill me if it's "well known issue":
I've found that there is a report on Squid site, which
describes a problem with FreeBSD IPC and includes suggested fix.
I verified that this suggested fix is not included in 3.2-RELEASE.
I wonder, if it is really a bug, as I cannot find it in PR database.
Could someone please comment on this report/bug/suggested fix
and if/when the fix could/will be submited?
original URL:
http://squid.nlanr.net/Squid/FAQ/FAQ-14.html#ss14.2
Thanks in advance,
Milon
--
[EMAIL PROTECTED]
bug report and suggested fix -
mbuf size
We noticed an odd thing with some of Squid's interprocess communication.
Often, output from the dnsserver processes would NOT be read in one
chunk. With full debugging, it looks like this:
1998/04/02 15:18:48| comm_select: FD 46 ready for reading
1998/04/02 15:18:48| ipcache_dnsHandleRead: Result from DNS ID 2 (100
bytes)
1998/04/02 15:18:48| ipcache_dnsHandleRead: Incomplete reply
other processing occurs...
1998/04/02 15:18:48| comm_select: FD 46 ready for reading
1998/04/02 15:18:48| ipcache_dnsHandleRead: Result from DNS ID 2 (9
bytes)
1998/04/02 15:18:48| ipcache_parsebuffer: parsing:
$name www.karup.com
$h_name www.karup.inter.net
$h_len 4
$ipcount 2
38.15.68.128
38.15.67.128
$ttl 2348
$end
Interestingly, it is very common to get only 100 bytes on the first
read. When two read() calls are required, this adds additional latency
to the overall request. On our caches running Digital Unix, the median
dnsserver response time was measured at 0.01 seconds. On our FreeBSD
cache, however, the median latency was 0.10 seconds.
Here is a simple patch to fix the bug:
===
RCS file: /home/ncvs/src/sys/kern/uipc_socket.c,v
retrieving revision 1.40
retrieving revision 1.41
diff -p -u -r1.40 -r1.41
--- src/sys/kern/uipc_socket.c 1998/05/15 20:11:30 1.40
+++ /home/ncvs/src/sys/kern/uipc_socket.c 1998/07/06 19:27:14
1.41
@@ -31,7 +31,7 @@
* SUCH DAMAGE.
*
* @(#)uipc_socket.c 8.3 (Berkeley) 4/15/94
- * $Id: FAQ.sgml,v 1.75 1999/07/06 16:07:36 wessels Exp $
+ * $Id: FAQ.sgml,v 1.75 1999/07/06 16:07:36 wessels Exp $
*/
#include
@@ -491,6 +491,7 @@ restart:
mlen = MCLBYTES;
len = min(min(mlen, resid), space);
} else {
+ atomic = 1;
nopages:
len = min(min(mlen, resid), space);
/*
Another technique which may help, but does not fix the bug, is to
increase the kernel's mbuf size. The default is 128 bytes. The MSIZE
symbol is defined in
/usr/include/machine/param.h. However, to change it we added this line
to our kernel configuration file:
options MSIZE="256"
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD: the stealth OS?
Matthew Dillon wrote: > > :Cool with the geeks beecause it's "unknown". > : > :http://www.msnbc.com/news/292376.asp > : > :Len > > I love the quote by Matthew Fuller at the end: > > "There's a lot of things that Linux is 'better' at, and a > lot of things FreeBSD is 'better' at, and a lot of those > things can easily fluctuate on a daily or weekly basis," > said Fuller, who maintains a Linux vs BSD Web page. > "Thus, any definitive narrow statement that can be made > is usually obsolete before anyone hears it.". I guess he didn't manage to get in touch with Terry. We spoke at length on Tuesday; I'm astonished how fast this came out. The writer was a DefCon for the first time; that was the first time HE had heard of BSD, and was relatively astonished to discover what a large and thriving community it is. I'd like to point out a quote from the March Daemon's Advocate at this point: ...the BSD community is just about reaching the size to be noted by the popular computing press, at least in the USA, and that what little they know of us is good. We must strive to keep this positive viewpoint. We're just finally starting to get our OWN press, where WE are the lead item and compared to Linux, rather than the other way around. This is helped by the fact that, as you can see in the MSNBC article, BSD users rarely claim that BSD is the solution to every problem on the planet, but rather just a good tool to solve problems that are commonly encountered. I am dissappointed he didn't include my plug for companies embedding BSD in products, though. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: 1373 sound chip
On Thu, 22 Jul 1999, Brian McGroarty wrote: > There's a patch for the 1371 floating around that seems to work for the 1373 > as well. > > Search the archive of FreeBSD-questions for "1371". > > Last I saw, the search page was still confused - you need to put "1371" in > the web search field at the top, but still click the mailing list search > button down below. Found it and applied the patch. Still no go. The 1373 is IDing as a 1371 from BIOS, but FreeBSD doesn't see it at all. Looking at the other messages, I see some folks using 'device pcm0 at nexus?' but they're also running -current. I tried that under 3.2 and after it told me that pcm0 is only good with ISA it seg-faulted and blew core. There was also mention of another patch from Joachim Kuebart for PCI, but no mention where to find it. Vince. > > > > -Original Message- > From: Vince Vielhaber [mailto:v...@michvhf.com] > Sent: Wednesday, July 21, 1999 6:54 PM > To: Brian McGroarty; freebsd-hardware; hackers > Subject: 1373 sound chip > > I sent this to multimedia about a week ago and didn't get a response > so I'm trying it here [hackers & hardware] (with minor mods): > > > I'm setting up a new machine that has onboard sound in the form of an > ES1373 Creative (Ensoniq, probably). Visual config shows an unknown > device as ES0 and pcm0 doesn't find anything (tried various forms in > the kernel config for that one, the last one was/is: > > device pcm0 > > Is there any driver for this chip? Under windows it uses the SoundBlaster > AudioPCI 64V driver. So far I haven't found any specs on Creative's or > Ensoniq's website. Can someone shed some light on possibly adapting the > pcm driver to this chip (like how to ID, etc.) ? > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > -- == Vince Vielhaber -- KA8CSH email: v...@michvhf.com flame-mail: /dev/null # includeTEAM-OS2 Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Anyone know how to dim and SGI flat panel?
: :XFree86 has an i2c driver in it for talking to monitors so it sounds as if :it should see it. : :-- :Doug RabsonMail: d...@nlsystems.com :Nonlinear Systems Ltd. Phone: +44 181 442 9037 : :... : :That is how I believe that DMPS communications are transported to the :display. Unfortunately, the DPMS specification is a VESA-proprietary :document so you will have to either join the XFree86 project or sponsor :FreeBSD as a VESA member (that would be nice 8). : :-- :\\ The mind's the standard \\ Mike Smith Ahhh. Interesting. Ah, the XFree ftp finished. Hmm. the DPMS stuff looks promising but I don't see an I128 port yet. Shoot. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Filesystem question...
On Thu, 22 Jul 1999, Tiny Non Cats wrote: > On Thu, Jul 22, 1999 at 10:06:04AM -0400 David E. Cross said: > > Since I am planning on writing userfs in order to impliment 'nsd' (and > > > This may be completely useless, because I've not been following what you want > to do with 'nsd', but you may find > >http://www.cs.columbia.edu/~ezk/research/security/index.html > > interesting. It's a description of 'WrapFS', written by Erik Zadok. It's a > stackable filesystem template written as a kernel module, and can be extended > to > do all sorts of stuff with relative ease, apparently. Cool. It's amazing what pops up on these lists sometimes! *sigh* If only I had some free time before starting my PhD :-( Kris To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: [FreeBSD-net-jp 1746] [FYI] Adaptec AIC-6915 "Starfire" ethernet controller driver and plus question compaq presario dec et
[[ Warning, you'll need something which can display Kanji to be able to read what I've written. I'm using mule and netscape. I've tried to make the non-Japanese parts separate enough that if you only understand English and have only english viewing programs, you can safely ignore the strange sequences of characters resembling TECO progragms and/or line noise. ]] In message <199907211400.kaa00...@skynet.ctr.columbia.edu> Bill Paul writes: : Sorry, but I'm just a dumb american: I can't read this. $B?=$7Lu$4$6$$$^$9!#;d$OJF9q?M$G$9!#FI$_$^$;$s!#(B (which translates, if I've gotten the Japanese correct, as "I'm very sorry. I'm an american. I cannot read this.") >$B%3%s%Q%C%/!!(BPRESARIO$B!!(B2274$B!!$K(BFreeBSD3.2$B%$%s%9%H!<%k$7$?$N$G$9$,!"(B > NIC$B!'!!(BDEC 21143-based > $B$H%S%G%*%+!<%I!'(bsis5598$...@_dj$,$&$^$/$$$-$^$;$s!"8=:_(B >$BF0$+$7$F$k(B >$BJ}$,$$$i$7$?$i65$($F$/$...@$5$$!#(B Using Netscape and http://www.dgs.monash.edu.au/cgi-bin/cgiwrap/jwb/wwwjdic?9T (and my little knowledge of Japanese grammar) I believe that this says something along the lines of: Compaq PRESARIO 2274 with FreeBSD 3.2 installed, but NIC: DEC 21143-based and Video Card: SiS5598 which won't [attach]. In the current [system], can you please instruct me how [to make it work]. The text in [] is guessed based on context, I didn't look up the words in hiragana that I didn't already know, or for which the literal translation didn't make sense. Warner To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Filesystem question...
On Fri, 23 Jul 1999, Kris Kennaway wrote: > Well, if you're running it as a kernel module then obviously you need root > permissions to load it. If it's running as a userland process, then > there's no reason why you can't run it as a user. mount presumably > wouldn't care as long as you had access rights to the underlying objects > (mountpoint + stacking layer process). well, you'll have to tell me more. (i have to get my freebsd source tree back :-) ) Are you saying that as an ordinary user I can mount something on top of /tmp, for example? Is the suser() check still in the mount system call? ron To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Looking for (commercial?) bandwith on NetBSD/FreeBSD machines
I'm involved in a linguistic analysis project which requires reasonable quantities of bandwidth. Due to duopolistic price-fixing, and volume-charing obtaining this bandwith in Australia is a very expensive proposition indeed (US$0.13/Mb!). I'm trying to find a co-hosting (or equivalent) solution, preferably on NetBSD or FreeBSD machines, although this is not essential and I could always provide the machine. Bandwidth usage would be about 4-10Gb/day incoming during the next few months. I also have sizeable disk requirements, which could be forfilled by 2-4x 17GB ATA/IDE -- unfortunately the equivalent in scsi is a little out of my budget. Suggestions? To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Filesystem question...
On Thu, 22 Jul 1999, Ronald G. Minnich wrote: > what if you're not root, and you want to add your own file system to your > file system name space? It seems a lot of these systems assume root > access, which seems unrealistic to me. Well, if you're running it as a kernel module then obviously you need root permissions to load it. If it's running as a userland process, then there's no reason why you can't run it as a user. mount presumably wouldn't care as long as you had access rights to the underlying objects (mountpoint + stacking layer process). Kris To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD: the stealth OS?
:Cool with the geeks beecause it's "unknown". : :http://www.msnbc.com/news/292376.asp : :Len I love the quote by Matthew Fuller at the end: "There's a lot of things that Linux is 'better' at, and a lot of things FreeBSD is 'better' at, and a lot of those things can easily fluctuate on a daily or weekly basis," said Fuller, who maintains a Linux vs BSD Web page. "Thus, any definitive narrow statement that can be made is usually obsolete before anyone hears it.". Perfect! -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Filesystem question...
what if you're not root, and you want to add your own file system to your file system name space? It seems a lot of these systems assume root access, which seems unrealistic to me. ron To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Update on Adaptec AIC-6915 "starfire" driver
I haven't received any feedback yet on the Adaptec "Starfire" driver, however I made a few updates that people should know about: - I created a version of the driver for FreeBSD 2.2.x. You can find it at http://www.freebsd.org/~wpaul/Adaptec/2.2. Note: while I have verified that this code compiles, I have not been able to test it. There should not be any problems, but as always, Murphy's Law applies. - I found a bug today which is that sf_stats_update() required splimp() protection. I use the indirect register access method which is done in two stages: first you set the indirect address register to the register offset that you want to play with, then you access it via the indirect data register. However sf_stats_update() was interruptible which means that it was possible for the interrupt handler to run in between the first and second stages, which caused the stats updater to modify incorrect register locations. This bug would manifest itself in the form of watchdog timeouts and the 'collisions' counter sometimes reporting wildly incorrect values. I corrected this problem and updated the driver sources for each FreeBSD version (including 2.2.x) and recompiled the KLD module for FreeBSD 4.0-current. - The pre-compiled KLD module for FreeBSD 4.0-current now includes BPF support, since I have been told that there stubs that should allow BPF-enabled drivers to work even if BPF support isn't compiled into the kernel. - I added a README at http://www.freebsd.org/~wpaul/Adaptec which explains how to install the driver on FreeBSD 2.2.x, 3.x and 4.0. Also, a quick note about the Adaptec cards. I said previously that the Duralink adapters were Adaptec's replacement for their older DEC tulip-based cards. Adaptec still sells multiport adapters based on the 21x4x chip, however I believe they use the 21143 now since Intel discontinued production of the 21140 and supplies are drying up. It is possible that Adaptec may stop production on the older cards though now that they have their own high performance chipset. The Duralink cards may also be preferable in some cases since they are 64-bit PCI devices. Anyway: I would appreciate it if people could test the driver and get back to me with some feedback. I hope to merge this into the -current branch soon. -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@skynet.ctr.columbia.edu | Columbia University, New York City = "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" = To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
RE: 1373 sound chip
On Thu, 22 Jul 1999, Brian McGroarty wrote: > There's a patch for the 1371 floating around that seems to work for the 1373 > as well. > > Search the archive of FreeBSD-questions for "1371". > > Last I saw, the search page was still confused - you need to put "1371" in > the web search field at the top, but still click the mailing list search > button down below. Found it and applied the patch. Still no go. The 1373 is IDing as a 1371 from BIOS, but FreeBSD doesn't see it at all. Looking at the other messages, I see some folks using 'device pcm0 at nexus?' but they're also running -current. I tried that under 3.2 and after it told me that pcm0 is only good with ISA it seg-faulted and blew core. There was also mention of another patch from Joachim Kuebart for PCI, but no mention where to find it. Vince. > > > > -Original Message- > From: Vince Vielhaber [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, July 21, 1999 6:54 PM > To: Brian McGroarty; freebsd-hardware; hackers > Subject: 1373 sound chip > > I sent this to multimedia about a week ago and didn't get a response > so I'm trying it here [hackers & hardware] (with minor mods): > > > I'm setting up a new machine that has onboard sound in the form of an > ES1373 Creative (Ensoniq, probably). Visual config shows an unknown > device as ES0 and pcm0 doesn't find anything (tried various forms in > the kernel config for that one, the last one was/is: > > device pcm0 > > Is there any driver for this chip? Under windows it uses the SoundBlaster > AudioPCI 64V driver. So far I haven't found any specs on Creative's or > Ensoniq's website. Can someone shed some light on possibly adapting the > pcm driver to this chip (like how to ID, etc.) ? > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > -- == Vince Vielhaber -- KA8CSH email: [EMAIL PROTECTED] flame-mail: /dev/null # includeTEAM-OS2 Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anyone know how to dim and SGI flat panel?
: :XFree86 has an i2c driver in it for talking to monitors so it sounds as if :it should see it. : :-- :Doug RabsonMail: [EMAIL PROTECTED] :Nonlinear Systems Ltd. Phone: +44 181 442 9037 : :... : :That is how I believe that DMPS communications are transported to the :display. Unfortunately, the DPMS specification is a VESA-proprietary :document so you will have to either join the XFree86 project or sponsor :FreeBSD as a VESA member (that would be nice 8). : :-- :\\ The mind's the standard \\ Mike Smith Ahhh. Interesting. Ah, the XFree ftp finished. Hmm. the DPMS stuff looks promising but I don't see an I128 port yet. Shoot. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Filesystem question...
On Thu, 22 Jul 1999, Tiny Non Cats wrote: > On Thu, Jul 22, 1999 at 10:06:04AM -0400 David E. Cross said: > > Since I am planning on writing userfs in order to impliment 'nsd' (and > > > This may be completely useless, because I've not been following what you want > to do with 'nsd', but you may find > >http://www.cs.columbia.edu/~ezk/research/security/index.html > > interesting. It's a description of 'WrapFS', written by Erik Zadok. It's a > stackable filesystem template written as a kernel module, and can be extended to > do all sorts of stuff with relative ease, apparently. Cool. It's amazing what pops up on these lists sometimes! *sigh* If only I had some free time before starting my PhD :-( Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [FreeBSD-net-jp 1746] [FYI] Adaptec AIC-6915 "Starfire" ethernet controller driver and plus question compaq presario dec et
[[ Warning, you'll need something which can display Kanji to be able to read what I've written. I'm using mule and netscape. I've tried to make the non-Japanese parts separate enough that if you only understand English and have only english viewing programs, you can safely ignore the strange sequences of characters resembling TECO progragms and/or line noise. ]] In message <[EMAIL PROTECTED]> Bill Paul writes: : Sorry, but I'm just a dumb american: I can't read this. $B?=$7Lu$4$6$$$^$9!#;d$OJF9q?M$G$9!#FI$_$^$;$s!#(B (which translates, if I've gotten the Japanese correct, as "I'm very sorry. I'm an american. I cannot read this.") >$B%3%s%Q%C%/!!(BPRESARIO$B!!(B2274$B!!$K(BFreeBSD3.2$B%$%s%9%H!<%k$7$?$N$G$9$,!"(B > NIC$B!'!!(BDEC 21143-based >$B$H%S%G%*%+!<%I!'(BSiS5598$B$N@_Dj$,$&$^$/$$$-$^$;$s!"8=:_(B >$BF0$+$7$F$k(B >$BJ}$,$$$i$7$?$i65$($F$/$@$5$$!#(B Using Netscape and http://www.dgs.monash.edu.au/cgi-bin/cgiwrap/jwb/wwwjdic?9T (and my little knowledge of Japanese grammar) I believe that this says something along the lines of: Compaq PRESARIO 2274 with FreeBSD 3.2 installed, but NIC: DEC 21143-based and Video Card: SiS5598 which won't [attach]. In the current [system], can you please instruct me how [to make it work]. The text in [] is guessed based on context, I didn't look up the words in hiragana that I didn't already know, or for which the literal translation didn't make sense. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU'
On 22-Jul-99 Jorge Biquez wrote: > I hope this helps. > I'm running version 3.1 on ASUS Pentium III double processor. Just a Rocket! > No problems at all on the installation all the SCSI ports were > recognized my entire machine cost me 2000 USD...similar one of a famous > brabd...at least 6,000 > > JB the ASUS boards PII/350M 128M, 3c905B, dual SCSI (1 on board + 1 Adaptec 2940B), Seagate ST39173W, Toshiba CD on IDE (had a spare HP DAT-24 tape drive) $3400 compared to a certain BigBlue box at $8000+ monitor FreeBSD 2.2.8, MySQL 3.22. been running without a hiccup since Feb. Regards, --- Don Read dr...@calcasieu.com EDP Manager dr...@texas.net Calcasieu Lumber Co. Austin TX -- But I'm in good company, sendmail has kicked a great many butts in the past To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Filesystem question...
On Fri, 23 Jul 1999, Kris Kennaway wrote: > Well, if you're running it as a kernel module then obviously you need root > permissions to load it. If it's running as a userland process, then > there's no reason why you can't run it as a user. mount presumably > wouldn't care as long as you had access rights to the underlying objects > (mountpoint + stacking layer process). well, you'll have to tell me more. (i have to get my freebsd source tree back :-) ) Are you saying that as an ordinary user I can mount something on top of /tmp, for example? Is the suser() check still in the mount system call? ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Looking for (commercial?) bandwith on NetBSD/FreeBSD machines
I'm involved in a linguistic analysis project which requires reasonable quantities of bandwidth. Due to duopolistic price-fixing, and volume-charing obtaining this bandwith in Australia is a very expensive proposition indeed (US$0.13/Mb!). I'm trying to find a co-hosting (or equivalent) solution, preferably on NetBSD or FreeBSD machines, although this is not essential and I could always provide the machine. Bandwidth usage would be about 4-10Gb/day incoming during the next few months. I also have sizeable disk requirements, which could be forfilled by 2-4x 17GB ATA/IDE -- unfortunately the equivalent in scsi is a little out of my budget. Suggestions? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Filesystem question...
On Thu, 22 Jul 1999, Ronald G. Minnich wrote: > what if you're not root, and you want to add your own file system to your > file system name space? It seems a lot of these systems assume root > access, which seems unrealistic to me. Well, if you're running it as a kernel module then obviously you need root permissions to load it. If it's running as a userland process, then there's no reason why you can't run it as a user. mount presumably wouldn't care as long as you had access rights to the underlying objects (mountpoint + stacking layer process). Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD: the stealth OS?
:Cool with the geeks beecause it's "unknown". : :http://www.msnbc.com/news/292376.asp : :Len I love the quote by Matthew Fuller at the end: "There's a lot of things that Linux is 'better' at, and a lot of things FreeBSD is 'better' at, and a lot of those things can easily fluctuate on a daily or weekly basis," said Fuller, who maintains a Linux vs BSD Web page. "Thus, any definitive narrow statement that can be made is usually obsolete before anyone hears it.". Perfect! -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Filesystem question...
what if you're not root, and you want to add your own file system to your file system name space? It seems a lot of these systems assume root access, which seems unrealistic to me. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Filesystem question...
One last thing: if you're writing userfs you might want to look at www.inter-mezzo.org ron To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Update on Adaptec AIC-6915 "starfire" driver
I haven't received any feedback yet on the Adaptec "Starfire" driver, however I made a few updates that people should know about: - I created a version of the driver for FreeBSD 2.2.x. You can find it at http://www.freebsd.org/~wpaul/Adaptec/2.2. Note: while I have verified that this code compiles, I have not been able to test it. There should not be any problems, but as always, Murphy's Law applies. - I found a bug today which is that sf_stats_update() required splimp() protection. I use the indirect register access method which is done in two stages: first you set the indirect address register to the register offset that you want to play with, then you access it via the indirect data register. However sf_stats_update() was interruptible which means that it was possible for the interrupt handler to run in between the first and second stages, which caused the stats updater to modify incorrect register locations. This bug would manifest itself in the form of watchdog timeouts and the 'collisions' counter sometimes reporting wildly incorrect values. I corrected this problem and updated the driver sources for each FreeBSD version (including 2.2.x) and recompiled the KLD module for FreeBSD 4.0-current. - The pre-compiled KLD module for FreeBSD 4.0-current now includes BPF support, since I have been told that there stubs that should allow BPF-enabled drivers to work even if BPF support isn't compiled into the kernel. - I added a README at http://www.freebsd.org/~wpaul/Adaptec which explains how to install the driver on FreeBSD 2.2.x, 3.x and 4.0. Also, a quick note about the Adaptec cards. I said previously that the Duralink adapters were Adaptec's replacement for their older DEC tulip-based cards. Adaptec still sells multiport adapters based on the 21x4x chip, however I believe they use the 21143 now since Intel discontinued production of the 21140 and supplies are drying up. It is possible that Adaptec may stop production on the older cards though now that they have their own high performance chipset. The Duralink cards may also be preferable in some cases since they are 64-bit PCI devices. Anyway: I would appreciate it if people could test the driver and get back to me with some feedback. I hope to merge this into the -current branch soon. -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: [EMAIL PROTECTED] | Center for Telecommunications Research Home: [EMAIL PROTECTED] | Columbia University, New York City = "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM & LDAP in FreeBSD, and userfs too.
On Thu, 22 Jul 1999, Dominic Mitchell wrote: > This is starting to get icky. This is also where the earlier idea of a > userspace filesystem would probably fare better, in terms of both > performance and simplicity. Maybe I don't get how this userspace filesystem is going to be set out (for the case of the nss stuff), but I don't see this. Kris -- The Feynman Problem-Solving Algorithm: (1) Write down the problem (2) Think real hard (3) Write down the answer -- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
On Wed, 21 Jul 1999, Vincent Poy wrote: > Greetings everyone, > > What are the current good motherboards for FreeBSD for the pentium > II and III? I know on the Pentium, it was the ASUS board but for the > PII/PIII, is the Abit the better board? Also, I was wondering what is the > fastest Celeron chip that can be overclocked to run at 100Mhz FSB? Does > it matter if it's Slot 1 or PPGA based? Thanks. I know a lot of people like the ASUS P2B boards, but I've noticed a tendency for the systems to reset occasionally when plugging in a keyboard. I've seen this with both FreeBSD and NT, so I'm considering it a property of the board. I've had great results with the Tyan 1836DLUAN/Thunder 100's. I've got several boxes with 1GB of RAM and dual 450's humming along. For comparison one system with less memory and a SuperMicro board but identical system software has had a couple of wierd spontaneous reboots over the last few months. Adrian -- [ adr...@ubergeeks.com -- Ubergeeks Consulting -- http://www.ubergeeks.com/ ] To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: > arpresolve: can't allocate llinfo for 255.255.255.0rt
On Thu, Jul 22, 1999 at 09:30:28AM -0400, Jung, Michael wrote: > I started getting these messages in the daily security output. > > > arpresolve: can't allocate llinfo for 255.255.255.0rt > > arpresolve: can't allocate llinfo for 255.255.255.0rt > > arpresolve: can't allocate llinfo for 255.255.255.0rt > > arpresolve: can't allocate llinfo for 255.255.255.0rt > > arpresolve: can't allocate llinfo for 255.255.255.0rt > > arpresolve: can't allocate llinfo for 255.255.255.0rt > > arpresolve: can't allocate llinfo for 255.255.255.0rt I get those after a long run of nmap on our /16 network. At this point, I just kill nmap and the problem goes away. I didn't bother looking into the routing table though. Maybe it's time to see what the PC support monkeys have plugged into my network again. :-) -- Dom Mitchell -- Palmer & Harvey McLane -- Unix Systems Administrator In Mountain View did Larry Wall Sedately launch a quiet plea: That DOS, the ancient system, shall On boxes pleasureless to all Run Perl though lack they C. -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU'
On 22-Jul-99 Jorge Biquez wrote: > I hope this helps. > I'm running version 3.1 on ASUS Pentium III double processor. Just a Rocket! > No problems at all on the installation all the SCSI ports were > recognized my entire machine cost me 2000 USD...similar one of a famous > brabd...at least 6,000 > > JB the ASUS boards PII/350M 128M, 3c905B, dual SCSI (1 on board + 1 Adaptec 2940B), Seagate ST39173W, Toshiba CD on IDE (had a spare HP DAT-24 tape drive) $3400 compared to a certain BigBlue box at $8000+ monitor FreeBSD 2.2.8, MySQL 3.22. been running without a hiccup since Feb. Regards, --- Don Read [EMAIL PROTECTED] EDP Manager [EMAIL PROTECTED] Calcasieu Lumber Co. Austin TX -- But I'm in good company, sendmail has kicked a great many butts in the past To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Filesystem question...
One last thing: if you're writing userfs you might want to look at www.inter-mezzo.org ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [FreeBSD-net-jp 1746] [FYI] Adaptec AIC-6915 "Starfire" ethernet controller driver and plus question compaq presario dec et and * trancelate for english
heloo all - Original Message - From: Bill Paul To: morita Cc: Sent: Wednesday, July 21, 1999 11:00 PM Subject: Re: [FreeBSD-net-jp 1746] [FYI] Adaptec AIC-6915 "Starfire" ethernet controller driver and plus question compaq presario dec et > Of all the gin joints in all the towns in all the world, morita had to > walk into mine and say: > > > 森田です。 > > > > > > These are Adaptec's replacements for its older DEC 21x4x-based multiport > > japanses 1 .> > このドライバーは無くなるのでしょうか？->DEC 21x4x-based english 1 . > > no more supllyed ->DEC 21x4x-based is it true? japanses 1=english 1 . > Sorry, but I'm just a dumb american: I can't read this. > > > > line of adapters. All cards support 10/100 speeds in full or half duplex. > > > The multiport cards consist of multiple AIC-6915 chips linkec via a PCI > > > to PCI bridge. Currently I have only tested the ANA-62022 dual port card, > > > however all of them should work equally well. The 64-bit cards will work > > > in a 32-bit slot on most newer machines. > > > > > english 2 > > コンパック PRESARIO 2274 にFreeBSD3.2インストールし たのですが、 japanese 2 he install of? FreeBSD3.2 to conpaq PRESARIO 2274 english 3 > > > NIC： DEC 21143-based とビデオカード：SiS5598の設定 がうまくいきません、現在 japanese 3 NIC： DEC 21143-based video chip is SiS5598 is not good condition now > > 動かしてる > > 方がいらしたら教えてください。 english 4 > tell him how install > > I can't read this either. :( > > -Bill > > -- > = > -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu > Work: wp...@ctr.columbia.edu | Center for Telecommunications Research > Home: wp...@skynet.ctr.columbia.edu | Columbia University, New York City > = > "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" > = > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: [FreeBSD-users-jp 44304] de0 is availa ble or not? (re:) using nic de0 oｆ peaple much in ja pan
ji です。 > > 高橋です。 takahashi san > > > 動かなかった環境 no move envilonment > ・10baseのバカHUB > ・接続相手はNE2000互換の10baseなNIC > ・ifconfigでmediaを指定しても "de0: link down: cable problem?" がで す。 > good move envilonment > 動いた環境 > ・10/100のデュアルスピードHUB(Autonegotiation有) > ・接続相手はVIA VT86C100Aチップを使ったNIC > ・ifconfigでmediaは特に指定せず question 10/100のデュアルスピードHUB(Autonegotiation有) でなく、１０の場合はどうすればいいのでしょうか？ kernel config とか？ それとも, それはいじらずですか？ how config Kernel config? > > どうも動いた環境の Autonegotiation有 がくせ者みたいです。 > 過去のusers-jpやnet-jpなどのメールを21143で検索してもやはり > メディアの指定をすると動いた方が多いようです。 > # 21143のdata sheet昔はDECのWeb siteにあったのになくなってる... > # だれか持ってないかなぁ(ぼそ > > --- > Daisuke Takahashi / $b$7$+$7$F2K$G$9$+!) > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
