Dear Alan Stern,
Ealier this year, we exchanged some messages regarding a problem that I had
with my USB Drive, which didn't work correctly with my VIA southbridge. In
the message quoted below, you advised me to use a patch for my future
kernels and that's precisely what I'm doing right now.
With your patch, I am able to use my USB Drive to save files to the USB
drive and carry them to work, but still, I have two fears:
1 - I'm using kernel 2.6.7 right now and it seems that each time, the patch
listed below applies correctly, but with some offset and I fear that
the kernel infra-structure will change enough in recent kernels so that
I won't be able to use the patch anymore.
So, in light of this, I'd like to ask you if it is possible to include
this patch upstream and, if not, if you would like me to test more
"purified" versions of the patch for inclusion in the main kernel.
2 - I still have those SCSI layer problems listed below. Can I send you
debbuging messages of the kernels that I compile so we can try to track
what the reason of the problem is? Or should I take this with someone
else?
Thank you very much for all your help, Rogério Brito.
P.S.: Our latest exchanged message is displayed below.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
On Feb 04 2004, Alan Stern wrote:
> 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 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;
>
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
