From owner-freebsd-current@FreeBSD.ORG Thu Feb 26 21:58:23 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EBCD106564A; Thu, 26 Feb 2009 21:58:23 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id CBBB98FC14; Thu, 26 Feb 2009 21:58:22 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 235992554; Thu, 26 Feb 2009 23:58:21 +0200 Message-ID: <49A7107A.5080208@FreeBSD.org> Date: Thu, 26 Feb 2009 23:58:18 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.19 (X11/20090118) MIME-Version: 1.0 To: Manfred Antar References: <200902250259.n1P2xvYh001449@pozo.com> <1235559230.15704.4.camel@buffy.york.ac.uk> <200902251410.n1PEAla5010605@pozo.com> <1235573928.15704.10.camel@buffy.york.ac.uk> <200902251508.n1PF8ORo001737@pozo.com> <1235576175.15704.15.camel@buffy.york.ac.uk> <200902260208.n1Q280jg001474@pozo.com> In-Reply-To: <200902260208.n1Q280jg001474@pozo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gavin Atkinson , FreeBSD-Current Subject: Re: Fatal trap 18 on Current 1386 since Saturday 21 Feb 2009 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 21:58:23 -0000 Manfred Antar wrote: > At 07:36 2/25/2009, Gavin Atkinson wrote: >> My suspicion is that it is this commit: >> >> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1637857+0+archive/2009/svn-src-all/20090222.svn-src-all >> >> >> Might be worthwhile trying the source from just before, and just after >> it and seeing if that is the cause. > > Yes that's it I put: > > /sys/dev/ata/ata-all.c > /sys/dev/ata/ata-all.h > /sys/dev/ata/ata-pci.h > /sys/dev/ata/ata-sata.c > /sys/dev/ata/chipsets/ata-promise.c > > from before the changes on the 21st in current /sys and kernel builds > and boots fine > My original date of the 14th was wrong, I looked at the calendar thought > it was the 14th > but actually uname -a of the last working kernel was the 21st 7am. Looking on on your first and later posts I would say that this commit may happen not a root of your problem. It may just trigger something else. Problem begins when some of your drives on ata1 channel timeouts request that leads to several controller reinits. I think that durung that driver somehow gets wrong drive parameters that leads to division by zero error inside ata_tf_write(). I have just committed one patch that probably does not fix the problem, but change process a bit. Could you try it and send me all ata related verbose messages starting from controller detection. -- Alexander Motin