David Brownell wrote:
On Tuesday 15 May 2007, Tzachi Perelstein wrote:
David Brownell wrote:
On Sunday 13 May 2007, Tzachi Perelstein wrote:
Hello,
I'm working on EHCI HC glue port for Marvell Orion SoC. The Orion has
a PCI/PCIE interfaces as well as an integrated USB controller.
While
Hi,
On Thursday 17 May 2007 06:38, David Brownell wrote:
On Wednesday 16 May 2007, Hans Petter Selasky wrote:
Hi,
On Wednesday 16 May 2007 20:20, David Brownell wrote:
URB submission has other failure possibilities than lack of
memory. Those other things have to be checked
Hello Group,
I have two devices connected to a host. I periodically read bulk
data from first device and pass it on to the second device via EP-2.
Apart from this periodic data, the host sends some vendor commands
through EP-0 of first device. Though these vendor commands are
received
On Wed, May 16, 2007 at 05:36:48PM -0400, Ben Collins wrote:
On Wed, 2007-05-16 at 13:59 -0700, Roland Dreier wrote:
/* The first entry is a placeholder for the insmod-specified device */
-{ USB_DEVICE(0x049F, 0x0003) },
Is it obvious why this patch is correct? Especially
On Wed, May 16, 2007 at 06:04:45PM +0200, Jan Engelhardt wrote:
Hello,
I seem to have problems with the ark3116 driver from 2.6.18.8. This is a
USB-RS232 cable. Just opening the /dev/ttyUSB0 device
gives (this is the
debug output enabled by `modprobe ark3116 debug=1`).
The lines
On Tue, May 15, 2007 at 03:32:35PM -0400, Matthew Hickey wrote:
Good afternoon all,
i have a 2.4.26 kernel with the newer patch for the pl2303 driver (10.1)
only the problem is that it only allows for a maxpacketsize of 64 bytes,
if i look at the driver for 2.6.x i see that there is a
On Thu, 2007-05-17 at 05:43 -0700, Greg KH wrote:
On Wed, May 16, 2007 at 05:36:48PM -0400, Ben Collins wrote:
On Wed, 2007-05-16 at 13:59 -0700, Roland Dreier wrote:
/* The first entry is a placeholder for the insmod-specified
device */
- { USB_DEVICE(0x049F, 0x0003)
On Thu, 17 May 2007 09:02:20 EDT, Ben Collins said:
So we just have to live with it, and the infinitesimal speed hit it
creates :)
Any objection to adding it to planned-for-removal and spitting out a
printk when someone uses the feature?
Do we have any good reason to believe that this
On Thu, May 17, 2007 at 09:02:20AM -0400, Ben Collins wrote:
On Thu, 2007-05-17 at 05:43 -0700, Greg KH wrote:
On Wed, May 16, 2007 at 05:36:48PM -0400, Ben Collins wrote:
On Wed, 2007-05-16 at 13:59 -0700, Roland Dreier wrote:
/* The first entry is a placeholder for the
On Thursday 17 May 2007, Tzachi Perelstein wrote:
Besides arguing with me if I have a buggy PCI or not, you couldn't
explain _why_ this is the appropriate handling.
I was pointing out to you that there's nothing particularly wrong
about it. And it has the virtues of being straightforward ...
Hi Greg,
On May 17 2007 05:45, Greg KH wrote:
I seem to have problems with the ark3116 driver from 2.6.18.8. This
is a USB-RS232 cable. Just opening the /dev/ttyUSB0 device gives
(this is the debug output enabled by `modprobe ark3116 debug=1`).
The lines that look suspicious are
On Thu, 17 May 2007, Jayaprakash Shanmugam wrote:
Hello Group,
I have two devices connected to a host. I periodically read bulk
data from first device and pass it on to the second device via EP-2.
Apart from this periodic data, the host sends some vendor commands
through EP-0 of first
On FreeBSD it will never happen that you call the equivalent
of usb_submit_urb() after that the device has detached! It must be
something terribly wrong in the Linux USB stack if the callbacks are
alive after that you have detached a USB device.
How does that work then
On Thu, 17 May 2007, Hans Petter Selasky wrote:
If you need to do Async stuff, then you have to do it in a separate thread or
in a so-called task-queue. Else you are in for great trouble! That was the
big sin in the old USB stack on FreeBSD: Calling synchronous USB callbacks
from
On May 17 2007 16:10, Jan Engelhardt wrote:
Hi Greg,
But does the driver seem to work properly?
Do you get data through the device properly?
I have taken a voltmeter and an appropriate testcase program - and yes,
at least transmit works.
USB-RS232-GenderChanger-RS232-USB.
A faulty setup that
On Thu, May 17, 2007 at 04:51:09PM +0200, Jan Engelhardt wrote:
On May 17 2007 16:10, Jan Engelhardt wrote:
Hi Greg,
But does the driver seem to work properly?
Do you get data through the device properly?
I have taken a voltmeter and an appropriate testcase program - and yes,
at least
On May 17 2007 07:58, Greg KH wrote:
On Thu, May 17, 2007 at 04:51:09PM +0200, Jan Engelhardt wrote:
On May 17 2007 16:10, Jan Engelhardt wrote:
Hi Greg,
But does the driver seem to work properly?
Do you get data through the device properly?
I have taken a voltmeter and an appropriate
Thanks,
JB
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
On Thursday 17 May 2007 16:35, Alan Stern wrote:
On Thu, 17 May 2007, Hans Petter Selasky wrote:
If you need to do Async stuff, then you have to do it in a separate
thread or in a so-called task-queue. Else you are in for great trouble!
That was the big sin in the old USB stack on FreeBSD:
Hi all,
Here is a list of some known regressions in 2.6.22-rc1.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
Timers/NOHZ
Subject: 2.6.21-git4 BUG: soft lockup detected on CPU#1!
References : http://lkml.org/lkml/2007/5/2/511
Submitter :
Hi Michal,
V4L
Subject: V4L ABI breakage
References : http://lkml.org/lkml/2007/5/14/42
Submitter : Robert Fitzsimons [EMAIL PROTECTED]
Caused-By : Hans Verkuil [EMAIL PROTECTED]
Mauro Carvalho Chehab [EMAIL PROTECTED]
commit
On Thursday 17 May 2007 16:20, David Brownell wrote:
On FreeBSD it will never happen that you call the equivalent
of usb_submit_urb() after that the device has detached! It must
be something terribly wrong in the Linux USB stack if the
callbacks are alive after that you
For some reason, this didn't appear in the mailing list archive, so I'm
sending again.
-Original Message-
From: Geoffrey Tam
Sent: Wednesday, May 09, 2007 11:14 AM
To: 'linux-usb-devel@lists.sourceforge.net'
Cc: '[EMAIL PROTECTED]'
Subject: RE: [linux-usb-devel] Cannot stall an endpoint
Hi,
I have a bunch of USB devices configured for ethernet over USB
connected to my machine. The host is running a 2.6.16 based kernel and
I notice that rx errors reported via /proc/net/dev keep increasing
infinitely. Initially the device responds without any problems, but at
some random time,
On Thu, 17 May 2007, Hans Petter Selasky wrote:
In Linux, the USB callbacks are generally atomic. Does that answer
your question?
Yes. So you protect the callback with a lock to make it atomic?
No, you don't understand. The callback is atomic because it is not
allowed to sleep. That's
On Thu, 17 May 2007, Yum Rayan wrote:
Hi,
I have a bunch of USB devices configured for ethernet over USB
connected to my machine. The host is running a 2.6.16 based kernel and
I notice that rx errors reported via /proc/net/dev keep increasing
infinitely. Initially the device responds
On Thursday 17 May 2007, Hans Petter Selasky wrote:
I would like introduce a new USB API call, so that my pre-allocate model will
work better with your USB API. For example I want something like this:
void
usb_setup_endpoint(struct usb_device *usb, struct usb_interface *ui, struct
Hi,
On Thursday 17 May 2007 19:03, Alan Stern wrote:
On Thu, 17 May 2007, Hans Petter Selasky wrote:
In Linux, the USB callbacks are generally atomic. Does that answer
your question?
Yes. So you protect the callback with a lock to make it atomic?
No, you don't understand. The
On Thu, 17 May 2007 10:44:13 -0700, David Brownell [EMAIL PROTECTED] wrote:
So what's the model ... GPL'd Linux drivers will be modified to
incorporate that call, so they'd work better on FreeBSD?
I thought that we ignored this on purpose and talking about the
licensing so deeply in the thread
On Thu, 17 May 2007, Hans Petter Selasky wrote:
Hi,
On Thursday 17 May 2007 19:03, Alan Stern wrote:
On Thu, 17 May 2007, Hans Petter Selasky wrote:
In Linux, the USB callbacks are generally atomic. Does that answer
your question?
Yes. So you protect the callback with a lock
On Thursday 17 May 2007 19:44, David Brownell wrote:
On Thursday 17 May 2007, Hans Petter Selasky wrote:
I would like introduce a new USB API call, so that my pre-allocate model
will work better with your USB API. For example I want something like
this:
void
usb_setup_endpoint(struct
On Thu, 17 May 2007 14:26:18 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote:
As it happens, USB callbacks cannot be interrupted. That's a somewhat
artificial restriction; in theory there's no reason we couldn't allow
interrupts.
Do you remember why we're doing this? I did not touch that
On Thursday 17 May 2007 20:19, Pete Zaitcev wrote:
On Thu, 17 May 2007 10:44:13 -0700, David Brownell [EMAIL PROTECTED]
wrote:
So what's the model ... GPL'd Linux drivers will be modified to
incorporate that call, so they'd work better on FreeBSD?
I thought that we ignored this on purpose
On Thu, 17 May 2007, Pete Zaitcev wrote:
On Thu, 17 May 2007 14:26:18 -0400 (EDT), Alan Stern [EMAIL PROTECTED]
wrote:
As it happens, USB callbacks cannot be interrupted. That's a somewhat
artificial restriction; in theory there's no reason we couldn't allow
interrupts.
Do you
Remove atomic operations on the reference counter for EHCI queue heads.
On various platforms (including ppc7448), atomic operations are unusable
with dma-coherent memory.
Signed-off-by: Steven J. Hill [EMAIL PROTECTED]
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
On Thursday 17 May 2007, Pete Zaitcev wrote:
On Thu, 17 May 2007 14:26:18 -0400 (EDT), Alan Stern [EMAIL PROTECTED]
wrote:
As it happens, USB callbacks cannot be interrupted. That's a somewhat
artificial restriction; in theory there's no reason we couldn't allow
interrupts.
Do you
On Thursday 17 May 2007, Pete Zaitcev wrote:
On Thu, 17 May 2007 10:44:13 -0700, David Brownell [EMAIL PROTECTED] wrote:
So what's the model ... GPL'd Linux drivers will be modified to
incorporate that call, so they'd work better on FreeBSD?
I thought that we ignored this on purpose and
On Thursday 17 May 2007, Hans Petter Selasky wrote:
On Thursday 17 May 2007 19:44, David Brownell wrote:
On Thursday 17 May 2007, Hans Petter Selasky wrote:
I would like introduce a new USB API call, so that my pre-allocate model
will work better with your USB API. ...
int
Hi,
On Thursday 17 May 2007 21:26, David Brownell wrote:
On Thursday 17 May 2007, Hans Petter Selasky wrote:
On Thursday 17 May 2007 19:44, David Brownell wrote:
On Thursday 17 May 2007, Hans Petter Selasky wrote:
I would like introduce a new USB API call, so that my pre-allocate
On Wednesday 16 May 2007, Alan Stern wrote:
On Tue, 15 May 2007, Laurent Pinchart wrote:
Hi everybody,
following the discussion about the split bulk transfers, Alan Stern and
David Brownell told me I shouldn't use usb_buffer_alloc as a generic
purpose URB buffer allocated. However,
On Wednesday 16 May 2007, David Brownell wrote:
On Tuesday 15 May 2007, Laurent Pinchart wrote:
Hi everybody,
following the discussion about the split bulk transfers, Alan Stern and
David Brownell told me I shouldn't use usb_buffer_alloc as a generic
purpose URB buffer allocated.
On Wednesday 16 May 2007, David Brownell wrote:
On Wednesday 16 May 2007, Hans Petter Selasky wrote:
Hi,
I'm currently working on a Linux USB emulation layer for FreeBSD. In that
regard I have some issues that makes the stack peform non-optimal due to
its API design.
...
in that
On Thursday 17 May 2007, Laurent Pinchart wrote:
On Wednesday 16 May 2007, David Brownell wrote:
On Wednesday 16 May 2007, Hans Petter Selasky wrote:
in that when you have
pre-allocated all buffers and all USB host controller descriptors, you
will never get in the situation of not
On Thu, 17 May 2007, Laurent Pinchart wrote:
A user of the Linux UVC driver unfortunately reported such a failure. The
driver allocates 5 bulk URBs, and the device asked for a 2.7MB buffer. The
system had been used for quite some time, and the user reported that
allocating such an amount
On Thursday 17 May 2007, David Brownell wrote:
On Thursday 17 May 2007, Laurent Pinchart wrote:
On Wednesday 16 May 2007, David Brownell wrote:
On Wednesday 16 May 2007, Hans Petter Selasky wrote:
in that when you have
pre-allocated all buffers and all USB host controller
On Thursday 17 May 2007, Laurent Pinchart wrote:
Shouldn't we implement scatter-gather for EHCI (and possibly other)
controllers ?
If by scatter-gather you mean struct scatterlist, we've
had that support for some time now ... in usb_sg_*() routines.
That's the usual definition inside Linux.
The call will setup one or two pre-allocated USB transfers for the
emulation layer between the Linux USB stack and the FreeBSD USB stack.
So what's a transfer ... just a bunch of TDs? And what would be
the advantage to a Linux driver, since the TDs are allocated on
demand in any
On Thursday 17 May 2007 23:04, Alan Stern wrote:
On Thu, 17 May 2007, Laurent Pinchart wrote:
A user of the Linux UVC driver unfortunately reported such a failure. The
driver allocates 5 bulk URBs, and the device asked for a 2.7MB buffer.
The system had been used for quite some time, and
On Thu, 17 May 2007, Jason Brewster wrote:
Thanks,
What kind of device is that? (could you please post at least output of
lsusb, etc.).
It might be that the device is standard-compliant (for example HID), so
wouldn't require any extra driver.
Thanks,
--
Jiri Kosina
On Thu, 17 May 2007 12:08:15 -0700, David Brownell [EMAIL PROTECTED] wrote:
As it happens, USB callbacks cannot be interrupted. That's a somewhat
artificial restriction; in theory there's no reason we couldn't allow
interrupts.
Do you remember why we're doing this? I did not
Hi,
Below is a patch with the following changes to the berry_charge.c module:
1) kzalloc() is called, but memory is never freed
Is this a memory leak? I'm not sure, but the buffer is only
a dummy buffer to hold return data that is never used,
so I suspect a stack
On Thursday 17 May 2007, Pete Zaitcev wrote:
On Thu, 17 May 2007 12:08:15 -0700, David Brownell [EMAIL PROTECTED] wrote:
As it happens, USB callbacks cannot be interrupted. That's a somewhat
artificial restriction; in theory there's no reason we couldn't allow
interrupts.
TAM KAPSAMLI CHECK-UP KAMPANYASI
SAÐLIÐINIZ
Description: Binary data
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just
On Thursday 17 May 2007, Hans Petter Selasky wrote:
Isn't that the job of usb_buffer_alloc(), to allocate memory in blocks of
PAGE_SIZE bytes?
Not at all. The size parameter is in bytes, and the utility
code it calls goes to some lengths to *avoid* that kind of wastage.
As they say: UTSL!
Hi
I'm using HP storageworks USB DAT device on RHEL4 (based on kernel 2.6.9).
It works okay most of the times, but sometimes the driver does not detect
the device (about 1 out of 10 times). No other USB devices are used on the
system. Let me explain some details.
I turned on the CONFIG_USB_DEBUG
On Thu, 17 May 2007 21:52:30 -0700 [EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=8498
Summary: BUG: 2.6.22-rc1+ resume after suspend-to-disk broken
when USB compiled in.
Kernel Version:
56 matches
Mail list logo
