-- Forwarded message --
From: Travis H. <[EMAIL PROTECTED]>
Date: Dec 3, 2005 7:48 PM
Subject: numerous usb isses (ehci not working, &c.)
To: linux-usb-users@lists.sourceforge.net
Hi, I'm going to lump a bunch of things into one email to save your patience.
kernel: 2.6.13 SMP
Fi
Hi.
Seems like some bug in usb-serial layer - the USB link was receiving
data (zeroes) at the high speed, from FT2232C second port, configured as
245 FIFO. While connecting to /dev/tts/USB1 & setting link opts got this
oops.
Rus
serial_oops.bz2
Description: Binary
Hi Greg,
The Kermit application closes once the mobile is turned off (using
AT+CFUN=0 command or any manually turn off the mobile) and it does not
allows to perform any further operation.
Our observation on this is after powering the mobile off disconnect
function is called and the file descripto
On Tue, Dec 06, 2005 at 05:24:59PM -0800, Deepak Saxena wrote:
> I need to implement support for the on-chip EHCI HCD on the Intel IXP46x
> NPU and being on-chip, it is clearly !PCI. The existing EHCI code ties
> the bus glue and core together and makes it rather difficult to add
> a non-PCI HCD un
On Wednesday 07 December 2005 11:19 am, Alan Stern wrote:
> Dave:
>
> We need to settle on a policy for handling USB drivers that don't have
> suspend/resume support. The current code in 2.6.15-rc returns 0 for the
> interface suspend call but doesn't change the interface's power_state
> value
On Wed, Dec 07, 2005 at 06:01:16PM +0530, [EMAIL PROTECTED] wrote:
>
> Hi Greg,
>
>
>
> I have some doubts on usbserial driver with respect to connect and
> disconnect functions.
>
>
>
> I'm using Kermit application to communicate with the device, when I'm
> powering off the mobile, mobile i
On Wed, 2005-12-07 at 15:00 -0800, Pete Zaitcev wrote:
> On Wed, 07 Dec 2005 18:31:17 +, harry <[EMAIL PROTECTED]> wrote:
>
> > This 'USB split driver' has a 'front-end' in the Linux kernel
> > running in a guest domain of the hypervisor and a 'back-end' in the
> > Linux kernel running in
On Wed, 07 Dec 2005 18:31:17 +, harry <[EMAIL PROTECTED]> wrote:
> This 'USB split driver' has a 'front-end' in the Linux kernel
> running in a guest domain of the hypervisor and a 'back-end' in the
> Linux kernel running in a device driver domain (usually the special
> privilidged domain
On Wed, 2005-12-07 at 14:35 -0500, Alan Stern wrote:
> > I did have a problem with URBs getting reordered on their way
> > between the front-end and the back-end which led to miscompares where
> > the correct bulk data was written on the USB key but at the wrong LBA. I
> > fixed this by mainta
On Wed, 7 Dec 2005, harry wrote:
> USB Folks,
>
> I've been working on a USB device driver for Linux running
> paravirtualized on the Xen hypervisor and I have a few questions about
> the design of the error recovery...
>
> This 'USB split driver' has a 'front-end' in the Linux kernel
>
Dave:
We need to settle on a policy for handling USB drivers that don't have
suspend/resume support. The current code in 2.6.15-rc returns 0 for the
interface suspend call but doesn't change the interface's power_state
value. As a result, the suspend call for the device fails, aborting the
e
Hi, Greg,
On Wed, Dec 07, 2005 at 09:56:14AM -0800, Greg KH wrote:
> On Wed, Dec 07, 2005 at 03:13:32PM -0200, Eduardo Pereira Habkost wrote:
> > I have a small question: in my view, this patch series is a small
> > step towards implementing the usb-serial drivers The Right Way, as it
> > removes
Le mercredi 07 décembre 2005 à 10:16 -0500, Alan Stern a écrit :
> On Wed, 7 Dec 2005, Marwan Cyril Sabra wrote:
>
> > [4296233.326000] usb-storage: This device (0482,0105,0100 S 06 P 50) has
> > unneede d SubClass and Protocol entries in unusual_devs.h
> > [4296233.326000]Please send a copy o
On Wed, Dec 07, 2005 at 03:13:32PM -0200, Eduardo Pereira Habkost wrote:
> I have a small question: in my view, this patch series is a small
> step towards implementing the usb-serial drivers The Right Way, as it
> removes a a bit of duplicated code.
It doesn't remove any "duplicated code", it onl
USB Folks,
I've been working on a USB device driver for Linux running
paravirtualized on the Xen hypervisor and I have a few questions about
the design of the error recovery...
This 'USB split driver' has a 'front-end' in the Linux kernel
running in a guest domain of the hypervisor and a
Alan Stern schrieb:
Darn it. There were two problem pathways in that code and the patch
changed the wrong one. Okay, this patch changes both.
Bear in mind that this is just a temporary band-aid. The real problem is
that the usblp driver doesn't have any suspend/resume support. That still
On Wed, Dec 07, 2005 at 02:51:13PM -0200, Luiz Fernando Capitulino wrote:
> On Wed, 7 Dec 2005 08:41:18 -0800
> Greg KH <[EMAIL PROTECTED]> wrote:
>
> | On Tue, Dec 06, 2005 at 09:56:10AM -0200, Luiz Fernando Capitulino wrote:
> | > Greg,
> | >
> | > Don't get scared. :-)
> |
> | I'm not scare
On Wed, Dec 07, 2005 at 02:55:07PM -0200, Otavio Salvador wrote:
> Greg KH <[EMAIL PROTECTED]> writes:
>
> > That's the right thing to do, so I'm not going to take this patch series
> > right now because of that. If you all want to work on moving to use the
> > serial core, I would love to see th
Greg KH <[EMAIL PROTECTED]> writes:
> That's the right thing to do, so I'm not going to take this patch series
> right now because of that. If you all want to work on moving to use the
> serial core, I would love to see that happen.
But wouldn't be better to have this intermediary solution merge
On Wed, 7 Dec 2005 08:41:18 -0800
Greg KH <[EMAIL PROTECTED]> wrote:
| On Tue, Dec 06, 2005 at 09:56:10AM -0200, Luiz Fernando Capitulino wrote:
| > Greg,
| >
| > Don't get scared. :-)
|
| I'm not scared, just not liking this patch series at all.
|
| In the end, it's just moving from one lock
On Tue, Dec 06, 2005 at 09:56:10AM -0200, Luiz Fernando Capitulino wrote:
> Greg,
>
> Don't get scared. :-)
I'm not scared, just not liking this patch series at all.
In the end, it's just moving from one locking scheme to another. No big
deal.
The problem is, none of this should be needed at
On Wed, 7 Dec 2005, Carl-Daniel Hailfinger wrote:
> Alan Stern schrieb:
> > On Wed, 7 Dec 2005, Carl-Daniel Hailfinger wrote:
> >
> >>Sorry, this patch didn't help. Anthing else I can try?
> >
> > What does the dmesg log say?
>
> Same as before:
>
> usb 1-2: new full speed USB device using uhc
On Wed, Dec 07, 2005 at 05:02:33PM +0100, Arjan van de Ven wrote:
>
> > > No they're not. Both are just about equally expensive cpu wise,
> > > sometimes the atomic_t ones are a bit more expensive (like on parisc
> > > architecture). But on x86 in either case it's a locked cycle, which is
> > > ju
Alan Stern schrieb:
On Wed, 7 Dec 2005, Carl-Daniel Hailfinger wrote:
Sorry, this patch didn't help. Anthing else I can try?
What does the dmesg log say?
Same as before:
usb 1-2: new full speed USB device using uhci_hcd and address 2
drivers/usb/class/usblp.c: usblp0: USB Bidirectional pri
On Wed, 7 Dec 2005, Carl-Daniel Hailfinger wrote:
> Sorry, this patch didn't help. Anthing else I can try?
What does the dmesg log say?
Alan Stern
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?
On Wed, 7 Dec 2005, linux-os (Dick Johnson) wrote:
> You need to know what it is that you intend to do if the code
> encounters a locked section.
>
> For example, let's pretend that every operation is atomic so
> that only the logic is investigated...
>
> if(!critical_section_flag) {
>
On Wed, 2005-12-07 at 11:01 -0500, Alan Stern wrote:
> On Wed, 7 Dec 2005, Arjan van de Ven wrote:
>
> > > On the other hand, Oliver needs to be careful about claiming too much.
> > > In
> > > general atomic_t operations _are_ superior to the spinlock approach.
> >
> > No they're not. Both are
On Mer, 2005-12-07 at 16:50 +0100, Oliver Neukum wrote:
> But the atomic variant has to guard against interrupts, at least on
> architectures that do load/store only, hasn't it?
Yes. And you will see at least four different approaches
1. ll/sc where if the sequence was interrupted and may be sta
> > No they're not. Both are just about equally expensive cpu wise,
> > sometimes the atomic_t ones are a bit more expensive (like on parisc
> > architecture). But on x86 in either case it's a locked cycle, which is
> > just expensive no matter which side you flip the coin...
>
> But if a lock i
On Wed, 7 Dec 2005, Arjan van de Ven wrote:
> > On the other hand, Oliver needs to be careful about claiming too much. In
> > general atomic_t operations _are_ superior to the spinlock approach.
>
> No they're not. Both are just about equally expensive cpu wise,
> sometimes the atomic_t ones ar
Alan Stern schrieb:
On Tue, 6 Dec 2005, Carl-Daniel Hailfinger wrote:
since I switched to 2.6.15-rc2-git6, my machine is not able to suspend
anymore if my USB printer is plugged in. The problem is reproducible.
usb 1-2: new full speed USB device using uhci_hcd and address 3
drivers/usb/class/
On Wed, Dec 07, 2005 at 04:22:23PM +0100, Arjan van de Ven wrote:
>
> > On the other hand, Oliver needs to be careful about claiming too much. In
> > general atomic_t operations _are_ superior to the spinlock approach.
>
> No they're not. Both are just about equally expensive cpu wise,
> someti
Am Mittwoch, 7. Dezember 2005 16:40 schrieben Sie:
> On Wed, 2005-12-07 at 16:37 +0100, Oliver Neukum wrote:
> > Am Mittwoch, 7. Dezember 2005 16:22 schrieb Arjan van de Ven:
> > > > On the other hand, Oliver needs to be careful about claiming too much.
> > > > In
> > > > general atomic_t operat
On Wed, 2005-12-07 at 16:37 +0100, Oliver Neukum wrote:
> Am Mittwoch, 7. Dezember 2005 16:22 schrieb Arjan van de Ven:
> > > On the other hand, Oliver needs to be careful about claiming too much.
> > > In
> > > general atomic_t operations _are_ superior to the spinlock approach.
> >
> > No the
On Tue, 6 Dec 2005, driversbin driversbin wrote:
> Hi,
>
> I am using a usb host-host cable from prolific (vendor
> id=0x067 product id=0x2501) . When I plug-in and out
> twice I start getting messages like the one below.
>
> usb 1-2: device not accepting address 4, error -110
>
> usb 1-2: new
Am Mittwoch, 7. Dezember 2005 16:22 schrieb Arjan van de Ven:
> > On the other hand, Oliver needs to be careful about claiming too much. In
> > general atomic_t operations _are_ superior to the spinlock approach.
>
> No they're not. Both are just about equally expensive cpu wise,
> sometimes the
On Wed, 7 Dec 2005, Alan Stern wrote:
> On Tue, 6 Dec 2005, Oliver Neukum wrote:
>
>> Am Dienstag, 6. Dezember 2005 21:13 schrieb Eduardo Pereira Habkost:
>>> Anyway, I don't see yet why the atomic_t would make the code slower on
>>> non-smp. Is atomic_add_unless(v, 1, 1) supposed to be slower th
On Tue, 6 Dec 2005, Carl-Daniel Hailfinger wrote:
> Hi,
>
> since I switched to 2.6.15-rc2-git6, my machine is not able to suspend
> anymore if my USB printer is plugged in. The problem is reproducible.
>
> usb 1-2: new full speed USB device using uhci_hcd and address 3
> drivers/usb/class/usblp
> On the other hand, Oliver needs to be careful about claiming too much. In
> general atomic_t operations _are_ superior to the spinlock approach.
No they're not. Both are just about equally expensive cpu wise,
sometimes the atomic_t ones are a bit more expensive (like on parisc
architecture).
On Wed, 7 Dec 2005, Marwan Cyril Sabra wrote:
> [4296233.326000] usb-storage: This device (0482,0105,0100 S 06 P 50) has
> unneede d SubClass and Protocol entries in unusual_devs.h
> [4296233.326000]Please send a copy of this message to
> <[EMAIL PROTECTED] .sourceforge.net>
Phil, this isn't
On Tue, 6 Dec 2005, Oliver Neukum wrote:
> Am Dienstag, 6. Dezember 2005 21:13 schrieb Eduardo Pereira Habkost:
> > Anyway, I don't see yet why the atomic_t would make the code slower on
> > non-smp. Is atomic_add_unless(v, 1, 1) supposed to be slower than
> > 'if (!v) v = 1;' ?
>
> spin_lock() c
On Tue, 6 Dec 2005, Ethan Dicks wrote:
> On Tue, Dec 06, 2005 at 12:46:32PM -0800, Deepak Saxena wrote:
> > I really think we need a rule in Documentation/CodingStyle that says
> > "Thou shalt not #include .c files from .c files."
>
> Wow! And I thought that was universally understood as a Bad I
On Thu, Dec 01, 2005 at 10:54:27PM -0800, Greg KH wrote:
> On Fri, Dec 02, 2005 at 12:20:09PM +0530, Rachita Kothiyal wrote:
> > On Thu, Dec 01, 2005 at 05:17:48PM -0800, Greg KH wrote:
> > > On Thu, Dec 01, 2005 at 10:05:02PM +0530, Rachita Kothiyal wrote:
> > > > Hi
> > > >
> > > > I am trying t
On Wed, 7 Dec 2005 14:01:25 +0100
Oliver Neukum <[EMAIL PROTECTED]> wrote:
| Am Mittwoch, 7. Dezember 2005 13:25 schrieb Luiz Fernando Capitulino:
| > On Tue, 6 Dec 2005 23:36:47 +0100
| > Oliver Neukum <[EMAIL PROTECTED]> wrote:
| >
| > | Am Dienstag, 6. Dezember 2005 22:18 schrieb Luiz Fernando
Am Mittwoch, 7. Dezember 2005 13:25 schrieb Luiz Fernando Capitulino:
> On Tue, 6 Dec 2005 23:36:47 +0100
> Oliver Neukum <[EMAIL PROTECTED]> wrote:
>
> | Am Dienstag, 6. Dezember 2005 22:18 schrieb Luiz Fernando Capitulino:
> | >
> | > Hi Pete,
> | >
> | > On Tue, 6 Dec 2005 13:02:07 -0800
> |
On Wed, 7 Dec 2005 10:41:24 -0200
Luiz Fernando Capitulino <[EMAIL PROTECTED]> wrote:
| On Wed, 07 Dec 2005 13:34:38 +0100
| Arjan van de Ven <[EMAIL PROTECTED]> wrote:
|
| | On Wed, 2005-12-07 at 10:30 -0200, Luiz Fernando Capitulino wrote:
| | > On Wed, 07 Dec 2005 13:27:13 +0100
| | > Arjan va
On Wed, 07 Dec 2005 13:34:38 +0100
Arjan van de Ven <[EMAIL PROTECTED]> wrote:
| On Wed, 2005-12-07 at 10:30 -0200, Luiz Fernando Capitulino wrote:
| > On Wed, 07 Dec 2005 13:27:13 +0100
| > Arjan van de Ven <[EMAIL PROTECTED]> wrote:
| >
| > |
| > | > Isn't it right? Is the URB write so fast t
On Wed, 2005-12-07 at 10:30 -0200, Luiz Fernando Capitulino wrote:
> On Wed, 07 Dec 2005 13:27:13 +0100
> Arjan van de Ven <[EMAIL PROTECTED]> wrote:
>
> |
> | > Isn't it right? Is the URB write so fast that switching to atomic_t
> | > doesn't pay-off?
> |
> | an atomic_t access and a spinlock
On Wed, 07 Dec 2005 13:27:13 +0100
Arjan van de Ven <[EMAIL PROTECTED]> wrote:
|
| > Isn't it right? Is the URB write so fast that switching to atomic_t
| > doesn't pay-off?
|
| an atomic_t access and a spinlock are basically the same price... so
| what's the payoff ?
One lock less, clean and
> Isn't it right? Is the URB write so fast that switching to atomic_t
> doesn't pay-off?
an atomic_t access and a spinlock are basically the same price... so
what's the payoff ?
---
This SF.net email is sponsored by: Splunk Inc. Do you grep
On Tue, 6 Dec 2005 23:36:47 +0100
Oliver Neukum <[EMAIL PROTECTED]> wrote:
| Am Dienstag, 6. Dezember 2005 22:18 schrieb Luiz Fernando Capitulino:
| >
| > Hi Pete,
| >
| > On Tue, 6 Dec 2005 13:02:07 -0800
| > Pete Zaitcev <[EMAIL PROTECTED]> wrote:
| >
| > | On Tue, 6 Dec 2005 18:14:49 -0200,
On Tue, 6 Dec 2005 23:48:14 +0100
Oliver Neukum <[EMAIL PROTECTED]> wrote:
| Am Dienstag, 6. Dezember 2005 21:13 schrieb Eduardo Pereira Habkost:
| > Anyway, I don't see yet why the atomic_t would make the code slower on
| > non-smp. Is atomic_add_unless(v, 1, 1) supposed to be slower than
| > 'if
BANNED FILENAME ALERT
Your message to: [EMAIL PROTECTED]
was blocked by our Spam Firewall. The email you sent with the following subject
has NOT BEEN DELIVERED:
Subject: Mail Delivery (failure [EMAIL PROTECTED])
An attachment in that mail was of a file type that the Spam Firewall is set to
blo
-110 is the timeout error and your device it not accepting the
SetAddress itself. What is your device ?
On 12/7/05, driversbin driversbin <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am using a usb host-host cable from prolific (vendor
> id=0x067 product id=0x2501) . When I plug-in and out
> twice I sta
[4296233.326000] usb-storage: This device (0482,0105,0100 S 06 P 50) has
unneede d SubClass and Protocol entries in unusual_devs.h
[4296233.326000]Please send a copy of this message to
<[EMAIL PROTECTED] .sourceforge.net>
--
Marwan Cyril Sabra
15, rue ALfred Brinon
69100 Villeurbanne
Courriel
55 matches
Mail list logo