Re: Western Digital hard disks and ATA timeouts
I can confirm that. Many FreeNAS users had problems with their HDDs (e.g. with APM, awake disks to access them after they felt to sleep). Increasing timeouts solves the problem in most cases. I think increasing the value BUT allowing the user to set it to a preferred value via sysctrl would be the best solution. I don't understand why adding such an sysctl interface is such an problem for some people. If someone wants to set any other value than the default one HE MUST KNOW what he do and live with the consequences. There are so many other kernel/system variables that can harm the system. Regards Volker http://dict.leo.org/ende?lp=endep=thMx..search=implications Peter Wemm wrote: On Thu, Nov 6, 2008 at 11:17 PM, Jeremy Chadwick [EMAIL PROTECTED] wrote: [..] As stated, FreeBSD's ATA command timeout is hard-set to 5 seconds, and is not adjustable without editing the ATA code yourself and increasing the value. The FreeNAS folks have made patches available to turn the timeout value into a sysctl. Soren and/or others, please increase this timeout value. Five seconds has now been deemed too aggressive a default. And please consider migrating the timeout value into a sysctl. The 5 second timeout has been a problem for quite a while actually. I've had a number of instances where I've had to increase it to 20 or 30 seconds when recovering from marginal drives. The longest successful recovery attempt I've seen was 26 seconds, I believe on a Maxtor drive a few years ago. (successful == the drive spent 26 seconds but eventually successfully read the sector). Even the IBM death star drives could take much longer than 5 seconds to do a recovery 5 years ago. 5 seconds has never been a good default. I think the timeout should be increased to at least 30 seconds. My windows box has a timeout that goes for several minutes. If there is concern about FreeBSD appearing to hang, I could imagine that a console warning message could be printed after 5 seconds. But just say drive has not yet responded. But give it more time. In this day and age we're generally not playing games with udma33 vs 66, notched cables, poor CRC support etc. SATA seems to have eliminated all that. Hmm, it might make sense to increase the timeout on SATA connections to 2 or 3 minutes by default. Internal Virus Database is out of date. Checked by AVG - http://www.avg.com Version: 8.0.175 / Virus Database: 270.8.5/1764 - Release Date: 03.11.2008 07:46 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Instant reboot with FreeBSD 6.3 and 2GB RAM
Hello, i can confirm that the bug fix submitted with PR 108215 solves the reboot problem when using mfsroot images in FreeBSD 6.3. I will test it also on FreeBSD 7.0, but i assume that it will fix it there too. Many users using FreeNAS reporting this reboot problem on their machines with RAM 2GB. Regards Volker Original-Nachricht Datum: Wed, 21 May 2008 21:08:25 +0200 Von: Volker [EMAIL PROTECTED] An: [EMAIL PROTECTED] CC: freebsd-stable@freebsd.org, [EMAIL PROTECTED] Betreff: Re: Instant reboot with FreeBSD 6.3 and 2GB RAM On 12/23/-58 20:59, [EMAIL PROTECTED] wrote: Hello, some users of FreeNAS which is based on FreeBSD 6.3 reported instant reboots on systems with 2GB RAM (most of them use 4GB). The reboot occurs right after displaying the FreeBSD loader menu. Most of them told me that they can boot if they reduce RAM to = 2GB. We are using the following kernel configuration which is based on GENERIC: http://freenas.svn.sourceforge.net/viewvc/freenas/branches/0.69/build/kernel-config/FREENAS-i386?revision=3291view=markup I found out another problem that causes a reboot on my 2GB machine. We are using a image for the LiveCD which is 64MB great. If i change back mfs_root size to 63MB all works well, but all above 64MB causes a reboot. Is there any limitation? Could someone help me out of this problem? Regards Volker Hi Volker ;) I'm not quite sure about your 2nd problem and your report is not quite detailed but from your description it looks like loader is causing that. As there's no filesystem available at that time, the loader has to read itself through the filesystem structures. Knowing that, PR misc/108215 comes to mind. I've not been able to check if the issue and the patch to it is right but you may give it a try. Probably somebody with loader and filesystem (ufs) knowledge may answer that question quickly if the patch contained in the PR is right. The report is about 6.2-R but at least I've checked loader code and 7.x code is the same. I came across that report yesterday and was unable to check the calculation. If that is really the case, your problem may be related to that. http://www.freebsd.org/cgi/query-pr.cgi?pr=108215 Assuming the problem report is right, it's about reading huge files by loader reads in wrong sectors. HTH Volker -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
