Re: weekly periodic security status
On 8/25/2013 1:37 PM, Jeremie Le Hen wrote: Hi Darren, On Sun, Aug 25, 2013 at 12:45:22PM -0400, Darren Pilgrim wrote: On 8/25/2013 7:05 AM, Jeremie Le Hen wrote: And the following variables to control whether you want each check to run daily, weekly or directly from crontab (the default, backward compatible values are shown): What do we do if we want to run a check both daily and weekly? I really don't see the point of running some checks weekly when you do daily. Do you have a particular example in mind? On one set of systems, I have a log analyser run as a periodic script. On a daily run, it grabs and filters logs into a database. On weekly runs, it does some statistical analysis of the filtered logs in the database. On monthly runs, it does a larger set of stats and a bit of housekeeping. The script lives in /usr/local/libexec and is hardlinked into the /usr/local/etc/periodic/ subtree and cases out the value of $0. The new framework would let me rely on the environment instead of $0, which, IMO, is more reliable. I'd need to be able to tell periodic to run that script with the daily, weekly and monthly security runs, though. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: weekly periodic security status
On 8/26/2013 5:09 PM, Jeremie Le Hen wrote: On Mon, Aug 26, 2013 at 12:29:30PM -0400, Darren Pilgrim wrote: The new framework would let me rely on the environment instead of $0, which, IMO, is more reliable. I'd need to be able to tell periodic to run that script with the daily, weekly and monthly security runs, though. If I understand what you say correctly, this should continue to work. As I understand the framework, I can only set the enable to NO, daily, weekly or monthly. Periodic will only run it one of the periods. How would I set it to run in all three? How would I set to run in only two of the three periods? It seems like you could add this functionality by adding stars to each end of the case patterns in check_yesno_period. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: weekly periodic security status
On 8/25/2013 7:05 AM, Jeremie Le Hen wrote: And the following variables to control whether you want each check to run daily, weekly or directly from crontab (the default, backward compatible values are shown): What do we do if we want to run a check both daily and weekly? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: weekly periodic security status
Thank you for this, but if I may make one suggestion: don't combine all the security report settings--keep both daily_* and weekly_*. This makes possible running some security tasks on a daily basis and others on a weekly basis. For example, daily pkg/portaudit checks, but weekly filesystem scans. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: will 9.2 be called 'diehard'? or maybe Naktomi?
http://freebsd.1045724.n5.nabble.com/will-9-2-be-called-diehard-or-maybe-Naktomi-tp5562525p5836490.html Perhaps a creative type might do up McKusick's mascot a la Bruce Willis. Bonus points for weapon hosters made from Christmas gift wrap tape. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Discussing ideas or wish list
On 8/9/2013 9:29 PM, Patrick Dung wrote: Yes, I can install lang/perl5.12. But in that case, I can't install other perl /p5 pre-build packages (which depends on Perl 5.14) provided by FreeBSD, due to dependency problem. Install them from ports and add the external dependencies from packages. Tools like portmaster even have options to automate this for you. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Discussing ideas or wish list
On 8/9/2013 9:34 AM, Patrick Dung wrote: Let share an experience for my case. I have installed OTRS (a great ticketing system) in FreeBSD 9.0. The Perl version at that time is 5.12. For me, upgrading to FreeBSD 9.1 take some time because the Perl version at that time is 5.14. OTRS depends on lots of Perl/p5 modules/packages. This is not scalable if I need to upgrade multiple servers. Perl is not in the base system, so why is this an issue? If you need 5.12 on 9.1, install lang/perl5.12. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On 2012-07-08 02:31, Doug Barton wrote: On 07/07/2012 17:47, Darren Pilgrim wrote: On 2012-07-07 16:45, Doug Barton wrote: Also re DNSSEC integration in the base, I've stated before that I believe very strongly that any kind of hard-coding of trust anchors as part of the base resolver setup is a bad idea, and should not be done. We need to leverage the ports system for this so that we don't get stuck with a scenario where we have stale stuff in the base that is hard for users to upgrade. Considering the current root update cert bundle has a 20-year root CA and 5-year DNSSEC and email CAs, Neither of which has any relevance to the actual root zone ZSK, which could require an emergency roll tomorrow. Emergency root key change is handled by just running unbound-anchor again and have it download the new ZSK. The only thing it can't do is retrieve the root cert chain--it either uses the compiled-in copy or a PEM file passed with the -c flag. Am I missing something in that process? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On 2012-07-07 16:45, Doug Barton wrote: Also re DNSSEC integration in the base, I've stated before that I believe very strongly that any kind of hard-coding of trust anchors as part of the base resolver setup is a bad idea, and should not be done. We need to leverage the ports system for this so that we don't get stuck with a scenario where we have stale stuff in the base that is hard for users to upgrade. Considering the current root update cert bundle has a 20-year root CA and 5-year DNSSEC and email CAs, I don't think it's unreasonable to maintain a copy of icannbundle.pem in the source tree or simply rely on the copy built into unbound-anchor. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: /etc/resolv.conf getting over written with dhcp
On 2012-06-15 07:14, Eugene Grosbein wrote:
15.06.2012 19:09, Varuna пишет:
About 2***, so what are the conditions to be true to figure out that
/etc/resolv.conf has not changed?
There is simple solution: create file /etc/dhclient-enter-hooks
and override add_new_resolv_conf() there to do nothing:
add_new_resolv_conf() {
return 0
}
Works just fine for my systems.
Or just add something like:
interface eth0 {
supersede domain-name example.com.;
supersede domain-name-servers 192.0.2.1;
}
To your /etc/dhclient.conf and make dhclient do the right thing.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD Boot Times
On 2012-06-13 14:18, Eitan Adler wrote: On 13 June 2012 14:16, claudiu vasadiclaudiu.vas...@gmail.com wrote: If you simplky do sysctl -d hw.usb.no_boot_wait you will see the explanation ;) No, you see a one liner that only explains things if you already understand what is going on: I believe it pertains to mounting root from a USB device. When set to 0, usb_attach tells VFS to wait on the USB device being attached. This results in not mounting root until the USB busses are all fully explored. If you don't rely on any USB devices for multi-user start-up, set this to 1 and let the kernel launch multi-user without waiting for USB probing. This is nice for those systems where the BIOS takes a long time to release control of any hubs with keyboards attached. IMO I'd rather have my gear do the boot process in a well-ordered fashion and get everything right, than try to shave off a handful of seconds at the risk of unreliable booting. For servers, the baseboard, OOB management, and SCSI BIOSes can mean minutes between power-on and OS bootstrap, so an extra 20 seconds is nothing. :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Is the FreeBSD clock UTC or TAI?
This came up during discussion of leap seconds and why UTC and TAI are different. My question is, does FreeBSD's internal clock use UTC or TAI for timekeeping? That is, is wallclock calculated from an exact count of the number of seconds since epoch (TAI), then adjusted with a leap seconds table to match UTC, or does it internally use UTC and have code to deal with the ambiguous seconds that occur at each leap second? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FYI: 3Ware 9650 can cause data corruption
Peter B wrote: 3ware 9650 in RAID6 mode with firmware version 3.08.00.004 seems to cause data corruption when rebuilding a single disc with raid6. http://www.webmasternetwork.se/f4t23551.html (Swedish) I thought this was serious enough for people to know. If another mailinglist is more appropiate for this kind of FYI then tell. This is a known issue with 3ware software v9.4.1.0 and 9.4.1.1 (firmware v3.08.00.004). 3ware released software v9.4.1.2 (firmware 3.08.02.005) that corrects the problem over three months ago and it has since been obsoleted by 9.4.1.3 and 9.5.0 (released earlier this week). In fact, the link you cite links to 3ware's advisory: http://www.3ware.com/support/UserDocs/RAID6-data-integrity-customer-notification_061907-FINAL.pdf While it is appreciated that you felt obligated to post this important bug notice, it would be even more appreciated if in the future, you would do a bit of research before clicking send. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A few questions...
Daniel Molina Wegener wrote: Hello, I need information about few things, I hope someone can help me and thanks in advance. a) Is there any function or variable that tells me which is the root user UID in the system, or root always have 0 and it's an elegant option to compare the variables or structure members against zero. Root is always UID 0. Checking UID == 0 is the common practice for determining if the effective UID has root priveleges. b) Can normal users look for system processes or kernel threads? Yes, depending on the value of the security.bsd.see_other_uids sysctl. If security.bsd.see_other_uids=0, non-root users can only see their own processes. c) Can root look for system processes or kernel threads? Yes, regardless of the value of security.bsd.see_other_uids. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MS Vista vs FreeBSD's bootloader
Ivan Voras wrote: [EMAIL PROTECTED] wrote: FWIW, if you just got your new computer with Windows Vista installed and were hoping to dual boot FreeBSD on it, let me tell you that FreeBSD's bootloader will screw things up. vista doesn't like: - bootloaders different than the one used by Vista. - Making a non Vista partition active. I can confirm this - messing with the boot sector will make Vista unbootable, but it can be repaired with the installer (of course, you lose FreeBSD at that point). It seems Vista uses registry or some other binary format to store boot info (as opposed to WinXP which uses a text file...) and it protects the boot loader for DRM reasons. This has been SOP at Microsoft for almost a decade. If you want to dual-boot Windows, the solution is to use the established methods for adding additional boot options to the built-in Windows boot-loader. For Vista, this means using the BCDEdit command-line tool to manipulate the Boot Configuration Data in the system registry rather than Notepad to edit boot.ini. BCDEdit and its options are detailed on MSDN: http://msdn2.microsoft.com/en-us/library/aa468636.aspx A slightly more useful discussion of BCDedit on bsdforums.org: http://www.bsdforums.org/forums/showthread.php?t=48405 It specifies Linux, but this is a tutorial for adding a non-Windows boot option to the Vista Boot Manager: http://port25.technet.com/archive/2006/10/13/Using-Vista_2700_s-Boot-Manager-to-Boot-Linux-and-Dual-Booting-with-BitLocker-Protection-with-TPM-Support.aspx -- Darren Pilgrim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Port/Package Management?
Yong Ma wrote: This time I am interested in the operational principle of the port/package system, what is going on while installing packages, and where is the source files if I want to do some modification? /usr/ports/Mk bsd.port.mk is the central component. There are extra files for various frameworks and platforms. -- Darren Pilgrim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LDAP integration
Mike Meyer wrote: In [EMAIL PROTECTED], Vulpes Velox [EMAIL PROTECTED] typed: LDAP is nice organizing across many systems, but if you are just dealing with one computer it is complete over kill for any thing. In that situation, it's not merely overkill, it's may actually be a bad idea. Can you say AIX SDR? How about Windows registry? Those system both took the approach of putting all the configuration information in a central database. This creates problems because the tools needed to examine/fix the config database require a complex environment - at least compared to a statically linked copy of ed. LDAP may not be so bad, but it still makes me nervous. On the other hand, if you've got a flock of boxes to manage, having a way to tell the rc subsystem Go read config values from this LDAP server seems like a very attractive alternative. And to think, all these years I've been wasting my time and effort using NFS and rsync to centralize the configurations of server farms. -- Darren Pilgrim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Options for boot program
I don't know why I was included in the CC list for this thread, nor do I have any input on the subject. Please trim my address from the CC list. Thanks. -- Darren Pilgrim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to disable a src.conf on command-line
M. Warner Losh wrote: So if you make WITH_SSP off by default, then having WITH_SSP in the src.conf can't be overridden. If you have it on by default, having WITHOUT_SSP in the src.conf file can't be overriden. this appears to be an unintended flaw with the with/without stuff. I'm not sure the right way to compensate. I can't speak for the right way, but if you specify the variable in src.conf/make.conf with ?= instead of =, you can override it on the command-line: # grep KERNCONF /etc/make.conf KERNCONF?=TTPWEB # make -V KERNCONF TTPWEB # env KERNCONF=SOMETHING_ELSE make -V KERNCONF SOMETHING_ELSE -- Darren Pilgrim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to disable a src.conf on command-line
M. Warner Losh wrote: In message: [EMAIL PROTECTED] Darren Pilgrim [EMAIL PROTECTED] writes: : M. Warner Losh wrote: : So if you make WITH_SSP off by default, then having WITH_SSP in the : src.conf can't be overridden. If you have it on by default, having : WITHOUT_SSP in the src.conf file can't be overriden. this appears to : be an unintended flaw with the with/without stuff. I'm not sure the : right way to compensate. : : I can't speak for the right way, but if you specify the variable in : src.conf/make.conf with ?= instead of =, you can override it on the : command-line: : : # grep KERNCONF /etc/make.conf : KERNCONF?=TTPWEB : # make -V KERNCONF : TTPWEB : # env KERNCONF=SOMETHING_ELSE make -V KERNCONF : SOMETHING_ELSE ?= doesn't mesh well with WITH/WITHOUT because then it will always be defined, thus defeating its purpose. Use .ifndef to define WITH/WITHOUT iff its counterpart is undef: .ifndef WITHOUT_FOO WITH_FOO=def .endif -- Darren Pilgrim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Core Duo - only one cpu being used
Eric Anderson wrote: Forgive me if I've missed this on a list somewhere, but My new laptop with a Core Duo doesn't seem to use both CPU's. It sees both, but I never see anything on cpu 1. Here's a top snippet: Your top output shows a single process eating the CPU. A single process can't span CPUs, so you're only going to see one CPU in use. You need to do something in parallel, like make -j N where N 1. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Boot manager beep (revisited)
Eric Anderson wrote: This thread: http://lists.freebsd.org/pipermail/freebsd-stable/2005-December/020572.html mentions a patch to disable the boot manager beep, and also discusses having it optional. I don't have enough asm-fu to make that option happen, but I can tell you, that on laptops, that beep is really annoying, and amazingly loud. Is this just waiting for an able minded person to code up the options and submit? Most laptops have a PC speaker volume control or on/off at boot in the BIOS. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can kldload trigger pci bus rescan?
[EMAIL PROTECTED] wrote: I tried to use kldload to load our HBA driver. But the driver's pci probe function can not find the HBA card! By this do you mean that when you have the card in the system, FreeBSD booted and you kldload the driver, you don't see kernel messages showing the appropriate attach messages? Is anything printed? Does it mean that kldload can not trigger pci bus rescan? If so, what should I do for triggering pci bus rescan after loading our pci driver? As Daniel and Warner already stated, the PCI rescan is automatic. This is more likely an identification or driver mismatch problem. Please provide the following: - The exact make and model of the HBA card. - The exact version of FreeBSD you're using. - Which driver you're trying to use. This information will allow us to nail down possible reasons why the attach is not occuring. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can kldload trigger pci bus rescan?
[EMAIL PROTECTED] wrote:
Hi guys:
My situation is:
(1) We are porting our HBA driver (Promise FastTrak TX4310 SoftRaid5) from
Linux to FreeBSD(6.0). Our HBA driver can work normally under Linux.
(2) At this time, I just wrote a sample driver code (see sr5.c in the
attached file) to check the driver's probe function in FreeBSD.
(3) After I successfully compiled the codes, I run make load (see Makefile
and load.info in the attached file) for testing.
(4) Our probe function was called indeed, but no matching pci device was
found! (Yes, I have plugged our HBA card in the system).
(5) Our HBA card information can be found by running pciconf (see
pciconf.info in the attached file).
The only two storage devices in the pciconf output are:
[EMAIL PROTECTED]:7:1: class=0x01018a card=0x74411022 chip=0x74411022
rev=0x04 hdr=0x00
vendor = 'Advanced Micro Devices (AMD)'
device = 'AMD-768 EIDE Controller'
class= mass storage
subclass = ATA
[EMAIL PROTECTED]:4:0: class=0x010400 card=0x3515105a chip=0x3515105a
rev=0x02 hdr=0x00
vendor = 'Promise Technology Inc'
class= mass storage
subclass = RAID
The first looks like the ATA controller on the motherboard. The second
is your Promise ATA RAID card. Both devices are already attached by
FreeBSD's ATA framework. You will need to patch FreeBSD's ATA framework
to not detect your card. The attached patch should do the trick (it
removes the corresponding PCI ID for your card). I tested the patch to
the point that it compiles, but I can't guarantee this will prevent the
attach or even result in a bootable kernel, so test carefully.
To apply the patch, do the following with root privileges:
cd /usr/src # Replace /usr/src with the base of your src tree.
patch /path/to/ata_no_PDC40719.diff
If you have ata compiled into your kernel, rebuild your kernel. If
you're loading the ATA modules, you can get away with just rebuilding
the ata modules:
cd /usr/src/sys/modules/ata
make clean make depend make make install
--- sys/dev/ata/ata-chipset.c.old Fri Oct 14 02:34:50 2005
+++ sys/dev/ata/ata-chipset.c Wed Apr 26 22:14:14 2006
@@ -2409,7 +2409,6 @@
{ ATA_PDC40518, 0, PRMIO, PRSATA2, ATA_SA150, Promise PDC40518 },
{ ATA_PDC40519, 0, PRMIO, PRSATA2, ATA_SA150, Promise PDC40519 },
{ ATA_PDC40718, 0, PRMIO, PRSATA2, ATA_SA300, Promise PDC40718 },
- { ATA_PDC40719, 0, PRMIO, PRSATA2, ATA_SA300, Promise PDC40719 },
{ 0, 0, 0, 0, 0, 0}};
char buffer[64];
uintptr_t devid = 0;
--- sys/dev/ata/ata-pci.h.old Fri Oct 14 02:34:50 2005
+++ sys/dev/ata/ata-pci.h Wed Apr 26 22:14:45 2006
@@ -213,7 +213,6 @@
#define ATA_PDC405180x3d18105a
#define ATA_PDC405190x3519105a
#define ATA_PDC407180x3d17105a
-#define ATA_PDC407190x3515105a
#define ATA_PDC206170x6617105a
#define ATA_PDC206180x6626105a
#define ATA_PDC206190x6629105a
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
Eric Anderson wrote: If I could figure out how to make sh do colors, I'd do it. :) Please do not use colors in rc. Escape-sequenced colors make unacceptable assumptions about the user and syslogd strips escape sequences anyway, so it would be of no use to logged consoles. Serial consoles introduce other problems with buggy escape handling in third-party terminal programs. A good text layout and descriptive status messages do far more for clarity and readability than any use of color ever can. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What's in a (device) name?
[EMAIL PROTECTED] wrote: On Mon, Apr 10, 2006 at 09:47:41AM -0400, Mike Meyer wrote: In [EMAIL PROTECTED], [EMAIL PROTECTED] typed: On Sun, Apr 09, 2006 at 10:47:53PM -0400, Mike Meyer wrote: Firewire would seem to be a lot like USB - hot pluggable and chainable, though I'm not sure if something like a firewire hub. What does it to do wire down device addresses? FireWire devices have uuids, you can simply enumerate them using those :-) Where do those come from? Assigned by the user? Dynamically by the controller? By the manufacturer? IIRC by the manufacturer, like MAC addresses. I think you mean the 64-bit EUI? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever
I think at this point it's been pretty well established that: - Device naming and unit numbering is not stable enough to avoid breakage across hardware changes. - There is a need for generic and/or descriptive interface naming independent of driver- and probe-order-based naming. - There are static bits of information available about each device in the system that can be used to locate a specific device that would be sufficient to allow assignment of a network configuration to a physical device, not it's attached name. If I were to write an rc.d script to use descriptive network interface names and wire configs to static hardware identification, would there be support for such a feature? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever (solution?)
Mike Meyer wrote: In [EMAIL PROTECTED], Darren Pilgrim [EMAIL PROTECTED] typed: You could test two different drivers on the same hardware and you wouldn't have to duplicate or modify your ifconfig lines in /etc/rc.conf, just run: Yup, and this is an advantage. On the other hand, if you tie the device name to the slot number (the real goal), you can swap different hardware into that slot without having to modify any configuration information at all. It wouldn't be too difficult to extend the configuration to allow entries like this: Interface0_addr=MAC 01:23:45:67:89:ab Interface1_addr=PCI 0:1:2 # pci0, device 1, function 2 Interface2_addr=USB 0:1:2 # usb0, addr 1, port 2 Add some bits to grok dmesg or pciconf/usbdevs or maybe even trigger from devd and there you go. I should mention that the second and third options could be broken by the addition or removal of a card with a PCI bridge or USB root hub on it. Of course, this doesn't help the OP's problem of wanting to be able to address the sole interface in a system without knowing it's name in advance. Maybe a feature to provide a default name for an interface if one isn't found in the config file would do that. # ifconfig `ifconfig -l link` name GenericName ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever (solution?)
M. Warner Losh wrote: The device subsystem already exports a bus-dependent plug and play position. No need to make it specific to USB/PCI/whatever. Where is this information found? I can't find anything obvious that wouldn't change if you inserted a bus in the middle of the probe order. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever
Mike Meyer wrote: If I do care - for instance, I want to distinguish between the ethernet interface that's on the internet and the one that's on my LAN, or I want root to be on the disk with the root file system on it - then this is a PITA, because every time I add hardware to the system, or re-arrange the cards in the cage, or similar things, I risk breaking the system configuration. If the device names are completely determined by the hardware settings, then this doesn't happen. I wrote some add-on bits for /etc/rc.network in 4.x that compares the link addresses of attached network interfaces to a list of link addresses, then sets ifconfig_ifN* variables accordingly before rc.network does anything. It provides a means of wiring IP addresses to physical ports in a way that gets around the problem of probe order. If there's interest, I'll get to work on an rcNG version. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever (solution?)
Mike Meyer wrote: In [EMAIL PROTECTED], David Taylor [EMAIL PROTECTED] typed: That doesn't quite work, though. Unless you require everyone wanting to distinguish between LAN and WAN interfaces uses different types of hardware for each card, they'll still end up with xl0 and xl1 (or whatever), which is in no way better than eth0 and eth1, You're right - but at least you have the option of using different types of cards to get different names. I agree that this sucks, but it's better than nothing. This is a script to rename interfaces based on the MAC address: #!/bin/csh set mac_list = /etc/MACaddr_list foreach ifn ( `ifconfig -l link` ) set ifn_mac = `ifconfig $ifn link | grep ether | cut -d ' ' -f 2` set ifn_name = `grep $ifn_mac $mac_list | cut -d ' ' -f 2` ifconfig $ifn name $ifn_name end Where /etc/MACaddr_list contains entries of the format: 00:00:00:00:00:00 NameLengthMax15 If you add something to /etc/rc.d so that a sh-ified version of this script runs after all interfaces have attached but before any numbering or cloning takes place you can have lines like this in /etc/rc.conf: ifconfig_PublicLAN=inet a.b.c.d/24 That's far better than trying to remember what's on em0. This is an off-the-top-of-my-head, 2-minute solution, largely untested due to present lack of a victim machine. pf doesn't seem to have any issue, but I haven't tested /etc/rc.d/netif, dhclient, wpa_supplicant, interface cloning and other things people do to their network interfaces. An rc-friendly version would probably make use of something like: ifconfig_UsefulName_linkaddr=00:00:00:00:00:00 in /etc/rc.conf rather than a seperate file, but this is just a proof of concept. Comments please! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever (solution?)
Mike Meyer wrote: In [EMAIL PROTECTED], Darren Pilgrim [EMAIL PROTECTED] typed: If you add something to /etc/rc.d so that a sh-ified version of this script runs after all interfaces have attached but before any numbering or cloning takes place you can have lines like this in /etc/rc.conf: ifconfig_PublicLAN=inet a.b.c.d/24 That's far better than trying to remember what's on em0. That's certainly true. But is there an advantage to tieing the PublicLAN name to a MAC address as opposed to em0? The network interface name the user sees becomes tied directly to the physical device by way of a unique, configuration-independent identifier. The probe order and driver name become transparent to the network configuration. You could test two different drivers on the same hardware and you wouldn't have to duplicate or modify your ifconfig lines in /etc/rc.conf, just run: /etc/rc.d/netif stop PublicLAN kldunload olddriver kldload newdriver /etc/rc.d/netif start PublicLAN Within the currently available capabilities, we get the network interface equivalent of disk volume labels. [ Proposed use of PCI addresses instead of MAC addresses. ] The real problem with what I proposed is that you have to arrange to search config information for things that may not be tied to a pci bus. That could get real messy. Right, it doesn't scale to ISA or USB devices. The prior probably isn't a big deal these days, but I imagine compatibility with USB devices is fairly important. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cloning a FreeBSD HDD
Khaled Hussain wrote: Thanks for the clarification...at the moment I am trying to set a boot manager on my disk but am unsure which slice to set as the default boot selection when using the boot0cfg command. boot0cfg -Bv -s? ad2 disklabel -r ad0 (on a different bsd system) gives: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 20480004.2BSD0 0 0 # (Cyl.0 - 12*) b: 2104640 204800 swap# (Cyl. 12*- 143*) c: 1172583720unused0 0# (Cyl.0 - 7298*) e:40960 23094404.2BSD0 0 0 # (Cyl. 143*- 146*) f: 114907972 23504004.2BSD0 0 0 # (Cyl. 146*- 7298*) Am I correct in assuming that a: is slice 1, b: is slice 2, etc? No. The above is the label inside a single slice. a: is the first partition within that slice. Use fdisk to look at your slices. If you really are getting the above from /dev/ad2 rather than /dev/ad2sN where N is a number from 1 to 4, then it's in dedicated mode and the issue is moot, since there's no slice table. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RFC: Adding a ``user'' mount option
Stefan Sperling wrote: Why do GNOME/KDE rely on /etc/fstab on FreeBSD? GNOME/KDE could be patched to create mount points somewhere in the user's home directory, and issue a 'mount device mount_point' instead of 'mount mount_point' if the user clicks the device icon. Limiting GNOME/KDE to just those mounts listed in /etc/fstab provides a mechanism of access control. If GNOME/KDE allowed user mounts of any device, then it would become possible for users to mount umounted system volumes. Using fstab also makes it possible for GNOME/KDE to mount items with mount options (sync, mode limits, quotas, etc.) and just rely on the system to get it right, rather than having system-specific, parallel mount code. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CVSup upgrading?
Carlos Silva, yourdot-internet.com wrote: Hi, but, it erases all! I have a doubt if he downloads the beta kernel sources. do you have another solution? HEAD is not the correct tag. Before I go further, to avoid any confusion, there is no beta source code nor are the kernel sources maintained seperately. That said... If you want the branch of development from which the most recent (version-wise) releases are being made, use tag=RELENG_6. If you want the source tree corresponding to the point of all new development, including experimental, rapidly-changing and otherwise unstable, brand-new code not yet put through broad-base testing, use tag=.. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Why do we have the orm device?
I see it on all of my machines and have never seen it used by anything. The orm(4) man page says it's part of ISA bus support and is designed to claim ROMs sitting in the memory address space, but doesn't go into any detail why it's necessary to prevent other drivers from using ROM addresses. So why do we have this device? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Ricoh PCI to SD device?
From: Clifton Royston If that NDA says some fairly typical things, and if the FreeBSD organization (or any individual developer) poneys up the money for the standard and signs the associated NDA, then either that developer or the FreeBSD group as a whole might then be permanently barred from writing open source code to implement the protocol, as a working implementation could disclose protocol information covered as a secret by the NDA. I'm sure that's *not* what you want to see. In a roundabout way, that's exactly what I'm saying. The SDA, by their actions, doesn't give a rats posterior about freedom. They're falsely convinced technology standards are a revenue vector and are surviving solely upon Apple, Microsoft, Dell, HP, Sony, Samsung and all the other huge companies having the capital to just pony up their extortionist fees rather than making a moral stand. The only reason I have any SD hardware at all is because it was a non-removable option in the notebook I bought. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Ricoh PCI to SD device?
From: M. Warner Losh [mailto:[EMAIL PROTECTED] In message: [EMAIL PROTECTED] Darren Pilgrim [EMAIL PROTECTED] writes: : From: Brooks Davis : On Mon, Jan 09, 2006 at 11:12:30AM -0500, David Gilbert wrote: : Has anyone had a look at the following: : : [ Ricoh SD Bus Host Adapter, PCI ID 0x08221180 ] : : People are looking at it, but there are no docs available. : Apparently, there is some work being done to reverse engineer : it. Linux doesn't support it either. : : That's odd, because Ricoh provides technical documentation upon : request via the LSI Contact Us[1] page on their website. : : 1: http://www.ricoh.com/LSI/mail.html Are you sure they provide technical documentation sufficent to write the driver? The last time I asked, I got a nice document that said that it implemented the sds standard sd host interface, but didn't document what that was. TI and winbond chips datasheets are the same way. Prove me wrong. I'd love it :-) The SD protocols aren't open standards. Ricoh can't legally include information about the protocols in their documentation. Without working implementation of the SDA's standards, FreeBSD is stuck. I don't blame the funding behind FreeBSD development for not ponying up the dosh; I think such fees are extortion made legal by intellectual property laws. But hey, it's the business. It's not like we're trying to make a good, free product everyone can use, right? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Ricoh PCI to SD device?
From: Brooks Davis On Mon, Jan 09, 2006 at 11:12:30AM -0500, David Gilbert wrote: Has anyone had a look at the following: [ Ricoh SD Bus Host Adapter, PCI ID 0x08221180 ] People are looking at it, but there are no docs available. Apparently, there is some work being done to reverse engineer it. Linux doesn't support it either. That's odd, because Ricoh provides technical documentation upon request via the LSI Contact Us[1] page on their website. 1: http://www.ricoh.com/LSI/mail.html ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Intel PRO/Wireless 2200BG/2915ABG
From: Nick Strebkov Does anybody here work already on this piece of hardware? I'm very interested in getting it work under FreeBSD and ready to help. The iwi driver supports these cards. You'll want to get in touch with Sam Leffler[1] and Damien Bergamini[2] and probably help get the iwi driver fully ported and working with FreeBSD's 802.11 framework. Sam will likely be able to list off the known problems with the FreeBSD import of the driver. [1] Guru working on the net80211 framework. Email: [EMAIL PROTECTED] [2] Author of the iwi, iwp and ral drivers. Email: [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Intel PRO/Wireless 2200BG/2915ABG
From: Nick Strebkov Thanks for your answers. I have 2915ABG and Belkin F5D8230-4 access point. Will it be enough to install RELENG_6 to play with iwi stuff? That depends. You'll need firmware before you can use the iwi driver. One of show-stopper problems with the iwi driver is that connections which spew large numbers of packets (cvs, cvsup, remote X, etc.) will make the iwi device suddenly stop working. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Intel PRO/Wireless 2200BG/2915ABG
From: Nick Strebkov On Tue, Sep 06, 2005 at 03:30:18PM -0700, Darren Pilgrim wrote: From: Nick Strebkov Thanks for your answers. I have 2915ABG and Belkin F5D8230-4 access point. Will it be enough to install RELENG_6 to play with iwi stuff? That depends. You'll need firmware before you can use the iwi driver. One of show-stopper problems with the iwi driver is that connections which spew large numbers of packets (cvs, cvsup, remote X, etc.) will make the iwi device suddenly stop working. Hm... It's really sad, but how does this prob relates to selection CURRENT vs RELENG_6? In terms of if_iwi, CURRENT and RELENG_6 are pretty much in sync. The only difference I can see is that CURRENT is bringing in support for WME/802.11e. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
How to disable at-boot configuration of a network interface but permit manual use of rc.d?
There are some conditions to the task given by the subject: 1: The interface must be present at boot. 2: Use of /etc/rc.d scripts to start and stop the interface is desirable. The first condition poses no problem, just don't include the relevant ifconfig_ifn line in /etc/rc.conf and the interface won't be configured. But rc.d/dhclient and rc.d/netif won't work without an ifconfig line for the interface. Adding the ifconfig line and then listing every interface but the one I want configured in network_interfaces does prevent it from being configured at boot while having an ifconfig line in rc.conf, but if I try to use rc.d/netif to start the interface, rc.d/netif does nothing because it tests the interface against the contents of network_interfaces and cloned_interfaces, so the interface I left out will be excluded. Have I overlooked an option somewhere? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: How to disable at-boot configuration of a network interface but permit manual use of rc.d?
From: Niki Denev [mailto:[EMAIL PROTECTED] Darren Pilgrim wrote: There are some conditions to the task given by the subject: 1: The interface must be present at boot. 2: Use of /etc/rc.d scripts to start and stop the interface is desirable. The first condition poses no problem, just don't include the relevant ifconfig_ifn line in /etc/rc.conf and the interface won't be configured. But rc.d/dhclient and rc.d/netif won't work without an ifconfig line for the interface. Adding the ifconfig line and then listing every interface but the one I want configured in network_interfaces does prevent it from being configured at boot while having an ifconfig line in rc.conf, but if I try to use rc.d/netif to start the interface, rc.d/netif does nothing because it tests the interface against the contents of network_interfaces and cloned_interfaces, so the interface I left out will be excluded. Have I overlooked an option somewhere? What happens if you configure the interface in 'down' state, like : ifconfig_fxp0=inet 192.168.0.10 netmask 0xff00 down Then rc.d/dhclient won't work. The DHCP keyword must be present in the ifconfig line in order for dhcpif to test true. A similar logic is in place for wpaif based on the WPA keyword. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Determining disk device and kicking GEOM when doing automatic mounting of umass devices
From: Dag-Erling Smørgrav [mailto:[EMAIL PROTECTED]
Darren Pilgrim [EMAIL PROTECTED] writes:
GEOM doesn't automatically read the partition table and create the
slice device [...]
Yes, it does. When the umassX provider shows up, GEOM immediately
tastes it and creates geoms for the individual slices.
If it really doesn't on your system, try the following:
# /etc/rc.d/devd stop
# logger START
# sysctl debug.bootverbose=1
# sysctl -b kern.geom.conftxt geom-before
[insert umass device, wait 10 secs]
# sysctl -b kern.geom.conftxt geom-after
# sysctl debug.bootverbose=0
# logger STOP
# /etc/rc.d/devd start
# awk '/START/{s=1}{if(s)print}/STOP/{s=0}' /var/log/messages
geom-logs
then post the contents of geom-{before,after,logs}.
Attached as named above. The logs show the da0 DISK class in the GEOM
config, but no MBR class entry.
This is on -current as of May 22.
geom-before
Description: Binary data
geom-after
Description: Binary data
geom-logs
Description: Binary data
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Determining disk device and kicking GEOM when doing automatic mounting of umass devices
-Original Message- From: Dag-Erling Smørgrav [mailto:[EMAIL PROTECTED] Sent: Friday, June 10, 2005 12:16 AM To: Darren Pilgrim Cc: freebsd-hackers@freebsd.org Subject: Re: Determining disk device and kicking GEOM when doing automatic mounting of umass devices Darren Pilgrim [EMAIL PROTECTED] writes: Attached as named above. The logs show the da0 DISK class in the GEOM config, but no MBR class entry. Take a closer look at geom-logs. It shows a slew of CAM errors. There's something wrong with your fob, or possibly (but not likely) with the USB stack. Except that after all those errors, it still mounts and works fine. Also, trying to mount /dev/da0 does produce the MBR entry in the GEOM config: 1 MBR da0s1 255849984 512 i 0 o 2048 ty 11 It also produces a single READ CAPACITY CAM error like those produced when the device attaches. I also tested with a known-good USB zip drive plugged into the same USB port. It attached flawlessly: the console showed the normal attach messages, GEOM config shows the appropriate MBR entry and /dev/da0s4 is created. So yeah I gueuss my fob is busted or funky. The CAM errors are just the drive saying there's no media present, so maybe the device doesn't support the commands necessary to report disk capacity? Is there a way to educate CAM about this so the attach procedure doesn't break? Why would the CAM errors prevent GEOM from creating the MBR geom during attach but not when trying to mount /dev/da0? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Determining disk device and kicking GEOM when doing automatic mounting of umass devices
I want to have a devd entry that automatically mounts umass devices when
they get attached. The problem is figuring out which device to mount and
then getting the correct devices created. For example, the entry for my
thumbdrive:
attach 1000 {
device-name umass[0-9]+;
match vendor 0x08ec;
match product 0x0015;
match sernum 0C50935151F0EA20;
action $scripts/mount_umass.sh $device-name msdosfs /stickdrive;
};
The mount_umass.sh script is as follows:
---BEGIN FILE---
sleep 10
scsidev=`echo ${1} | sed s/umass/umass-sim/g`
diskdev=`camcontrol devlist -v | grep -A 1 ${scsidev} | tail -n 1 | \
awk -F ( '{ print $2 }' | awk -F , '{ print $1 }'`
fstype=${2}
mountpoint=${3}
mount -t ${fstype} /dev/${diskdev} ${mountpoint} 2/dev/null
mount -t ${fstype} /dev/${diskdev}s1 ${mountpoint} 2/dev/null
END FILE
First, the script has to sleep because the device doesn't immediately show
up in the CAM device list. After waiting long enough to be safe, the script
takes the device name passed by devd and uses it to parse the device name
from the output of `camcontrol devlist`. GEOM doesn't automatically read
the partition table and create the slice device, so the script forces it to
do so by trying to mount the base device before mounting the actual
partition.
These tricks are ridiculous, IMO. There has to be a more intelligent means
of going about this. How do I get the scsi disk device name created for a
umass device as soon as it's created? How do I inform GEOM that it needs to
add a new MBR to it's configuration and create the appropriate /dev/da?s*
devices?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Forcing static-linking on a port?
From: Dan Nelson [mailto:[EMAIL PROTECTED] In the last episode (May 23), Darren Pilgrim said: I need to make use of a port during start up, but it has library dependencies that aren't available, before the complete library path is established. I've tried the following: NO_SHARED=true (added to /etc/make.conf) make -DNO_SHARED make LDFLAGS+=-static Every time, running file on the compiled program tells me that the binary is dynamically-linked. I couldn't find anything else in any man pages, Mk files, mailing lists, Google, etc. Sorry for the semi-inappropriate list choice, but this one would get swallowed up on -questions. NO_SHARED only works on programs that use the bsd.prog.mk makefile template; I'd guess under a dozen ports do this. Some pieces of software have dynamic-link options hardcoded in their Makefiles, probably as a workaround for bugs in other OSes. Those options override -static. I can't think of a valid reason for them to be used in FreeBSD. Search for (and remove) any occurances of -Wl,-Bdynamic and -Wl,-Bstatic , and you should be set. No luck on either string. I ended up getting what I wanted by going through the source Makefile and adding -static to the appropriate line in the target for the program I needed static-linked. Now devd can bring up my wireless NIC at boot. Works great! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Forcing static-linking on a port?
I need to make use of a port during start up, but it has library dependencies that aren't available, before the complete library path is established. I've tried the following: NO_SHARED=true (added to /etc/make.conf) make -DNO_SHARED make LDFLAGS+=-static Every time, running file on the compiled program tells me that the binary is dynamically-linked. I couldn't find anything else in any man pages, Mk files, mailing lists, Google, etc. Sorry for the semi-inappropriate list choice, but this one would get swallowed up on -questions. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: What mouse? (was: Samsung Cordless Mouse)
From: Greg 'groggy' Lehey Can anybody recommend a good mouse? My criteria are: - Middle button easy to use. The current crop of mice has the middle button integrated with the roller, and that makes the middle button either heavy or easy to confuse with the roller. - Preferably cordless. Cord mice tend to wander a little when you let go of them, and that's a real nuisance on a high-resolution display. I have a Logitech MX700. Very solid mouse, excellent performance and rechargable battery life. It can also run on standard alkalines (though you can't charge them). The mouse is heavier than most, but this seems to help with making smooth movements. The weight makes some of the more fervid in-game mouse maneuvers a bit tiresome on the wrist, though. It does integrate the middle button with the wheel. But there is hope! The force needed to press the wheel-button isn't much more than that of the right and left buttons. The return spring on the wheel housing can be easily removed. Doing so makes the return tension the same as the left and right buttons without affecting the wheel's functionality. It also has five additional buttons which are presented as separate buttons (6 through 10, in xf86config). They could be mapped to the middle button if you don't want to do surgery on your mouse. I've used the MX700 in 5.1 with XF86 4.3.x with great success. The only thing I couldn't get to work was the AppSwitch button, but I ended up never needing to use it anyway. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD firewall for high profile hosts - waste of time ?
Dmitry Morozovsky wrote:
On Thu, 16 Jan 2003, Darren Pilgrim wrote:
DP There is sorting that you can do, like putting the highest-traffic rules
DP near the top. ipfw terminates the search on the first matching rule except
DP for count and skipto. Also, the fewer items that have to be checked the
DP faster the rule is. Perhaps there is some aggregation that can be done with
DP the rules themselves?
By the way, is (moderately complex) aggregated rule faster than mix of simple
rules? (for now, we drop accounting issues)
So, will
permit tcp from {a.b.c.0/24 or e.f.g.0/20} to any 22,25,80,443 setup
perform measurably better than set of 8 corresponding rules?
I'm not sure if the {a.b.c.0/24 or e.f.g.0/20} part is valid, but in theory
this rule should require fewer ops on average than 8 seperate rules. What I
meant when I said aggregate is that if you have a contiguous block of IPs,
say 1.2.3.1 through 1.2.3.63, most need ports 22, 25, 80, and 443 open, then
create one rule:
pass tcp from any to 1.2.3.0/26 22,25,80,443
Then turn on the tcp.blackhole sysctl on the machines and you have the same
effect with just one rule instead of 60 or configure firewalls with just two
rules:
allow tcp from any to me porta,portb,portc
allow tcp from me to any
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: USB hub detach causing panic in 4.7p3
Josef Karthauser wrote: On Tue, Jan 14, 2003 at 12:05:37PM -0800, Darren Pilgrim wrote: I have a USB hub that's built into my Viewsonic PT775 monitor. The hub probes during boot and post-boot attach as follows: When the hub is disconnected, whether by unplugging it or turning off the monitor, I get a panic in 4.7p3 if there are no devices connected to the hub's downstream ports. mass snip Would this PR be related? http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/45579 I'm not sure? I didn't have anything running, that I could tell, that would have had the uhub device open. The machine was sitting idle at the login prompt. If someone would like to point me at a list of what I need to do to produce useful debugging information, I'll gladly do so. There are a number of brokenisms in the USB stack in -stable. As to whether they will get fixed or not is a matter of whether anyone has the time to MFC the USB stack from -current or not. It's much better over there, and I've already merged the framework to make it easier to MFC, but it is very unlikely that I will be attempting the work myself as I don't use USB on -stable myself. So the problem I'm having is a known issue when detaching a uhub device, then? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
Josh Brooks wrote: Thank you for that advice - it is very well taken. Obviously, my goal is to mitigate as much as possible - I have accepted that I cannot stop all DDoS - my question is, do serious people ever attempt to do the mitigation/load shedding with a host-based firewall (in this case fbsd+ipfw) ? Or would all serious people interested in mitigating attacks use an appliance, like a netscreen ? I will say this - 9/10 attacks that hurt me do not do anything interesting - in fact they are even low bandwidth (2-3 megabits/s) but they have a packet/second rate that just eats up all my firewall cpu and no traffic goes through - and as soon as the attack goes away the firewall is fine. So, I am looking at putting in more sophisticated traffic shaping (limiting packets/s from each IP I have) and skipto rules to make the ruleset more efficient ... but this is going to be a lot of work, and I want to know if it is all just a waste because no matter how good I get at a freebsd firewall, a netscreen 10 will always be better ? That depends on what you're asking of the machine. The routing information that will need to be held is the biggest one I can see, since the netscreens have defined limits. A FreeBSD box, in theory, doesn't have these limitations. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
Josh Brooks wrote: Again, thank you very much for your advice and comments - they are very well taken. I will clarify and say that the fbsd system I am using / talking about is a _dedicated_ firewall. Only port 22 is open on it. The problem is, I have a few hundred ipfw rules (there are over 200 machines behind this firewall) and so when a DDoS attack comes, every packet has to traverse those hundreds of rules - and so even though the firewall is doing nothing other than filtering packets, the cpu gets all used up. There is sorting that you can do, like putting the highest-traffic rules near the top. ipfw terminates the search on the first matching rule except for count and skipto. Also, the fewer items that have to be checked the faster the rule is. Perhaps there is some aggregation that can be done with the rules themselves? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
USB hub detach causing panic in 4.7p3
I have a USB hub that's built into my Viewsonic PT775 monitor. The hub probes during boot and post-boot attach as follows: uhub1: vendor 0x0543 product 0x00ff, class 9/0, rev 1.00/0.00, addr 2 uhub1: 5 ports with 4 removable, self powered The hub is connected and disconnected with the switching on and off of the monitor. When the hub is disconnected, whether by unplugging it or turning off the monitor, I get a panic in 4.7p3 if there are no devices connected to the hub's downstream ports. If there are devices connected to the downstream ports, the detach/reattach process works just fine. I only have the one hub to test this issue on. I can't say when the problem appeared as I hadn't used FreeBSD with this hub until a few weeks ago, and I hadn't turned the monitor off with nothing plugged into its USB ports until the 12th. Here is the console output from the panics caused by disconnecting the hub: Fatal trap 12: page fault while in kernel mode fault virtual addres= 0x3 fault code = supervisor read, page not present instruction pointer = 0x8:0xc031fe04 stack pointer = 0x10:0xc0250fb0 frame pointer = 0x10:0xc0250fc4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = bio trap number = 12 panic: page fault syncing disks... Fatal trap 12: page fault while in kernel mode fault virtual address = 0x30 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01c2498 stack pointer = 0x10:0xc0250d98 frame pointer = 0x10:0xc0250da0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = bio trap number = 12 panic: page fault Later on, when I was testing various configurations and boot/plug/unplug patterns to (try to) fix/diagnose the problem, the debug information was different from the above, but the same for all the panics I induced while testing. This is the output for those panics: Fatal trap 12: page fault while in kernel mode fault virtual addres= 0x3 fault code = supervisor read, page not present instruction pointer = 0x8:0xc031fe04 stack pointer = 0x10:0xc0250fb0 frame pointer = 0x10:0xc0250fc4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = bio trap number = 12 panic: page fault syncing disks... Fatal trap 12: page fault while in kernel mode fault virtual address = 0x30 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01c2498 stack pointer = 0x10:0xc0250dd0 frame pointer = 0x10:0xc0250dd8 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = bio trap number = 12 panic: page fault To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: USB hub detach causing panic in 4.7p3
I neglected to include from details: The USB drivers are kldloaded. The dmesg output and kernel config aren't included, but available upon request (as is any other config info or other needed data). Darren Pilgrim wrote: I have a USB hub that's built into my Viewsonic PT775 monitor. The hub probes during boot and post-boot attach as follows: uhub1: vendor 0x0543 product 0x00ff, class 9/0, rev 1.00/0.00, addr 2 uhub1: 5 ports with 4 removable, self powered The hub is connected and disconnected with the switching on and off of the monitor. When the hub is disconnected, whether by unplugging it or turning off the monitor, I get a panic in 4.7p3 if there are no devices connected to the hub's downstream ports. If there are devices connected to the downstream ports, the detach/reattach process works just fine. I only have the one hub to test this issue on. I can't say when the problem appeared as I hadn't used FreeBSD with this hub until a few weeks ago, and I hadn't turned the monitor off with nothing plugged into its USB ports until the 12th. Here is the console output from the panics caused by disconnecting the hub: Fatal trap 12: page fault while in kernel mode fault virtual addres= 0x3 fault code = supervisor read, page not present instruction pointer = 0x8:0xc031fe04 stack pointer = 0x10:0xc0250fb0 frame pointer = 0x10:0xc0250fc4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = bio trap number = 12 panic: page fault syncing disks... Fatal trap 12: page fault while in kernel mode fault virtual address = 0x30 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01c2498 stack pointer = 0x10:0xc0250d98 frame pointer = 0x10:0xc0250da0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = bio trap number = 12 panic: page fault Later on, when I was testing various configurations and boot/plug/unplug patterns to (try to) fix/diagnose the problem, the debug information was different from the above, but the same for all the panics I induced while testing. This is the output for those panics: Fatal trap 12: page fault while in kernel mode fault virtual addres= 0x3 fault code = supervisor read, page not present instruction pointer = 0x8:0xc031fe04 stack pointer = 0x10:0xc0250fb0 frame pointer = 0x10:0xc0250fc4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = bio trap number = 12 panic: page fault syncing disks... Fatal trap 12: page fault while in kernel mode fault virtual address = 0x30 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01c2498 stack pointer = 0x10:0xc0250dd0 frame pointer = 0x10:0xc0250dd8 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = bio trap number = 12 panic: page fault To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: USB hub detach causing panic in 4.7p3
Anish Mistry wrote: On Tuesday 14 January 2003 06:51 am, Darren Pilgrim wrote: I have a USB hub that's built into my Viewsonic PT775 monitor. The hub probes during boot and post-boot attach as follows: When the hub is disconnected, whether by unplugging it or turning off the monitor, I get a panic in 4.7p3 if there are no devices connected to the hub's downstream ports. mass snip Would this PR be related? http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/45579 I'm not sure? I didn't have anything running, that I could tell, that would have had the uhub device open. The machine was sitting idle at the login prompt. If someone would like to point me at a list of what I need to do to produce useful debugging information, I'll gladly do so. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: USB hub detach causing panic in 4.7p3
Someone's requested these already, so I've made the dmesg output and kernel config for the panicing machine available at www.lokisheathens.org/speck. On Tuesday 14 January 2003 06:51 am, Darren Pilgrim wrote: I have a USB hub that's built into my Viewsonic PT775 monitor. The hub probes during boot and post-boot attach as follows: uhub1: vendor 0x0543 product 0x00ff, class 9/0, rev 1.00/0.00, addr 2 uhub1: 5 ports with 4 removable, self powered The hub is connected and disconnected with the switching on and off of the monitor. When the hub is disconnected, whether by unplugging it or turning off the monitor, I get a panic in 4.7p3 if there are no devices connected to the hub's downstream ports. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: I'm leaving the project
Matt Dillon wrote: Thanks to my dear friend Warner Losh. I've decided to leave FreeBSD and flame in another project. Maybe I could join OpenBSD, the seem to share my views on how to deal with other people. I hereby give maintainership of all my code to Warner, or, whoever wants it, for that matter. Does anyone know why this person is trying to (poorly) impersonate MD? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: I'm leaving the project
Matthew Dillon wrote: : :Matt Dillon wrote: : Thanks to my dear friend Warner Losh. I've decided to leave FreeBSD and : flame in another project. Maybe I could join OpenBSD, the seem to share : my views on how to deal with other people. : : I hereby give maintainership of all my code to Warner, or, whoever wants : it, for that matter. : :Does anyone know why this person is trying to (poorly) impersonate MD? Probably because I lambast him mercilessly for being such a whimp. It's kinda sad, actually. He's probably not making any friends with the people running the blind proxies he abuses to post, either. You know the person by name/alias, then? Who is it? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gigabit NIC of choice?
Terry Lambert wrote: Dan Ellard wrote: What's the gigabit ethernet NIC of choice these days? (I've had good experiences with the NetGear G620T, but apparently this card is no longer being sold.) The Tigon II has the best performances, but that's because software people rewrote the firmware, instead of hardware engineers moonlighting as programmers. 8-) 8-). I recall from a while back that gigabit cards have relatively large caches on them, correct? How does the size of the cache impact performance, and what is considered a sufficient cache size? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gigabit NIC of choice?
Thank you! It was fun to watch questions come up and get shot down while reading the same email. Now if you'll excuse me, I need to go use the source, Terry. Terry Lambert wrote: Darren Pilgrim wrote: Terry Lambert wrote: Dan Ellard wrote: What's the gigabit ethernet NIC of choice these days? (I've had good experiences with the NetGear G620T, but apparently this card is no longer being sold.) The Tigon II has the best performances, but that's because software people rewrote the firmware, instead of hardware engineers moonlighting as programmers. 8-) 8-). I recall from a while back that gigabit cards have relatively large caches on them, correct? How does the size of the cache impact performance, and what is considered a sufficient cache size? The best advice I have for you is to read the source code for the drivers, specifically any commentary by Bill Paul up top; he tells it like it is, with regard to the hardware. long explaination snipped To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD Problems with dc(4) ADMtek AN985 chip
Martin Blapp wrote: Hi, The NIC is the external interface on my gateway. It was originally connected to an old HP 8-port 10bT hub and is now connected directly to a Westel DSL bridge. It has worked seemingly without problems handling the 768/128 DSL traffic. I say seemingly because I've never bothered to really push the NIC and I've never seen any link-level problems. 10 or 100 mbit with your Westel DSL bridge ? 10mbit half-duplex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD Problems with dc(4) ADMtek AN985 chip
Martin Blapp wrote: Hi, I have a 100mbit full-duplex connection, maybe this is the difference ? 10mbit half-duplex Since the issue seems to be the sort where high amounts of traffic would be a triggering factor, it's quite possible. Give me 20 minutes or so and I'll go swap the interfaces around so the dc is on the inside connected to 100mbit/full and flood the link. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD Problems with dc(4) ADMtek AN985 chip
Darren Pilgrim wrote: Martin Blapp wrote: I have a 100mbit full-duplex connection, maybe this is the difference ? 10mbit half-duplex Since the issue seems to be the sort where high amounts of traffic would be a triggering factor, it's quite possible. Give me 20 minutes or so and I'll go swap the interfaces around so the dc is on the inside connected to 100mbit/full and flood the link. I swapped the NICs around and hammered the LNE100TX for at least 30 minutes straight. I didn't get any problems. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: -fomit-frame-pointer for the world build
Terry Lambert wrote: Dmitry Morozovsky wrote: What are the drawbacks of building FreeBSD with -fomit-frame-pointer? The frame pointer is used for debugging, specifically for the stack traceback function to know arguments. Removing it means losing some debugging functionality. Next time try info gcc: If you don't have any need for debugging your software, is there any use for frame pointers? Is this something that can safely be used for both CFLAGS and COPTFLAGS? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Counting the clock cycles
Andrei Cojocaru wrote: doesn't fit my criteria since it changes, bah I'll just use gettimeofday since it's a portable API and hope the computers I run it on don't change their blocks by too much... If you're really worried about it, get a GPS device that can provide you with a PPS signal for use with ntpd. Then I'd say you could safely rely on the computer's clock being accurate. From: Cy Schubert - CITS Open Systems Group [EMAIL PROTECTED] In message 00d501c22dc4$57d08b00$0200a8c0@twothousand, Andrei Cojocaru writes: I was asking around in #freebsdhelp on EFNet what the equivalent of GetTickCount() in the Win32 API is in FreeBSD. I need a way to properly determine passage of time that is not affected if I change the system clock for example. The only way I'm aware that you can do that is by counting the number of clock cycles since system startup. What function does that in FreeBSD? I'd also like a Linux way if possible. (that is a way that will work across all UNIX clones). Thanks and please include my email in the reply directly since I'm not signed up to this mailing list. Thanks once again. How about time(3)? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Counting the clock cycles
M. Warner Losh wrote: In message: [EMAIL PROTECTED] Darren Pilgrim [EMAIL PROTECTED] writes: : If you're really worried about it, get a GPS device that can provide : you with a PPS signal for use with ntpd. Then I'd say you could safely : rely on the computer's clock being accurate. If you are lucky enough to find accuracy in the 10s of us close enough. I don't quite understand what you're saying here. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: tuning for samba
Chad David wrote:
A local company has been having issues with samba for some time (it kills
an e250, and has seriously stressed an e5000) and I've been telling the
admin (half seriously) that he should just toss it on a PC with FreeBSD.
Well they finally got tired of hearing FreeBSD this and FreeBSD that and
asked me to bring a box in if I was so confident... tomorrow morning at
9am. So, I'm building a new box tonight and was wondering if anybody
has any tried and true tuning parameters for samba on -stable. They
currently have ~700 users attached. The load per user is pretty low
but just rebooting and handling the reconnects has killed small boxes.
As a side note, the data being served will be attached to the samba server
via NFS.
The one thing I've seen kill a box besides the reboot-reconnect blast
is content searches by the Windows Find dialog. All it takes is one
user on a fast machine and network link doing the Windows equivalent
of find / -name * -exec grep foo \{\} \; to run you out of file
descriptors in a matter of seconds.
Samba uses a seperate process for each connection, and Windows opens
one connection per share. Most Windows users only work on one share
at a time, so with two open shares on ~700 machines that means ~1400
connections with roughly half of them idle. That's a lot of freeable
RAM should you suddenly need it.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: tuning for samba
Richard Sharpe wrote: On Wed, 10 Jul 2002, Darren Pilgrim wrote: Samba uses a seperate process for each connection, and Windows opens one connection per share. Yes to the first claim, no to the second. Most definitely not. For a single client, windows puts all share access (net use, mounting, whatever you want to call it) over the single TCP connection to the server. You're right, sorry. I had gotten mixed up on the multiple connection issue because of my own configuration that results in one share per connection. Nope, ~700 connections! Even with just one connection per machine, though, you're still going to have a significant amount of swappable memory in idle smbd processes. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: tuning for samba
Richard Sharpe wrote: On Thu, 11 Jul 2002, Darren Pilgrim wrote: Richard Sharpe wrote: On Wed, 10 Jul 2002, Darren Pilgrim wrote: Samba uses a seperate process for each connection, and Windows opens one connection per share. Yes to the first claim, no to the second. Most definitely not. For a single client, windows puts all share access (net use, mounting, whatever you want to call it) over the single TCP connection to the server. You're right, sorry. I had gotten mixed up on the multiple connection issue because of my own configuration that results in one share per connection. Nope, ~700 connections! Even with just one connection per machine, though, you're still going to have a significant amount of swappable memory in idle smbd processes. Yes, I agree. Something that I would like to do more about by making sure that as much as possible is shared. At over 4MB per process (4252K each on my server), I should hope that most of it is already shared. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How does swap work address spacewise?
Bernd Walter wrote: On Fri, Jul 05, 2002 at 05:58:15PM -0700, Darren Pilgrim wrote: If RAM + swap can be more than 4GB, how does FreeBSD address swap on a 32-bit machine? Does the kernel internally use a wider address space The same way it does on every partitition: using block numbers. That way you can address 1TByte. I thought the limit for filesystems was 2TB? And you can have more than a single swap partition. Up to four, so then the theoretical limit for swap is 8TB? In reality managementstructures which have to be in kernel addressspace is limiting swap before. Do these management structures grow as swap grows, or do they only change as the utilization increases? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How does swap work address spacewise?
Bernd Walter wrote: On Sat, Jul 06, 2002 at 02:37:02PM -0700, Darren Pilgrim wrote: Bernd Walter wrote: On Fri, Jul 05, 2002 at 05:58:15PM -0700, Darren Pilgrim wrote: If RAM + swap can be more than 4GB, how does FreeBSD address swap on a 32-bit machine? Does the kernel internally use a wider address space The same way it does on every partitition: using block numbers. That way you can address 1TByte. I thought the limit for filesystems was 2TB? The Blocknumber is signed that gives: 2^31 * 512Bytes Why sign the blocknumber? LBA uses an unsigned 32-bit integer, allowing 2TB, and IIRC SCSI uses an unsigned integer as well (though I can't remember if that one is 32 or 48 bits, or if they've gotten to 64 bits by now). And you can have more than a single swap partition. Up to four, so then the theoretical limit for swap is 8TB? 4 is just a default. The limit here is the maximum number of harddisks, which is IIRC 512 per driver. This cames from the available minor bits in the device node. That makes sense, how do you get past the default of four? Is there a tweak to be made, or do you just swapon as usual? In reality managementstructures which have to be in kernel addressspace is limiting swap before. Do these management structures grow as swap grows, or do they only change as the utilization increases? AFAIK there is a static part. Possible not memory but only KVM addressspace. Also AFAIK it makes a difference if you allocate the same space using a single partition or in more than one. Understandable, with more than one, the kernel then has to do what amounts to software RAID on the swap partitions. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How does swap work address spacewise?
Matthew Dillon wrote: The nominal limit for swap space is around 14 GB due to limitations in available KVM. There are three major limiting factors in the kernel: * The swap bitmap eats 2 bits per page of swap. The bitmap is sized to handle NSWAP (default 4) x size_of_largest_swap_partition. Is NSWAP tied to the NSWAPDEV kernel option, or is it the actual number of active swap devices? If the prior, is setting NSWAPDEV to the actual number of swap devices a useful for improving memory usage? Is NSWAPDEV just a compile-time tunable, or is there a sysctl to do the same thing? * The system has to keep track of pages that are swapped out. The system reserves 8 x physical_pages_in_system worth of KVM to keep track of swapped out pages. A machine with 4G of ram reserves enough KVA to hold 32GB worth of swapped out pages. * The system limits the size of the above zone to VM_SWZONE_SIZE_MAX, which is typically around 70 MB of KVM (enough to hold 14 GB worth of swap mappings). So the nominal limit is around 14 GB on a 32 bit architecture. With tuning this limit can be bumped up, but the practical limit is going to be around 60GB unless you give the kernel more KVA (reducing the amount of VM a user process can access). Can VM_SWZONE_SIZE_MAX be tuned down as well, or does the kernel already handle this efficiently enough to keep it at a minimum useful value sized relative to PHYS? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How does swap work address spacewise?
Thanks guys, for explaining the swap system to me. I have a good understanding of how the system works now. I want to particularly thank Matthew Dillon for taking the time to lay down the technical details as he did. Being able to ask a question like this and get it answered so well is what puts FreeBSD so far above other OSes in my book. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
How does swap work address spacewise?
If RAM + swap can be more than 4GB, how does FreeBSD address swap on a 32-bit machine? Does the kernel internally use a wider address space with some kind of translation to 32-bit space for programs and hardware that can't handle 64-bit addresses or does it not map swap into the address space at all, instead using it as a kind of offline storage for pages not in use? Does the Alpha port handle swap the same way? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Cyrus vs. UW IMAP (was: Re: I Volunteer)
Terry Lambert wrote: Chris Dillon wrote: It's quite simple to integrate Cyrus IMAP with the local system. Cyrus will by default use the system password database for its authentication, While I appreciate the positive support of Cyrus, I guess I need to point out that this approach only works if you are willing to send passwords over the wire in plaintext. There's no support for SSL in Cyrus? What about secure authentication? Speaking of which, what does it take to get secure authentication to work on FreeBSD? Courier supports it, but the port compiles with options to disable the secure authentication methods. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: I Volunteer
Evan Dower wrote: I don't know who might have use of my services (or what my services might be for that matter), but I hereby offer them up. I'm a student at the University of Washington and I'll be applying to the Computer Science major in February. I'd like to get involved with the OS that is serving me so well. I'll do what I can to help with whatever. Just let me know if anyone needs a minion. I could use the experience. It's not exactly FreeBSD, but how about rewriting pine and uw-imap? Last I heard they could use a little work. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Does FreeBSD have a problem with some AMD processors?
Jordan K Hubbard wrote: I'll bet you wouldn't have any trouble running -stable on it. There was a problem with MTRR support which still needs a little fixing in order to shut down properly but that's nowhere near as bad as X not running. Fix should be in FreeBSD 4.6 as well. The MTRR issue you're referring to, is this related to the one in the AMD errata docs about SMM TSEG and large page mappings? Which CPUs does this bug affect? Is it AMD specific at all? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: UID Limit
Peter Pentchev wrote: I believe you are thinking of pid's (process ID's), not uid's (user ID's). Yes, you're right. Serves me for trying to do email after a long night of hacking at perverse bit-twiddling scripts. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: UID Limit
Peter Pentchev wrote: On Wed, May 22, 2002 at 04:27:12PM +0100, Jamie Heckford wrote: Hi, I was wondering if anyone would be able to tell me what the limit is on a UID? Ie what is the highest integer it can go up to. I suppose as well some applications have different values.. or am I completly wrong :) The functions that deal with user ID's take a parameter of type uid_t. The uid_t type is defined in sys/types.h as u_int32_t. Hence, at least theoretically, FreeBSD supports uid's in the range 0 to 4G-1. It supports them that high, yes, but I believe they wrap at 9. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Optimal UFS parameters
This is a interesting topic (to me, anyway), and is one of the things that often gets overlooked by those of us with less experience. Rather than getting into a long discussion about modifying the newfs defaults across the board, what if the newfs options used were based on the size of the FS? There could be a simple rule in sysinstall that increased the newfs options from their default values if the defaults meant there would be more an x number of inodes and cg's. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
