kernel BUG at scsi_merge.c:83

Quoted 8 lines · Jens Axboe

Quoted 6 lines · Peter Osterlund

Hi!

While doing some stress testing on the 2.5.2-pre5 kernel, I am hitting a kernel BUG at scsi_merge.c:83, followed by a kernel panic. The problem is that scsi_alloc_sgtable fails because the request contains too many physical segments. I think this patch is the correct fix:

Quoted 2 lines

Correct, ll_rw_blk default is ok now. I missed this when killing scsi_malloc/scsi_dma, thanks.

It turns out this is still not enough to fix the problem for me, because ll_new_hw_segment is still allowing nr_phys_segments to become too large. Is the following patch the correct way to deal with this problem, or is that case supposed to be prevented by some other means? At least, this patch prevents the kernel panic during my stress test.

Quoted 10 lines · Peter Osterlund

Quoted 8 lines · Jens Axboe

Quoted 6 lines · Peter Osterlund

Hi!

While doing some stress testing on the 2.5.2-pre5 kernel, I am hitting a kernel BUG at scsi_merge.c:83, followed by a kernel panic. The problem is that scsi_alloc_sgtable fails because the request contains too many physical segments. I think this patch is the correct fix:

Quoted 8 lines

Quoted 2 lines

Correct, ll_rw_blk default is ok now. I missed this when killing scsi_malloc/scsi_dma, thanks.

It turns out this is still not enough to fix the problem for me, because ll_new_hw_segment is still allowing nr_phys_segments to become too large. Is the following patch the correct way to deal with this problem, or is that case supposed to be prevented by some other means? At least, this patch prevents the kernel panic during my stress test.

<snipped patches/>

Peter,
I was able to get a repeatable oops at that line copying files from /boot onto a "fake" scsi_debug disk with "pre5". The first largish file it attempted to copy caused the oops (which I sent to Jens).

Anyway, I just applied your 2 patches (to scsi.c and ll_rw_blk.c) and the oops is no more.