Jens Axboe wrote: > On Wed, Mar 16 2005, [EMAIL PROTECTED] wrote: >> Hayes, Stuart wrote: >>> This patch will map the sg buffers to kernel virtual memory space in >>> the functions idescsi_input_buffers() and idescsi_output_buffers(). >>> Without this patch, idescsi passes a null pointer to >>> atapi_input_bytes() and atapi_output_bytes() when sg pages are in >>> high memory (i686 architecture). >>> >>> I'm attaching as a file, too, as the text will certainly be wrapped. >>> >>> (Sorry for the subject rename--I'm trying to use the correct format >>> for patch emails.) >>> >>> Thanks >>> Stuart >> >> And, while there's another high memory/kmap patch question on this >> list... >> >> Is there some reason nobody seems interested in this patch (except >> Jens--thanks for the help!)? I'm kind of new to sending in patches, >> and I'm not sure if I'm just not waiting long enough, or if there is >> a problem with this patch... >> >> But really, we're getting a null pointer dereference oops when using >> ATAPI tape drives (with ide-scsi) without this patch... > > Sorry, that did seem to get dropped on the floor. Actually I'm > wondering why you are seeing highmem pages there in the first place, > it would be easier/better just to limit ide-scsi to non-highmem > pages. That would remove the need to add any work arounds in the > driver.
I think we're seeing highmem pages in the sg list because that's where the user memory was when st_write() was called. The sg list is set up when st_write(), which calls setup_buffering(), which calls st_map_user_pages()... this just sets up the sg pages to point directly to the user memory. So, by the time ide-scsi comes into the picture, the sg list is already set up to point to high memory pages. Are you suggesting that ide-scsi should change the dma_mask for the device so that st_map_user_pages() won't let sg pages point to high memory? Or is there something else I'm missing? Thanks, Stuart - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
