From owner-freebsd-arm@FreeBSD.ORG Tue Mar 5 01:21:12 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2B3A5779 for ; Tue, 5 Mar 2013 01:21:12 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id C01FF757 for ; Tue, 5 Mar 2013 01:21:11 +0000 (UTC) Received: from [88.198.91.248] (helo=[IPv6:::1]) by id.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UCgYw-000Njs-1O for freebsd-arm@freebsd.org; Mon, 04 Mar 2013 17:21:04 -0800 Message-ID: <5135487C.80107@bluezbox.com> Date: Mon, 04 Mar 2013 17:21:00 -0800 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: Weird kernel mode data abort panic on Zedboard. References: <51354125.4060500@sbcglobal.net> In-Reply-To: <51354125.4060500@sbcglobal.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 3/4/2013 4:49 PM, Thomas Skibo wrote: > > Hello, again. > > I thought I'd describe this kernel panic and see if anyone has seen > anything similar. This is on the Zedboard (ARM Cortex-A9 armv6). > > I can consistently panic the kernel by ftp'ing files to a local > filesystem. It crashes every fourth time or so in the same manner. > The specific fault is a 'Permission Fault (P)' on the first page of > data in a file buf. > > The fault occurs in ffs_write() when it attempts to uiomove/copyin > data from user space to the file buf. The first write faults but > copyin() catches the fault and then calls vfs_bio_clrbuf() which tries > to zero out the buf data. It's the second fault that causes the panic. > > Using Xilinx's XMD tool, I can walk the page table in physical memory > and find the PTE. It is always okay and has priviledged read and > write permissions. Curiously, sometimes I get another permission > fault if I try to read from the fault address in the debugger. That > tells me there is a stale TLB entry without read permissions either. > The other buf pages seem okay. > > Any ideas? I can duplicate this with l2 cache turned off. I can also > duplicate it using a USB-ethernet interface instead of the Zynq cgem > ethernet interface so it's not that driver. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 01:21:12 -0000 On 3/4/2013 4:49 PM, Thomas Skibo wrote: > > Hello, again. > > I thought I'd describe this kernel panic and see if anyone has seen > anything similar. This is on the Zedboard (ARM Cortex-A9 armv6). > > I can consistently panic the kernel by ftp'ing files to a local > filesystem. It crashes every fourth time or so in the same manner. > The specific fault is a 'Permission Fault (P)' on the first page of > data in a file buf. > > The fault occurs in ffs_write() when it attempts to uiomove/copyin > data from user space to the file buf. The first write faults but > copyin() catches the fault and then calls vfs_bio_clrbuf() which tries > to zero out the buf data. It's the second fault that causes the panic. > > Using Xilinx's XMD tool, I can walk the page table in physical memory > and find the PTE. It is always okay and has priviledged read and > write permissions. Curiously, sometimes I get another permission > fault if I try to read from the fault address in the debugger. That > tells me there is a stale TLB entry without read permissions either. > The other buf pages seem okay. > > Any ideas? I can duplicate this with l2 cache turned off. I can also > duplicate it using a USB-ethernet interface instead of the Zynq cgem > ethernet interface so it's not that driver. Just a hunch here - looks like TLB entry is not update properly. Might be missing PTE_SYNC in pmap-v6.c. Or current PTE_SYNC implementation does not cover all requirements for your platform. I'd say latter - but without proper debugging it's just guesswork.