On Thu, 2007-11-15 at 11:38 -0500, Tony Battersby wrote: > James Bottomley wrote: > > On Thu, 2007-11-15 at 10:06 -0500, Tony Battersby wrote: > > > >> This patch increases the sg_tablesize for sym53c8xx from 96 to 128, > >> which enables commands to transfer larger amounts of data (e.g. 512 KB > >> instead of 384 KB, assuming 4 KB non-adjacent pages). > >> > >> In the current design of sym53c8xx, SYM_CONF_MAX_SG must be set low > >> enough so that (sym_fw1.a_size <= PAGE_SIZE) && (sym_fw2.a_size <= > >> PAGE_SIZE). With SYM_CONF_MAX_SG == 128, sym_fw1.a_size == 3940 and > >> sym_fw2.a_size == 3576 (plus or minus a few bytes depending on other > >> configuration options). The a_size values increase by 16 for every > >> additional sg vector, so SYM_CONF_MAX_SG cannot be set much higher than > >> 128 without making more intrusive changes. > >> > > > > This has been suggested before. I thought the problem was there were > > some cards of the 875 ilk that choke on a sg table larger than 96? If I > > recall the conversation correctly, the claim was made, but no-one > > managed to turn up the errata that showed it. > > > > James > > > > > > > I will try to get ahold of some 875's to test. Thanks ... even if there's a problem, we can take your hard coded update and dynamically (probably via PCI ID) lower the host->sg_tablesize for the problem cards at probe time, so they'll never see the longer list. James - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
