On Wed, 8 Jun 2005, Dag Nygren wrote:
> That stick was plugged in during the boot from power on.
> The application will have to be able to handle that, so I hope there
> is no problem at the kernel layer in this case.
Well, for testing purposes it might be better if you leave the stick
unplugged during boot and then plug it in later.
> > 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.
>
> This might be due to my syslogd+ klogd being the ones from busybox,
> not the "regular ones". They might both be writing the same things
> to the messages file.
No, that's not it. The log shows that the first time the stick was
assigned address 2 and the second time it was assigned address 3. Then
the 2.0 stick was assigned address 4. Then the oops occurred...
> Using the USB 1.1 stick does find files and can handle them as expected.
Okay, but the log is still a mystery.
> > is too different from mine. Anyway, it killed the khubd thread and that's
> > what caused all the USB functions to stop working.
>
> Would that freeze the "cat /proc/net/usb/devices" process too?
Yes it would. khubd had acquired a semaphore and it was killed while
still holding it.
> > Extract just that portion and post it so I can see what your kernel is
> > doing.
>
> Here we go:
It's puzzling. Apparently some list pointers have gotten messed up, but
I can't tell which ones or how. Below is a diagnostic patch to add some
additional information in the system log.
I hope this isn't something the SCSI developers already know about and
have fixed!
Alan Stern
Index: usb-2.6/drivers/scsi/scsi_sysfs.c
===================================================================
--- usb-2.6.orig/drivers/scsi/scsi_sysfs.c
+++ usb-2.6/drivers/scsi/scsi_sysfs.c
@@ -655,9 +655,15 @@ void __scsi_remove_target(struct scsi_ta
unsigned long flags;
struct scsi_device *sdev, *tmp;
+ printk(KERN_INFO "starget %p, shost %p\n", starget, shost);
+ printk(KERN_INFO "target channel %u, id %u\n", starget->channel,
+ starget->id);
spin_lock_irqsave(shost->host_lock, flags);
starget->reap_ref++;
list_for_each_entry_safe(sdev, tmp, &shost->__devices, siblings) {
+ printk(KERN_INFO "sdev %p, tmp %p\n", sdev, tmp);
+ printk(KERN_INFO "sdev channel %u, id %u\n", sdev->channel,
+ sdev->id);
if (sdev->channel != starget->channel ||
sdev->id != starget->id)
continue;
@@ -806,6 +812,9 @@ void scsi_sysfs_device_initialize(struct
list_add_tail(&sdev->same_target_siblings, &starget->devices);
list_add_tail(&sdev->siblings, &shost->__devices);
spin_unlock_irqrestore(shost->host_lock, flags);
+ printk(KERN_INFO "new sdev %p, target %p, host %p\n", sdev,
+ starget, shost);
+ printk(KERN_INFO "channel %u, id %u\n", sdev->channel, sdev->id);
}
int scsi_is_sdev_device(const struct device *dev)
-------------------------------------------------------
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
