On Mon, 05 Feb 2007 14:16:50 +1100, Matt Doran <[EMAIL PROTECTED]> wrote:
> So I'm not sure whether these disconnects are the fault of the hardware
> or the USB layer, but I'd like to help track it down. Is there anything
> that I can do to help track down the cause of the disconnections? Can
Hi there,
I'm writing to the list on request of one of the DVB driver developers,
who is seeking some advice on possible causes of a "USB disconnects".
The issue is that I see USB disconnects for a DVB Tuner card that is a
PCI card that implements a USB hub with 2 DVB tuners attached. Due to
On Sun, 4 Feb 2007, Oliver Neukum wrote:
> Am Sonntag, 4. Februar 2007 17:07 schrieb Alan Stern:
> > On Sat, 3 Feb 2007, Oliver Neukum wrote:
> >
> > > If you want simplicity, I'd suggest serialization. kmalloc for 4 bytes
> > > is overkill. I think it is even faster if we block on the cases ther
On Sun, 4 Feb 2007, Dirk Eddelbuettel wrote:
> | As near as I can tell, this shows that the kernel behaves the same way
> | regardless of CONFIG_USB_SUSPEND, and all the problems seem to be caused
> | either by the Treo itself or by the pilot-xfer program.
> |
> | Do you agree? While there may
On Sun, 4 Feb 2007, Prakash Punnoor wrote:
> Am Sonntag 04 Februar 2007 schrieb Alan Stern:
>
> > Prakash, here's an alternative patch. It should work just as well as the
> > previous one (don't try to apply them both!).
>
> Seems to work fine for me. Nice work! Out of curiousity. Did the git-b
Jiri Kosina wrote:
> On Thu, 1 Feb 2007, Phil Dibowitz wrote:
>
>> What's odd is when I plug it in, it declares itself a HID device:
>> bInterfaceClass 3 Human Interface Devices
>> bInterfaceSubClass 0 No Subclass
>> bInterfaceProtocol 0 None
>> Feb 1 22:44:04
Hello
I would like to add the VID and PID for Telldus Technologies Homeautomation
usb-dongle to the ftdi_sio driver.
I have attached a patch for the changes
Regards Micke
--- ftdi_sio.c.old 2007-02-04 23:26:16.0 +0100
+++ ftdi_sio.c 2007-02-04 23:28:07.0 +0100
@@ -513,6 +513,7 @
Begin forwarded message:
Date: Sun, 4 Feb 2007 13:52:15 -0800
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bugme-new] [Bug 7932] New: Unable to initialize USB-Devices
http://bugzilla.kernel.org/show_bug.cgi?id=7932
Summary: Unable to initialize USB-Devices
Kernel Ver
Am Sonntag, 4. Februar 2007 22:45 schrieben Sie:
> Hello Oliver,
>
> On Sun, Feb 04, 2007 at 09:59:00PM +0100, Oliver Neukum wrote:
> > Did you test this with ehci? Unless we know for sure that even with
> > the larger packet size the tty layer can cope, I want to be conservative.
>
> Good point.
It seems that the CDC-ACM driver can get stuck in a throttling
condition.
The proposed patch fixes this by resetting the acm->throttle flag at
device open time. This patch was tested on i386, ohci-hcd with a custom
USB device and appears to fix the problem.
Signed-off-by: Joris van Rantijk <[EMAI
According to the USB CDC class specification, line state control
is an optional feature for ACM devices. However, the cdc-acm driver
bails out when acm_set_control() fails while opening the device.
The proposed patch changes that behaviour: Failure of acm_set_control
is now only considered an erro
Hello Oliver,
On Sun, Feb 04, 2007 at 09:59:00PM +0100, Oliver Neukum wrote:
> Did you test this with ehci? Unless we know for sure that even with
> the larger packet size the tty layer can cope, I want to be conservative.
Good point. No I didn't, my device does not do high speed.
The tty layer
Am Samstag, 3. Februar 2007 17:10 schrieben Sie:
> On Sat, Feb 03, 2007 at 04:18:24PM +0100, Oliver Neukum wrote:
> > 1. Why not simply take the lock earlier?
>
> And call the tty layer under acm->throttle_lock? I think not.
No, it would deadlock, you are right.
> We could of course read acm->th
Am Sonntag, 4. Februar 2007 17:07 schrieb Alan Stern:
> On Sat, 3 Feb 2007, Oliver Neukum wrote:
>
> > If you want simplicity, I'd suggest serialization. kmalloc for 4 bytes
> > is overkill. I think it is even faster if we block on the cases there's
> > a collision that go through kmalloc/kfree ea
Hi Alan,
On 4 February 2007 at 11:37, Alan Stern wrote:
| On Sat, 3 Feb 2007, Dirk Eddelbuettel wrote:
|
| > I think you may be right. The behaviour was not that different between the
| > twp variants of 2.6.18 I tried, one with and one without CONFIG_USB_SUSPEND
| > and CONFIG_USB_DEBUG.
| >
Am Sonntag 04 Februar 2007 schrieb Alan Stern:
> Prakash, here's an alternative patch. It should work just as well as the
> previous one (don't try to apply them both!).
Seems to work fine for me. Nice work! Out of curiousity. Did the git-bisect
point to the correct change?
Cheers,
--
(°=
On Sat, 3 Feb 2007, Dirk Eddelbuettel wrote:
> I think you may be right. The behaviour was not that different between the
> twp variants of 2.6.18 I tried, one with and one without CONFIG_USB_SUSPEND
> and CONFIG_USB_DEBUG.
>
> In either case, it works if you do the following exactly as describe
深圳市雄德贸易有限公司
本公司因进项较多,每个月有结余各地发票可对外优惠代开有,
(海关缴款书\商品销售\运输\ 广告\ 建筑安装\ 其它服务类\租赁
商业\企业\ 餐饮\ 咨询)等等.普通发票详细收费可根据贵公司所
开金额大小来衡量点数。
本公司可依照贵公司的要求进行合作,对于双方合作关系绝对
保密,所开出的票据可上网查询验证.各地均可代开！
1．公司为一
On Sat, 3 Feb 2007, Oliver Neukum wrote:
> If you want simplicity, I'd suggest serialization. kmalloc for 4 bytes
> is overkill. I think it is even faster if we block on the cases there's
> a collision that go through kmalloc/kfree each time.
On the other hand, the same routine calls usb_control_
Am Sonntag, 4. Februar 2007 05:11 schrieb Pete Zaitcev:
> On Sat, 3 Feb 2007 17:02:27 -0500 (EST), Alan Stern <[EMAIL PROTECTED]> wrote:
>
> > + buffer = kmalloc(sizeof(*buffer), GFP_NOIO);
>
> Why is this GFP_NOIO, if it's not in the path of block I/O? Or is it?
It is used by usb_reset_device
20 matches
Mail list logo
