Messages in this thread | | | Subject | Re: Undo aic7xxx changes | From | Andreas Schwab <> | Date | Fri, 09 May 2003 17:18:12 +0200 |
| |
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." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |