Re: Memory requirements between releases
On Fri, 2005-Aug-12 21:38:43 +0100, Chris wrote: The installation notes for 4.11 say, referring to i386 platform ...after installation, FreeBSD itself can be run in 4-8MB of RAM with a pared-down kernel The installation notes for 5.4 and 6 (the floppies README.TXT) say FreeBSD for the i386 requires ...at least 24 MB of RAM. Did the memory requirement really jump that much or is something different being measured? As Kris said, you are measuring two different things. Note the phrase after installation in your first quote. Installation takes substantially more memory because FreeBSD needs to load a full-sized GENERIC kernel, allocate space for a RAM disk to hold the installation filesystem process and have enough RAM left over to actually run the installaton processes. Once you've installed FreeBSD, you can prune down the kernel and you don't need the RAM disk. That said, 5.x is larger than 4.x (which is larger than 3.x, etc). I have on old tosh 110CT laptop with 24mb memory I want to set up as a wireless router/NAT box but would prefer to use 6 or 5.4. Can I reduce the amount of memory required? I have compiled a reduced kernel but it swaps like mad when compiling. Kismet and deps took over 12 hours. Just after boot and not doing anything it has about 2mb free and 17 processes running. 24MB should be adequate as a SOHO wireless router/NAT box but doing compilations will stress it significantly (as you've noticed). It would be too small if you were going to run lots of applications (named, squid etc) 2MB free sounds about right. The Unix kernel sees free space as wasted space and tries to avoid having too much of it. You can add inactive to the free memory to get a better idea of how much RAM isn't being used, and the cache will shrink if processes need for RAM. As long as your system isn't paging during normal operation (normal operation for a firewall excludes compiling ports or the kernel), then you have enough RAM. 17 processes sounds a bit high. You can probably find some that aren't necessary - in particular, you probably only want one or two gettys. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/sys/net80211 ieee80211.c ieee80211_input.c ieee80211_ioctl.c ieee80211_node.c ieee80211_node.h ieee80211_output.c ieee80211_proto.c ieee80211_proto.h ieee80211_var.h src/sys/dev/ath if_ath.c src/sys/dev/ipw if_ipw.c ...
On Saturday 13 August 2005 14:27, Sam Leffler wrote: [Not sure why you're sending this to cvs-all] Oops, freebsd-stable@ is probably better. Daniel O'Connor wrote: ipw is still broken [for me].. Sorry but that wasn't the question. I don't believe the commit you are responding to changed the behaviour of the ipw driver and that was what I wanted to confirm. OK, same old behaviour then :) [inchoate 13:20] ~ sudo ifconfig ipw0 ipw0: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500 inet 192.168.1.100 netmask 0xff00 broadcast 192.168.1.255 ether 00:04:23:a4:12:74 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid dons channel 6 authmode OPEN privacy OFF txpowmax 100 Someone reported the ipw driver at the author's web site works (better); you might try that. Unfortunately the code in the tree is not being maintained so far as I can tell. Hmm.. Maybe because it hasn't been broken :) (ie it's older). I will try and search for the date of breakage to provide some more information. It is somewhat annoying that both ipw and ndis are hosed and used to work on at least a basic level. I don't believe the ipw driver does honors any of the net80211 debug controls. I see.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgp8JFFaLNmpg.pgp Description: PGP signature
Re: Memory requirements between releases
On Saturday, 13. August 2005 10:32, Peter Jeremy wrote: 24MB should be adequate as a SOHO wireless router/NAT box but doing compilations will stress it significantly (as you've noticed). Probably stating the obvious here, but that's where those fine binary packages FreeBSD builds from ports are really convenient. :) -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgpBJxYs3doej.pgp Description: PGP signature
Re: Too short ethernet frame...
Just now, I add date=2005.07.31.03.00.00 to my src cvsup sup-file and make kernel, too short ethernet frames are still sniffered. But when I add date=2005.07.22.03.00.00 to sup-file and cvsup and make kernel, the damn datagrams gone!!! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/sys/net80211 ieee80211.c ieee80211_input.c ieee80211_ioctl.c ieee80211_node.c ieee80211_node.h ieee80211_output.c ieee80211_proto.c ieee80211_proto.h ieee80211_var.h src/sys/dev/ath if_ath.c src/sys/dev/ipw if_ipw.c ...
Daniel O'Connor wrote: On Saturday 13 August 2005 14:27, Sam Leffler wrote: [Not sure why you're sending this to cvs-all] Oops, freebsd-stable@ is probably better. Not really, but whatever. Daniel O'Connor wrote: ipw is still broken [for me].. Sorry but that wasn't the question. I don't believe the commit you are responding to changed the behaviour of the ipw driver and that was what I wanted to confirm. OK, same old behaviour then :) [inchoate 13:20] ~ sudo ifconfig ipw0 ipw0: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500 inet 192.168.1.100 netmask 0xff00 broadcast 192.168.1.255 ether 00:04:23:a4:12:74 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid dons channel 6 authmode OPEN privacy OFF txpowmax 100 Someone reported the ipw driver at the author's web site works (better); you might try that. Unfortunately the code in the tree is not being maintained so far as I can tell. Hmm.. Maybe because it hasn't been broken :) (ie it's older). I will try and search for the date of breakage to provide some more information. It is somewhat annoying that both ipw and ndis are hosed and used to work on at least a basic level. The ipw and iwi drivers (at least) have never worked right so far as I can tell. At one point I tried the iwi driver and it kinda worked but failed in many common scenarios and in general was very fragile. I no longer have the facilities to even test these drivers and given that I know of no cardbus cards w/ intel parts in them it's unlikely I ever will unless someone wants to donate a laptop dedicated to testing. When these drivers (as well as others) were committed to the tree I warned the author they had issues (actually I told him _before_ they were committed). I explained that they were violating net80211 api's reaching inside data structures where they should not be and otherwise had problems that were going to cause trouble (e.g. the locking of the rx path was wrong). When the changes were committed to support WPA I again explained that the changes were wrong. All these warnings were ignored. I cannot be responsible for drivers that are unmaintained and written in the ways I've described. The ndis support has a similarly incestuous relationship with the net80211 layer and it's author too has been distant of late. A lot of this is a byproduct of C's inability to properly hide data. When you need to expose information across files anyone can access it and in this case it enables drivers to be written that break when you change the internal workings of net80211. I am very happy to see new drivers in the tree but unless they are maintained it's not clear they should be incorporated. This is in fact the reason I didn't break these drivers into the tree in the first place (i.e. I had no time to maintain them). I don't believe the ipw driver does honors any of the net80211 debug controls. I see.. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 5.4 pagedaemon abnormal loading
Hi all: I have encountered a strange situation which my host went out of countrol out of peak time. top -S shows that CPU Sys. is over 90 %, and pagedaemon has very high loading, then the server died. Would anyone give me some advices to solve this queer problem? Thanks and have a nice day, Weicheng Pan. === top -S: last pid: 38024; load averages: 11.03, 39.34, 25.33 up 1+10:55:52 03:49:51 299 processes: 8 running, 250 sleeping, 41 waiting CPU states: % user, % nice, % system, % interrupt, % idle Mem: 475M Active, 1258M Inact, 220M Wired, 50M Cache, 112M Buf, 3976K Free Swap: 1024M Total, 1024M Free PID USERNAME PRI NICE SIZERES STATE C TIME WCPUCPU COMMAND 55 root -160 0K 8K RUN0 6:05 104.64% 104.64% pagedaem on 44 root -28 -147 0K 8K WAIT 1 4:18 14.94% 14.94% swi5: cloc k sio 38019 root 1210 5852K 3356K RUN1 0:06 11.34% 10.50% httpd 38023 wcpan 1220 2676K 1820K CPU1 1 0:03 17.75% 9.38% top 516 root 1150 3480K 8K select 0 0:11 162.00% 7.91% sendmail 15131 www 4 10 149M 8K accept 0 2:58 24.75% 4.49% httpd 3 root-80 0K 8K - 1 0:35 4.35% 4.35% g_up 37946 wcpan 1090 6212K 8K select 0 0:07 5.51% 2.49% sshd systat -vm 1 usersLoad 35.17 54.01 27.95 Aug 14 03:48 Mem:KBREALVIRTUAL VN PAGER SWAP PAGER Tot Share TotShareFree in out in out Act 17666167460 271234814144 57140 count All 2047068 11416 728943219748 pages Interrupts Proc:r p d s wCsw Trp Sys Int Sof Flt 87 cow 236 total 3 2226 103 208 285 287 28 200 227316 wire6: fdc0 484556 act 128 8: rtc 98.1%Sys 1.9%Intr 0.0%User 0.0%Nice 0.0%Idl 1286108 inact 13: npx |||||||||| 50972 cache 14: ata 6176 free19: ata daefr 4 24: bge Namei Name-cacheDir-cache 81 prcfr 4 25: bge Calls hits% hits% 16 react 100 0: clk 102 102 10010 pdwake 26 zfod4323760 pdpgs Disks ad8 ad10 8 ofodintrn KB/t 0.00 0.00 32 %slo-z 114464 buf tps 0 0 143 tfree35 dirtybuf MB/s 0.00 0.00 10 desiredvnodes % busy0 0 90089 numvnodes 48765 freevnodes ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
IRQ conflict between twa0 and skc0
So I'm having yet another problem with my AMD64x2/nforce4 system. Of the two builtin NICs 5.4-S is only recognizing the marvell gigabit chip, which wasn't a problem until I added a 3ware 9500S-12. With the 3ware card in the network doesn't work, take it out and it works. From the dmesg bits below it looks like both twa0 and skc0 are trying to use irq 18 and twa0 is winning. I have the bios set to handle pnp stuff so I don't know whats going on. Any suggestions? --- pcib1: ACPI PCI-PCI bridge at device 9.0 on pci0 pci1: ACPI PCI bus on pcib1 3ware device driver for 9000 series storage controllers, version: 3.50.00.017 twa0: 3ware 9000 series Storage Controller port 0xac00-0xacff mem 0xfd00-0xfd7f,0xfcfff000-0xfcfff0ff irq 18 at device 6.0 on pci1 twa0: INFO: (0x15: 0x1300): Controller details:: 12 ports, Firmware FE9X 2.06.00.009, BIOS BE9X 2.03.01.051 pci1: display, VGA at device 7.0 (no driver attached) skc0: Marvell Gigabit Ethernet port 0xa800-0xa8ff mem 0xfcff8000-0xfcffbfff irq 18 at device 10.0 on pci1 skc0: Marvell Yukon Lite Gigabit Ethernet rev. (0x9) sk0: Marvell Semiconductor, Inc. Yukon on skc0 sk0: Ethernet address: 00:01:29:fc:8c:59 miibus0: MII bus on sk0 e1000phy0: Marvell 88E1000 Gigabit PHY on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto skc0: couldn't set up irq e1000phy0: detached miibus0: detached sk0: detached device_attach: skc0 attach returned 22 pci0: bridge at device 10.0 (no driver attached) --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/sys/net80211 ieee80211.c ieee80211_input.c ieee80211_ioctl.c ieee80211_node.c ieee80211_node.h ieee80211_output.c ieee80211_proto.c ieee80211_proto.h ieee80211_var.h src/sys/dev/ath if_ath.c src/sys/dev/ipw if_ipw.c ...
Quoting Sam Leffler [EMAIL PROTECTED]: The ipw and iwi drivers (at least) have never worked right so far as I can tell. At one point I tried the iwi driver and it kinda worked but failed in many common scenarios and in general was very fragile. I no longer have the facilities to even test these drivers and given that I know of no cardbus cards w/ intel parts in them it's unlikely I ever will unless someone wants to donate a laptop dedicated to testing. If you have a notebook with a MiniPCI slot, the Intel 2100, 2200 and 2915 MiniPCI cards can be had in the after-market for US$30 or less. This message was sent using IMP, the Internet Messaging Program. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IRQ conflict between twa0 and skc0
On Sat, August 13, 2005 8:02 pm, Brandon Fosdick said: So I'm having yet another problem with my AMD64x2/nforce4 system. Of the two builtin NICs 5.4-S is only recognizing the marvell gigabit chip, which wasn't a problem until I added a 3ware 9500S-12. With the 3ware card in the network doesn't work, take it out and it works. From the dmesg bits below it looks like both twa0 and skc0 are trying to use irq 18 and twa0 is winning. I have the bios set to handle pnp stuff so I don't know whats going on. Any suggestions? The easiest thing would probably be to disable the onboard sk card, and put in an em (intel gigabit card). The marvell chipset and driver is known to be problematic. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IRQ conflict between twa0 and skc0
Mike Jakubik wrote: The easiest thing would probably be to disable the onboard sk card, and put in an em (intel gigabit card). The marvell chipset and driver is known to be problematic. I had thought of that, but the motherboard only has 2 non-express PCI slots and they're both currently filled by the video card and the raid card. I could take the video card out, but then I wouldn't be able to see what I was doing. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IRQ conflict between twa0 and skc0
On Sun, August 14, 2005 12:47 am, Brandon Fosdick said: I had thought of that, but the motherboard only has 2 non-express PCI slots and they're both currently filled by the video card and the raid card. I could take the video card out, but then I wouldn't be able to see what I was doing. You can always use ssh and a serial console. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IRQ conflict between twa0 and skc0
On Sun, August 14, 2005 12:47 am, Brandon Fosdick said: I had thought of that, but the motherboard only has 2 non-express PCI slots and they're both currently filled by the video card and the raid card. I could take the video card out, but then I wouldn't be able to see what I was doing. Forgot to mention. You can always buy a cheap pciE video card :) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: IRQ conflict between twa0 and skc0
From: Brandon Fosdick Mike Jakubik wrote: The easiest thing would probably be to disable the onboard sk card, and put in an em (intel gigabit card). The marvell chipset and driver is known to be problematic. I had thought of that, but the motherboard only has 2 non-express PCI slots and they're both currently filled by the video card and the raid card. I could take the video card out, but then I wouldn't be able to see what I was doing. Try switching slots with the RAID and video cards. It's silly, but then so is PCI interrupt routing. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 4.11 to RELENG_6
In message: [EMAIL PROTECTED] Oliver Fromme [EMAIL PROTECTED] writes: : Björn König [EMAIL PROTECTED] wrote: : Randy Bush wrote: :any peculiarities/clues for upgrading an antique from 4.11 to :RELENG_6 beyond the To upgrade in-place from 5.x-stable to :current in UPDATING? : : I guess not. From the release notes of 6.0-BETA2: : : Source upgrades to FreeBSD 6.0-CURRENT are only supported from FreeBSD : 5.3-RELEASE or later. Users of older systems [...] : : Unfortunately, that statement is ambiguous: FreeBSD 4.11 : (Jan. 2005) is _not_ older than 5.3 (Nov. 2004). However, : I guess that's not what the release notes really mean. Older here means 'numerically smaller' not 'released earlier'. Warner ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IRQ conflict between twa0 and skc0
Mike Jakubik wrote: Forgot to mention. You can always buy a cheap pciE video card :) You're a big help :) I was fiddling and I noticed something odd. Previously, the ESCD screen at boot showed the raid controller and network controller both at IRQ 5. The dmesg I sent before showed both at IRQ 18. That seemed odd to me. I also noticed that unused drive channels were being assigned IRQs so I disabled them in the BIOS. The idea being to free up an IRQ and maybe one of the controllers would use it. Now the ESCD table shows both the raid and the network on IRQ 10 and dmesg still shows them at IRQ 18. This seems screwy to me, but I have no idea what it means. Now that I know both IRQs 10 and 18 are useable, is there some way to force the drivers? Aren't there some boot hints that handle this? Or was it done in the kernel config. I can't remember. BTW, this is all with the stock SMP kernel. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Memory requirements between releases
In message: [EMAIL PROTECTED] Chris [EMAIL PROTECTED] writes: : The installation notes for 5.4 and 6 (the floppies README.TXT) say : FreeBSD for the i386 requires ...at least 24 MB of RAM. : : Did the memory requirement really jump that much or is something : different being measured? Not really, if you know what you are doing. : I have on old tosh 110CT laptop with 24mb memory I want to set up as a : wireless router/NAT box but would prefer to use 6 or 5.4. Can I reduce : the amount of memory required? I have compiled a reduced kernel but it : swaps like mad when compiling. Kismet and deps took over 12 hours. Just : after boot and not doing anything it has about 2mb free and 17 processes : running. You can deploy to one of these laptops, but chances are good that the extra memory required for large compiles (anything bigger than hello world) will swap its little brains out. You can trim the kernel down a lot for the 100CT. You can eliminate all the SCSI stuff, all the raid stuff, most of the pci stuff, all the old crusty ISA ethernet hardware. You can trim down usb quite a bit, eliminate eisa. That helps a lot. I can boot on my 16MB laptop, but it is a little painful to do much on. On that I can elimiante usb and pci since there's no pci bus at all. Oh, and firewire too! Warner ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IRQ conflict between twa0 and skc0
Darren Pilgrim wrote: Try switching slots with the RAID and video cards. It's silly, but then so is PCI interrupt routing. Unbelievable. Who ever wrote the PCI spec should have been shot. I switched the cards and now the network card is sharing an interrupt with the video card, but neither seems to mind. More importantly it isn't sharing with the raid card and they all appear to be happy. Thanks, that was a big help. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
