> >>Trace; c013f258 <try_to_free_buffers+88/f0>
> >>Trace; c0133a67 <shrink_cache+217/300>
> >>Trace; c0133c95 <shrink_caches+55/90>
> >>Trace; c0133d03 <try_to_free_pages_zone+33/60>
> >>Trace; c0134c10 <balance_classzone+60/200>
> >>Trace; c0134e89 <__alloc_pages+d9/170>
> >>Trace; c012fcde <generic_file_write+32e/6d0>
> >>Trace; d080ec81 <[jbd].text.lock.journal+5ea5/14284>
> >>Trace; c013b314 <sys_write+84/100>
> >>Trace; c0108f03 <system_call+33/40>
> >
> > If you suspect the problem really lies in usb-storage, you could try
> > enabling the debug option for usb-storage and recompiling it. Then see
> > what your kernel log has to say.
> >
> > Alan Stern
>
> Well here is a dmesg extract with usb-storage-debug turned on and the
> oops and the output of ksymoops. There doesn't appear to be much wrong
> with usb-storage? I am no expert...
It seems like queuecommand of usb-storage is handed a NULL-pointer.
Could you add debugging output like:
struct us_data *us = (struct us_data *)srb->host->hostdata[0];
if (!us)
printk("us NULL.\n");
US_DEBUGP("queuecommand() called\n");
srb->host_scribble = (unsigned char *)us;
if (!srb)
printk("srb NULL.\n");
/* get exclusive access to the structures we want */
down(&(us->queue_exclusion));
Regards
Oliver
-------------------------------------------------------
This SF.NET email is sponsored by: A Thawte Code Signing Certificate
is essential in establishing user confidence by providing assurance of
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
