Messages in this thread | | | Date | Wed, 19 Nov 2008 16:00:10 +0100 | From | Jens Axboe <> | Subject | Re: ISP1760 driver crashes |
| |
On Wed, Nov 19 2008, Alan Stern wrote: > On Wed, 19 Nov 2008, Sebastian Andrzej Siewior wrote: > > > Hommel, Thomas (GE EntSol, Intelligent Platforms) wrote: > > > > > I indeed have HIGHMEM enabled in my configuration. > > > I recompiled the kernel without HIGHMEM and it works. I don't think that > > > this a satisfying solution for a board with up to 2GB of RAM and > > > considerable amount of VMALLOC space, but at least this works. > > > If you have any more ideas how to circumvent this, please let me know. > > Sure, this is not a sollution but atleast now I know what happens: > > - The kernel allocates memory for transfer > > - the memory is highmem and not in kernel so the buffer is NULL > > - we don't have a dma-mask and therefore the dma address is 0 > > - boom > > > > The sollution would be probably to prevent the usb-storage core to > > allocate memory from HIGHMEM. > > usb-storage doesn't allocate the memory. The memory is allocated by > the block layer or the filesystem. > > > Now I don't if there is a flag for something > > like that and I am not using that. On the other hand this may be broken > > for a long time and you are the first one which has that much memory with > > no DMA-capable USB controller. > > Jens, is there any way to tell the kernel that a device uses PIO and > therefore its buffers shouldn't be allocated in high memory? For > example, shouldn't a NULL dma_mask do this?
Sure, just use blk_queue_bounce_limit(q, BLK_BOUNCE_HIGH), then you are certain that you will always have a virtual mapping for the IO you receive.
Or you can use the bio kmap/kunmap helpers to get such a mapping temporarily if you wish. But if your pio condition is permanent, you may as well just use bouncing.
-- Jens Axboe
| |