From owner-freebsd-current@FreeBSD.ORG Fri May 9 12:29:46 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F2DF37B401; Fri, 9 May 2003 12:29:46 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7C2643F3F; Fri, 9 May 2003 12:29:45 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.9/8.12.9) with ESMTP id h49JTiMS019054 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 9 May 2003 15:29:45 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h49JTdW06778; Fri, 9 May 2003 15:29:39 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16060.419.751589.275820@grasshopper.cs.duke.edu> Date: Fri, 9 May 2003 15:29:39 -0400 (EDT) To: Kris Kennaway In-Reply-To: <20030509163718.GA22231@rot13.obsecurity.org> References: <20030509163718.GA22231@rot13.obsecurity.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: alpha@freebsd.org cc: current@freebsd.org Subject: Re: Unaligned access fault in fxp on alpha X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Fri, 09 May 2003 19:29:47 -0000 Kris Kennaway writes: > I reported this to mux 3 days ago, but haven't heard any > acknowledgement from him of the issue. Could someone else > investigate? This is a reproducible panic. > Can you try this patch please? It causes gcc to emit slightly different code, which deals with storing to aligned 16-bit values. What's happening is that because the u_int32_t link_addr (and rbd_addr) fields preceded the "size" field, gcc was assuming that the rfa struct would be aligned and was cheating. It was using operations which only work on aligned-32 bit values on 16-bit values. Removing the u_int32_t's disabuses gcc of this assumption, therby causing safe code to be emitted. I don't understand why mux changed these fields in rev 1.31, with, so I'm not sure that I want to commit this until mux reviews it. For all I know, it breaks sparc64 or something.. Drew Index: dev/fxp/if_fxpreg.h =================================================================== RCS file: /home/ncvs/src/sys/dev/fxp/if_fxpreg.h,v retrieving revision 1.33 diff -u -r1.33 if_fxpreg.h --- dev/fxp/if_fxpreg.h 6 Apr 2003 21:35:45 -0000 1.33 +++ dev/fxp/if_fxpreg.h 9 May 2003 18:55:10 -0000 @@ -346,8 +346,8 @@ struct fxp_rfa { u_int16_t rfa_status; u_int16_t rfa_control; - u_int32_t link_addr; - u_int32_t rbd_addr; + u_int8_t link_addr[4]; + u_int8_t rbd_addr[4]; u_int16_t actual_size; u_int16_t size;