From owner-freebsd-sparc64@FreeBSD.ORG Mon Dec 28 14:30:02 2009 Return-Path: Delivered-To: freebsd-sparc64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FF711065692 for ; Mon, 28 Dec 2009 14:30:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E62878FC14 for ; Mon, 28 Dec 2009 14:30:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBSEU1on073515 for ; Mon, 28 Dec 2009 14:30:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBSEU1se073510; Mon, 28 Dec 2009 14:30:01 GMT (envelope-from gnats) Resent-Date: Mon, 28 Dec 2009 14:30:01 GMT Resent-Message-Id: <200912281430.nBSEU1se073510@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-sparc64@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Manuel Schiller Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F52B10656C5 for ; Mon, 28 Dec 2009 14:25:59 +0000 (UTC) (envelope-from mala@hinterbergen.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by mx1.freebsd.org (Postfix) with ESMTP id 9F20D8FC19 for ; Mon, 28 Dec 2009 14:25:58 +0000 (UTC) Received: from router.hinter.bergen2 (pD95489F0.dip0.t-ipconnect.de [217.84.137.240]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MeMN5-1NcEDY1kqN-00PaWv; Mon, 28 Dec 2009 15:13:19 +0100 Received: by router.hinter.bergen2 (Postfix, from userid 1000) id 8D83B5C04; Mon, 28 Dec 2009 15:13:15 +0100 (CET) Message-Id: <20091228141315.8D83B5C04@router.hinter.bergen2> Date: Mon, 28 Dec 2009 15:13:15 +0100 (CET) From: Manuel Schiller To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Manuel Schiller Subject: sparc64/142102: FreeBSD 8.0 kernel panics on sparc64 when accessing NFS X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Manuel Schiller List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2009 14:30:02 -0000 >Number: 142102 >Category: sparc64 >Synopsis: FreeBSD 8.0 kernel panics on sparc64 when accessing NFS >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-sparc64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Dec 28 14:30:01 UTC 2009 >Closed-Date: >Last-Modified: >Originator: Manuel Schiller >Release: FreeBSD 8.0-RELEASE-p1 sparc64 >Organization: (none) >Environment: System: FreeBSD router.hinter.bergen2 8.0-RELEASE-p1 FreeBSD 8.0-RELEASE-p1 #4: Mon Dec 28 11:53:32 CET 2009 root@router.hinter.bergen2:/usr/obj/usr/src/sys/FENCHURCH sparc64 The machine is a SUN Netra T1 running FreeBSD 8.0. The kernel configuration is almost what ships as GENERIC, only a few unneeded NIC drivers have been removed, and KDB and DDB have been enabled. >Description: The kernel panics due to an unaligned memory access in the NFS server code. I could trace the problem to the statement on line 209 of sys/nfsserver/nfs_fha.c which does not satify the alignment requirements which sparc64 imposes. The backtrace I get from my kernel is below (sorry, kgdb does not work properly on sparc64, so I have to use the in-kernel backtrace...): panic: trap: memory address not aligned cpuid = 0 KDB: stack backtrace: panic() at panic+0x1c8 trap() at trap+0x4d0 -- memory address not aligned sfar=0xd6663424 sfsr=0x40029 %o7=0xc051b86c -- fha_assign() at fha_assign+0x140 svc_run_internal() at svc_run_internal+0x71c svc_thread_start() at svc_thread_start+0x8 fork_exit() at fork_exit+0x80 fork_trampoline() at fork_trampoline+0x8 Uptime: 1m12s Dumping 512 MB (2 chunks) chunk at 0: 268435456 bytes |\ If you need anything or want something tested, please let me know. >How-To-Repeat: Enable the NFS server options in /etc/rc.d on a sparc64 machine and try to mount any NFS share from a different machine. >Fix: Replace the assignment on line 209 of sys/nfsserver/nfs_fha.c with a call to memcpy, i.e. something like: memcpy(&i->fh, &fh.fh_generic.fh_fid.fid_data, sizeof(const u_int64_t *)); This is ugly, but will work for all architectures, regardless of alignment constraints imposed. This is likely to be a little slower than the original code, but I doubt the difference will be noticeable (we're talking about different ways to copy eight bytes, so the code would have to be called in a very tight loop for things to become noticeably slower). The issue with the original assignment is that the structs in question do not satisfy the alignment contstraints on sparc64 for reading a pointer from fid_data. Instead of playing with the struct to get the alignment right, it seemed safer to me to use a memcpy here, since in future modifications of the struct, the alignment constraints are most likely not at the front of the mind of the person doing the modification. The change has been tested on sparc64 for half a day, and things seem to be running smoothly. >Release-Note: >Audit-Trail: >Unformatted: