Looking for a way to test Performance.
hi, I'm installing alot of squid proxy servers with Freebsd my servers config is like this Intel 600MHz Dual 1G Ram 3*18G Ultra2 (seagate Cheetah) disks.. I'm using vinum, and it is running transparent proxy with wccp V1 I want to make sure that I'm getting all of the power the box can provide.. is there a tool that can help me in determining that.. Best Regards Mustafa N. Deeb Palnet Communications Ltd. Systems Administrator emaiL: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
cool
So, if you are in the Singapore Changi international airport, the internet center in the transit area will loan you for FREE, a wavelan PC-CARD. So here I am waiting for my next flight and I'm on the net! (well they hold your passport in exchange but that's ok) I couldn;t get teh DHCP client to work, It kept saying: jules# /sbin/dhclient ifconfig: ioctl (SIOCAIFADDR): File exists Listening on BPF/wi0/00:60:1d:1e:42:6c Sending on BPF/wi0/00:60:1d:1e:42:6c Can't find free bpf: No such file or directory exiting. And the log files showed.. Jun 14 00:54:37 jules /kernel: rtinit: wrong ifa (0xc0f85980) was (0xc0ee3000) Jun 14 00:54:37 jules dhclient: Can't find free bpf: No such file or directory Jun 14 00:54:37 jules dhclient: exiting. So I just did: # wicontrol -i wi0 -p 1 # tcpdump eventually a packet showed up, from the router at 192.100.100.1 so I just grabbed 192.100.100.2 (S!) now if I can get dhcp to work this would be great! julian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Remote syslog with a tag ?
On Tue 2000-06-13 (22:40), Bernd Walter wrote: > > I've often thought it would be nice to be able to get syslogd to > > make choices based on hostname. I'm sure a patch would be easy > > enough to produce, but the trick would be to produce a good syntax > > fox syslog.conf. Are there any syslogds that can do this? What > > syntax do they use? > > I have a patched version to do this. > If anyone is interessted I'm producing diffs. I'm sure many people are interested. Send a PR, or patches to [EMAIL PROTECTED] Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
I'm only going to reply once to this thread In message <[EMAIL PROTECTED]> Robert Watson writes: : And in a sense, we already have two kerneld's -- pccardd and usbd, which : maintain mappings between named devices and drivers, etc. Combining them, : and adding another source of requests (and LPC channel over a UNIX domain : socket) would not be that hard. I personally think that a devd would be great to have. One that could do things when devices arrive and leave as well as when the removable hardware/software detects a new hunk of hardware that doesn't attach to any resident driver. It would be extremely useful if only the specific driver that was for that hardware wound up in the kernel. It would also be useful if that module were unloaded when that removable device went away. No need to keep it in memory, so long as there was a way to bring it back later. Sure, there's a monster bug in the kldload/unload right now where that eats wired memory. That bug should be fixed. Finally, all of this would be less of an issue if one could page the kernel, or at least parts of it... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI Wavelan adapter timeouts
In message <[EMAIL PROTECTED]> Chris Csanady writes: : Has anyone one successfully used one of these? I have read through : the list archives, but I never saw the problems resolved. I have : tried 4.0, and current with no luck. My dmesg output looks like: : : pcic-pci0: irq 10 at device 10.0 on pci0 : pcic-pci0: TI12XX PCI Config Reg: [pwr save][pci only] : pcic-pci1: irq 10 at device 10.1 on pci0 : pcic-pci1: TI12XX PCI Config Reg: [pwr save][pci only] : : pcic0: at port 0x3e0 iomem 0xd irq 10 on isa0 : pcic0: management irq 10 : pccard0: on pcic0 : pccard1: on pcic0 : : wi0: at port 0x240-0x27f irq 7 slot 0 on pccard0 Do you have any other hardware on IRQ 7. Note, I didn't ask if you had any other driver at IRQ 7, but any other hardware at all. You can't share interrupts. You'll have to disable the parallel printer port in your BIOS to be able to use IRQ 7. The device timeout is a classic case of IRQ misconfiguration. : Neither irq 7, or 10 conflict with anything else. Again, have you disabled the IRQ 7 sources (eg parallel port) in the BIOS, otherwise there will be a conflict. I'm not sure that anybody has gotten these to work. I do know that 4.0 RELEASE will not properly work all the time with these devices, and that you need 4.0 STABLE from approx middle of March to even have a chance. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
Warner Losh wrote: > Sure, there's a monster bug in the kldload/unload right now where that > eats wired memory. That bug should be fixed. There is? There is a well-known leak for preload stuff - the pages are not (yet) reclaimed after unload. We have the infrastructure to do that now. See vm_page_t vm_add_new_page(vm_offset_t pa); This can be used to reclaim the space consumed by preloaded files. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI Wavelan adapter timeouts
> In message <[EMAIL PROTECTED]> Chris Csanady writes: > : Has anyone one successfully used one of these? I have read through > : the list archives, but I never saw the problems resolved. I have > : tried 4.0, and current with no luck. My dmesg output looks like: > : > : pcic-pci0: irq 10 at device 10.0 on pci0 > : pcic-pci0: TI12XX PCI Config Reg: [pwr save][pci only] > : pcic-pci1: irq 10 at device 10.1 on pci0 > : pcic-pci1: TI12XX PCI Config Reg: [pwr save][pci only] > : > : pcic0: at port 0x3e0 iomem 0xd irq 10 on isa0 > : pcic0: management irq 10 > : pccard0: on pcic0 > : pccard1: on pcic0 > : > : wi0: at port 0x240-0x27f irq 7 slot 0 on pccard0 well I'm typing this across the following: pccard: card inserted, slot 0 wi0: at port 0x240-0x27f irq 9 slot 0 on pccard0 wi0: Ethernet address: 00:60:1d:1e:42:6c I'm not seeing problems there.. (though dhclient doesn't seem to work on it for some reason) > > Do you have any other hardware on IRQ 7. Note, I didn't ask if you > had any other driver at IRQ 7, but any other hardware at all. You > can't share interrupts. You'll have to disable the parallel printer > port in your BIOS to be able to use IRQ 7. The device timeout is a > classic case of IRQ misconfiguration. > > : Neither irq 7, or 10 conflict with anything else. > > Again, have you disabled the IRQ 7 sources (eg parallel port) in the > BIOS, otherwise there will be a conflict. > > I'm not sure that anybody has gotten these to work. I do know that > 4.0 RELEASE will not properly work all the time with these devices, > and that you need 4.0 STABLE from approx middle of March to even have > a chance. > > Warner > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message -- ^ | __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 )_.---._/ presently in: Singapore v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Looking for a way to test Performance.
> > I'm installing alot of squid proxy servers with Freebsd > my servers config is like this > Intel 600MHz Dual > 1G Ram > 3*18G Ultra2 (seagate Cheetah) disks.. > > I'm using vinum, and it is running transparent proxy with wccp V1 > > I want to make sure that I'm getting all of the power the box > can provide.. > is there a tool that can help me in determining that.. > Hmm. Tools? Sure, your own eyes. Have a peek in "System Performance Tuning". Amazon.com, $25,=. Old as it is, it will teach you how to watch a BSD system, and how to interpret the output of top and vmstat and friends, down to the HDD led that's on the front of your box. IIRC, the examples assume SunOS 4 or VAX. Fact is that it gives you a fundamental understanding of measuring performance of BSD systems. It covers CPU, memory, disk and network performance each in their own section. I found that I could use the book even for Windows machines. Kees Jan == Everyone is responsible for his own actions, and (people tend to forget this) the effect they have on others. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Mylex AccelRAID 150 and Quantum Drives...
I am having problems getting a Mylex AccelleRAID 150 RAID Card to see my Quantum Atlass 10k SCA 80-pin drives. Mylex is a little unclear as why quantum drives dont work. Has anyone used quantum atlass 10k SCA drives with a Mylex card? Thanks. -john v. e. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NVIDIA Drivers for XF4
Thus spake Trent Nelson ([EMAIL PROTECTED]): > What's porting going to involve? I can't see porting the kernel module > being *too* difficult (I'd love to start on something after exams) - but > I don't know how the Linux object files for the XFree86 interface are > going to be dealt with (Linux developer port?). If I understood dfr correctly (I've not taken a look at this yet), the new AGP driver in -current does similar things and works for two chipsets already (can't recall which, read cvs-all). However, porting the nvidia driver shouldn't be the problem. Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
[Oz-ISP] FreeBSD and the forces of darkness. Real religious wars! (fwd)
This is a message which appeared on the aussie-isp mailing list earlier today. I thought people here might like it :-) Ross is a reliable source, so I doubt we can chalk this one up to "urban legend". - mark > -- Forwarded message -- > Date: Wed, 14 Jun 2000 15:45:51 +1000 (EST) > From: Ross Wheeler <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: [Oz-ISP] FreeBSD and the forces of darkness. Real religious wars! > > > I've got to tell someone about this I'm flabergasted! > > A client of a client had their internet gateway machine (a Linux box) > hacked recently, and seriously compromised. Ok... totally screwed. > > So, much panic, waving of arms and gnashing of teeth, and it was a case of > "drop everything and help" this poor school. The person who set up the > original box is on the other side of the continent and seems to be not > contactable, or something. > > Anyhow, we helped. KNOWING the box had been hacked and WOULD be under > constant scrutiny, we suggested FreeBSD (now before we start any religious > wars here, yes, a linux box MAY be as secure as a FreeBSD box, assuming > both were set up by people familiar and competent with them both but > we're a FreeBSD site and not expert with Linux! Plus, it was compromised > as a Linux box, much better to change things a little while we're at it). > > So the box was completely re-built. They moved the goalposts a couple of > times (changing how things needed to be set up AFTER it had been done, but > hey...). and now that it's all going and working. they want to rip it > out and put linux back on again. > > Why? > > > > > Well I could start a guessing competition here. > > And you guys (and girls) are NOT allowed to kill yourselves laughing > here... This is what the person actually typed: > > > "I've just had a converstaion with (our Principal) about some > of the changes. We've had to deal with some of the philosphical issues > related to BSD. As you know BSD uses a 'devil' icon to portray the BSD > symbol. Given we are a Christian school this is a significant concern for > us. Even after reviewing the sites blurb about the origin of the symbol, > we've come to the conclusion that it would not be appropriate for us to > use the software." > > Can you believe it?! > > I tried to "inform" them about the "mascot" > > "some of our parents who are very technically savvy would not care about > the disctinction. It is the subliminal message the icon represents..." > > And then the FreeBSD site itself fueled the fire: > > "Even the site talks about a deamon being 'unleashed' in you computer blah." > > So that's that. No further discussion would be entered into. They've made > their decision. with a parting shot that: > > "what we need to concern ourselves with as a Christian school is the > 'message' or 'image' that may unwittingly be portrayd." I tried an internal modem,[EMAIL PROTECTED] but it hurt when I walked. Mark Newton - Voice: +61-4-1620-2223 - Fax: +61-8-82231777 - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: [Oz-ISP] FreeBSD and the forces of darkness. Real religious w ars!(fwd)
> > "Even the site talks about a deamon being 'unleashed' in you > computer blah." > Have you perhaps pointed out that Linux is full of daemons too? If you listen closely to the box you can hear them chitter amongst eachother. Inetd for example, a.k.a. "The Mother of All Deamons". Phew, they don't come much worse than that. It's even known to spawn others. I won't even mention the http deamon and maybe even the talk daemon. No telling who it talks to. At least BSD puts a clear warning sticker on the box, whereas Linux daemons tend to hide in animal guises. Penguins, I believe. Anyway, there's nothing to worry about. If your box is CE compliant it will shield the outside world quite efficiently from what's inside. Kees Jan == Everyone is responsible for his own actions, and (people tend to forget this) the effect they have on others. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [Oz-ISP] FreeBSD and the forces of darkness. Real religious w ars! (fwd))
+[ Koster, K.J. ]- [Charset iso-8859-1 unsupported, filtering to ASCII...] | > | > "Even the site talks about a deamon being 'unleashed' in you | > computer blah." | > | Have you perhaps pointed out that Linux is full of daemons too? If you | listen closely to the box you can hear them chitter amongst eachother. Inetd | for example, a.k.a. "The Mother of All Deamons". Phew, they don't come much | worse than that. It's even known to spawn others. I won't even mention the | http deamon and maybe even the talk daemon. No telling who it talks to. | | At least BSD puts a clear warning sticker on the box, whereas Linux daemons | tend to hide in animal guises. Penguins, I believe. Catholic schools are probably a lot happier with Penguin imagery... *thinks of Jake & Elwood* -- Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew Milton The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 | ACN: 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI Wavelan adapter timeouts
In message <[EMAIL PROTECTED]> Julian Elischer writes: : well I'm typing this across the following: : : pccard: card inserted, slot 0 : wi0: at port 0x240-0x27f irq 9 slot 0 on pccard0 : wi0: Ethernet address: 00:60:1d:1e:42:6c : I'm not seeing problems there.. : (though dhclient doesn't seem to work on it for some reason) Maybe wi doesn't support broadcasts? Anyway, we know that the wi cards work. Are you typing it on the same PCI pccard adapter that Chris is having problems with? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [Oz-ISP] FreeBSD and the forces of darkness. Real religious w ars! (fwd))
Tell them that it is a daemon, not a devil. A daemon isn't the devil, nor does it promote the worship of devilry. In Japan, the daemon is viewed as a nice, lovable creature. The Japanese think he is cute. Too bad the BSD magazine isn't more widely available in the states. The daemons in it are very cute. I especially like the daemons that are the mom, pop and kid pictures. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Conflict between Intel 82558/9 and VIA MVP4?
We're having problems with the Intel EtherExpress 10/100 NICs in our product platform. We suspect unfavorable interaction between the 82558 and 82559 Intel parts and our motherboard chipset. Here are some specifics: We're using 3.4-STABLE, with the "latest" fxp driver code: $FreeBSD: src/sys/pci/if_fxp.c,v 1.59.2.7 2000/04/01 19:04:21 dg Exp $ $FreeBSD: src/sys/pci/if_fxpreg.h,v 1.13.2.3 1999/12/06 20:11:53 peter Exp $ $FreeBSD: src/sys/pci/if_fxpvar.h,v 1.6.2.2 2000/04/01 19:04:22 dg Exp $ The platform is a small PC designed for the point of sale folks, and uses the VIA Apollo MVP4 chipset. From dmesg: chip0: rev 0x02 on pci0.0.0 chip1: rev 0x00 on pci0.1.0 chip2: rev 0x14 on pci0.7.0 chip3: rev 0x10 on pci0.7.4 We use an AMD K6-2 at 350 or 450 Mhz, 32MB of RAM and boot from Compact Flash. The two PCI slots are on a riser card. On the riser card is a RealTEK 8139 10/100 interface which works quite well: rl0: rev 0x10 int a irq 12 on pci0.13.0 We can install other RealTEK-based NICs in either or both riser card PCI slots, and they work well, as do WAN cards. The problem comes when we install a NIC based on the Intel 82558 or 82559 parts. When the NIC is in the "top" slot on the riser (pci0.1.19), the kernel panics in if_fxp.c at fxp_add_rfabuf + 0xc4. The backtrace says fxp_add_rfabuf was called from fxp_intr. With the NIC in the "bottom" slot (pci0.1.17), there is no panic, but the card gets choked up and seems not to listen reliably. For example, it will hear an ARP reply if it sent the ARP request, but will ignore an ARP request inbound. My sniffer shows the packets on the link, but there is no indication in a "netstat -i" that the NIC saw them. Further watching of a "netstat -i -w 1" display shows something very puzzling and troubling. When the card _is_ working, the transmitted and received byte counts get updated in the display, but the associated packet counts don't go up for one or two seconds. When the card is NOT working right (doesn't hear), the bytes-received counts will increment and the packets-received counts WON'T. Here's the display for a "working" NIC on a quiet subnet that has a single machine sending broadcasts every 3 seconds and a quick 100-packet flood ping of that machine. Note the two second delay before the packet counts catch up: input (fxp0) output packets errs bytespackets errs bytes colls 1 0 0 0 0 0 0 0 0 71 0 0 0 0 0 0 0 0 0 0 0 1 0 9800 0 0 9800 0 0 0 71 0 0 0 0 100 0 0100 0 0 0 1 0 0 0 0 0 0 0 0 71 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 Our mbuf levels are hitting really high peaks, and I suspect that whatever is hanging onto the packets is responsible for that. Other NICs in the same situation (including the much maligned RealTEK) don't exhibit this symptom, and don't run up our peak mbufs. In addition to causing massive peaks, the Intel NICs do something else ugly. It appears that they get choked up when they can't get rid of queued outputs as quickly as they would like. A 10Mbps shared-media segment will have many many collisions when transfering a file or doing a flood ping between two fast FreeBSD boxes, and a bunch of the queued output mbufs wind up in limbo. Changing to a full-duplex 100Mbps connection between the boxes eliminates the buffer-loss problem, but does not stop the NIC from having its receive or panic problems. We see the mbuf peak symptoms on other motherboards as well, but not the ignored received packets. The NICs we have tried are Intel EtherExpress Pro 100B, Pro 100+, and the new EtherExpress Pro 100+ Management Adaptors. The Management Adaptors have another side effect in our platform. The Management Adaptors have the Wake on Lan function integrated, as well as having a net boot ROM installed and enabled by default. Intel has a utility called "brow" that will modify the settings of these new features, and we routinely turn off both the WOL and net boot facilities. We have to do this in a PC that is not one of our shipping product platforms, because our product won't get through the BIOS PCI scan with these "features" enabled. Can somebody help us here? We're in a bit of a panic. Best regards, -Les -- Les BiffleCommunity Service... Just Say NO! (480) 778-0177[EMAIL PROTECTED] http://www.les.safety.net/ Network Safety, 7802 E Gray Rd Ste 500, Scottsdale, AZ 85260 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the mes
Re: PCI Wavelan adapter timeouts
At Wed, 14 Jun 2000 09:36:47 -0600, Warner Losh <[EMAIL PROTECTED]> wrote: > > In message <[EMAIL PROTECTED]> Julian >Elischer writes: > : well I'm typing this across the following: > : > : pccard: card inserted, slot 0 > : wi0: at port 0x240-0x27f irq 9 slot 0 on pccard0 > : wi0: Ethernet address: 00:60:1d:1e:42:6c > : I'm not seeing problems there.. > : (though dhclient doesn't seem to work on it for some reason) > > Maybe wi doesn't support broadcasts? I'm using dhclient on wi in infrastructure mode. -- --- Tatsumi Hosokawa [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI Wavelan adapter timeouts
In message <[EMAIL PROTECTED]> Tatsumi Hosokawa writes: : At Wed, 14 Jun 2000 09:36:47 -0600, : Warner Losh <[EMAIL PROTECTED]> wrote: : > : > In message <[EMAIL PROTECTED]> :Julian Elischer writes: : > : well I'm typing this across the following: : > : : > : pccard: card inserted, slot 0 : > : wi0: at port 0x240-0x27f irq 9 slot 0 on pccard0 : > : wi0: Ethernet address: 00:60:1d:1e:42:6c : > : I'm not seeing problems there.. : > : (though dhclient doesn't seem to work on it for some reason) : > : > Maybe wi doesn't support broadcasts? : : I'm using dhclient on wi in infrastructure mode. OK. Is this with the PCI addapter or with another adapter? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD Support of Hot Swappable NICs
In message <[EMAIL PROTECTED]> Dan Nelson writes: : In-Reply-To: <[EMAIL PROTECTED]>; from "Alfred Perlstein" on :Wed Jun 7 11:41:59 GMT 2000 : X-OS: FreeBSD 5.0-CURRENT : : In the last episode (Jun 07), Alfred Perlstein said: : > Brech, Cary <[EMAIL PROTECTED]> [000607 10:33] wrote: : > > Lucent recently introduced a product that uses FreeBSD as its OS. : > > We are currently contemplating adding the ability to "Hot Swap" the : > > custom network interface cards we are developing for the next : > > release. The question we have is does FreeBSD support the ability : > > to hot swap network interface cards? : > > : > > Thanks in advance for your assistance! : > : > We can do pcmcia hot swap, but it gets hairy if the interface is : > in use, the interface should be 'downed' before removing afaik. : : Or do you mean PCI hot-plug? FreeBSD currently doesn't support : powering off PCI slots or re-probing the PCI bus after bootup, both of : which are required for hot-plug. I don't know how hard it would be to : add, either. You'll probably have to ask -hackers about that (cc and : reply-to reset there). The compact PCI hot swap spec isn't implemented in FreeBSD at this time. The compact PCI cards will work w/o the hot swap stuff just fine. The hot swap spec doesn't include a register set to program to, as far as I could tell in my limited researches, so each chipset needs its own driver to add hot swap capibilities. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD Support of Hot Swappable NICs
In message <[EMAIL PROTECTED]> Wes Peters writes: : Warner Losh has just started to look into support for CPCI, which would : mandate hot-swap and bus reprobing. The CardBus support is similar in : concept, too. Yes. Cardbus is indeed quite similar. That's one reason I like the CPCI stuff we have at work :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD Support of Hot Swappable NICs
In message <[EMAIL PROTECTED]> Mike Smith writes: : Actually, there's still a *lot* of work that has to be done to make this : work "right" - let me say two things only: : : "resource allocation" : : "interrupt routing" Yes. Given cardbus support, these are easy. We don't have cardbus support yet, so these will be quite hard. You have to cooperate with the pci bios to do either of these in a MI way. And the pci bios might not exist on all platforms, iirc. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD Support of Hot Swappable NICs
In message <[EMAIL PROTECTED]> Sergey Babkin writes: : 1. When the card is physically removed inform the driver that it : should shut down and don't try to get to the card afterwards. That means : it would handle some subset of configuration requests and delay or : throw away any data transfer requests. : : 2. Later take any neccessary amount of time to clean up the things. We've been through this on the pccard stuff. In that case, you have a few milliseconds to cease all access to the hardware. In the CPCI case you'd have on the order of a second. The CPCI spec says that a board shall have a led and a removal switch. The removal switch is put into the remove position, and the user is supposed to wait for the led to light (or was that go out) before removing the card. Even if he/she/it doesn't, it will take about a second to remove the card after frobbing the switch. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
In message <[EMAIL PROTECTED]> Peter Wemm writes: : There is? There is a well-known leak for preload stuff - the pages : are not (yet) reclaimed after unload. We have the infrastructure to : do that now. See vm_page_t vm_add_new_page(vm_offset_t pa); : This can be used to reclaim the space consumed by preloaded files. Maybe it was something a driver of mine did then, since in 4.0-stable I have observed that multiple load/unload of the driver caused a memory leak that was about the same size as the text/data sections of the driver. Maybe I had a leak in my code instead... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Conflict between Intel 82558/9 and VIA MVP4?
>We're having problems with the Intel EtherExpress 10/100 NICs in our >product platform. We suspect unfavorable interaction between the 82558 >and 82559 Intel parts and our motherboard chipset. Here are some >specifics: > >We're using 3.4-STABLE, with the "latest" fxp driver code: > > $FreeBSD: src/sys/pci/if_fxp.c,v 1.59.2.7 2000/04/01 19:04:21 dg Exp $ > $FreeBSD: src/sys/pci/if_fxpreg.h,v 1.13.2.3 1999/12/06 20:11:53 peter Exp $ > $FreeBSD: src/sys/pci/if_fxpvar.h,v 1.6.2.2 2000/04/01 19:04:22 dg Exp $ > >The platform is a small PC designed for the point of sale folks, and uses >the VIA Apollo MVP4 chipset. From dmesg: > > chip0: rev 0x02 on pci0.0.0 > chip1: rev 0x00 on pci0.1.0 > chip2: rev 0x14 on pci0.7.0 > chip3: rev 0x10 on pci0.7.4 > >We use an AMD K6-2 at 350 or 450 Mhz, 32MB of RAM and boot from Compact Flash. > >The two PCI slots are on a riser card. On the riser card is a RealTEK >8139 10/100 interface which works quite well: > > rl0: rev 0x10 int a irq 12 on pci0.13.0 > >We can install other RealTEK-based NICs in either or both riser card PCI >slots, and they work well, as do WAN cards. The problem comes when we >install a NIC based on the Intel 82558 or 82559 parts. > >When the NIC is in the "top" slot on the riser (pci0.1.19), the kernel >panics in if_fxp.c at fxp_add_rfabuf + 0xc4. The backtrace says >fxp_add_rfabuf was called from fxp_intr. That definately sounds like a hardware problem - an electrical problem, perhaps noise related, on the PCI bus. >With the NIC in the "bottom" slot (pci0.1.17), there is no panic, but the >card gets choked up and seems not to listen reliably. For example, it >will hear an ARP reply if it sent the ARP request, but will ignore an >ARP request inbound. My sniffer shows the packets on the link, but there >is no indication in a "netstat -i" that the NIC saw them. Could possibly be caused by a number of things. It could be another manifestation of the problem above, it could be that the duplex isn't being negotiated properly, or could be something altogether different. >Further watching of a "netstat -i -w 1" display shows something very >puzzling and troubling. When the card _is_ working, the transmitted and >received byte counts get updated in the display, but the associated >packet counts don't go up for one or two seconds. When the card is NOT >working right (doesn't hear), the bytes-received counts will increment >and the packets-received counts WON'T. The stats on the NIC are only read every second for the packet count, but the byte count is updated as soon as the packet is sent or received. This can cause a one second delay. I can't explain a two second delay other than the DMA [to complete the stats transfer] is extremely slow for some reason. >Here's the display for a "working" NIC on a quiet subnet that has a >single machine sending broadcasts every 3 seconds and a quick 100-packet >flood ping of that machine. Note the two second delay before the packet >counts catch up: > >input (fxp0) output > packets errs bytespackets errs bytes colls > 1 0 0 0 0 0 0 > 0 0 71 0 0 0 0 > 0 0 0 0 0 0 0 > 1 0 9800 0 0 9800 0 > 0 0 71 0 0 0 0 > 100 0 0100 0 0 0 > 1 0 0 0 0 0 0 > 0 0 71 0 0 0 0 > 0 0 0 0 0 0 0 > 1 0 0 0 0 0 0 > >Our mbuf levels are hitting really high peaks, and I suspect that >whatever is hanging onto the packets is responsible for that. Other >NICs in the same situation (including the much maligned RealTEK) don't >exhibit this symptom, and don't run up our peak mbufs. > >In addition to causing massive peaks, the Intel NICs do something else >ugly. It appears that they get choked up when they can't get rid of >queued outputs as quickly as they would like. A 10Mbps shared-media >segment will have many many collisions when transfering a file or doing >a flood ping between two fast FreeBSD boxes, and a bunch of the queued >output mbufs wind up in limbo. Changing to a full-duplex 100Mbps >connection between the boxes eliminates the buffer-loss problem, but >does not stop the NIC from having its receive or panic problems. We >see the mbuf peak symptoms on other motherboards as well, but not the >ignored received packets. Peak mbuf levels really aren't relevant to the problem. The fxp driver holds onto mbufs as part of an optimization to reduce interrupt overhead. It shouldn't peak higher than about 250 or so, however, if things are working correctly. It sounds to me as though there is a serious problem with the
Re: Remote syslog with a tag ?
On Wed, Jun 14, 2000 at 11:52:22AM +0200, Neil Blakey-Milner wrote: > On Tue 2000-06-13 (22:40), Bernd Walter wrote: > > > I've often thought it would be nice to be able to get syslogd to > > > make choices based on hostname. I'm sure a patch would be easy > > > enough to produce, but the trick would be to produce a good syntax > > > fox syslog.conf. Are there any syslogds that can do this? What > > > syntax do they use? > > > > I have a patched version to do this. > > If anyone is interessted I'm producing diffs. > > I'm sure many people are interested. Send a PR, or patches to > [EMAIL PROTECTED] It's placed on ftp://ftp.cosmo-project.de/pub/syslogd/syslogd.diff They where made with a 3.x version but I asume they will also apply to current. Only some string functions are changed since then it seems. man page modifications are included. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
limit on MAXDSIZ ?
Can anyone tell me what is the upper limit on the per process datasize specified in MAXDSIZ ? A quick look in the kernel code reveals that ressource limit struct uses rlim_t which is quad_t which is int64_t. Setting MAXDSIZ to "2048UL*1024*1024" works fine. Over 2Gb, the machine gives all sort of errors and doesn't complete the booting process. Florent. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
USENIX dinner.
can people send me email (privately) if they plan on attending an after-hours freebsd dinner. also, if people can help me plan possible times: 7-9 on Tuesday is out for me. Wednesday is all BSD Thursday at 8 is Linux... do we go out instead of hearing what Linus has to say? enclosed is my latest copy of the BOF schedule: PRE-SCHEDULED BIRDS-OF-A-FEATHER SESSIONS SAN DIEGO 2000 ANNUAL CONFERENCE as of June 6, 2000 TUESDAY, JUNE 20, 2000 == 6:00pm - 7:00pm An Update on Standards Nick Stoughton, USENIX Standards Liaison 6:00pm - 8:00pm Active Content: UNIX based protection for a Windows Virus World David Perry, Trend Micro CERT/CC Incident and Vulnerability Update Cory Cohen, CERT/CC 7:00pm - 8:00pm Sendmail Meets Perl Gurusamy Sarathy, ActiveState; Jeff Radice, Sendmail 7:00pm - 9:00pm Workplace Issues for Lesbian, Gay, Bisexual, Transgendered Sysadmins & Friends Chris Josephes, Onvoy WEDNESDAY, JUNE 21, 2000 7:00pm - 8:00pm Automated Backup Integration: Solutions & Ideas Dave Hiechel, Eagle Software NetBSD Charles Hannum, SAGE BOF Peg Schafer, SAGE Executive Committee The GNU BOF Bradley Kuhn, The Free Software Foundation 7:00pm - 9:00pm NAS & SAN: Will the Twain Meet Uresh Vahalia, EMC AFS, Kerberos, and Distributed Infrastructures Stephen Wynne, CMU; Garry Zacheiss, MIT 8:00pm - 9:00pm To GUI or not to GUI: Issues in Firewall Configuration Tools Avishai Wool, Lucent Technologies Gorilla Warfare - Operations Guide to Successful Internet Deployment Suzanne George, AOL Multithreading: Issues in Concurrency Bil Lewis, Lambda Computer Science Open BSD Theo de Raadt, OpenBSD Project 9:00pm - 10:00pm Plan 9/Brazil/Inferno Scott Schwartz, Penn State FreeBSD Jordan Hubbard, BSDI 10:00pm - 11:00pm Berkeley Softare Design, Inc. Paul Borman, BSDI THURSDAY, JUNE 22, 2000 == 8:00pm Linux Linus Torvalds, Transmeta __ Pat Lynch [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Systems Administrator Rush Networking To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
loading modules from within the kernel....
There seems to be a number of ways to approach this from within -current, so I thought I'd ask- While I'm configuring a PCI driver, I want to refer to another (possibly loadable) module- I can name it anything I want. It doesn't have any standard entry points- basically, it's a container for firmware for my card that I want to refer to when I'm configuring the PCI driver, and then I can release (and the module can go away after that). If this was Solaris, I would use weak elf binding and some (undocumented) DDI functions to get the kernel linker to pull in the module and satisfy the reference at runtime. What's the right mechanism currently for doing this in FreeBSD-current? A couple of pointers in the right direction would be greatly appreciated. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: loading modules from within the kernel....
Since your driver initialisation is going to (often) happen before disk I/O, I'd be inclined to put a dependancy in your module to another module with a container object containing the firmware. Of course, this brings to light the fact that I don't think we support "soft" dependancies, ie. load-this-if-you-can-but-don't-fail-if-you-can't. The current school of thought for solving this would be to have your firmware load as a plain container in a fashion similar to the way we load the MFS root image, and then use preload_search_by_type() to locate it. > There seems to be a number of ways to approach this from within -current, so I > thought I'd ask- > > While I'm configuring a PCI driver, I want to refer to another (possibly > loadable) module- I can name it anything I want. It doesn't have any standard > entry points- basically, it's a container for firmware for my card that I want > to refer to when I'm configuring the PCI driver, and then I can release (and > the module can go away after that). > > If this was Solaris, I would use weak elf binding and some (undocumented) DDI > functions to get the kernel linker to pull in the module and satisfy the > reference at runtime. > > What's the right mechanism currently for doing this in FreeBSD-current? A > couple of pointers in the right direction would be greatly appreciated. > > -matt > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: loading modules from within the kernel....
> > Since your driver initialisation is going to (often) happen before disk > I/O, I'd be inclined to put a dependancy in your module to another module > with a container object containing the firmware. Right. I would expect that the loader(8) would DTRT. Of course, this then raises an issue about how this might be supported statically as well! > Of course, this brings to light the fact that I don't think we support > "soft" dependancies, ie. load-this-if-you-can-but-don't-fail-if-you-can't. Oh, err, uh, that's gotta be fixed. Let the caller/invoker of a load action decide what the policy for failure is. > > The current school of thought for solving this would be to have your > firmware load as a plain container in a fashion similar to the way we > load the MFS root image, and then use preload_search_by_type() to locate > it. Does this approach use functions/APIs that are likely to not change for a while? -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: loading modules from within the kernel....
> > Since your driver initialisation is going to (often) happen before disk > > I/O, I'd be inclined to put a dependancy in your module to another module > > with a container object containing the firmware. > > Right. I would expect that the loader(8) would DTRT. Of course, this then > raises an issue about how this might be supported statically as well! I keep running up against the need for dlsym() functionality in the kernel; eg. the work I'm doing with the Mylex and AMI drivers is going to mandate CAM, even if you don't have any other SCSI hardware. > > Of course, this brings to light the fact that I don't think we support > > "soft" dependancies, ie. load-this-if-you-can-but-don't-fail-if-you-can't. > > Oh, err, uh, that's gotta be fixed. Let the caller/invoker of a load action > decide what the policy for failure is. The problem here is that we depend on the loader to perform early loads for stuff in the boot path, and that's where you are. Realistically, the "right" way to handle your particular case is probably going to be to associate a pile of PCI IDs with each of your firmware objects, and then use the loader's PCI-awareness to pull them in. > > The current school of thought for solving this would be to have your > > firmware load as a plain container in a fashion similar to the way we > > load the MFS root image, and then use preload_search_by_type() to locate > > it. > > Does this approach use functions/APIs that are likely to not change for a > while? Yes; things like MD_ROOT and the splash screen code depend on being able to preload opaque objects and then look them up. Right now, the API needs to be extended to these objects after bootup. *sigh* So much to do, so little time. Yadda yadda. 8) -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
pricerange for dinner.
Also, does anyone have a prefereed pricerange for dinner? I have one restaurant alreading bidding at 40/plate -Pat __ Pat Lynch [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Systems Administrator Rush Networking To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Has anybody looked at RAID-5 vinum performance on the "whole system"?
On Tuesday, 13 June 2000 at 16:39:01 -0700, Jaye Mathisen wrote: > > I was just curious what people's thoughts were on the potential "total > system throughput" (whatever you choose it to be), wrt using software > RAID. > > It would seem that software RAID would just kill big chunks of > cache, especially CPU cache, moving lots of data throught it to > calcuate CRC's. Hmm. Yes, it might seem that way, but that's a very different order of magnitude from the I/O transfers themselves. > perhaps the raid 1/0's would be fine, since the calcuation could be > ignored. Well, there is no calculation. > It would seem that for file-server type tasks, where hopefully CPU > is not an issue, then as long as you can exceed the capacity of your > network, you're probably fine. > > And most workstations probably don't run 100% (modulo things like > the various crackers and seti), that it's a non issue. It's a non-issue anyway. The RAID-5 parity calculations don't take up any time. The real issue is that each write requires two physical reads and two physical writes, reducing write performance to about 25% of the performance of RAID-1 writes. Take a look through http://www.lemis.com/vinum.html for further details. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
subdomain
I guess this is not a really FreeBSD question, but i guess it is still related :) I want to know if anyone can give me a subdomain with an NS record, my ISP hostname is very ugly and my existing subdomainname is often offline , their DNS server are not to be trusted :( So if anyone can help me plz Thx Fenix. ** |*The Deamon Inside**| |=--=--=--=--=--=--=--=--=--=| |May the source be with you !| |=--=--=--=--=--=--=--=--=--=| ** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pricerange for dinner.
Pat Lynch writes: > Also, does anyone have a prefereed pricerange for dinner? I have one > restaurant alreading bidding at 40/plate Considering the stature of famous and soon-to-be-famous people who will be attending, one should be able to demand more than $40 and dinner for one's presence. :-) -- David Kelly N4HHE, [EMAIL PROTECTED] = The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
question abt top...
hi all, what does CPU0 in the STATE field of "top" mean. i am running a SMP kernel. a process utilizes 99% of cpu and shows CPU0 in its STATE field. thanx in advance joy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
BAFUG DNS
Is anybody on right now that has access to cdrom.com DNS servers? Thanks Nicole [EMAIL PROTECTED] [EMAIL PROTECTED] |\ __ /| (`\ http://www.unixgirl.com/ [EMAIL PROTECTED] | o_o |__ ) ) http://www.dangermouse.org/ // \\ ---(((---(((- -- Powered by Coka-Cola and FreeBSD -- -- Strong enough for a man - But made for a Woman -- -- OWNED? MS: Who's Been In/Virused Your Computer Today? -- --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
install / boot last 3 gig of 25 gig drive
I tryed to install FreeBSD 3.3,3.4, and 4.0 release on the last three gig of a 25 gig drive with no success. After an install attempt the partition table of my disk is corrupt. Now it is so screwed up that Partition Magic cant read it. Through testing I determined that all I have to do to corrupt the partition table is load the fdisk style editor (boot the install cd ) and hit "w" to write the info. I changed nothing and only performed a write. Looking at the partition info below, it appears as though the installer is having some sort of 1023/4 cyclnder limit problem. I thought this was not an issue with LBA? Disk Geometry Information for Disk 1:3278 Cylinders, 240 Heads, 63 Sectors/Track System PartSect # Boot BCyl Head Sect FSECyl Head SectStartSect NumSects === 0 1 00 011 A0 554 15 63 63 559,377 Info: Partition didn't end on cylinder boundary. ucEndHead expected to be 239, not 15. Error #110: Number of sectors in partition is inconsistent. ucSectors = 559377 end - begin = 8377425 0 2 803701 071023 15 63 559,440 17,130,960 Info: End C,H,S values were large drive placeholders. Actual values are: 0 2 80 3701 07 1169 239 63 559440 17130960 0 3 00 102301 071023 15 63 17,690,400 25,734,240 Info: Begin C,H,S values were large drive placeholders. Info: End C,H,S values were large drive placeholders. Actual values are: 0 3 00 117001 07 2871 239 63 17690400 25734240 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Programming problem, Shared Memory
Please help me with the simple 'Shared Memory' example.. I cant use fork, many
different
applications may speaking to one 'server' application..
This small function can run as the memory server (pass bogus parameters) and as a
client
in another terminal (dont pass any parameters) I can read from the server the int and
string but not the server allocated string..
What am I doing worng??
Please examine: (yes -- very new to NOT USING WINDOWS OS's)
file://FreeBSD 4.0
#include
#include
#include
#include
#include
#include
#include
struct SharedMemBlock
{
char *APtr; // To be allocated
int AInt; // A simple set
char AStr[40]; // A simple Set
};
SharedMemBlock *SMB = NULL;
int main (int argc, char *argv[])
{
key_t KeyToIt = ftok(".",'8');
int shmid;
if (argc > 2) // Any passed junk -- just tell is to be a 'server'
{
if ((shmid = shmget(KeyToIt, sizeof (struct SharedMemBlock),IPC_CREAT|IPC_EXCL|0666))
== -1)
{
printf("Already exists -- Please shutdown originating server");
}
else
{
SMB = (struct SharedMemBlock *)shmat(shmid,0,0);
SMB->AInt = 97; // A simple set
strcpy(SMB->AStr,"Hello how are you"); // A simple set
if ((SMB->APtr = (char *)malloc(100) ) != NULL)
{
printf("APtr Allocated");
strcpy(SMB->APtr,"WOW IT WORKED");
}
else
{
printf("No APtr Allocated");
}
// OK, the 'server' is up, now with another xterm run this same
// program again WITHOUT passing any parameters.. that is the 'Client'
// You can run the client as many times as you wish.. Util the Server's
// getchar() is satisfied
getchar();
if (SMB->APtr != NULL)
{
free(SMB->APtr);
SMB->APtr = NULL;
}
}
}
else
{
// This is the client who wants to read the servers memory
if ((shmid = shmget(KeyToIt, sizeof (struct SharedMemBlock),IPC_EXCL|0666)) == -1)
{
printf("Please Start Server (Same but pass params)");
}
else
{
SMB = (struct SharedMemBlock *) shmat(shmid,0,0);
printf("---%d\n%s\n\n\n", SMB->AInt,SMB->AStr);
if (SMB->APtr != NULL) // The problem is RIGHT HERE
printf("Now trying allocated server pointer\n[%s]", SMB->APtr);
else
printf("No allocated server pointer");
}
}
return(0);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
