Re: 3Com 10/100 Mini PCI Ethernet
> Mike Smith wrote: > > > > I'm looking for docs for the Mini PCI card in the subject, it has the 3Com > > > part/product no. 3CN3AV1556. It is a 10/100 ethernet 56k modem combo card > > > built into an HP laptop. > > > > Have you tried booting FreeBSD on this system yet? If so, does the 'xl' > > driver pick it up? If not, can you send the output of 'pciconf -l', as > > it may just require a new PCI ID in the driver. > > Yes, i first tried the ep driver, then the xl and then the vx by adding the > chip id (0x6055) to the probe routine. > > I think the ep driver (which does some funny things to the eeprom) managed > to overwrite part of the eeprom so that the xl driver failed to recognize > the card. I then tried to add it to the vx driver (at that point i think > i started to know what i did) which failed too, so i wrote a subroutine > to display the eeprom contents which (because i did not understood the > the OP and SubOP command fields before running it) finally erased the > eeprom contents to 0x in all locations (which now prevents the card > from being initialized by the BIOS - has anybody an idea how to revive > such a PCI card ). You would need to write the original EEPROM contents back into the EEPROM, after manually configuring it. Very difficult. > Do i understand you right in that you would do a fresh start with this > card using the xl driver ? I'm a bit concerned about again accidentially > overwriting the eeprom, its an _expensive_ card ... ;-) That's correct. The xl driver is not likely to trash the eeprom, although I'm quite surprised that the 'ep' driver did. What possessed you to start with an ISA-only driver when the device is so clearly a PCI device? -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
subscribe
Hi I'd like to subscribe to the list, at the address [EMAIL PROTECTED] Thanks Dominic Parry |From DOMINIC CHARLES PARRY | |MAIL : G98P1836 | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Does sio have a maintainer?
Hi folks, Does the sio driver have a maintainer? There are two PR's open that contain patches to provide support for new devices, but I can't find anyone to pin them on. :-) kern/20341 support Cronyx-Omega-PCI serial multiport adapters kern/20410 support high-speed NS16550A, ST16650A and TI16750 Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 3Com 10/100 Mini PCI Ethernet
Mike Smith wrote: > > I think the ep driver (which does some funny things to the eeprom) managed > > to overwrite part of the eeprom so that the xl driver failed to recognize > > the card. I then tried to add it to the vx driver (at that point i think > > i started to know what i did) which failed too, so i wrote a subroutine > > to display the eeprom contents which (because i did not understood the > > the OP and SubOP command fields before running it) finally erased the > > eeprom contents to 0x in all locations (which now prevents the card > > from being initialized by the BIOS - has anybody an idea how to revive > > such a PCI card ). > > You would need to write the original EEPROM contents back into the > EEPROM, after manually configuring it. Very difficult. Am i right assuming that pciconf is the right tool for this (manually configuring) job ? > > Do i understand you right in that you would do a fresh start with this > > card using the xl driver ? I'm a bit concerned about again accidentially > > overwriting the eeprom, its an _expensive_ card ... ;-) > > That's correct. The xl driver is not likely to trash the eeprom, > although I'm quite surprised that the 'ep' driver did. > > What possessed you to start with an ISA-only driver when the device is so > clearly a PCI device? It was the device ID 0x6055 in the ep driver which is identical to the device ID in the Mini PCI version. hellmuth -- Hellmuth Michaelis[EMAIL PROTECTED] Hamburg, Europe We all live in a yellow subroutine, yellow subroutine, yellow subroutine ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vmware changes result in nasty bridging mess
Ok, guys.
See in the attachment fix, you should apply it to prevent current behavior.
On Sun, Aug 06, 2000 at 07:14:59PM -0400, Robert Watson wrote:
> On Thu, 3 Aug 2000, Vladimir N. Silyaev wrote:
>
> > >Bridging on by default may
> > >have nasty side effects for multi-interface machines (especially security
> > >side effects).
> > It's several ways to work around about that:
> > - compile kernel without bridging support.
> > - remove bridge starting code vmware.sh file in rc.d directory.
> > - create special bridge cluster with one real interface and with one emulated
>
> Actually, I was hoping that the vmware port wouldn't interfere with
> existing configurations on the box :-). I compile in the BRIDGE code so
> that I can test/develop with it, not so that ethernet support on the
> notebook can be broken after I install the vmware port, or so that a port
> can arbitrarily turn on bridging of all attached ethernet devices.
>
> > >I haven't read the code (I admit) but I finding the
> > >current behavior both (a) irritating (messages) and (b) worrying
> > >(unpredicted bridging with potential side effects).
> > I don't know I never seen such effect. Could you to do more testing
> > about that.
>
> The behavior with the wi0 ethernet driver seems to be continuous printing
> of the output included in my previous message.
>
> With the ep0 driver, the results are actually much worse -- I'm unable to
> use networking at all while the bridging sysctl is enabled (the default).
> While the sysctl is enabled, dhclient fails for that interface, and any
> attempt to manually configure and use it results in a route not found.
> When I disable the sysctl, networking begins to work on the box.
>
> The following default-installed startup script is really, really scary:
>
> sysctl net.link.ether.bridge_refresh && bridge="_bridge"
> kldload if_tap.ko
> echo -n >/compat/linux/dev/vmnet1
> ifconfig vmnet1 $host_ip netmask $netmask
> if [ _$bridge != _ ]; then
> sysctl -w net.link.ether.bridge_refresh=1
> sysctl -w net.link.ether.bridge=1
> fi
>
> Un-announced, the vmware port enabled bridging between the ethernet
> interfaces on my notebook, generated voluminous output for wi0, and broke
> networking for ep0. This is a security risk, in that it automatically
> enables bridging between previously un-connected LAN segments that may
> have different security properties. This is against POLA in that it
> breaks functionality (networking), bridges packets unto unexpected
> segments (potentially breaking many other things, especially DHCP), etc.
> Previously, use of networking support would create a virtual network
> between the host and the guest OS, but not affect other networking
> functionality.
--
Vladimir
Index: files/vmware.sh
===
RCS file: /home/vns/cvs/vmware/vmware/vmmon-only/freebsd/port/files/vmware.sh,v
retrieving revision 1.5
diff -u -r1.5 vmware.sh
--- files/vmware.sh 2000/07/31 00:54:37 1.5
+++ files/vmware.sh 2000/08/07 03:16:16
@@ -8,6 +8,7 @@
networking=@@NETWORKING@@
host_ip=@@HOST_IP@@
netmask=@@NETMASK@@
+start_bridge=0
[ -x $vmware_dir/bin/vmware ] || exit
@@ -19,17 +20,32 @@
exec >/dev/null
+if [ $networking -eq 1 ]; then
+ if sysctl net.link.ether.bridge_refresh; then
+ if sysctl net.link.ether.bridge|grep 1; then
+ bridge="_bridge_on"
+ start_bridge=0
+ else
+ if [ $start_bridge -eq 1 ]; then
+ bridge="_bridge"
+ else
+ bridge="_bridge_off"
+ fi
+ fi
+ fi
+fi
+
case $1 in
start)
kldload ${vmware_dir}/lib/modules/vmmon_${suffix}.ko
if [ $networking -eq 1 ]; then
- sysctl net.link.ether.bridge_refresh && bridge="_bridge"
kldload if_tap.ko
echo -n >@@LINUX_DIR@@/dev/vmnet1
ifconfig vmnet1 $host_ip netmask $netmask
+ sysctl net.link.ether.bridge
if [ _$bridge != _ ]; then
sysctl -w net.link.ether.bridge_refresh=1
- sysctl -w net.link.ether.bridge=1
+ [ $start_bridge -eq 1 ] && sysctl -w net.link.ether.bridge=1
fi
fi
echo -n " VMware${bridge}" >&2
@@ -40,7 +56,6 @@
if [ $networking -eq 1 ]; then
ifconfig vmnet1 down
ifconfig vmnet1 delete $host_ip
- sysctl net.link.ether.bridge_refresh && bridge="_bridge"
[ _$bridge != _ ] && sysctl -w net.link.ether.bridge_refresh=1
fi
;;
newbus questions
Hi all, there are two recent articles on newbus on daemonnews, and one at people.freebsd.org/~asmodai by jeroen. Does anyone remember seeing any others? I thought for sure i remembered seeing a article explaining the OO design concepts behind newbus, particularly the use of soft_c, the local data, the global data, and methods for a particular device. jm -- --- Jonathon McKitrick -- [EMAIL PROTECTED] Honk if you hate people too. --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Restoring old IPv4 raw socket behavior under 4.1-RELEASE
Hi All: Just upgraded from 4.0-RELEASE to 4.1-RELEASE, and now a custom application of ours that used to do: socket(AF_INET, SOCK_RAW, 4); No longer works with: Protocol not supported opening socket. As far as I can tell, this is because SOCK_RAW sockets now default to IPv6. Is there a SIMPLE way to restore old ipv4 SOCK_RAW socket() behavior, so that I don't need to have any IPv6 routes at all? I tried replacing AF_INET with AF_INET6, but then I got host unreachable from the sendto(), because I don't have IPv6 routes set up. Thanks, Bernie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: dlopen() and friends from a statically-linked binary?
Daniel O'Connor writes:
>
> On 20-Jul-00 Raymond Wiker wrote:
> > Is it possible, at all, to use dlopen etc from a
> > statically-linked executable? My experiments with FreeBSD-4.0 (see
> > below) indicate that it's not possible.
>
> You can't do it from a statically linked binary, however you can
> create a dynamic executable with no external unresolved
> references.. I forget how though :-/
OK... I'll take a look at this. Thanks to everyone who
responded.
>
> > The reason that I'd like this to work is that SBCL (a Common
> > Lisp implementation, see http://sbcl.sourceforge.net) needs the
> > addresses of certain library symbols (e.g, errno) when building the
> > initial lisp image. This seems to require static linking. On the other
> > hand, SBCL is severely handicapped if it cannot subsequently use
> > dlopen() to load foreign code into the running lisp system.
>
> Well, I don't see why it would need static linking for that.. When
> the binary runs the libraries it uses will get loaded, and then it
> can use dlsym() to get the addresses it needs.. (ie what I am
> saying is I don't understand your explanation :)
A running SBCL system includes a runtime substrate written in
C, along with Lisp code compiled into native code or byte-code. The C
runtime calls a top-level function in the Lisp system at startup; this
call does not return until the top-level Lisp function exits. The
top-level Lisp function calls into the C substrate for various
low-level services, including garbage-collecting of Lisp objects.
This implies a circular dependency: the C runtime must have
the address of the top-level Lisp function, while the Lisp code needs
the addresses of various code and data in the C runtime. In SBCL this
is solved in the bootstrapping process, by a function that patches up
the Lisp code with the addresses from the C code. This cannot be done
at startup, as the Lisp object format differs from the conventional
formats (a.out or ELF).
At the moment, my options seem to be:
1) find a way of compiling the C runtime so that there are no
unresolved externals, while still producing a dynamic executable.
2) identify a small set of symbols from libc.so, and
encapsulate them (possibly using dlsym("foo", RTLD_NEXT)?)
3) modify SBCL so that the patchup is done at startup time,
instead of at compilation time.
Of these, 1) is probably the least work, 2) is slightly more
work and inelegant, and 3) is the most work but carries a few other
benefits (notably, it reduces the Lisp -> C dependency).
//Raymond.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Speaking about vmware...
Yes, It appears that there is an occasional glitch with FreeBSD and VMware. I have to record the core.. /m At 04:50 PM 8/6/00 -0700, Matthew Jacob wrote: >Has anyone been having their system just plain lock up running vmware? Mine >has been.. (4.1-stable).. > >-matt > > > > > >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: 3Com 10/100 Mini PCI Ethernet
> Mike Smith wrote: > > > > I think the ep driver (which does some funny things to the eeprom) managed > > > to overwrite part of the eeprom so that the xl driver failed to recognize > > > the card. I then tried to add it to the vx driver (at that point i think > > > i started to know what i did) which failed too, so i wrote a subroutine > > > to display the eeprom contents which (because i did not understood the > > > the OP and SubOP command fields before running it) finally erased the > > > eeprom contents to 0x in all locations (which now prevents the card > > > from being initialized by the BIOS - has anybody an idea how to revive > > > such a PCI card ). > > > > You would need to write the original EEPROM contents back into the > > EEPROM, after manually configuring it. Very difficult. > > Am i right assuming that pciconf is the right tool for this (manually > configuring) job ? No, you are wrong. The only way to write to the EEPROM (that I know of anyway) is via the usual EEPROM control registers in the card's I/O space, which won't be mapped if the card is so fubared that the BIOS won't initialize it. > > > Do i understand you right in that you would do a fresh start with this > > > card using the xl driver ? I'm a bit concerned about again accidentially > > > overwriting the eeprom, its an _expensive_ card ... ;-) Then you should have been more careful with it. > > That's correct. The xl driver is not likely to trash the eeprom, > > although I'm quite surprised that the 'ep' driver did. > > > > What possessed you to start with an ISA-only driver when the device is so > > clearly a PCI device? > > It was the device ID 0x6055 in the ep driver which is identical to the > device ID in the Mini PCI version. I'm sorry, but after reading this thread, I'm having a hard time coming up with an explanation for this nonsense which doesn't involve you being a dumbass. The device ID in question is in if_ep_pccard.c which is for PCMCIA devices only! Not PCI! There is no way that the ep driver will probe a PCI device unless you go to some lengths to twist its arm! Why you resorted to this arm-twisting instead of the blazingly obvious action of trying an actual PCI driver is beyond me. (_How_ you even managed to twist its arm is also beyond me. Obviously you decided not to tell us exactly what you did for fear of being found out. Too late.) This is not one of those "it's nobody's fault" situations. You did not make an innocent mistake: you screwed up. In front of god and everything. You ignored all of the signs, portents, and the dude with the spooky black robe and scythe standing over your shoulder. And then you tried to cover it up. Now, get out a piece of paper, write "I damaged this card because I'm a dumbass" on it, stick it to the card, then take it back to where you got it and try to get it replaced. Alternatively, tell us where you got it so I can order one and try to get it supported properly instead of having my blood pressure driven off the scale by yet another tale of foot-shooting idiocy. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
CVS question
Consider this source file: http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/xntpd/lib/Attic/ranny.c Question: what version should this command checkout? $ cvs co -D 'January 18, 1999 0:00' freebsd/src/usr.sbin/xntpd/lib/ranny.c Perhaps version 1.1.1.2 would be correct, but instead you get 1.1. It seems CVS is being inconsistent: - If you had done a 'head' checkout on that date you would have gotten 1.1.1.2 - If you later do a 'head' checkout, and specify that date, you get 1.1 What am I missing here.. ? Has this behavior in CVS changed at some point? Thanks, -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ELF rtld and environment variables...
Ollivier Robert wrote: > According to Julian Stacey: > > just as today I'd use an encrypting file system on my new laptop, > > but such file system don't exist on FreeBSD unfortunately. > > Ahem. Why did I sent an update for security/cfs to green a few months ago? :-) 4.1-release produces no /sbin/mount_cfs, & man mount give no hint, If you have patches to test, I volunteer to test on 4.1 or 3.4 :-) Julian - Julian Stacey http://bim.bsn.com/~jhs/ Munich Unix Consultant. Free BSD Unix with 3600 packages & sources. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ffs_getpages()
Just wondering if anyone can shed some light on the changes in the page fault handling code in 3.3 vs 4.0. I've noticed that the async read ahead that used to work for mmaped files via a VOP_READ in ffs_getpages() is no longer there... I've run some very simple (and by no means exhaustive) tests, and on the surface the tradeoff appears to be that in 3.3 the disk is accessed synchronously, 16 pages at a time, whereas in 4.0 access may be asynchronous, 32 pages at a time. I am aware of the fact that in 3.3, using the vnode vlastr field was maybe not a perfect way to detect seq access for "normal" objects in ffs_getpages, but I thought the asynch read ahead was a real bonus - I might be overlooking something obvious here, but can anyone tell me why this has changed? Thanks, Yvonne To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 3Com 10/100 Mini PCI Ethernet
Bill Paul wrote: > I'm sorry, but after reading this thread, I'm having a hard time coming > up with an explanation for this nonsense which doesn't involve you being > a dumbass. Yes, i am. I'm guilty for the death of this innocent card, and it is just and only my personal fault and nobody else's. Please, whoever it currently has, give me the conical hat and i'll wear it for the next 2 or 3 months and i promise, i'll stick this "I damaged this card because, I'm a dumbass" paper on the top of the hat so everyone can see it. I will not anymore write PCI probe/attach routines for an unknown chip to connect it to drivers meant only for ISA, MCA, EISA and PCMCIA devices. I'm also very sorry to be the cause of your blood pressure going up, please accept my apologies. AFAIK, this card is a 3Com OEM product which is not available for purchase, all i can give you is an HP part number. It is also not a "normal" PCI card but a so called "Mini PCI" card and its about as large as a matchbox or even a bit smaller. Anyway, i have replaced the card, and i will try hard not to make the same mistakes again (before this whole mess, i was under the impression that only monitors can be destroyed by software, now i know better ...). But, i want to get this card supported. In case you have one or the other good suggestion (except "stay away from the card, don't even look at it !!") on how to proceed in a more orderly fashion, please let me hear them. hellmuth -- Hellmuth Michaelis[EMAIL PROTECTED] Hamburg, Europe We all live in a yellow subroutine, yellow subroutine, yellow subroutine ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD belly up with big config
On Sat, 5 Aug 2000, Dennis wrote: > With 1800 interfaces in the system Freebsd seems to use about 50Mhz of cpu > when idle in "interrupts" even when there are no interrupts to process. on > a 500Mhz box it uses 10% of the cpu and it seems linear with different > speed processors. > > the 1800 interfaces are 900 DLCIs on a T3 frame with 900 bridge groups > (rather common for a DSL delivered via Frame). This with just one > line...the same problem could occur with say 8 T1 lines with 100+ DLCIs on > each. > > It seems that there is substantial overhead just scanning interfaces for > some routine maintenance...is there any hope of alleviating this deboggle? I'd made some similar observations about the current lack of scalability both in management of (struct ifnet) chains, and mountpoints in the file system. As we move to a more dynamic network environment, a lot of things about ifnet handling need to be improved, including fixing (really fixing) the freeing of struct ifnet (lots of loose mbuf pointers hanging around to the struct ifnet, as well as stuff in filtering rules, et al). The bridging code isn't currently designed to work in this manner, and also has problems with dynamically introduced interfaces (try and use options BRIDGE and the sysctl enabled with a pccard sometime). Robert N M Watson [EMAIL PROTECTED] http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 3Com 10/100 Mini PCI Ethernet
> AFAIK, this card is a 3Com OEM product which is not available for purchase,
> all i can give you is an HP part number. It is also not a "normal" PCI card
> but a so called "Mini PCI" card and its about as large as a matchbox or
> even a bit smaller.
>
> Anyway, i have replaced the card, and i will try hard not to make the same
> mistakes again (before this whole mess, i was under the impression that
> only monitors can be destroyed by software, now i know better ...).
>
> But, i want to get this card supported. In case you have one or the other
> good suggestion (except "stay away from the card, don't even look at it !!")
> on how to proceed in a more orderly fashion, please let me hear them.
Type "pciconf -l" and show us the results so we can actually see the
vendor/device ID data. If it is indeed vendor ID 0x10B7 and device ID
0x6055, then try the patch included with this e-mail. To apply it, do
the following:
- Save this message to a file, e.g. /tmp/xl.diff
- cd /sys/pci
- patch < /tmp/xl.diff
Then make a new kernel and/or if_xl.ko module and test it. If it works
correctly, you should see the ethernet address and proper media selections
in the dmesg output. And, more importantly, you should be able to send
and receive traffic. If it doesn't probe correctly, then it's probably
not a Cyclone/Hurricane/Tornado chipset and the xl driver won't support
it. I believe that it is a Cyclone/Hurricane/Tornado chipset though,
since 3Com doesn't make any other 10/100 devices except for what's on
the 3CR990 card, which is a) undocumented and b) overkill for an embedded
laptop ethernet adapter.
-Bill
*** if_xl.c.origMon Aug 7 14:25:39 2000
--- if_xl.c Mon Aug 7 14:25:03 2000
***
*** 55,60
--- 55,61
* 3Com 3c980C-TX 10/100Mbps server adapter (Tornado ASIC)
* 3Com 3cSOHO100-TX 10/100Mbps/RJ-45 (Hurricane ASIC)
* 3Com 3c450-TX 10/100Mbps/RJ-45 (Tornado ASIC)
+ * 3Com 3cN3AV155610/100Mpps/RJ-45 HP laptop ethernet (Tornado ASIC?)
* Dell Optiplex GX1 on-board 3c918 10/100Mbps/RJ-45
* Dell on-board 3c920 10/100Mbps/RJ-45
* Dell Precision on-board 3c905B 10/100Mbps/RJ-45
***
*** 184,189
--- 185,192
"3Com 3cSOHO100-TX OfficeConnect" },
{ TC_VENDORID, TC_DEVICEID_TORNADO_HOMECONNECT,
"3Com 3c450-TX HomeConnect" },
+ { TC_VENDORID, TC_DEVICEID_3CN3AV1556,
+ "3Com 3CN3AV1556 Fast Etherlink XL" },
{ 0, 0, NULL }
};
***
*** 1142,1147
--- 1145,1151
case TC_DEVICEID_HURRICANE_SOHO100TX: /* 3cSOHO100-TX */
case TC_DEVICEID_TORNADO_10_100BT: /* 3c905C-TX */
case TC_DEVICEID_TORNADO_HOMECONNECT: /* 3c450-TX */
+ case TC_DEVICEID_3CN3AV1556:/* 3cN3AV1556 */
sc->xl_media = XL_MEDIAOPT_BTX;
sc->xl_xcvr = XL_XCVR_AUTO;
if (verbose)
*** if_xlreg.h.orig Mon Aug 7 14:25:39 2000
--- if_xlreg.h Mon Aug 7 14:20:14 2000
***
*** 641,646
--- 641,647
#define TC_DEVICEID_TORNADO_10_100BT_SERV 0x9805
#define TC_DEVICEID_HURRICANE_SOHO100TX 0x7646
#define TC_DEVICEID_TORNADO_HOMECONNECT 0x4500
+ #define TC_DEVICEID_3CN3AV15560x6055
/*
* PCI low memory base and low I/O base register, and
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: ELF rtld and environment variables...
According to Julian Stacey: > 4.1-release produces no /sbin/mount_cfs, & man mount give no hint, > If you have patches to test, I volunteer to test on 4.1 or 3.4 :-) It is a port. I'd love to import it into CURRENT though. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: US$100 prize for adding ESS Audiodrive support to pcm
Alan Clegg wrote: > > On a simmilar note: what about a driver for ESS Maestro 2E? I'm certainly [...] > Add $100 from me. There is one that works for some folks out there > by <[EMAIL PROTECTED]>, but it does not work for me. where do you find this? > -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 ;_.---._/ presently in: Budapest v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD belly up with big config
Robert Watson <[EMAIL PROTECTED]> wrote: > >I'd made some similar observations about the current lack of scalability >both in management of (struct ifnet) chains, and mountpoints in the file >system. When I had a brief look at the way mount points are handled I concluded that most of the time they were found via the vnode tree which is independent of the number of mounted filesystems. The list of mountpoints is only scanned rarely, when you are doing heavy stuff like mounting or unmounting a filesystem. Tony. -- en oeccget g mtcaaf.a.n.finch v spdlkishrhtewe y[EMAIL PROTECTED] eatp o v eiti i d.[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD belly up with big config
At 11:54 PM 8/6/00 -0700, Mike Smith wrote: >> With 1800 interfaces in the system Freebsd seems to use about 50Mhz of cpu >> when idle in "interrupts" even when there are no interrupts to process. on >> a 500Mhz box it uses 10% of the cpu and it seems linear with different >> speed processors. >> >> the 1800 interfaces are 900 DLCIs on a T3 frame with 900 bridge groups >> (rather common for a DSL delivered via Frame). This with just one >> line...the same problem could occur with say 8 T1 lines with 100+ DLCIs on >> each. >> >> It seems that there is substantial overhead just scanning interfaces for >> some routine maintenance...is there any hope of alleviating this deboggle? > >Probably. Without some idea of what's actually happening, though, it's a >little hard to point a finger and say "look here". > >A profiling dump of the system when idle would be very illuminating, as >it'd give you a good idea of what's actually going on to use so much CPU How do I do this in 4.1? I have a test bed set up that demonstrates the problem. Dennis To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD belly up with big config
> >> It seems that there is substantial overhead just scanning interfaces for > >> some routine maintenance...is there any hope of alleviating this deboggle? > > > >Probably. Without some idea of what's actually happening, though, it's a > >little hard to point a finger and say "look here". > > > >A profiling dump of the system when idle would be very illuminating, as > >it'd give you a good idea of what's actually going on to use so much CPU > > How do I do this in 4.1? I have a test bed set up that demonstrates the > problem. Config your kernel with '-pg', build and install. (See config(8)) Low-resolution profiling should be fine. Boot the new kernel, and when it's running use kgmon to grab a profiling dump for, say, 30 seconds. Then use gprof to translate the dump into readable output; at this point the flat profile is a good place to start to get a feel for where the code is busiest. Hope this helps. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vmware changes result in nasty bridging mess
At a quick glance, "start_bridge" doesn't seem to have chance to be 1, does it? And, what's the difference among those three values of "bridge"? > + bridge="_bridge_on" > + bridge="_bridge" > + bridge="_bridge_off" -- / /__ __ / ) ) ) ) / Akinori -Aki- MUSHA aka / (_ / ( (__( @ idaemons.org / FreeBSD.org "We're only at home when we're on the run, on the wing, on the fly" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
VLAN Support in FreeBSD
About a month ago, David Gilbert <[EMAIL PROTECTED]> started a thread in freebsd-stable about supporting a 1500MTU through a VLAN trunk (see Message-ID: <[EMAIL PROTECTED]>). Since this would be very useful to me, I did some digging into it and looked through the code (there being no other documentation). As far as I can tell from the code, the only thing restricting VLAN over ethernet devices to an MTU of 1496 is the code deleted in the following patch. Based on references to if_mtu, ifi_mtu, if_hdrlen and ifi_hdrlen, there is nothing in the system which will get upset if the MTU+hdrlen on the VLAN interface is more than the MTU+hdrlen on the trunk interface (the VLAN parent). When I try this in practise, I can send 1500 byte packets without problem, but when a 1500 byte packet is sent to me, it never arrives (at least at bpf_tap() on the trunk interface). Unfortunately, I can't tell (at this stage) whether this is a problem with the 3Com 3C905 NIC, or the switch. (There's no problem with shorter packets). Has anyone else played with VLAN's in FreeBSD? Does anyone know which (if any) NICs are likely to object to receiving VLAN trunk frames (1522 instead of 1518 bytes). Index: if_vlan.c === RCS file: /home/CVSROOT/src/sys/net/if_vlan.c,v retrieving revision 1.18 diff -u -r1.18 if_vlan.c --- if_vlan.c 2000/07/13 22:54:30 1.18 +++ if_vlan.c 2000/08/08 06:11:02 @@ -356,11 +356,7 @@ if (ifv->ifv_p) return EBUSY; ifv->ifv_p = p; - if (p->if_data.ifi_hdrlen == sizeof(struct ether_vlan_header)) - ifv->ifv_if.if_mtu = p->if_mtu; - else - ifv->ifv_if.if_mtu = p->if_data.ifi_mtu - EVL_ENCAPLEN; - + ifv->ifv_if.if_mtu = p->if_mtu; /* * Preserve the state of the LINK0 flag for ourselves. */ Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
