Re: Undo aic7xxx changes

[Andreas Schwab <schwab@suse.de>]

Willy Tarreau <willy@w.ods.org> writes:

|> On Fri, May 09, 2003 at 03:46:37PM +0200, Stephan von Krawczynski wrote:
|> > On Fri, 9 May 2003 15:27:57 +0200
|> > Willy Tarreau <willy@w.ods.org> wrote:
|> > 
|> > > On Fri, May 09, 2003 at 03:02:07PM +0200, Stephan von Krawczynski wrote:
|> > >  
|> > > > I cannot say which version of the driver it was, the only thing I can tell
|> > > > you is that the archive was called aic79xx-linux-2.4-20030410-tar.gz.
|> > > 
|> > > That's really interesting, because I got the bug since around this version
|> > > (20030417 IIRC), and it locked up only on SMP, sometimes during boot, or
|> > > during heavy disk accesses caused by "updatedb" and "make -j dep". It's
|> > > fixed in 20030502 from http://people.freebsd.org/~gibbs/linux/SRC/
|> > 
|> > I tried to merge the latest aic archive into 2.4.21-rc2, besides the "usual"
|> > signed/unsigned warnings I got this one:
|> > 
|> > aic7xxx_osm.c: In function `ahc_linux_map_seg':
|> > aic7xxx_osm.c:770: warning: integer constant is too large for "long" type
|> 
|> Good catch, but in fact, it's more this line which worries me :
|> 
|> 758:                if ((addr ^ (addr + len - 1)) & ~0xFFFFFFFF) {
|> 
|> I don't see how ~0xFFFFFFFF can be non-null on 32 bits archs

It will always be zero even on 64 bit archs, because ~0xFFFFFFFF is of
type unsigned int.  The context doesn't matter.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."