From owner-freebsd-current@FreeBSD.ORG  Sat May 10 16:36:43 2003
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
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 EDA1837B401; Sat, 10 May 2003 16:36:43 -0700 (PDT)
Received: from elvis.mu.org (elvis.mu.org [192.203.228.196])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 6D99543FDF; Sat, 10 May 2003 16:36:43 -0700 (PDT)
	(envelope-from mux@freebsd.org)
Received: by elvis.mu.org (Postfix, from userid 1920)
	id 599432ED414; Sat, 10 May 2003 16:36:43 -0700 (PDT)
Date: Sun, 11 May 2003 01:36:43 +0200
From: Maxime Henrion <mux@freebsd.org>
To: Andrew Gallatin <gallatin@cs.duke.edu>
Message-ID: <20030510233643.GX21011@elvis.mu.org>
References: <20030509163718.GA22231@rot13.obsecurity.org>
	<16060.419.751589.275820@grasshopper.cs.duke.edu>
	<20030510221612.GT21011@elvis.mu.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030510221612.GT21011@elvis.mu.org>
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-current@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 10 May 2003 23:36:44 -0000

Maxime Henrion wrote:
> 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.

Kris just reported to me that the __packed thing fixes things.  I'll
commit it as soon as I get re@ approval.

Cheers,
Maxime