This should handle it:
hwif->seg_boundary_mask = 0xffffffff;
> Also BUG_ON() in udma_new_table is bogus. Change code:
> - u32 cur_len = sg_dma_len(sg) & 0xffff;
> + u32 cur_len = sg_dma_len(sg);
> /* Delete this ... */
> BUG_ON(cur_len > ch->max_segment_size);
> *table++ = cpu_to_le32(cur_addr);
> - *table++ = cpu_to_le32(cur_len);
> + *table++ = cpu_to_le32(cur_len & 0xffff);
> Without first change BUG_ON will not trigger on any transfer: values
> up to 0xFE00 are legal, and values over 0x10000 get cut down to
> Second change is needed only if we have some driver setting
> max_segment_size to value > 0xffff: currently we do not have such driver,
> default is 0xfe00, and value set by cs5530 is 0xfe00 too.
Well trm390 *does* set ->seg_boundary_mask.
>>Hmm... It is very well possible that the Toshiba doesn't like the
>>fact that the intel chipsets cheat and do something like UDMA88 instead
>>of UDMA100. Could you verify this by checking whatever forcing them to
>>UDMA66 helps please? Vojtech?
> It happens with UDMA0 too (and I tried slowest possible timming at
> i845, and it still happens).
I'm more and more amanzed, why my system works at all...
> P.S.: Marcin, are you Marcin or Martin? MAINTAINERS says Martin,
> but your replies state Marcin...
It doesn't really matter. Marcin is just the polish spelling of the name
Martin. So choose whatever you want please.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/