I did look at the latest code for usb-skeleton and it hadn't changed much at all and the problem looked very straight forward illegal call of a non-interrupt function in the call back so it seemed likely to be present (or understood in the latest code). On 20 October 2010 05:22, Greg KH <greg@xxxxxxxxx> wrote: > On Tue, Oct 19, 2010 at 02:12:27PM -0400, Alan Stern wrote: >> On Tue, 19 Oct 2010, Oliver Neukum wrote: >> >> > Am Dienstag, 19. Oktober 2010, 18:12:52 schrieb Alan Stern: >> > > The problem is that usb-skeleton calls usb_free_coherent() in its >> > > skel_write_bulk_callback() routine. That indirectly calls >> > > dma_pool_free(), which for some strange reason doesn't like to run >> > > in_interrupt. >> > >> > I suppose it needs to do IPIs and wait for answers. >> > >> > > usb-skeleton probably should not use a coherent buffer. There's no >> > > good reason for it. Ok I assumed that it was related to performance - but I barely grasp the performance implications - but it is good to know that it is not a dramatic level. e.g. unnecessary cache collisions or something I guess? >> > >> > Among other things it should be an example. If this is easy to get wrong, we >> > should come up with a correct solution. >> >> Examples can be arbitrarily complicated. But a complicated example >> defeats the purpose of helping people learn how to write a driver. >> >> Most drivers should not use coherent buffers. If you want to create an >> example showing how to use them, go ahead -- but I think usb-skeleton >> is not the appropriate place for it. usb-skeleton should simply use >> kmalloc. > > I agree, I'll go fix it up. > > thanks, > > greg k-h That would be great, it's got lots of "magic looking" buffer functions. kmalloc() would be *so* much clearer. I some how thought if I used a kmalloc() buffer something bad might happen but perhaps there are some special flags that tell it not to optimise it. I agree that as usb-skeleton is not tested it will be subject to bitrot so likely it may have worked in the past. Perhaps a simple example, that can be transformed in to working code for device by a simple sed script for easy testing could check this easily? The real driver could be more complex and highly optimised et cetera - but always the basic skeleton should work? Thanks for your comments. Andrew PS: Sorry for not sending this originally to the list. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
