Messages in this thread | | | Date | Fri, 9 May 2003 16:56:21 +0200 | From | Willy Tarreau <> | Subject | Re: Undo aic7xxx changes |
| |
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, because addr is a bus_addr_t which is in turn dma_addr_t which itself is u32. So unless I don't find the trick this would mean that this code should never be executed. Perhaps ~0xFFFFFFFFULL would be more appropriate, or even >0xFFFFFFFF, since this can be detected with u32 using the carry left by the addition.
Regards, Willy
- 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/
| |