From owner-freebsd-alpha@FreeBSD.ORG  Sat May 10 15:16:13 2003
Return-Path: <owner-freebsd-alpha@FreeBSD.ORG>
Delivered-To: freebsd-alpha@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id B793637B401; Sat, 10 May 2003 15:16:13 -0700 (PDT)
Received: from elvis.mu.org (elvis.mu.org [192.203.228.196])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 39BF543FBD; Sat, 10 May 2003 15:16:13 -0700 (PDT)
	(envelope-from mux@freebsd.org)
Received: by elvis.mu.org (Postfix, from userid 1920)
	id 090892ED3F8; Sat, 10 May 2003 15:16:13 -0700 (PDT)
Date: Sun, 11 May 2003 00:16:12 +0200
From: Maxime Henrion <mux@freebsd.org>
To: Andrew Gallatin <gallatin@cs.duke.edu>
Message-ID: <20030510221612.GT21011@elvis.mu.org>
References: <20030509163718.GA22231@rot13.obsecurity.org>
	<16060.419.751589.275820@grasshopper.cs.duke.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <16060.419.751589.275820@grasshopper.cs.duke.edu>
User-Agent: Mutt/1.4.1i
cc: alpha@freebsd.org
cc: current@freebsd.org
cc: Kris Kennaway <kris@obsecurity.org>
Subject: Re: Unaligned access fault in fxp on alpha
X-BeenThere: freebsd-alpha@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Porting FreeBSD to the Alpha <freebsd-alpha.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-alpha>,
	<mailto:freebsd-alpha-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-alpha>
List-Post: <mailto:freebsd-alpha@freebsd.org>
List-Help: <mailto:freebsd-alpha-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-alpha>,
	<mailto:freebsd-alpha-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 10 May 2003 22:16:14 -0000

Andrew Gallatin wrote:
> 
> 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..

Thanks Andrew, I should have taken care of this since some time but was
veyr busy these days.

I removed them because they were just looking bogus.  I wanted to ask
people to test a patch adding a __packed in the struct definition to see
if it fixed things.  If it works with a __packed keyword, I'd like
it better than going back to having an array of four u_int8_t.
Otherwise I'll put the u_int8_t back.

Cheers,
Maxime