From owner-freebsd-arm@FreeBSD.ORG Tue Sep 30 14:05:16 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5FAD0170; Tue, 30 Sep 2014 14:05:16 +0000 (UTC) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AD1E2F84; Tue, 30 Sep 2014 14:05:15 +0000 (UTC) Received: by mail-lb0-f174.google.com with SMTP id p9so1536383lbv.33 for ; Tue, 30 Sep 2014 07:05:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=JjqUw6WWChcVY6g7VTtBTZxbSWUJnU/9bjrLiK5EuII=; b=gbPnjRJ3lLLGaLT6/X9Z2CXwaPtdMzqm2TdPUclssMlss5Zq+ZRejHQgRW/i+v6Y2I TS5NKvWMUWt38+DrxUGj2+tB5L8jTGpkkeaw935ylWDttE2IiR3OMLlMINbO+hUkcSgI odaAF3q3U+vbZWtfTtxrFTn2ff6OEcNSWVxntZeE4b8Xp2ltZ/tJRWoXjStYNeFOIrf5 rc19v2QzTfNgzLU2j0GotMGCzrSAQre7aAABWXUPF6NP4mSSdu8qC7t8bS6UsUSc2r5D 6I0QvppV311M/jdy2Q3VkeNvO9v6jkc64PplXGaK0ArBsvMUVkF63ZamysM3CZ7yejqV GgLQ== X-Received: by 10.152.7.193 with SMTP id l1mr48037144laa.62.1412085913538; Tue, 30 Sep 2014 07:05:13 -0700 (PDT) Received: from ?IPv6:2001:1620:ff0:c51:65fd:7630:d87f:4cbe? ([2001:1620:ff0:c51:65fd:7630:d87f:4cbe]) by mx.google.com with ESMTPSA id jv4sm6099946lbc.35.2014.09.30.07.05.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Sep 2014 07:05:12 -0700 (PDT) Message-ID: <542AB897.3020309@gmail.com> Date: Tue, 30 Sep 2014 16:05:11 +0200 From: Mattia Rossi User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-arm , jmg@funkthat.com Subject: Re: Random Kernel Panic on Dreamplug (FS related) References: <542559BC.7090100@gmail.com> <20140929040126.GG43300@funkthat.com> <54291B74.5010307@gmail.com> <20140930112937.GU43300@funkthat.com> <542A9EA4.70109@gmail.com> <20140930123010.GZ43300@funkthat.com> In-Reply-To: <20140930123010.GZ43300@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 14:05:16 -0000 Am 30.09.2014 14:30, schrieb John-Mark Gurney: > Mattia Rossi wrote this message on Tue, Sep 30, 2014 at 14:14 +0200: >> Am 30.09.2014 13:29, schrieb John-Mark Gurney: >>> Mattia Rossi wrote this message on Mon, Sep 29, 2014 at 10:42 +0200: >>>> Am 29.09.2014 06:01, schrieb John-Mark Gurney: >>>>> Mattia Rossi wrote this message on Fri, Sep 26, 2014 at 14:19 +0200: >>>>>> This might be part of the weird FFS issues the Dreamplug has and no-one >>>>>> knows why they're happening. >>>>> Are you running w/ FFS journaling? If so, try turning it off, but >>>>> keeping softupdates on.. >>>> No journaling, no softupdates. I'll try enabling softupdates next time. >>>> don't know if it will panic though >>>>>> data_abort_handler() at data_abort_handler+0x5c0 >>>>>> pc = 0xc0de7a28 lr = 0xc0dd711c (exception_exit) >>>>>> sp = 0xde019898 fp = 0xde019a20 >>>>>> r4 = 0xffffffff r5 = 0xffff1004 >>>>>> r6 = 0xc3f3f6c0 r7 = 0x00001000 >>>>>> r8 = 0xc443e880 r9 = 0x00000000 >>>>>> r10 = 0xc3d69000 >>>>>> exception_exit() at exception_exit >>>>>> pc = 0xc0dd711c lr = 0xc0d53828 (ffs_truncate+0xaa8) >>>>>> sp = 0xde0198e8 fp = 0xde019a20 >>>>>> r0 = 0xd0238120 r1 = 0x00000e60 >>>>>> r2 = 0x00000000 r3 = 0x00000000 >>>>>> r4 = 0x00000120 r5 = 0x00000000 >>>>>> r6 = 0xc3f3f6c0 r7 = 0x00001000 >>>>>> r8 = 0xc443e880 r9 = 0x00000000 >>>>>> r10 = 0xc3d69000 r12 = 0xd0238120 >>>>>> memset() at memset+0x48 >>>>>> pc = 0xc0de521c lr = 0xc0d53828 (ffs_truncate+0xaa8) >>>>>> sp = 0xde0198e8 fp = 0xde019a20 >>>>>> Unwind failure (no registers changed) >>>>> No more beyond this? If you could run addr2line on 0xc0d53828 so >>>>> that we know where in ffs_truncate it's failing, that'd be very >>>>> nice... >>>> So I was trying to save the coredump in order to reboot and run >>>> addr2line, but that failed: >>>> >>>> Physical memory: 504 MB >>>> Dumping 67 MB:(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 01 d5 1f20 >>>> 00 00 01 00 >>>> (da0:umass-sim0:0:0:0): CAM status: Resource Unavailable >>>> (da0:umass-sim0:0:0:0): Error 5, Retries exhausted >>>> Aborting dump due to I/O error. >>>> >>>> ** DUMP FAILED (ERROR 5) ** >>>> >>>> So I guess this error is related to the CAM errors I'm getting from time >>>> to time. I was hoping that those errors were related to the INVARIANTS >>>> option that slowed down the system and thus might have triggered CAM >>>> errors, but obviously the SD Card seems to be the real issue here. >>>> So no crashdump for further analysis. >>> That's fine.. w/ the addr2line we have some lines to explore... >>> >>>> Interestingly the CAM errors didn't show up on the terminal as other >>>> times, the kernel just panicked straight away. >>> Hmm.. that is odd.. someone who knows the SD card layer should look >>> at this part... It could be that the SD card driver doesn't handle >>> dumping (there is this global flag that gets set) properly and the driver >>> needs to behave differently when it's set... >> I also need to grab a new SD card, just to make sure it's really not the >> card. >> >>>> But I've got the addr2line output, even though I'm not sure it makes any >>>> difference: >>>> >>>> addr2line -f -e /mnt/kernel.debug 0xc0d53828 >>>> >>>> ffs_truncate >>>> /usr/devel/dreamplug/sys/ufs/ffs/ffs_inode.c:321 >>> can you give me the contents of the line? and a few lines of context >>> around it? In HEAD's source, this is DOINGASYNC, and there is no call >>> to memset, nor a variable assignment that would result in memset being >>> called... >> Same here.. The file hasn't been changed in a while (Fri, 31 May 2013): >> >> ip->i_size = length; >> DIP_SET(ip, i_size, length); >> if (bp->b_bufsize == fs->fs_bsize) >> bp->b_flags |= B_CLUSTEROK; >> if (flags & IO_SYNC) >> bwrite(bp); >> 321: else if (DOINGASYNC(vp)) >> bdwrite(bp); >> else >> bawrite(bp); >> ip->i_flag |= IN_CHANGE | IN_UPDATE; >> return (ffs_update(vp, !DOINGASYNC(vp))); >> >> No idea what's going on. > ok, could you send me the output of objdump -dSl, but you only need > to include the part from XXXXX : to the next XXX: > line... probably off list as it'll be quite long... I'm sorry, but given that I just broke all my working worlds using fsck, I'm not going to be able to do that until I'm back from holidays.... currently working on the stuff remotely and after today's work day, I'm not going to be able to get my hands on the dreamplug.