Hi
I got a ehci_hcd pcmcia host controller. Everytime I unplug it with the
module loaded the kernel oopses. If I rmmod the module before I got no
problem. I am using 2.4.21 and 2.4.22 here. I got a
usb-mass-storage-device attached to the controller here. The problem is
100% reproduceable here, it
On Wed, Sep 10, Alan Stern wrote:
> On Wed, 10 Sep 2003, Olaf Hering wrote:
>
> > On Wed, Sep 10, Alan Stern wrote:
> >
> > > Something's very wrong with your system, but whether it's the device, the
> > > cable, or something else is hard to say. Do other USB storage devices
> > > work with
On Wed, 10 Sep 2003, Olaf Hering wrote:
> On Wed, Sep 10, Alan Stern wrote:
>
> > Something's very wrong with your system, but whether it's the device, the
> > cable, or something else is hard to say. Do other USB storage devices
> > work with the same cable and computer?
>
> It should. This
On Wed, Sep 10, 2003 at 12:50:04PM +0200, Duncan Sands wrote:
> speedtch.c |7 +--
> 1 files changed, 1 insertion(+), 6 deletions(-)
Rejected the 2.4 version of this patch for the same reasons...
greg k-h
---
This sf.net email is spon
On Wed, Sep 10, 2003 at 12:52:45PM +0200, Duncan Sands wrote:
> speedtch.c |7 +--
> 1 files changed, 1 insertion(+), 6 deletions(-)
>
>
> diff -Nru a/drivers/usb/misc/speedtch.c b/drivers/usb/misc/speedtch.c
> --- a/drivers/usb/misc/speedtch.c Wed Sep 10 13:25:09 2003
> +++ b/driver
David Brownell wrote:
Julian Back wrote:
Hi,
I've been implementing a UDC driver for the on-board UDC of various
SuperH devices. I have now got the device to enumerate using Gadget
Zero but this has exposed some problems with the gadget driver
framework when used with the SuperH UDC.
I alwa
On Wed, Sep 10, 2003 at 07:03:15PM +0400, Sergey Vlasov wrote:
> On Fri, 5 Sep 2003 17:16:35 -0700
> Greg KH <[EMAIL PROTECTED]> wrote:
>
> > ChangeSet 1.1119.3.8, 2003/09/05 15:47:25-07:00, [EMAIL PROTECTED]
> >
> > [PATCH] USB: fix copy_to_user call in mdc800 driver
> >
> >
> > drivers/usb/m
This last part just adds kbuild support for the three drivers
sent in the earlier patches. (There's no "mid-layer".)
- Dave
--- a/Makefile Wed Sep 10 13:58:45 2003
+++ b/Makefile Wed Sep 10 13:58:45 2003
@@ -181,6 +181,7 @@
DRIVERS-$(CONFIG_HAMRADIO) += drivers/net/hamradio/hamradio.o
DRIVERS
Howdy,
I have an interesting situation with 2 different TEAC FD-05PUB-x59
floppy drives. The x59 designation is on the external device label,
the two samples in my lab are -159 and -259.
Both show the same descriptors, and both indicate they are C/B/I
devices according to lsusb.
How
"Gadget Zero" is useful for testing the usb stack in a given
device, by giving control and bulk/interrupt transfers
a good workout. If "g_zero" passes stress tests, then the
driver for the underlying hardware is probably in good
enough shape to handle more challenging tasks.
Oh -- this also includ
This gadget driver provides Ethernet-style networking over USB.
When used with more functional hardware (such as net2280), it
implements the CDC Ethernet class, which is widely supported
by non-Microsoft operating systems. (And since some cable
modems talk CDC Ethernet, it can also talk to Window
This is the two header files used in the API.
Note that on 2.4 drivers can only #include one of
and . On 2.6
the APIs can be used together.
- Dave
--- /dev/null Wed Dec 31 16:00:00 1969
+++ b/include/linux/usb_ch9.h Wed Sep 10 13:58:45 2003
@@ -0,0 +1,315 @@
+/*
+ * This file holds USB cons
Hi,
I'm pleased to see the level of interest in the "gadget" API
that's coming from developers using Linux 2.4 systems. So
here's a version to merge into the main tree, which should
make it simpler to use and patch.
I'm submitting it as several smaller patches:
1 - and , API decls.
2 - usb/g
Our virus detector has just been triggered by a message you sent:-
To: [EMAIL PROTECTED]
Subject: Re: Thank you!
Date: Wed Sep 10 16:35:12 2003
One or more of the attachments (application.pif) are on
the list of unacceptable attachments for this site and will not have
been delivered.
Consid
On Wed, 2003-09-10 22:56:46 +0800, Michael Frank <[EMAIL PROTECTED]>
wrote in message <[EMAIL PROTECTED]>:
> On Saturday 06 September 2003 18:55, Jan-Benedict Glaw wrote:
> > I've never seen that. My impression is that this (only?) happens if
> > there are some bytes received from serial, but not r
On Wed, Sep 10, Alan Stern wrote:
> And finally the device seems to have timed out, maybe crashed. Perhaps it
> uses some non-standard variation of the protocol?
possible, google wasnt that helpful, '0x784 0x4300' returned one guy
with a similar problem and a list which lists it as unsupported
On Wed, Sep 10, 2003 at 12:32:34PM -0700, David Brownell wrote:
> I just noticed that Linus' tree is using the wrong CONFIG_* symbols
> for kicking in the PXA 2xx support (except for "gadgetfs"). It
> should use USB_PXA2XX not USB_PXA250, since it handles PXA 255,
> PXA 210, PXA 263, and others.
>
[ once more, with patch! ]
I just noticed that Linus' tree is using the wrong CONFIG_* symbols
for kicking in the PXA 2xx support (except for "gadgetfs"). It
should use USB_PXA2XX not USB_PXA250, since it handles PXA 255,
PXA 210, PXA 263, and others.
Please merge to Linus' tree. Russell, if you
On Wed, 10 Sep 2003, Olaf Hering wrote:
> Here is the log from an intel box.
>
> I heard it doesnt even work under Windows, sometimes it locks up the
> box. Thats not very promising
No, it isn't. :-(
> usb-storage: GetMaxLUN command result is 0, data is 0
That looks better.
> usb-storage
I just noticed that Linus' tree is using the wrong CONFIG_* symbols
for kicking in the PXA 2xx support (except for "gadgetfs"). It
should use USB_PXA2XX not USB_PXA250, since it handles PXA 255,
PXA 210, PXA 263, and others.
Please merge to Linus' tree. Russell, if you include the PXA
UDC code in
On Wed, Sep 10, Alan Stern wrote:
> Something's very wrong with your system, but whether it's the device, the
> cable, or something else is hard to say. Do other USB storage devices
> work with the same cable and computer?
It should. This is bigendian, just in case it matters. I will try it o
Duncan Sands wrote:
Hi all, in 2.6 a flag is set on device disconnect that causes any
future urb submissions to fail. Then all pending urbs are "nuked".
This sounds great (especially if you want to "fire and forget" your
urbs), but does it actually work? For example, uhci-hcd does not
seem to imp
On Wed, 10 Sep 2003, Duncan Sands wrote:
> Hi all, in 2.6 a flag is set on device disconnect that causes any
> future urb submissions to fail. Then all pending urbs are "nuked".
> This sounds great (especially if you want to "fire and forget" your
> urbs), but does it actually work? For example,
On Wed, 10 Sep 2003, Olaf Hering wrote:
> hub.c: new USB device 11:08.0-1, assigned address 3
> usb.c: USB device 3 (vend/prod 0x784/0x4300) is not claimed by any active driver.
> Initializing USB Mass Storage driver...
> usb.c: registered new driver usb-storage
> usb-storage: act_altsettting is 0
On Wed, 10 Sep 2003, Duncan Sands wrote:
> > The dma_handle actually isn't needed at all, believe it or not.
> > The value is needed only at the time the TD is being linked into the
> > schedule, which can be done as it is created. After that, the dma_handle
> > value is available (if needed)
On Saturday 06 September 2003 18:55, Jan-Benedict Glaw wrote:
> On Sat, 2003-09-06 15:55:46 +0800, Michael Frank <[EMAIL PROTECTED]>
> wrote in message <[EMAIL PROTECTED]>:
> > On Saturday 06 September 2003 15:38, Jan-Benedict Glaw wrote:
> > > On Fri, 2003-09-05 16:08:52 -0700, Greg KH <[EMAIL PRO
Julian Back wrote:
Hi,
I've been implementing a UDC driver for the on-board UDC of various
SuperH devices. I have now got the device to enumerate using Gadget
Zero but this has exposed some problems with the gadget driver framework
when used with the SuperH UDC.
I always like to hear about mor
On Wed, 10 Sep 2003, Tomita, Haruo wrote:
> Using ioctl (fd, USBDEVFS_RESET, 0), I tested reset.
> usb-storage of USB2.0 was successful.
> When FDD was used in the case of USB1.1,
> mount became impossible after reset.
What do you mean? What does the log show?
Alan Stern
--
Hello,
kernel 2.6.0-test4, OHCI, MEDIA GX using pwc without pwcx, Java Media
Framework, DEBUGING ON within the driver:
PCVC680K "Vesta Pro"
Sep 10 08:30:37 CCSpro kernel: pwc << pwc_isoc_init()
Sep 10 08:30:37 CCSpro kernel: pwc VIDIOCMCAPTURE done.
Sep 10 08:30:37 CCSpro kernel: pwc VIDIOCMCAPT
On Fri, 5 Sep 2003 17:16:35 -0700
Greg KH <[EMAIL PROTECTED]> wrote:
> ChangeSet 1.1119.3.8, 2003/09/05 15:47:25-07:00, [EMAIL PROTECTED]
>
> [PATCH] USB: fix copy_to_user call in mdc800 driver
>
>
> drivers/usb/mdc800.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletion(-)
>
>
> dif
On Fri, 5 Sep 2003 17:16:36 -0700
Greg KH <[EMAIL PROTECTED]> wrote:
> ChangeSet 1.1119.3.10, 2003/09/05 15:47:40-07:00, [EMAIL PROTECTED]
>
> [PATCH] USB: fix copy_to_user calls in vicam driver.
>
>
> drivers/usb/vicam.c | 17 ++---
> 1 files changed, 10 insertions(+), 7 deletio
speedtch.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff -Nru a/drivers/usb/misc/speedtch.c b/drivers/usb/misc/speedtch.c
--- a/drivers/usb/misc/speedtch.c Wed Sep 10 13:25:33 2003
+++ b/drivers/usb/misc/speedtch.c Wed Sep 10 13:25:33 2003
@@ -111,10 +111,10
speedtch.c |4 +++-
1 files changed, 3 insertions(+), 1 deletion(-)
diff -Nru a/drivers/usb/misc/speedtch.c b/drivers/usb/misc/speedtch.c
--- a/drivers/usb/misc/speedtch.c Wed Sep 10 13:25:25 2003
+++ b/drivers/usb/misc/speedtch.c Wed Sep 10 13:25:25 2003
@@ -23,6 +23,8 @@
/*
CREDITS |2 +-
MAINTAINERS |2 +-
drivers/usb/misc/speedtch.c |4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff -Nru a/CREDITS b/CREDITS
--- a/CREDITS Wed Sep 10 13:25:17 2003
+++ b/CREDITS Wed Sep 10 13:25:17 2003
@@ -2795,7 +2795
speedtch.c |7 +--
1 files changed, 1 insertion(+), 6 deletions(-)
diff -Nru a/drivers/usb/misc/speedtch.c b/drivers/usb/misc/speedtch.c
--- a/drivers/usb/misc/speedtch.c Wed Sep 10 13:25:09 2003
+++ b/drivers/usb/misc/speedtch.c Wed Sep 10 13:25:09 2003
@@ -1293,14 +1293,9 @
speedtch.c |4 +++-
1 files changed, 3 insertions(+), 1 deletion(-)
diff -Nru a/drivers/usb/speedtch.c b/drivers/usb/speedtch.c
--- a/drivers/usb/speedtch.cWed Sep 10 13:37:53 2003
+++ b/drivers/usb/speedtch.cWed Sep 10 13:37:53 2003
@@ -23,6 +23,8 @@
/*
* Written by Johan Verrep
CREDITS|2 +-
MAINTAINERS|2 +-
drivers/usb/speedtch.c |4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff -Nru a/CREDITS b/CREDITS
--- a/CREDITS Wed Sep 10 13:37:46 2003
+++ b/CREDITS Wed Sep 10 13:37:46 2003
@@ -2719,7 +2719,7 @@
D: Dosem
speedtch.c |7 +--
1 files changed, 1 insertion(+), 6 deletions(-)
diff -Nru a/drivers/usb/speedtch.c b/drivers/usb/speedtch.c
--- a/drivers/usb/speedtch.cWed Sep 10 13:37:39 2003
+++ b/drivers/usb/speedtch.cWed Sep 10 13:37:39 2003
@@ -1289,14 +1289,9 @@
static int __init uds
Am Mittwoch, 10. September 2003 05:27 schrieb Greg KH:
> On Wed, Sep 10, 2003 at 12:38:18PM +1000, Mark McDougall wrote:
> > Hi All,
> >
> > I'm having problems unlinking in my device driver.
> >
> > My driver submits a number of IN urbs on device open (up to 16) and
> > simply appends data in a
Your message was not delivered to the following recipients:
[EMAIL PROTECTED]: 550 5.1.1 <[EMAIL PROTECTED]>... User Unknown
The Walt Disney Company and its affiliates are in the process of an e-Mail system
upgrade. The person you intended to send this message to may have had
Hi,
I've been implementing a UDC driver for the on-board UDC of various SuperH
devices. I have now got the device to enumerate using Gadget Zero but this has
exposed some problems with the gadget driver framework when used with the SuperH
UDC.
The SuperH UDC is less flexible than the other su
On Tue, Sep 09, Alan Stern wrote:
> On Mon, 8 Sep 2003, Olaf Hering wrote:
>
> > Hi,
> >
> > any idea how to get this going? First time I got the attached oops.
> >
> > "Vivitar, Inc."
> > traveller DC 4300
>
> > usb.c: USB device 5 (vend/prod 0x784/0x4300) is not claimed by any active driver
Hi all, in 2.6 a flag is set on device disconnect that causes any
future urb submissions to fail. Then all pending urbs are "nuked".
This sounds great (especially if you want to "fire and forget" your
urbs), but does it actually work? For example, uhci-hcd does not
seem to implement the disable m
Hi!
> > > The latter two functions do not exist in -test5. It would helpful if you
> > > tried to reproduce with a virgin -test5. It would be courteous to state
> > > what patches you applied on top of the virgin -test5 kernel.
> >
> > Lot of them, but only "revert to -test3 swsusp" should be
On Tuesday 09 September 2003 16:38, Alan Stern wrote:
> On Tue, 9 Sep 2003, Baldrick wrote:
> > Hi Alan, since you didn't squelch those ideas how about this even wilder
> > one: it seems to me that for IN transfers (I am thinking bulk) it is
> > possible to allocate no TDs whatsoever! The TDs are
> How about a different radical approach. Remembering that there's
> already a queue of URBs in the HCD glue, it's clear that they don't
> all need to have TDs immediately allocated ... when an endpoint queue
> is "empty enough", the lower level HCD code could check for urbs
> that are queued to t
Hi Alan,
Thank you for your help.
Alan> This time the bus_reset() routine worked, which is an
Alan> improvement over
Alan> what you were seeing before. But the device still didn't respond:
Haruo> If a device becomes an error, it seems that reset is not effective.
Haruo> Using ioctl (fd, USBD
47 matches
Mail list logo
