On 11/30/2010 07:04 PM, Kai Makisara wrote: > On Tue, 30 Nov 2010, Boaz Harrosh wrote: > >> On 11/30/2010 06:23 PM, Kai Makisara wrote: >>> On Tue, 30 Nov 2010, Boaz Harrosh wrote: >>> >>>> On 11/30/2010 03:31 PM, Lukas Kolbe wrote: >>>>> On Mon, 2010-11-29 at 19:09 +0200, Kai Makisara wrote: >>>>> >>> .... >>>> It looks like something is broken/old-code in sr. Most important LLDs >>>> and block-layer scsi-ml fully support sg-chaining that effectively are >>>> able to deliver limitless (Only limited by HW) sg sizes. It looks like >>>> sr has some code that tries to allocate contiguous buffers larger than >>>> PAGE_SIZE. Why does it do that? It should not be necessary any more. >>>> >>> The relevant driver is st >> >> Sorry I meant st, yes. >> >>> and it use sg chaining when necessary. I tried >>> to explain that the effective limit in this case comes from mptsas. I >>> don't know if it is HW limit or driver limit. >>> >> >> Than I don't understand where is the failing allocation. Where in the >> code path anyone is trying to allocate something bigger then a page? >> Please explain? >> > The function enlarge_buffer() in st.c tries to allocate a driver buffer > that is large enough for one block so that the number of contiguous memory > blocks does not exceed the allowed maximum. Allocation is done using > alloc_pages() (at line 3744 in st.c in 2.6.36), usually with order > 0. > I looked at enlarge_buffer() and it looks fragile and broken. If you really need a pointer eg: STbuffer->b_data = page_address(STbuffer->reserved_pages[0]); Than way not use vmalloc() for buffers larger then PAGE_SIZE? But better yet avoid it by keeping a pages_array or sg-list and operate on an aio type operations. > Kai But I understand this is a lot of work on an old driver. Perhaps pre-allocate something big at startup. specified by user? Thanks Boaz -- 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