Re: Dell PERC5/i SAS5/5IR - RAID monitoring
Am 21.07.2007 um 01:15 schrieb Tom Judge: Michael Worobcuk wrote: Am 21.07.2007 um 00:18 schrieb Tom Judge: Michael Worobcuk wrote: Tom Judge wrote: As for performance issues with the SAS5/i, there is a problem in the controller. A work arround was created by Scott Long which created a sysctl that could be set to cause the controller to turn on the on drive write cache's. These changes where commited to RELENG_6 on 2007-06-05 21:32:57 UTC. ... Here is the original commit log: scottl 2007-06-03 23:13:05 UTC FreeBSD src repository Modified files: sys/dev/mpt mpt.c mpt.h mpt_cam.c Log: mpt.c: mpt.h: Add support for reading extended configuration pages. mpt_cam.c: Do a top level topology scan on the SAS controller. If any SATA device are discovered in this scan, send a passthrough FIS to set the write cache. This is controllable through the following tunable at boot: hw.mpt.enable_sata_wc: -1 = Do not configure, use the controller default 0 = Disable the write cache 1 = Enable the write cache The default is -1. This tunable is just a hack and may be deprecated in the future. I set mpt.enable_sata_wc to 1, as hw.mpt.enable_sata_wc is, AFAIK not tunable in mpt_cam.c. This did not take any effect to the performance. Is there anything else to change ? Not that I know of, do you have SAS or SATA disks attached to the controller? yes, SAS. In that case the above sysctl is not going to work for you as as the name suggests it is only for sata devices. For someone with a bit more SCSI experience than me: Could this be solved by setting the WCE (Write cache enable) bit in the modepage (8) on sas devices if it is not already set? The driver could make this change on SAS devices during the topology scan in similar way to the way it does for SATA devices? Tom hey sorry. Already a bit tired yesterday. I have SATA drives connected, in my mind was the name: sas5ir. But I have SATA DRIVES. sorry again. Michael ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: removing external usb hdd without unmounting causes reboot?
Norberto Meijome schrieb: On Thu, 19 Jul 2007 17:38:14 +0200 [LoN]Kamikaze [EMAIL PROTECTED] wrote: As I mentioned earlier I remember it working during the 5.3 era on Stable, at some point it worked. I even remember removing my CD-Rom drive from my Thinkpad without running atacontrol detach. The system just took it and the drive just continued working after I put it back in. on 6.2-STABLE (of a few days ago), i have this happening a couple of times with no adverse effect at all. Burn DVD/Cd, when finished, hald detects the disk, mounts it, /dev/cd0 in /media/whatever. i can eject the disk just fine (which in itself is weird, i think) the device is still there... umount /dev/cd0 works fine and off it goes. other than that, no, i havent tried to access the device in question In that case the device has been mounted R/O before, and if you don't remove it in the middle of a transaction, there is nothing the kernel might want to do with the physical device to unmount it (and even within a transfer, this ought to be caught by the driver). For that reason I had suggested to have a soft-R/O mode for removable devices, which together with a very short flush delay might allow such a device to be mounted R/O nearly all the time (tm) ;-) This is not a perfect solution, but it is similar to the way USB sticks are used with Windows/XP: Wait a second or two and remove it. While not perfect this covers the case of MP3 players or digicams that are mounted as USB storage devices, and many other cases. To make this a perfect solution is much harder, but even a simple implementation would be a big step forward. Regards, STefan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: removing external usb hdd without unmounting causes reboot?
From: Norberto Meijome [EMAIL PROTECTED] i can eject the disk just fine (which in itself is weird, i think) the device is still there... umount /dev/cd0 works fine and off it goes. other than that, no, i havent tried to access the device in question I never saw that behaviour. It really should not eject. As you, I use scsi emulation, with no acd device at all. This topic is extremely interesting. For me, unmounting usb device is not so hard to do. I remember -r flag to mount with just read option. So, if hand follows the brain impuls, put another impuls to unmount it first. Zoran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCSI error during boot
Just so you know... after having done a large number of SCSI target mode implementations and having seen what initiators do, it's Microsoft that is the closest to actually adhering to and using the SCSI standards correctly. On 7/20/07, Torfinn Ingolfsen [EMAIL PROTECTED] wrote: On Fri, 20 Jul 2007 23:43:35 +0200 Uffe R. B. Andersen [EMAIL PROTECTED] wrote: That's nice to know, though I didn't expect it to be critical, as the disk has worked well for all 8 years, running with Windows 2000 and XP. IMHO, you should never use working on win... as a statement to say that some hardware is a) working b) compliant with a standard Just my two cents (having seen too much of broken hw and standards on win through the years). -- Regards, Torfinn Ingolfsen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell PERC5/i SAS5/5IR - RAID monitoring
Tom Judge wrote: Michael Worobcuk wrote: Am 21.07.2007 um 00:18 schrieb Tom Judge: Michael Worobcuk wrote: Tom Judge wrote: As for performance issues with the SAS5/i, there is a problem in the controller. A work arround was created by Scott Long which created a sysctl that could be set to cause the controller to turn on the on drive write cache's. These changes where commited to RELENG_6 on 2007-06-05 21:32:57 UTC. ... Here is the original commit log: scottl 2007-06-03 23:13:05 UTC FreeBSD src repository Modified files: sys/dev/mpt mpt.c mpt.h mpt_cam.c Log: mpt.c: mpt.h: Add support for reading extended configuration pages. mpt_cam.c: Do a top level topology scan on the SAS controller. If any SATA device are discovered in this scan, send a passthrough FIS to set the write cache. This is controllable through the following tunable at boot: hw.mpt.enable_sata_wc: -1 = Do not configure, use the controller default 0 = Disable the write cache 1 = Enable the write cache The default is -1. This tunable is just a hack and may be deprecated in the future. I set mpt.enable_sata_wc to 1, as hw.mpt.enable_sata_wc is, AFAIK not tunable in mpt_cam.c. This did not take any effect to the performance. Is there anything else to change ? Not that I know of, do you have SAS or SATA disks attached to the controller? yes, SAS. In that case the above sysctl is not going to work for you as as the name suggests it is only for sata devices. For someone with a bit more SCSI experience than me: Could this be solved by setting the WCE (Write cache enable) bit in the modepage (8) on sas devices if it is not already set? The driver could make this change on SAS devices during the topology scan in similar way to the way it does for SATA devices? There are absolutely no plans for the MPT driver to automatically change WCE settings for SAS, FC, or SCSI drives. The hack that I put in for SATA is exactly what it is, a hack. It gets around the fact that there is no SATA layer within CAM yet and thus no way to send SATA commands from userland like there is with SCSI/FC/SAS. That will be addressed in the future. So yes, the proper way to handle this is via camcontrol. With that you should be able to change the WCE bit both temporarily (i.e. until the next bus reset or power reset) or permanently (i.e. in NVRAM of the drive). Worst case scenario is the the drive doesn't support permanent settings, so you write a simple RC script to run camcontrol on each boot. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell PERC5/i SAS5/5IR - RAID monitoring
Michael Worobcuk wrote: Tom Judge wrote: As for performance issues with the SAS5/i, there is a problem in the controller. A work arround was created by Scott Long which created a sysctl that could be set to cause the controller to turn on the on drive write cache's. These changes where commited to RELENG_6 on 2007-06-05 21:32:57 UTC. ... Here is the original commit log: scottl 2007-06-03 23:13:05 UTC FreeBSD src repository Modified files: sys/dev/mpt mpt.c mpt.h mpt_cam.c Log: mpt.c: mpt.h: Add support for reading extended configuration pages. mpt_cam.c: Do a top level topology scan on the SAS controller. If any SATA device are discovered in this scan, send a passthrough FIS to set the write cache. This is controllable through the following tunable at boot: hw.mpt.enable_sata_wc: -1 = Do not configure, use the controller default 0 = Disable the write cache 1 = Enable the write cache The default is -1. This tunable is just a hack and may be deprecated in the future. I set mpt.enable_sata_wc to 1, as hw.mpt.enable_sata_wc is, AFAIK not tunable in mpt_cam.c. This did not take any effect to the performance. Is there anything else to change ? Send me output from bootverbose. Also ensure that you have the following line in your /boot/loader.conf file: hw.mpt.enable_sata_wc=1 Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell PERC5/i SAS5/5IR - RAID monitoring
Am 21.07.2007 um 21:33 schrieb Scott Long: Michael Worobcuk wrote: Tom Judge wrote: As for performance issues with the SAS5/i, there is a problem in the controller. A work arround was created by Scott Long which created a sysctl that could be set to cause the controller to turn on the on drive write cache's. These changes where commited to RELENG_6 on 2007-06-05 21:32:57 UTC. ... Here is the original commit log: scottl 2007-06-03 23:13:05 UTC FreeBSD src repository Modified files: sys/dev/mpt mpt.c mpt.h mpt_cam.c Log: mpt.c: mpt.h: Add support for reading extended configuration pages. mpt_cam.c: Do a top level topology scan on the SAS controller. If any SATA device are discovered in this scan, send a passthrough FIS to set the write cache. This is controllable through the following tunable at boot: hw.mpt.enable_sata_wc: -1 = Do not configure, use the controller default 0 = Disable the write cache 1 = Enable the write cache The default is -1. This tunable is just a hack and may be deprecated in the future. I set mpt.enable_sata_wc to 1, as hw.mpt.enable_sata_wc is, AFAIK not tunable in mpt_cam.c. This did not take any effect to the performance. Is there anything else to change ? Send me output from bootverbose. Also ensure that you have the following line in your /boot/loader.conf file: hw.mpt.enable_sata_wc=1 Yuppa, that worked ! Final score for writes: 285 Final score for reads : 16692 It was the line in my /boot/loader.conf. Thank you very very much. Very cool :) Michael ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCSI error during boot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Torfinn Ingolfsen wrote: IMHO, you should never use working on win... as a statement to say that some hardware is a) working b) compliant with a standard I was only stating, that after 8 years of use, I would have noticed if the disk/controller combination were giving file corruption. Just my two cents (having seen too much of broken hw and standards on win through the years). YMMW :) - -- Med venlig hilsen - Sincerely Uffe R. B. Andersen - mailto:[EMAIL PROTECTED] http://www.twe.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (MingW32) iD8DBQFGonxixC95nUQcrpgRAsRSAJ9cIfD5VwIrO6bQKkrO09019u0/0ACg+gZs JNmA1vEiGnqgU3gheALhJ+U= =coj5 -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ntpd just sits there and does nothing
Hi, [LoN]Kamikaze wrote: Doug Hardie wrote: On Jul 19, 2007, at 10:08, [LoN]Kamikaze wrote: As the subject says, on my 6-stable systems ntpd just sits there and does nothing. The logs only mention when the daemon gets started or shut down. It complains when servers are not reachable, but does nothing when they are available. The drift file always contains 0.00. ntpdate and openntpd both successfully manage to set the time, so I suppose it's a problem with ntpd. Are you on a static IP address? If not, ntpd obtains its IP address when it starts up and uses it forever. If your IP address changes then it will not be able to communicate with the upstream ntp servers. It has to be restarted everytime your IP address changes. I have a static address. The trouble is it seems to operate fine, only it forgets to change the time when it differs from the time servers too much. Sometimes my clock goes wrong more than 1 second within a day. ntpd will not change time if the difference is too big - I think it should be less then 1000s. ntpdate will :) ntpdate is deprecated and is not recommended these days. The proper answer is to start ntpd with the -g option and to add the 'iburst' option to one or more of the servers in /etc/ntp.conf. The 'iburst' will speed up th initial sync to close to that of ntpdate, but have much greater accuracy. You can get the '-g' by adding 'ntpd_sync_on_start=YES' to rc.conf. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpEVvJs4P11r.pgp Description: PGP signature
Re: removing external usb hdd without unmounting causes reboot?
In message: [EMAIL PROTECTED] Norberto Meijome [EMAIL PROTECTED] writes: : On Thu, 19 Jul 2007 09:02:50 -0600 (MDT) : M. Warner Losh [EMAIL PROTECTED] wrote: : : In message: [EMAIL PROTECTED] : Momchil Ivanov [EMAIL PROTECTED] writes: : : What is then the reason for the kernel not being able to unmount a : : filesystem whose provider is no longer present? : : The problem is that the device driver has wound down, deallocated : memory, etc. Now the kernel comes along with stale references to the : device and panic ensues. It is really just that simple. There's no : replacement of the now-dead device with dead calls. : : And even if you fixed that, most of the file systems in the tree today : do not tolerate errors on writes at all and that also leads to : panics. This is why firewire freezes the I/Os rather than failing : them (and why umount -f on a firewire drive hangs). : : Please point me to the correct RTFM, because I feel this worth it :) src/sys/fs/..., src/sys/kern/... and src/sys/vm/... are your best bets. : Is there a reason why the kernel cannot check 'upwards' if a device : is being used, ie mounted ? and prevent the unloading of the device : driver ? Check, sure, it can check. But what does a simple check accomplish if the filesystem panics if the underlying media returns an error? The problem isn't as simple as just looking in one place or another, but rather systemic in nature. Warner ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SATA 300 Drive Being Run At 150
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Saturday, July 21, 2007 11:55:39 -0500 Dan Nelson [EMAIL PROTECTED] wrote: In the last episode (Jul 21), Tim Daneliuk said: I asked this question a while back, but needed to do more digging to make sure I had latest sources etc. I have an Intel motherboard that shows this for a SATA controller: atapci1: Intel ICH7 SATA300 controller port 0x20c8-0x20cf,0x20ec-0x20ef,0x20c0-0x20c7,0x20e8-0x20eb,0x20a0-0x20af mem 0x90204000-0x902043ff irq 19 at device 31.2 on pci0 But the hard drive - a SATA 300 device - shows up like this: ad4: 238475MB WDC WD2500JS-00NCB1 10.02E02 at ata2-master SATA150 ^^^ Using dd, I have confirmed that the drive is running nowhere near SATA-III speeds, at least on reads: 968470075 bytes transferred in 7.132891 secs (135775249 bytes/sec) What was your dd commandline? If you've got more than 1GB of RAM and tested by reading a file and not the raw device itself, you just tested FreeBSD buffer cache. According to http://www.wdc.com/en/products/productspecs.asp?driveid=135 , that drive's maximum sustained speed is only 93.5 MB/sec, so it doesn't really matter if your interface is running at SATA150 or SATA300 unless you plan on reading exclusively from its 8MB buffer :) 'k, I just bought a new desktop, SATA/300MB/s interface, and this drive: http://www.wdc.com/en/products/products.asp?DriveID=254 Web site states 3Gb/s ... I'm seeing same SATA!50: atapci0: JMicron JMB361 SATA300 controller port 0xbf00-0xbf07,0xbe00-0xbe03,0xbd00-0xbd07,0xbc00-0xbc03,0xbb00-0xbb0f mem 0xfdbfe000-0xfdbf irq 16 at device 0.0 on pci2 atapci1: Intel ICH8 SATA300 controller port 0xfa00-0xfa07,0xf900-0xf903,0xf800-0xf807,0xf700-0xf703,0xf600-0xf60f,0xf500-0xf50f irq 19 at device 31.2 on pci0 atapci2: Intel ICH8 SATA300 controller port 0xf300-0xf307,0xf200-0xf203,0xf100-0xf107,0xf000-0xf003,0xef00-0xef0f,0xee00-0xee0f irq 19 at device 31.5 on pci0 ad8: 152627MB WDC WD1600AAJS-08PSA0 05.06H05 at ata4-master SATA150 Latest 6.x STABLE ... - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFGosqU4QvfyHIvDvMRAhENAKDhq0K+IDbZvD9Lcm51aLTwzjhz9ACgnFZz b3iDMLhANYWByT3a7Vu3utQ= =ZnlY -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SATA 300 Drive Being Run At 150
On Sun, Jul 22, 2007 at 12:10:12AM -0300, Marc G. Fournier wrote: 'k, I just bought a new desktop, SATA/300MB/s interface, and this drive: http://www.wdc.com/en/products/products.asp?DriveID=254 Web site states 3Gb/s ... I'm seeing same SATA!50: Seagate and WDC both ship SATA300 drives with a SATA150-limiting jumper on them. It's documented on the drive itself, and in the manufacturing manuals. Both companies do this as a precaution; there are some buggy chipsets out there which claim to support SATA300 but then break badly when utilising it. This is why the jumper's set to SATA150 by default. Chances are your drives have the jumper limiting the drive to SATA150. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SATA 300 Drive Being Run At 150
On Sun, Jul 22, 2007 at 12:10:12AM -0300, Marc G. Fournier wrote: In the last episode (Jul 21), Tim Daneliuk said: ad4: 238475MB WDC WD2500JS-00NCB1 10.02E02 at ata2-master SATA150 ad8: 152627MB WDC WD1600AAJS-08PSA0 05.06H05 at ata4-master SATA150 Something else I thought I'd mention in passing (though neither of you are affected by this, but I thought I'd throw it out there so people can find it): There is a specific model of WDC drive that reports incorrect thermal statistics via SMART. The temperatures are approximately 20C off (20C too high). The problem may affect other models, but so far has been confirmed by WD to affect 1 specific model. Rumour is that a drive firmware update can fix the problem, but WD isn't giving out the firmware nor the updater. Instead they're insisting owners file an RMA and send the drive back to WDC. How convenient. Two weeks ago I noticed one (Seagate) drive in our server was reporting 32C, while the WDC drive in the carrier next to it was reporting 54C. As usual these days: Google to the rescue. I opted to do the Advance Replacement, which is where you pay $80 or so for a replacement drive to be shipped to you first, and you'll be credited when WD receives the RMA'd drive. I'm glad I did it this way too, since chances are had I done a standard RMA it would've been returned to me with a there's nothing wrong with this drive note. The new drive I received had the same model and f/w revision, yet didn't see +20C temperatures via SMART. H! The reason I'm pointing this out: either it's a hardware problem (thermistor of the wrong kind being installed), or a f/w problem. If it's a f/w problem, they aren't bothering to update the f/w revision number to differentiate drives with the broken code vs. ones with the working code. Naughty Western Digital... The file I kept on this matter is below, which includes a quote from some forum user. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | = Protocol Serial ATA II device model WDC WD2500KS-00MJB0 firmware revision 02.01C03 http://episteme.arstechnica.com/groupee/forums/a/tpc/f/24609792/m/857003655731 http://forum.effizienzgurus.de/f40/temps-bei-wd-se16-250gb-wd2500ks-t1060.html So I got in touch with WD's Customer Support and I have just being informed that this paticular drive, WD2500KS-00MJB0, contains a bug in the Firmware (mine got version number 02.01C03) with regards to the usage of the SMART feature. The temperature of the drive which it reports is not correct. Mine read over 30 degrees centigrade just after I started the PC up. This Temperature got up to 62 degrees after a short while, whilst my other two WD drives still reported only 32-33 degrees in about the same position in the tower as this drive. I've been told an Firmware upgrade to rectify this is on it's way. http://www.bugtrack.almico.com/view.php?id=468 http://secure.ncix.com/forumpost/displaythread.php?threadid=1026701 http://www.lavalys.com/forum/lofiversion/index.php/t1372.html = ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
