From owner-freebsd-stable@FreeBSD.ORG Wed Mar 17 23:30:27 2004 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 682E616A4CF; Wed, 17 Mar 2004 23:30:27 -0800 (PST) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A5B643D48; Wed, 17 Mar 2004 23:30:26 -0800 (PST) (envelope-from sos@DeepCore.dk) Received: from DeepCore.dk (csc-gw1.novi.dk [130.225.63.24]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id i2I7U8RQ028082; Thu, 18 Mar 2004 08:30:23 +0100 (CET) (envelope-from sos@DeepCore.dk) Message-ID: <40594FFA.80204@DeepCore.dk> Date: Thu, 18 Mar 2004 08:30:02 +0100 From: =?KOI8-R?Q?S=3Fren_Schmidt?= User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6b) Gecko/20040126 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eugene Grosbein References: <40591EC9.B797F608@kuzbass.ru> In-Reply-To: <40591EC9.B797F608@kuzbass.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit X-mail-scanned: by DeepCore Virus & Spam killer v1.4 cc: stable@FreeBSD.ORG cc: bug-followup@FreeBSD.ORG cc: sos@FreeBSD.ORG Subject: Re: kern/60526: Post-PAE stable SMP machine freezes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2004 07:30:27 -0000 Eugene Grosbein wrote: > Hi! > > According to > http://freebsd.rambler.ru/bsdmail/freebsd-hackers_2003/msg03936.html > the problem may be related to the > and ATA write cache (hw.ata.wc=1). > > Note however, I had no kernel panic with post-PAE STABLE. > I had kernel lockup. I can understand kernel panic due to the faulty > devices but not endless loop that it seems to happen. > > It's known (and noted in the Errata for 4.9-RELEASE) > that PAE integration broke hw.ata.tags. Perhaps, its time > either to document that hw.ata.wc is broken for noted controller too, > either to forbid write cache for it by force. I have a hard time beliving WC can be the problem. WC is a function of the disk drive it has nothing todo with the controller or even the way we talk to the disk... That said, the ROSB4 is known to be wierd, bad things can easily happend with it in some setups and there is noting we can do about it in SW (less using PIO mode). However some HW vendors seem to have found a HW solution to the problem (ASUS is one of them, my old CUR-DLS doesn't show the problems at all)... -- -S?ren