http://bugzilla.kernel.org/show_bug.cgi?id=15007 --- Comment #1 from Anonymous Emailer <anonymous@xxxxxxxxxxxxxxxxxxxx> 2010-01-14 08:25:25 --- Reply-To: fujita.tomonori@xxxxxxxxxxxxx On Fri, 8 Jan 2010 11:07:49 GMT bugzilla-daemon@xxxxxxxxxxxxxxxxxxx wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=15007 > > Summary: SCSI host adapter's scatter-gather list size Issue > Product: IO/Storage > Version: 2.5 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: SCSI > AssignedTo: linux-scsi@xxxxxxxxxxxxxxx > ReportedBy: nick.cheng@xxxxxxxxxxxx > CC: akpm@xxxxxxxxxxxxxxxxxxxx > Regression: No > > > I found if I set scatter-gather table size as 1024 Areca's RAID controller, You mean that setting sg_tablesize in scsi_host_template to 1024? > ARC1680, and then execute "mkfs.ext3 /dev/sdX" on a sas/sata volume which is > formated as NTFS, it will kill the controller and let it restart. > This issue pops up easily on Intel server board with multi-processors and so > far can not be reproduced on a volume with a original Linux filesystem such as, > ext3. Can your controller hardware and firmware handle 1024 scatter gather entries? > I also found the issue is on the write command with 128 sg entries, each with > 4K byte in length. As the command comes from the upper layer, it lacks data in > the 128th sg entry. The device driver really get 128 entries? How can you issue a write command with 128 sg entries? Even if your user-space application issues a write command with 128 sg entries, the device driver could get less sg entries. If the device driver gets a command including 128 sg entries (cmd->sdb.table.nents is set to 128) and 128th sg entry doesn't have data, then probably we have a bug in scatter gather or block layer code. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. -- 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
