On Wed, 4 Feb 2004, Rogério Brito wrote:
> Hi, Alan.
>
> Here I am again. And concerning your question, here are the relevant
> lines from the output of lspci from my Desktop (which indeed has a VIA
> Southbridge):
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 02)
> 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP]
> 00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22)
> 00:04.1 IDE interface: VIA Technologies, Inc.
> VT82C586A/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE (rev 10)
> 00:04.2 USB Controller: VIA Technologies, Inc. USB (rev 10)
> 00:04.3 USB Controller: VIA Technologies, Inc. USB (rev 10)
> 00:04.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Aha!
> > Just out of curiosity, maybe you can try this patch and see what shows
> > up in the debugging log. It enlarges the size of the packets the
> > system asks for; maybe that will prevent the controller from shutting
> > down.
>
> Ok, after I read your reply, I understood what the patch made. Sorry for
> the stupid question that I sent you earlier. I had understood that my
> system was requesting packets larger than the internal hub could handle,
> not the other way round (like per your second explanation).
>
> Anyway, here follows the logs with some slight comments interspersed.
> The USB Drive worked fine with this new patch, after both cold and warm
> reboots. The system also identified the drive correctly after unplugging
> and replugging it.
The important line in your log was this one:
> hub 1-2:1.0: int length 8
This says that the internal hub sent back an 8-byte response to a status
query when it was only supposed to send back 1 byte. So, a bug in the
internal hub. This caused the VIA USB controller to stop dead in its
tracks, a bug in the VIA controller. Those two bugs together were deadly
for your system.
The patch below is all that you should need to fix this up; it's the
functional part of the previous patch. Everything else was just debugging
messages. This has the advantage over the older working patch of being
fully correct, even though it wastes about 60 bytes of memory for every
hub -- not enough to worry about.
> SCSI error: host 0 id 0 lun 0 return code = 8000002
> Sense class 7, sense error 0, extended sense 0
> sda: sda1
> SCSI error: host 0 id 0 lun 0 return code = 8000002
> Sense class 7, sense error 0, extended sense 0
> Attached scsi removable disk sda at scsi0, channel 0, id 0, lun 0
> SCSI error: host 0 id 0 lun 0 return code = 8000002
> Sense class 7, sense error 0, extended sense 0
> Unable to load NLS charset cp437
> SCSI error: host 0 id 0 lun 0 return code = 8000002
> Sense class 7, sense error 0, extended sense 0
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
> As you can see, the error messages from the SCSI layer are still there,
> but I can use the drive quite well (well, at least I think so).
It might be worthwhile to track down those errors too. Here's how to do
it. You can turn off USB debugging in the kernel configuration because
that problem has been solved. Then turn on usb-storage debugging. Your
system log will be full of interesting information from the usb-storage
driver, and some of it should indicate the reason for those errors.
Alan Stern
--- 2.6/drivers/usb/core/hub.h.orig Tue Feb 3 10:58:00 2004
+++ 2.6/drivers/usb/core/hub.h Tue Feb 3 10:58:38 2004
@@ -175,8 +175,8 @@
struct completion *urb_complete; /* wait for urb to end */
unsigned int urb_active:1;
- /* buffer for urb ... 1 bit each for hub and children, rounded up */
- char (*buffer)[(USB_MAXCHILDREN + 1 + 7) / 8];
+ /* buffer for urb ... max is 64 bytes for full speed */
+ char (*buffer)[64];
dma_addr_t buffer_dma; /* DMA address for buffer */
union {
struct usb_hub_status hub;
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
