Top display pri and renice questions...
Hi guys, Have a question regarding top PRI and the renice command extract from top PID USERNAME THR PRI NICE SIZERES STATETIME WCPU COMMAND 17269 brahama 1 960 5932K 5300K select 30:55 0.00% perl5.8.8 Ok...what are the values of PRI? for instance if i renice this pid 10, it will go to 106...where can i find relevant info about this...I benn lookint and couldnt find any clear explanation... Ok..and the renice question is regarding this parameters.. on man it says that by doing this: renice +1 987 -u daemon root -p 32 would change the priority of process ID's 987 and 32, and all processes owned by users daemon and root. but i cannot seem to make it worki want to renice peoples group processes to 10 but i get renice: Bad pid argument: people like its getting people as a PID...people is a group from /etc/group.. Can this be done? Thanks and cheers, Agustin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: upgrade from 6.3 to 7.0
k Hi I ve got 6.3 stable database server. Can i directly upgrade my server from 6.3 to 7.0 yes. anyway - if your server works fine - why? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Security Issue Alert
[chaseNewlogo.gif] Security Issue Alert. We recently reviewed your account and suspect that your ChaseBank Account may have been accesed by an unauthorized third party.Protecting the security of your account and of the ChaseBank Network is our primary concern. Therefore, as a preventive measure we have temporarily limited access to sensitive ChaseBank Account Features. Click The link below in order to regain access to your Chase Cardmembers Account, simply: [logon_button_home.gif] Please fill in the required informations. This is required for us to continue to offer you a safe and risk free environment. Sincerley, Account Online Management HAVE QUESTIONS ABOUT YOUR ACCOUNT? We cannot respond to individual messages through this email address, because we are unable the verify the true identity. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IP alias/routing question
David Allen wrote: On Fri, Jul 25, 2008 at 10:12 AM, Matthew Seaman [EMAIL PROTECTED] wrote: Chris Pratt wrote: Carefully not answering the 'why do these packets come from the wrong address' question, Deliberately addressing the question of 'why do these packets come from the wrong address' question which Mr. Seaman avoided ...heh, heh heh. Good job with the wording guys. I smiled brightly when I went through this ;) Since I've replied but clipped out any further context, I'll add a bit... I agree with David in that this is purely a routing issue. What (IMHO) it comes down to is 'source address selection'. I've been more focused in this scope within IPv6, but it is apparently a problem as well with IPv4, in a different manner. Perhaps this will become more of an issue as more people get used to the understanding that having multiple addresses per interface is the design goal, not an alias workaround. At one point I was advised that there is the ability to use multiple route tables within -current. If the box is being designed for only one application, could you try the new implementation of routing as opposed to making the application fit? Steve ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: upgrade from 6.3 to 7.0
On Sat, Jul 26, 2008 at 08:38:08AM +0200, Wojciech Puchar wrote: k Hi I ve got 6.3 stable database server. Can i directly upgrade my server from 6.3 to 7.0 yes. anyway - if your server works fine - why? Because 7 is demonstrably faster than 6.x? Because local policy requires the upgrade? Because he wants to run 7? -- Daniel Bye _ ASCII ribbon campaign ( ) - against HTML, vCards and X - proprietary attachments in e-mail / \ pgpwjlsxCXf6X.pgp Description: PGP signature
Binary upgrade from legacy version
Hi, list! I want to upgrade two freebsd machines I have from 6.1-SECURITY and 5.3-RELEASE respectively, to the latest 7.0 release of FreeBSD. I don't want to cvsup and build, but prefer to use prebuilt binaries. Also I'd like to avoid wiping the systems, and starting afresh. I know this might break my systems and are willing to take the risk. I also reqognize that I probably have to rebuild a lot of ports afterwards. What steps do I take to increase my probablity of success? How do I do this the cleanest way possible? Could I just get all the distfiles and put them on top of my old system? How do I find files that are to be deleted from the old system? sv. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: crontab mails
Hi Yavuz, It's easy to tell crontab stop sending mail to you by disable sendmail in /etc/rc.conf % echo sendmail_enable=\NO\ man rc.conf for more information :-) or set the variable MAILTO null on corntab MAILTO= Regards, jyuny1 2008/7/26 Yavuz Maslak [EMAIL PROTECTED] Hello On freebsd7.0, my crontab sends many mails about its jobs. I want crontab not to send these mails How can I do that ? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: optimal CPUTYPE / arch for Intel T5600 ?
Hi Rene, for optimizationm, CPUTYPE is depends on what verison of gcc you use. you can determine waht CPUTYPE you use by checking gcc's online manul http://gcc.gnu.org/onlinedocs/ i.e. http://gcc.gnu.org/onlinedocs/gcc-4.2.4/gcc/Optimize-Options.html#Optimize-Options Regards, jyuny1 2008/7/25 Rene Ladan [EMAIL PROTECTED] Hi, I have an Asus A6JE laptop which has an Intel T5600 CPU. It is currently configured as i386 with CPUTYPE=prescott. But after reading wikipedia, I get the idea that I have slightly underconfigured my box, i.e. that a better configuration is possible. dmesg says (7.0-release): CPU: Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz (1828.77-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6f6 Stepping = 6 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe3bdSSE3,RSVD2,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x2010NX,LM AMD Features2=0x1LAHF Cores per package: 2 real memory = 2147287040 (2047 MB) avail memory = 2095947776 (1998 MB) ACPI APIC Table: AMIOEMAPIC FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 Version 2.0 irqs 0-23 on motherboard acpi0: _ASUS_ Notebook on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 7ff0 (3) failed Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 acpi_ec0: Embedded Controller: GPE 0x1c port 0x62,0x66 on acpi0 acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 900 cpu0: ACPI CPU on acpi0 coretemp0: CPU On-Die Thermal Sensors on cpu0 est0: Enhanced SpeedStep Frequency Control on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6130b2406000b24 device_attach: est0 attach returned 6 p4tcc0: CPU Frequency Thermal Control on cpu0 cpu1: ACPI CPU on acpi0 ACPI Warning (tbutils-0243): Incorrect checksum in table [SSDT] - 77, should be 2C [20070320] coretemp1: CPU On-Die Thermal Sensors on cpu1 est1: Enhanced SpeedStep Frequency Control on cpu1 p4tcc1: CPU Frequency Thermal Control on cpu1 Maybe some amd64 configuration is possible, since it the cpu has AMD features? Please cc me, I'm not subscribed. Regards, Rene -- http://www.rene-ladan.nl/ GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Switch to alternate screen buffer
Hi, Am Donnerstag, 24. Jul 2008, 16:57:40 +0200 schrieb Wojciech Puchar: I know from some old Linux installations that Less and Vim are able to switch to an alternate screen buffer. They use the escape sequences \e[?1047h and \e[?1047l to switch back respectively. How can I activate this in FreeBSD? no idea but do someprg 21|vim - No. I will not waive. This is not Microsoft here. Edit /usr/share/misc/termcap. Change the following entry: xterm|xterm-color|X11 terminal emulator:\ :ti=\E[?47h:te=\E[?47l:tc=xterm-xfree86: Don't forget to execute cap_mkdb termcap. No need to get over with a poor workaround. Bertram -- Bertram Scharpf Stuttgart, Deutschland/Germany http://www.bertram-scharpf.de ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Backspace Key Not Working
Hey, I have an annoying problem that I'm not sure how to solve. Here's my setup: PuTTy = My FreeBSD 6.2 box = Production FreeBSD 7.0 box All via SSH, of course. Now, on my FreeBSD 6.2 box, the backspace key works fine all the time. However, when I connect from my 6.2 box into the production 7.0 box, the backspace key does not work all the time. In the console, it works fine (as in, it deletes what I type). However, when I'm in programs such as VIM, it displays ^? instead of deleting. Is there a way to fix this? Thanks for your time. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Backspace Key Not Working
Schiz0 [EMAIL PROTECTED] wrote: I have an annoying problem that I'm not sure how to solve. Here's my setup: PuTTy = My FreeBSD 6.2 box = Production FreeBSD 7.0 box All via SSH, of course. Now, on my FreeBSD 6.2 box, the backspace key works fine all the time. However, when I connect from my 6.2 box into the production 7.0 box, the backspace key does not work all the time. In the console, it works fine (as in, it deletes what I type). However, when I'm in programs such as VIM, it displays ^? instead of deleting. Is there a way to fix this? What are the contents of .vimrc on the 7.0 machine? And how have you set your TERM environment variable on that machine? Does anything change if you connect directly to your 7.0 box without going through 6.2 in between? -- Sahil Tandon [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Backspace Key Not Working
.vimrc on the 7.0 box: --- set autoindent set background=dark set backspace=indent,eol,start set cmdheight=2 set ignorecase set number set numberwidth=2 set report=0 set restorescreen=on set ruler set scrolloff=3 set showbreak=++ set showmatch set showmode set showtabline=3 set smartcase set smartindent set smarttab syntax on set visualbell set ff=unix --- I haven't manually set $TERM to anything, however I am running this inside screen (using UTF-8 encoding). So screen automatically sets $TERM to screen. I just checked, and if I connect directly to the 7.0 box using PuTTy, the backspace key works fine all the time. Thanks for the quick reply. On Sat, Jul 26, 2008 at 11:55 AM, Sahil Tandon [EMAIL PROTECTED] wrote: Schiz0 [EMAIL PROTECTED] wrote: I have an annoying problem that I'm not sure how to solve. Here's my setup: PuTTy = My FreeBSD 6.2 box = Production FreeBSD 7.0 box All via SSH, of course. Now, on my FreeBSD 6.2 box, the backspace key works fine all the time. However, when I connect from my 6.2 box into the production 7.0 box, the backspace key does not work all the time. In the console, it works fine (as in, it deletes what I type). However, when I'm in programs such as VIM, it displays ^? instead of deleting. Is there a way to fix this? What are the contents of .vimrc on the 7.0 machine? And how have you set your TERM environment variable on that machine? Does anything change if you connect directly to your 7.0 box without going through 6.2 in between? -- Sahil Tandon [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Binary upgrade from legacy version
Svein Halvor Halvorsen wrote: Hi, list! I want to upgrade two freebsd machines I have from 6.1-SECURITY and 5.3-RELEASE respectively, to the latest 7.0 release of FreeBSD. I don't want to cvsup and build, but prefer to use prebuilt binaries. Also I'd like to avoid wiping the systems, and starting afresh. I know this might break my systems and are willing to take the risk. I also reqognize that I probably have to rebuild a lot of ports afterwards. What steps do I take to increase my probablity of success? How do I do this the cleanest way possible? Could I just get all the distfiles and put them on top of my old system? How do I find files that are to be deleted from the old system? The cleanest way possible really is wipe and reinstall. For your 5.3 systems, I'd strongly recommend you do exactly that -- 5.3 is almost certainly too old to support the newer upgrading mechanisms that have come into use since it was released and upgrading by cvsup+rebuild will be exceedingly tedious, as you'll have to take it in a number of steps to get all the way to 7.0. For your 6.1 systems, you can update by cvsup+rebuild to RELENG_6_3 in one step, or via there to RELENG_7_0 in two. (Actually, you can probably do 6.1-7.0 in one step, but it's not guaranteed to work properly) You will need to rebuild all your installed software, which is not a trivial undertaking but once you've got past the first few hurdles rapidly becomes nothing more than time-consuming. If your 6.1 system is using a system installed from one of the official iso images and hasn't been locally rebuilt (upgrading via freebsd-updates is OK though) then there is a quicker way. See http://www.daemonology.net/blog/2007-11.html Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: Switch to alternate screen buffer
On Sat, Jul 26, 2008 at 03:03:57PM +0200, Bertram Scharpf wrote: Hi, Am Donnerstag, 24. Jul 2008, 16:57:40 +0200 schrieb Wojciech Puchar: I know from some old Linux installations that Less and Vim are able to switch to an alternate screen buffer. They use the escape sequences \e[?1047h and \e[?1047l to switch back respectively. How can I activate this in FreeBSD? no idea but do someprg 21|vim - No. I will not waive. This is not Microsoft here. Edit /usr/share/misc/termcap. Change the following entry: xterm|xterm-color|X11 terminal emulator:\ :ti=\E[?47h:te=\E[?47l:tc=xterm-xfree86: 47 by itself won't clear the alternate buffer (probably not what is intended). For more information http://invisible-island.net/xterm/xterm.faq.html#xterm_tite -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpDDMCRzIVMH.pgp Description: PGP signature
Root boot/mount Password?
Hi all FreeBSD 6.2 I would like to put a password when booting/mounting mi Freebsd box. is it possible? How? What I want is that if the system is rebooted or shutdown, somebody must enter a password to boot and/or mounting / is for protecting the system from unauthorized users Thanks in advance Juan Coruña Desarrollo de Software Atlantico ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Root boot/mount Password?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 DSA - JCR wrote: Hi all FreeBSD 6.2 I would like to put a password when booting/mounting mi Freebsd box. is it possible? How? What I want is that if the system is rebooted or shutdown, somebody must enter a password to boot and/or mounting / is for protecting the system from unauthorized users A couple of items here. The first is a long known rule of security, which is, if an attacker has physical access to the console, then the game is up, you can't protect it any more. This has *somewhat* been modified in the last few years, because it's a become a fairly common option in BIOSes to allow for a boot password. This too can be bypassed, pretty quickly and thoroughly, by doing a CMOS memory clear, but it IS a step in the right direction. Honestly, though, a good security strategy is to respect that rule about an attacker with physical access to the console: protect yourself physically. Yes, you can set that boot password in the BIOS (active before any OS, including FreeBSD, starts up) but don't be silly and rely on that ... protect yourself. Thanks in advance Juan Coruña Desarrollo de Software Atlantico ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiLZJYACgkQz62J6PPcoOkWkgCePG+GpCdE3XJ+g1IzXjZ9QzzT jm8An2MpTyWMnTnTvfLMCmqNhTC2GXaj =YdcO -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Root boot/mount Password?
On Sat, Jul 26, 2008 at 05:31:23PM -, DSA - JCR wrote: Hi all FreeBSD 6.2 I would like to put a password when booting/mounting mi Freebsd box. is it possible? How? Yes. Use geli(8) encryption. is for protecting the system from unauthorized users Disk encryption also protects your data if the PC or harddrive is stolen. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpMYMGTDTpep.pgp Description: PGP signature
Re: Root boot/mount Password?
On Sat, Jul 26, 2008 at 01:53:27PM -0400, Chuck Robey wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 DSA - JCR wrote: Hi all FreeBSD 6.2 I would like to put a password when booting/mounting mi Freebsd box. is it possible? How? What I want is that if the system is rebooted or shutdown, somebody must enter a password to boot and/or mounting / is for protecting the system from unauthorized users A couple of items here. The first is a long known rule of security, which is, if an attacker has physical access to the console, then the game is up, you can't protect it any more. You cannot protect the machine if an attacker has physical access. But you _can_ protect your data by encrypting it. Hence my advice to use geli(8). Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgprMHXOlFhSB.pgp Description: PGP signature
VLAN vs Virtual IPs(Alias)....
Hi guys, I have a doubt while planning my network enlargement... I have a router where i created 3 Virtual ips(alias)...eth0:1, eth0:2, etcso i have 3 subnets with only one eth interface192.168.[0-3].0 subnets...this connected to a switch, a simple one which doesnt support 802.1q and 4 bsds connected to the switch, 2 in one subnet and the otheres in each subnet, thus the 3 subnets(alias) in my routerI was reading and wanted to know which is the difference, which one is better, can i implement any of this two options (Vlan or Alias) in my network? do i need to recompile my kernel? i have 6.2? Thanks in advance, Have a nice weekend, Agustin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Root boot/mount Password?
Hi! Allthough you already got good answers, I'd like to add the following: On Sat, 26 Jul 2008 17:31:23 - (GMT), DSA - JCR [EMAIL PROTECTED] wrote: Hi all FreeBSD 6.2 I would like to put a password when booting/mounting mi Freebsd box. is it possible? How? What I want is that if the system is rebooted or shutdown, somebody must enter a password to boot and/or mounting / Next to the usual means of access control (no automated login, no users without password), there would be an option to boot the system in single user mode first. Your /etc/ttys would contain insecure in the 5th field so nobody would get into the shell without the root password. Then, fsck and mount -a, followed by exit or Ctrl-D would be neccessary to boot the system into multi user mode. To boot your system into SUM, I think /boot/loader.conf must contain the line ,,boot_single=YES''. If I remember correctly, there as been a way to put a password request into a much earlier stage of booting (boot oder loader), but sadly, I can't remember where to do this or if it's still possible. Maybe these ideas are helpful. -- Polytropon From Magdeburg, Germany Happy FreeBSD user since 4.0 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Root boot/mount Password?
On Sat, Jul 26, 2008 at 09:58:53PM +0200, Polytropon wrote: What I want is that if the system is rebooted or shutdown, somebody must enter a password to boot and/or mounting / Next to the usual means of access control (no automated login, no users without password), there would be an option to boot the system in single user mode first. Your /etc/ttys would contain insecure in the 5th field so nobody would get into the shell without the root password. Then, fsck and mount -a, followed by exit or Ctrl-D would be neccessary to boot the system into multi user mode. To boot your system into SUM, I think /boot/loader.conf must contain the line ,,boot_single=YES''. Assuming physical access to the machine, this can be easily circumvented by booting from a FreeBSD CD. Of yourse you can disable booting from CD in the BIOS, and guard that with a password. But that is usually easy to wipe by shorting a jumper on the motherboard. It just depends on the amount of time and knowledge that the attacker has. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpvCq1i3bfD6.pgp Description: PGP signature
malloc options
I have a program that has run correctly since FreeBSD 3.7. However, when upgrading the server to 7.0 I am encountering issues where values just seem to arbirtrarily change. These values are all located in memory allocated by malloc. Malloc was significantly changed with 7.0 and reading through the malloc man page there are a number of flags that can be set with /etc/malloc.conf. The default for that file is to not exist. The man page does not indicate which settings are used in that situation. After reading through it I get the feeling that the default settings for D and M are 'dM'. Hence, to return to the older malloc aproach to see if the problems go away I would need to set Dm. But some of the descriptions seem to indicate that might not be correct. What are the default settings? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
The FreeBSD Diary: 2008-07-06 - 2008-07-26
The FreeBSD Diary contains a large number of practical examples and how-to guides. This message is posted weekly to freebsd-questions@freebsd.org with the aim of letting people know what's available on the website. Before you post a question here it might be a good idea to first search the mailing list archives http://www.freebsd.org/search/search.html#mailinglists and/or The FreeBSD Diary http://www.freebsddiary.org/. These are the articles posted during this period: 6-Jul : ezjail - A jail administration framework This makes jails easier http://freebsddiary.org/ezjail.php?2 -- Dan Langille BSDCan - http://www.BSDCan.org/ - BSD Conference ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: malloc options
Doug Hardie wrote: I have a program that has run correctly since FreeBSD 3.7. However, when upgrading the server to 7.0 I am encountering issues where values just seem to arbirtrarily change. These values are all located in memory allocated by malloc. Malloc was significantly changed with 7.0 and reading through the malloc man page there are a number of flags that can be set with /etc/malloc.conf. The default for that file is to not exist. The man page does not indicate which settings are used in that situation. After reading through it I get the feeling that the default settings for D and M are 'dM'. Hence, to return to the older malloc aproach to see if the problems go away I would need to set Dm. But some of the descriptions seem to indicate that might not be correct. What are the default settings? I don't think those are the right questions to be asking. Firstly, if you did not recompile the program under 7.0 then it is not using the new malloc at all. If you did recompile it and it is behaving differently then it is probably because your program contains bugs in how it manages memory that happened to be working by accident with the old memory allocator. e.g. because you were making use of memory after it had been freed, but before the allocator returned it to some other malloc() call. Finally, there is no way to revert to the old approach because the new allocator is completely new; it allocates memory based on its own strategy. None of the malloc options affect the behaviour of correct programs (but some of them can help to improve performance, or to debug incorrect programs). Kris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: malloc options
On Jul 26, 2008, at 17:10, Kris Kennaway wrote: Doug Hardie wrote: I have a program that has run correctly since FreeBSD 3.7. However, when upgrading the server to 7.0 I am encountering issues where values just seem to arbirtrarily change. These values are all located in memory allocated by malloc. Malloc was significantly changed with 7.0 and reading through the malloc man page there are a number of flags that can be set with /etc/ malloc.conf. The default for that file is to not exist. The man page does not indicate which settings are used in that situation. After reading through it I get the feeling that the default settings for D and M are 'dM'. Hence, to return to the older malloc aproach to see if the problems go away I would need to set Dm. But some of the descriptions seem to indicate that might not be correct. What are the default settings? I don't think those are the right questions to be asking. I fail to see why asking what the defaults are in not a valid question. That information should be documented in the man page (or at least the developer's manual). Dredging through malloc.c it appears that the defaults are actually DM. If so, that gives me 2 different options to try to see if the behavior changes (dM and Dm). Since those options affect the location of the data in the process address space its possible that one of them might come closer than DM to how malloc used to work. It might give a temporary workaround till the underlying issue can get resolved. Firstly, if you did not recompile the program under 7.0 then it is not using the new malloc at all. It was recompiled. All there is on the system is new stuff. It was built from scratch when 7.0 came out. If you did recompile it and it is behaving differently then it is probably because your program contains bugs in how it manages memory that happened to be working by accident with the old memory allocator. e.g. because you were making use of memory after it had been freed, but before the allocator returned it to some other malloc() call. That is certainly possible. However, the program has worked under considerable load for many years with versions 3.7 to 6.2. Problems only occur with 7.0. The program is quite complex and big. It uses probably hundreds of mallocs in a typical use. The problems only occur reasonably randomly and only under quite heavy load. The developer is looking into it, but the problem only occurs on FreeBSD 7.0, not any other Unix systems. In the meantime I am losing money because of it. Finally, there is no way to revert to the old approach because the new allocator is completely new; it allocates memory based on its own strategy. None of the malloc options affect the behaviour of correct programs (but some of them can help to improve performance, or to debug incorrect programs). Not surprising but I seem to recall that when it was first introduced into stable that there was some discussion on how to make it look more like the old malloc. I couldn't find that via a search though. Kris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: graid3
Wojciech Puchar wrote: i read the graid3 manual and http://www.acnc.com/04_01_03.html to make sure i know what's RAID3 and i don't understand few things. 1) The number of components must be equal to 3, 5, 9, 17, etc. (2^n + 1). why it can't be say 5 disks+parity? The reason is in the definition on RAID 3, which says the updates to the RAID device must be atomic. In some ideal universe, RAID 3 is implemented in hardware and on individual bytes, but here we cannot write to the drives in units other than sectorsize and sectorsize is 512 bytes. Parity needs to be calculated with regards to each sector, so at the sector level, the minimum number of sectors is three sectors: two for data and one for parity. This means the high-level atomic sectorsize is 2*512=1024 bytes. If you inspect your RAID 3 devices, you'll see just that: # diskinfo -v /dev/raid3/homes /dev/raid3/homes 1024# sectorsize 107374181376# mediasize in bytes (100G) 104857599 # mediasize in sectors But each drive has a normal sectorsize of 512: # diskinfo -v /dev/ad4 /dev/ad4 512 # sectorsize 80026361856 # mediasize in bytes (75G) 156301488 # mediasize in sectors Sector sizes cannot be arbitrary for various reasons, mostly dealing with how memory pages and virtual memory are managed. In short, they need to be powers of two. This restricts us to high-level (big) sector sizes that can be exactly one of the following values: 1024, 2048, 4096, 8192, etc. Since drive sectors are fixed to 512 bytes, this means that the number of *data* drives must also be a power of two: 2, 4, 8, 16, etc. Add one more drive for the parity and you get the starting sequence: 3, 5, 9, 17. In practice, this means that if you have 17 drives in RAID3, the sectorsize of the array itself will be 16*512 = 8192. Each write to the array will update all 17 drives before returning (one sector on each drive, ensuring an atomic operation). Note that the file system created on such an array will also have its characteristics modified to the sector size (the fragment size will be the sector size). 2) -r Use parity component for reading in round-robin fashion. Without this option the parity component is not used at all for reading operations when the device is in a complete state. With this option specified random I/O read operations are even 40% faster , but sequential reads are slower. One cannot use this option if the -w option is also specified. how parity disk could speed up random I/O? It will work well only when the number of drives is small (i.e. three drives), by using the parity drive as a valid source of data, avoiding some seeks to all drives. I think that, theoretically, you can save at most 0.33 (1/3) of all seeks - I don't know where the 40% number comes from. signature.asc Description: OpenPGP digital signature
Re: malloc options
Doug Hardie wrote: If you did recompile it and it is behaving differently then it is probably because your program contains bugs in how it manages memory that happened to be working by accident with the old memory allocator. e.g. because you were making use of memory after it had been freed, but before the allocator returned it to some other malloc() call. That is certainly possible. However, the program has worked under considerable load for many years with versions 3.7 to 6.2. Problems only occur with 7.0. The program is quite complex and big. It uses The memory allocator was the same between 3.7 and 6.x - it only changed in 7.0. Your description looks like a use-after-free bug. Your application is in C, not C++, right? probably hundreds of mallocs in a typical use. The problems only occur reasonably randomly and only under quite heavy load. The developer is looking into it, but the problem only occurs on FreeBSD 7.0, not any other Unix systems. In the meantime I am losing money because of it. Some generic things to try: - add debug flags to malloc.conf, especially J, maybe X and P and see if anything abnormal comes up. If it does, the bug is in the program. - run it on an older version of FreeBSD with debugging flags (for the old malloc: J, X and Z), also look for problems. - link with an alternative malloc, there are several in ports - link with a debugging malloc, try to see if there are bugs Finally, there is no way to revert to the old approach because the new allocator is completely new; it allocates memory based on its own strategy. None of the malloc options affect the behaviour of correct programs (but some of them can help to improve performance, or to debug incorrect programs). Not surprising but I seem to recall that when it was first introduced into stable that there was some discussion on how to make it look more like the old malloc. I couldn't find that via a search though. You can never make it look like the old malloc - that was the point of introducing it. There could be a bug in the new malloc, but many complex programs are running fine on it so the chances are slim. signature.asc Description: OpenPGP digital signature
Re: malloc options
On Sat, 26 Jul 2008 17:36:35 -0700, Doug Hardie [EMAIL PROTECTED] wrote: On Jul 26, 2008, at 17:10, Kris Kennaway wrote: Firstly, if you did not recompile the program under 7.0 then it is not using the new malloc at all. It was recompiled. All there is on the system is new stuff. It was built from scratch when 7.0 came out. If you did recompile it and it is behaving differently then it is probably because your program contains bugs in how it manages memory that happened to be working by accident with the old memory allocator. e.g. because you were making use of memory after it had been freed, but before the allocator returned it to some other malloc() call. That is certainly possible. However, the program has worked under considerable load for many years with versions 3.7 to 6.2. Problems only occur with 7.0. The program is quite complex and big. It uses probably hundreds of mallocs in a typical use. The problems only occur reasonably randomly and only under quite heavy load. The developer is looking into it, but the problem only occurs on FreeBSD 7.0, not any other Unix systems. In the meantime I am losing money because of it. While that's understandable, the current malloc() has undergone quite extensive testing by Jason Evans and a lot of people who use it in FreeBSD 7.X or later. Its ability to expose bugs in this way was deemed important enough that it is now used by other projects too. What Kris wrote in: Finally, there is no way to revert to the old approach because the new allocator is completely new; it allocates memory based on its own strategy. None of the malloc options affect the behaviour of correct programs (but some of them can help to improve performance, or to debug incorrect programs). is a bit important. Even if you tweak enough options the new malloc() may *not* work similarly enough for the program to keep working. If you are lsing money _right_ _now_ because of problems in the program, it may be worth going back to 6-STABLE and the old malloc() until the bugs of the program have been fixed by the developers. Not surprising but I seem to recall that when it was first introduced into stable that there was some discussion on how to make it look more like the old malloc. I couldn't find that via a search though. If all else fails, you can try forward-porting phkmalloc to 7.X but it's not necessarily easier than going temporarily back to 6.X and fixing the program to work correctly on 7.X. It basically all boils down to ``How much time do you want to spend with a possibly crashing service?'' There's definitely a bug somewhere and you ultimately need it resolved. It is highly unlikely that it is in malloc() itself, but you can probably use its debugging features to help you find out if it is a bug in malloc() (see the preprocessor define MALLOC_PRODUCTION in libc/stdlib/malloc.c), or if it a bug in the program using malloc() and _where_ it may be. The new malloc() also includes an option that can dump 'utrace' debug output of all the malloc(), calloc(), realloc(), posix_memalign() and free() calls of malloc.c. If you haven't tried it already, it may be another useful tool to help you track down where the bug is. Tracing a program's malloc usage with the 'U' option is relatively easy to do if you spawn just *this* program with MALLOC_OPTIONS='U': # ktrace env MALLOC_OPTIONS='U' your-program-here Then you can dump the 'utrace' entries logged by ktrace, with: # kdump [optionally, more kdump options] -f ktrace.out You should see something like this: $ kdump -T -t u -f ktrace.out | head -40 26674 ls 1217123351.156040 USER malloc_init() 26674 ls 1217123351.156369 USER 0x8101000 = malloc(4096) 26674 ls 1217123351.156515 USER 0x8102000 = malloc(2560) 26674 ls 1217123351.156611 USER 0x8103800 = malloc(2048) 26674 ls 1217123351.156702 USER 0x810b020 = malloc(20) 26674 ls 1217123351.156881 USER free(0x8101000) 26674 ls 1217123351.157074 USER 0x8101000 = malloc(3191) 26674 ls 1217123351.157191 USER 0x810c000 = malloc(4096) 26674 ls 1217123351.157369 USER 0x810d000 = malloc(3219) 26674 ls 1217123351.157431 USER free(0x8101000) 26674 ls 1217123351.157538 USER free(0x810c000) 26674 ls 1217123351.157743 USER 0x810e400 = malloc(524) 26674 ls 1217123351.157865 USER 0x8104000 = malloc(1280) 26674 ls 1217123351.157922 USER 0x8101040 = malloc(89) 26674 ls 1217123351.157975 USER 0x81010a0 = malloc(90) 26674 ls 1217123351.158065 USER 0x8101100 = malloc(89) 26674 ls 1217123351.158170 USER free(0x8101100) [...] If your bug is a double-free bug, then a bit of post-processing of this will quickly reveal if there *is* a double free bug when a duplicate free() call is found. Then you can dump more ktrace records, in an
Re: crontab mails
On Sat, Jul 26, 2008 at 08:18:14PM +0800, Jyun-Yi Liou wrote: Hi Yavuz, It's easy to tell crontab stop sending mail to you by disable sendmail in /etc/rc.conf % echo sendmail_enable=\NO\ man rc.conf for more information :-) Kind of overkill, don't you think? Sendmail does more than crontab mails. or set the variable MAILTO null on corntab MAILTO= Better. jerry Regards, jyuny1 2008/7/26 Yavuz Maslak [EMAIL PROTECTED] Hello On freebsd7.0, my crontab sends many mails about its jobs. I want crontab not to send these mails How can I do that ? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: upgrade from 6.3 to 7.0
On Fri, Jul 25, 2008 at 09:25:12PM -0400, David Gurvich wrote: You should not do the upgrade, Whatever would cause you to give such poor advice? though you can. ZFS is still experimental on FreeBSD though you can certainly use zfs pools on your existing system. It works. jerry ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: malloc options
On Jul 26, 2008, at 18:47, Ivan Voras wrote: Doug Hardie wrote: If you did recompile it and it is behaving differently then it is probably because your program contains bugs in how it manages memory that happened to be working by accident with the old memory allocator. e.g. because you were making use of memory after it had been freed, but before the allocator returned it to some other malloc() call. That is certainly possible. However, the program has worked under considerable load for many years with versions 3.7 to 6.2. Problems only occur with 7.0. The program is quite complex and big. It uses The memory allocator was the same between 3.7 and 6.x - it only changed in 7.0. Your description looks like a use-after-free bug. Your application is in C, not C++, right? I can't say for sure as I have never looked at all the code. Part is in c though. I would tend to support that theory except that the area being modified is still allocated. It was never freed. Its value got changed to something that is not in any file on the computer. It is a reasonably recoginizable ascii string, but basically meangineless. Also, this app has been running for almost 5 years doing the same thing on earlier versions of FreeBSD. I know at least 6.1, 6.2, 5.4 5.3 and possibly earlier. I just don't recall which one was in use when we setup the workload that is causing the issue now. It still continues to run just fine on 6.3. probably hundreds of mallocs in a typical use. The problems only occur reasonably randomly and only under quite heavy load. The developer is looking into it, but the problem only occurs on FreeBSD 7.0, not any other Unix systems. In the meantime I am losing money because of it. Some generic things to try: - add debug flags to malloc.conf, especially J, maybe X and P and see if anything abnormal comes up. If it does, the bug is in the program. - run it on an older version of FreeBSD with debugging flags (for the old malloc: J, X and Z), also look for problems. - link with an alternative malloc, there are several in ports - link with a debugging malloc, try to see if there are bugs I'll give those a try. Finally, there is no way to revert to the old approach because the new allocator is completely new; it allocates memory based on its own strategy. None of the malloc options affect the behaviour of correct programs (but some of them can help to improve performance, or to debug incorrect programs). Not surprising but I seem to recall that when it was first introduced into stable that there was some discussion on how to make it look more like the old malloc. I couldn't find that via a search though. You can never make it look like the old malloc - that was the point of introducing it. There could be a bug in the new malloc, but many complex programs are running fine on it so the chances are slim. This is definitely a difficult issue. The majority of malloc calls are actually within strdup. There are no frees for any of those returned values. They live till the program ends. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: malloc options
On Jul 26, 2008, at 19:03, Giorgos Keramidas wrote: While that's understandable, the current malloc() has undergone quite extensive testing by Jason Evans and a lot of people who use it in FreeBSD 7.X or later. Its ability to expose bugs in this way was deemed important enough that it is now used by other projects too. while in general I like the new approach, this problem has been a killer. I did find a number of errors in my own code where I was not allocating enough space for some things. Those showed up instantly with 7.0 and were easy to fix. What Kris wrote in: Finally, there is no way to revert to the old approach because the new allocator is completely new; it allocates memory based on its own strategy. None of the malloc options affect the behaviour of correct programs (but some of them can help to improve performance, or to debug incorrect programs). is a bit important. Even if you tweak enough options the new malloc() may *not* work similarly enough for the program to keep working. If you are lsing money _right_ _now_ because of problems in the program, it may be worth going back to 6-STABLE and the old malloc() until the bugs of the program have been fixed by the developers. Unfortunately that is not possible. We upgraded the hardware and some of the components were not supported very well under 6.x. Despite several weeks of testing of the new hardware and 7.0, the problem did not arise till several weeks after going into production. It takes about a week of real time before the problem tends to become visible. By compressing the workload I have been able to setup a test machine such that it takes 2-4 days before it occurs. Not surprising but I seem to recall that when it was first introduced into stable that there was some discussion on how to make it look more like the old malloc. I couldn't find that via a search though. If all else fails, you can try forward-porting phkmalloc to 7.X but it's not necessarily easier than going temporarily back to 6.X and fixing the program to work correctly on 7.X. It basically all boils down to ``How much time do you want to spend with a possibly crashing service?'' There's definitely a bug somewhere and you ultimately need it resolved. It is highly unlikely that it is in malloc() itself, but you can probably use its debugging features to help you find out if it is a bug in malloc() (see the preprocessor define MALLOC_PRODUCTION in libc/stdlib/malloc.c), or if it a bug in the program using malloc() and _where_ it may be. The new malloc() also includes an option that can dump 'utrace' debug output of all the malloc(), calloc(), realloc(), posix_memalign() and free() calls of malloc.c. If you haven't tried it already, it may be another useful tool to help you track down where the bug is. Tracing a program's malloc usage with the 'U' option is relatively easy to do if you spawn just *this* program with MALLOC_OPTIONS='U': # ktrace env MALLOC_OPTIONS='U' your-program-here Then you can dump the 'utrace' entries logged by ktrace, with: # kdump [optionally, more kdump options] -f ktrace.out You should see something like this: $ kdump -T -t u -f ktrace.out | head -40 26674 ls 1217123351.156040 USER malloc_init() 26674 ls 1217123351.156369 USER 0x8101000 = malloc(4096) 26674 ls 1217123351.156515 USER 0x8102000 = malloc(2560) 26674 ls 1217123351.156611 USER 0x8103800 = malloc(2048) 26674 ls 1217123351.156702 USER 0x810b020 = malloc(20) 26674 ls 1217123351.156881 USER free(0x8101000) 26674 ls 1217123351.157074 USER 0x8101000 = malloc(3191) 26674 ls 1217123351.157191 USER 0x810c000 = malloc(4096) 26674 ls 1217123351.157369 USER 0x810d000 = malloc(3219) 26674 ls 1217123351.157431 USER free(0x8101000) 26674 ls 1217123351.157538 USER free(0x810c000) 26674 ls 1217123351.157743 USER 0x810e400 = malloc(524) 26674 ls 1217123351.157865 USER 0x8104000 = malloc(1280) 26674 ls 1217123351.157922 USER 0x8101040 = malloc(89) 26674 ls 1217123351.157975 USER 0x81010a0 = malloc(90) 26674 ls 1217123351.158065 USER 0x8101100 = malloc(89) 26674 ls 1217123351.158170 USER free(0x8101100) [...] If your bug is a double-free bug, then a bit of post-processing of this will quickly reveal if there *is* a double free bug when a duplicate free() call is found. Then you can dump more ktrace records, in an effort to pinpoint the exact place where the original allocation happens, and you can keep going from there. If you see data changing 'under your feet' it's quite likely that you are trying to use data after it has been freed. A nice option that you can _enable_ to catch that in action is 'J'. By dumping the unexpected data and using the info from malloc.conf(5)'s description of
SATA300
My machine, a home-brew running 7.0-RELEASE-p2, has 3 SATA hard drives all of which were advertised, I believe, as SATA300 drives, but: vader# dmesg | grep ATA ata0: ATA channel 0 on atapci0 ata1: ATA channel 1 on atapci0 atapci1: Intel ICH7 SATA300 controller port 0x20c8-0x20cf,0x20ec-0x20ef,0x20c0-0x20c7,0x20e8-0x20eb,0x20a0-0x20af irq 19 at device 31.2 on pci0 ata2: ATA channel 0 on atapci1 ata3: ATA channel 1 on atapci1 ad4: 305245MB Hitachi HDT725032VLA360 V54OA7EA at ata2-master SATA150 ad5: 476940MB MAXTOR STM3500630AS 3.AAE at ata2-slave SATA150 ad6: 305245MB Hitachi HDT725032VLA360 V54OA7EA at ata3-master SATA150 Does this mean I'm only getting half the throughput I could be getting? Thanks, Jason ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
SATA300
My machine, a home-brew running 7.0-RELEASE-p2, has 3 SATA hard drives all of which were advertised as SATA300 drives, but: vader# dmesg | grep ATA ata0: ATA channel 0 on atapci0 ata1: ATA channel 1 on atapci0 atapci1: Intel ICH7 SATA300 controller port 0x20c8-0x20cf,0x20ec-0x20ef,0x20c0-0x20c7,0x20e8-0x20eb,0x20a0-0x20af irq 19 at device 31.2 on pci0 ata2: ATA channel 0 on atapci1 ata3: ATA channel 1 on atapci1 ad4: 305245MB Hitachi HDT725032VLA360 V54OA7EA at ata2-master SATA150 ad5: 476940MB MAXTOR STM3500630AS 3.AAE at ata2-slave SATA150 ad6: 305245MB Hitachi HDT725032VLA360 V54OA7EA at ata3-master SATA150 Does this mean I'm only getting half the throughput I could be getting? Thanks, Jason ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SATA300
On Sat, Jul 26, 2008 at 11:22:26PM -0400, Jason Lenthe wrote: My machine, a home-brew running 7.0-RELEASE-p2, has 3 SATA hard drives all of which were advertised as SATA300 drives, but: vader# dmesg | grep ATA ata0: ATA channel 0 on atapci0 ata1: ATA channel 1 on atapci0 atapci1: Intel ICH7 SATA300 controller port 0x20c8-0x20cf,0x20ec-0x20ef,0x20c0-0x20c7,0x20e8-0x20eb,0x20a0-0x20af irq 19 at device 31.2 on pci0 ata2: ATA channel 0 on atapci1 ata3: ATA channel 1 on atapci1 ad4: 305245MB Hitachi HDT725032VLA360 V54OA7EA at ata2-master SATA150 ad5: 476940MB MAXTOR STM3500630AS 3.AAE at ata2-slave SATA150 ad6: 305245MB Hitachi HDT725032VLA360 V54OA7EA at ata3-master SATA150 Does this mean I'm only getting half the throughput I could be getting? Considering that the fastest SATA drives available today tops out at a throughput of about 120MB/s (and most are quite a bit slower), I would say that any speed loss from running at SATA150 speed instead of SATA300 will be fairly minor and probably not even noticable. Many SATA hard drives have a jumper that can be used to limit them to SATA150 speeds. It is often set by default, since some older SATA controllers fail to auto-negotiate speed correctly, so the drive must be running at SATA150 to work with those controllers. See if you drives have such a jumper set. If so try removing it. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
