On Tue, Oct 24, 2006 at 02:43:22PM -0700, Phil Dibowitz wrote:
> Alan Stern wrote:
> > There's a comment about this in the source code, asking what should be
> > done if the INQUIRY response is too short (as it is here). Maybe the best
> > approach would be always to assume the first 36 bytes are
Alan Stern wrote:
...
> @@ -575,6 +575,19 @@ static int scsi_probe_lun(struct scsi_de
...
> + * On the whole, the best approach seems to be to assume the first
> + * 36 bytes are valid no matter what the device says. That's
> + * better than copying < 36 bytes to the inquiry-result
Alan Stern wrote:
> There's a comment about this in the source code, asking what should be
> done if the INQUIRY response is too short (as it is here). Maybe the best
> approach would be always to assume the first 36 bytes are valid, even when
> the device says they aren't. It ought to solve your
> The patch is below. This replaces the patch I sent earlier.
Thank you, it works just fine!
scsi scan: INQUIRY result too short (5), using 36
scsi 1:0:0:0: Direct-Access GENERIC USB DISK DEVICE 1.00 PQ: 0 ANSI: 0 CCS
--
Meelis Roos ([EMAIL PROTECTED])
--
On Tue, 24 Oct 2006, Meelis Roos wrote:
> > Here's the best thing to do to find out what is really happening: Use the
> > usbmon facility to see exactly what data bytes are being sent to the
> > computer (instructions in Documentation/usb/usbmon.txt). This will tell
> > us for certain whether th
> Here's the best thing to do to find out what is really happening: Use the
> usbmon facility to see exactly what data bytes are being sent to the
> computer (instructions in Documentation/usb/usbmon.txt). This will tell
> us for certain whether those garbage bytes are left-over junk in RAM or
>
Hello,
This patch adds support for JTEC FA8101 USB to Ethernet device.
Seems that it was dropped in 2002, for some reason:
http://sourceforge.net/mailarchive/message.php?msg_id=236
There are many users of this device here in Brazil. The patch was
tested this week on a notebook running kernel
On Tuesday 24 October 2006 2:37 am, Toralf Förster wrote:
> drivers/built-in.o: In function `usbnet_set_settings':
> : undefined reference to `mii_ethtool_sset'
> drivers/built-in.o: In function `usbnet_get_settings':
> : undefined reference to `mii_ethtool_gset'
> drivers/built-in.o: In function
On Friday 20 October 2006 12:10 am, Armen Baloyan wrote:
> Hi all,
>
> During my work on ISOC EPs support implementation for USB OTG driver I've
> met some difficulties - as is written in usb 2.0 spec:
>
> 5.12.4.1.2 Synchronous
>
> Synchronous endpoints can have their clock system (their n
This patch (as809) moves the declaration of the hub driver's private
data structure from hub.h into the hub.c source file. Lots of other
files import hub.h; they have no need to know about the details of the
hub driver's private data.
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
---
Index: usb
This patch (as808) fixes a minor race in ohci-hcd's root-hub code. If
we have to turn off the Root-Hub-Status-Change bit in the Interrupt
Status register, better to do it _before_ looking for status changes
rather than _after_.
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
---
Index: usb-2.6/dr
When a suspended OHCI controller sees a port's status change, it sets
both the Root-Hub-Status-Change and the Resume-Detect bits in the
Interrupt Status register. Processing both these bits, the driver
tries to resume the root hub twice!
This patch (as807) fixes the bug by ignoring RD if RHSC is
This patch (as806) fixes a compiler warning when ohci-hcd is built
with CONFIG_PM turned off.
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
---
Index: usb-2.6/drivers/usb/host/ohci-hub.c
===
--- usb-2.6.orig/drivers/usb/host/ohci-hu
On Tue, 24 Oct 2006, Helge Hafting wrote:
> > (By the way, what do you mean by 4 KB chunks or 1 MB chunks? Does this
> > refer to the bs= option for dd? That has almost nothing to do with the
> > size of the transfers actually sent to the device.)
> >
> Yes, it refers to the bs option. I kn
On Tue, 24 Oct 2006, Helge Hafting wrote:
> I just tested this. 2.6.18 does not crash. I still get tons of errors,
> and no data. Copying using 1MB chunks or 4kB chunks
> don't matter, it doesn't work. So card, reader or driver must be faulty.
> The card works in a windows machine though.
>
> 2.
On Tue, 24 Oct 2006, Alex Litvin wrote:
> I've succeeded with usb_bulk_write() but can't utilize
> usb_bulk_read(). It returns an error [i]open error 11 Resource
> temporarily unavailable[/i].
>
> Here is the output of
> [i]cat /prog/bus/usb/devices[/i]:
> [code]T: Bus=01 Lev=01 Prnt=01 Port=00
Christopher "Monty" Montgomery wrote:
On 10/20/06, Alan Stern <[EMAIL PROTECTED]> wrote:
At this point it's beyond me. Monty will have to take it from here.
I will look more closely at what might have changed there. Despite
the code refactoring (and a hand-resolved patch collision at that
po
I've succeeded with usb_bulk_write() but can't utilize
usb_bulk_read(). It returns an error [i]open error 11 Resource
temporarily unavailable[/i].
Here is the output of
[i]cat /prog/bus/usb/devices[/i]:
[code]T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=00(>i
18 matches
Mail list logo
