On Mon, Apr 09, 2012 at 05:28:41PM +0200, Daniel Mack wrote:
> On 09.04.2012 14:30, Hans J. Koch wrote:
> > On Sun, Apr 08, 2012 at 04:12:23PM +0200, Christoph Fritz wrote:
> >>> How about works as mass storage?
> >>
> >> After some read while write testing I get the trace below.
> >
> > Is this reproducible? If you run your test several times, does it
> > always crash at the same address?
> >
> > If no, follow your broken-hardware theory. Another possibility could
> > be an error in DMA handling, which can also lead to more or less
> > random memory corruption.
>
> FWIW, I second this opinion. Especially as the trace seems totally
> unrelated to the USB function in question. A memory corruption can be
> tricky to find, but it would well explain the effects you see.
After applying this patch [1] g_mass_storage seems to be stable, but the
"ping-test" for g_ether still fails.
[1] NFS: check for req==NULL in nfs_try_to_update_request cleanup
http://git.linux-nfs.org/?p=trondmy/nfs-2.6.git;a=commit;h=f30fb85b7d4bf18f6b89ea64dca632ecadf9279a
Trond, I can't find this patch neither in linux-next nor rc2, is
there something wrong with it?
> A first step could be to disable DMA for the USB controller and see if
> that helps.
Would you still recommend testing without DMA?
Thanks,
-- Christoph
--
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
