http://bugzilla.kernel.org/show_bug.cgi?id=12207 ------- Comment #15 from anonymous@xxxxxxxxxxxxxxxxxxxx 2008-12-23 08:42 ------- Reply-To: James.Bottomley@xxxxxxxxxxxxxxxxxxxxx On Tue, 2008-12-23 at 18:30 +0200, Kai Makisara wrote: > On Tue, 23 Dec 2008, bugme-daemon@xxxxxxxxxxxxxxxxxxx wrote: > > > http://bugzilla.kernel.org/show_bug.cgi?id=12207 > > > > > > > > > > > > ------- Comment #13 from alan@xxxxxxxxxxxxxxxxxxx 2008-12-23 08:18 ------- > > What may have happened is something else changed to trigger the enforcement of > > that limit on not block paths ? > > > Something like this ;-) From 2.6.16 st.c has used scsi_execute_async() > that sends the request to the block layer. That's probably it! Realistically, though, allowing st to override the block limits was wrong. Most drivers (except USB) don't set these arbitrarily, they usually represent fundamental hardware limits. If you force down a transaction that's larger than they declared themselves capable of, they'll do strange things like wrap descriptors or truncate the transaction, which will cause silent data corruption. Hopefully we can figure out how to get USB working. James -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. -- 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
