On Wed, 8 Jun 2005, Dag Nygren wrote:
> There is also no swap available and 28 MB memory available only.
> Does that make a difference
It might, if you were to use up all the memory.
> Also forgot to mention that the thing seems to work perfectly
> with a USB 1.1 stick.
I don't think the USB version has anything to do with it. And "seems" is
the right word; although the log might not show any errors the USB 1.1
stick did not work correctly either.
In fact there are several questionable things about your log. First of
all, it appears that you plugged in the 1.1 stick before the system bootup
procedure had finished. That is, the timestamps show various bootup
activities continuing until 19:45:11, which is the same timestamp for when
the stick was detected. You should have waited longer before plugging it
in.
Next, if you read through the section between when the 1.1 stick was
plugged in and when the 2.0 stick was plugged in, you'll see that
everything occurs twice. For some reason the system thought the 1.1 stick
was disconnected shortly after it was detected. It was detected again and
the same sequence repeated.
And then the same thing happened with the 2.0 stick, except that in this
case it triggered an oops. The oops occurred somewhere in the SCSI layer,
as you can see from the EIP address:
Jun 9 19:45:27 (none) kern.warn kernel: EIP is at
__scsi_remove_target+0x65/0x120
I'm not able to determine anything more about the oops because your kernel
is too different from mine. Anyway, it killed the khubd thread and that's
what caused all the USB functions to stop working.
> =============== Why do we need paging at this point?? There is no swap on
> this embedded device... ===============
> Jun 9 19:45:26 (none) kern.alert kernel: Unable to handle kernel paging
> request at virtual address 766f6d65
You don't need paging. What the message means is that the kernel got an
invalid memory reference, treated it as a paging request, and wasn't able
to handle it because you don't have any swap.
So there are two mysteries here: Why do the sticks keep getting
disconnected and why did the oops occur? To help answer the first
question you should turn on both USB and USB mass storage verbose
debugging in the kernel configuration (CONFIG_USB_DEBUG and
CONFIG_USB_STORAGE_DEBUG) and rebuild the drivers. Maybe the dmesg log
will then contain some useful information.
To help answer the second question, you can run
objdump -d drivers/scsi/scsi_sysfs.o
and redirect the output to some file. Then edit the file and find the
portion between the lines that say
00000xxx <__scsi_remove_target>:
and
00000yyy <scsi_remove_target>:
Extract just that portion and post it so I can see what your kernel is
doing.
Alan Stern
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
