On Friday 30 March 2007 7:59 pm, Alan Stern wrote:
> > > Nope. If an smp_mb() is needed, the reason is because of other
> > > driver-internal bugs.
> > >
> > > Remember that the driver isn't allowed to so much as *LOOK* at any
> > > field of an URB until the completion callback. That generalize
> That raises the question how the issue is to be solved. To me the obvious
> solution to a lack of memory ordering is to specify memory ordering
> explicitely. However, I seem to be in the minority.
>
> The other way around it would be to use wait_for_completion().
> Oppinions?
Memory barriers a
On Sat, 31 Mar 2007, Oliver Neukum wrote:
> Am Samstag, 31. März 2007 04:59 schrieb Alan Stern:
> > isn't clean -- but several drivers do it this way. I'm not even certain
> > that adding smp_mb() to the completion routine will really fix it; memory
> > barriers have to be used in pairs, and so
Am Samstag, 31. März 2007 04:59 schrieb Alan Stern:
> isn't clean -- but several drivers do it this way. I'm not even certain
> that adding smp_mb() to the completion routine will really fix it; memory
> barriers have to be used in pairs, and so there would also need to be a
> barrier between t
Am Samstag, 31. März 2007 04:59 schrieb Alan Stern:
> There still remains the question of how to do this cleanly. Obviously
> some sort of synchronization primitive is needed. wait_for_completion()
> includes all the necessary memory barriers, whereas wait_event() does not.
> Or a spinlock coul
Am Samstag, 31. März 2007 01:31 schrieb David Brownell:
> On Friday 30 March 2007 2:49 pm, Oliver Neukum wrote:
>
> > > Nope. If an smp_mb() is needed, the reason is because of other
> > > driver-internal bugs.
>
> > > Remember that the driver isn't allowed to so much as *LOOK* at any
> > > fiel
On Fri, 30 Mar 2007, Oliver Neukum wrote:
> Am Freitag, 30. März 2007 22:59 schrieb David Brownell:
> > On Friday 30 March 2007 1:38 pm, Oliver Neukum wrote:
> > > Am Freitag, 30. März 2007 22:04 schrieb David Brownell:
> > > > Remember that if every completion callback does
> > > >
> > > >
On Friday 30 March 2007 2:49 pm, Oliver Neukum wrote:
> > Nope. If an smp_mb() is needed, the reason is because of other
> > driver-internal bugs.
> > Remember that the driver isn't allowed to so much as *LOOK* at any
> > field of an URB until the completion callback. That generalizes:
> > it m
Am Freitag, 30. März 2007 22:59 schrieb David Brownell:
> On Friday 30 March 2007 1:38 pm, Oliver Neukum wrote:
> > Am Freitag, 30. März 2007 22:04 schrieb David Brownell:
> > > Remember that if every completion callback does
> > >
> > > status = urb->status;
> > >
> > > at the top, the u
On Friday 30 March 2007 1:38 pm, Oliver Neukum wrote:
> Am Freitag, 30. März 2007 22:04 schrieb David Brownell:
> > Remember that if every completion callback does
> >
> > status = urb->status;
> >
> > at the top, the urb->status issue will by definition go away. That's
>
> Only if it d
Am Freitag, 30. März 2007 22:04 schrieb David Brownell:
> Remember that if every completion callback does
>
> status = urb->status;
>
> at the top, the urb->status issue will by definition go away. That's
Only if it does smp_mb(), which is the whole point of this thread.
Regard
Am Freitag, 30. März 2007 21:36 schrieb Pete Zaitcev:
> > That's not the issue. The question is not what we USB needs in terms
> > of performance. Every time we use a lock we screw anybody caring about
> > interrupt latency. The amount of work some drivers do in irq is awful.
>
> That's true, I su
On Friday 30 March 2007 11:33 am, Oliver Neukum wrote:
> Am Freitag, 30. März 2007 19:56 schrieb Greg KH:
> > > The bottom line is, there's no excuse for using any kind of smp_mb()
> > > in USB drivers. None at all. When we have 100Gbit/s USB, then perhaps
> > > we can talk about it.
> >
> > Perha
On Fri, 30 Mar 2007 20:33:10 +0200, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Am Freitag, 30. März 2007 19:56 schrieb Greg KH:
> > > The bottom line is, there's no excuse for using any kind of smp_mb()
> > > in USB drivers. None at all. When we have 100Gbit/s USB, then perhaps
> > > we can talk a
Am Freitag, 30. März 2007 19:56 schrieb Greg KH:
> > The bottom line is, there's no excuse for using any kind of smp_mb()
> > in USB drivers. None at all. When we have 100Gbit/s USB, then perhaps
> > we can talk about it.
>
> Perhaps then, but even then, I doubt it...
That's not the issue. The qu
On Fri, Mar 30, 2007 at 10:38:01AM -0700, Pete Zaitcev wrote:
> On Fri, 30 Mar 2007 11:17:28 +0200, Oliver Neukum <[EMAIL PROTECTED]> wrote:
>
> > This can'be solved with a simple spinlock, as wait_event() can sleep.
>
> That's because wait_event() and its ilk make a bad API. I mentioned it
> man
On Fri, Mar 30, 2007 at 01:31:28PM -0400, Alan Stern wrote:
> On Fri, 30 Mar 2007, Greg KH wrote:
>
> > I think it really comes down to the problem of checking the urb status
> > flag.
> >
> > I _REALLY_ want to get rid of that field and not have drivers us it at
> > all. I would like to pass th
On Fri, 30 Mar 2007 11:17:28 +0200, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> This can'be solved with a simple spinlock, as wait_event() can sleep.
That's because wait_event() and its ilk make a bad API. I mentioned it
many times before, and the answer by its pushers was "make the condition
to b
On Fri, 30 Mar 2007, Greg KH wrote:
> I think it really comes down to the problem of checking the urb status
> flag.
>
> I _REALLY_ want to get rid of that field and not have drivers us it at
> all. I would like to pass the value of the status flag to the urb
> callback directly, and only have t
On Fri, Mar 30, 2007 at 06:08:44PM +0200, Oliver Neukum wrote:
> Am Freitag, 30. M?rz 2007 17:41 schrieb Greg KH:
> > On Fri, Mar 30, 2007 at 11:17:28AM +0200, Oliver Neukum wrote:
>
> > > However it would not always work out so nicely.
> > > Have a look at this code from usblp:
> > >
> > >
Am Freitag, 30. März 2007 17:41 schrieb Greg KH:
> On Fri, Mar 30, 2007 at 11:17:28AM +0200, Oliver Neukum wrote:
> > However it would not always work out so nicely.
> > Have a look at this code from usblp:
> >
> > timeout = USBLP_WRITE_TIMEOUT;
> >
> > r
On Fri, Mar 30, 2007 at 11:17:28AM +0200, Oliver Neukum wrote:
> Am Freitag, 30. M?rz 2007 11:03 schrieb Greg KH:
> > On Fri, Mar 30, 2007 at 10:45:26AM +0200, Oliver Neukum wrote:
> > > Am Freitag, 30. M?rz 2007 10:39 schrieb Greg KH:
> > > > > To solve this with locking would require both CPU A a
Am Freitag, 30. März 2007 11:03 schrieb Greg KH:
> On Fri, Mar 30, 2007 at 10:45:26AM +0200, Oliver Neukum wrote:
> > Am Freitag, 30. M?rz 2007 10:39 schrieb Greg KH:
> > > > To solve this with locking would require both CPU A and CPU B to take
> > > > the lock, which means that the urb would have
On Fri, Mar 30, 2007 at 10:45:26AM +0200, Oliver Neukum wrote:
> Am Freitag, 30. M?rz 2007 10:39 schrieb Greg KH:
> > > To solve this with locking would require both CPU A and CPU B to take
> > > the lock, which means that the urb would have to be submitted with
> > > GFP_ATOMIC.
> >
> > Can't thi
Am Freitag, 30. März 2007 10:39 schrieb Greg KH:
> > To solve this with locking would require both CPU A and CPU B to take
> > the lock, which means that the urb would have to be submitted with
> > GFP_ATOMIC.
>
> Can't this all be solved with a simple:
>
> get port spinlock
> a =
On Fri, Mar 30, 2007 at 10:28:48AM +0200, Oliver Neukum wrote:
> Am Freitag, 30. M?rz 2007 09:48 schrieb Greg KH:
> > > As an added complication, the resubmission would happen on another cpu.
> > > Therefore the order on the bus must be correct, hence the "smp_mb()".
> >
> > This part I still don'
Am Freitag, 30. März 2007 09:45 schrieb David Brownell:
> > As an added complication, the resubmission would happen on another cpu.
> > Therefore the order on the bus must be correct, hence the "smp_mb()".
>
> Erm, resubmit would happen on the CPU running the completion handler.
> So, no mb() or e
Am Freitag, 30. März 2007 09:48 schrieb Greg KH:
> > As an added complication, the resubmission would happen on another cpu.
> > Therefore the order on the bus must be correct, hence the "smp_mb()".
>
> This part I still don't understand.
>
> What are we doing a memory barier for after the comple
On Fri, Mar 30, 2007 at 08:58:38AM +0200, Oliver Neukum wrote:
> Am Freitag, 30. M?rz 2007 07:07 schrieb Greg KH:
> > On Thu, Mar 29, 2007 at 02:25:34PM +0200, Oliver Neukum wrote:
> > > @@ -332,12 +330,12 @@
> > >
> > > dbg("%s - port %d", __FUNCTION__, port->number);
> > >
> > > - port->wri
On Thursday 29 March 2007 11:58 pm, Oliver Neukum wrote:
> /* complete() can reenter this HCD */
> spin_unlock (&ehci->lock);
> usb_hcd_giveback_urb (ehci_to_hcd(ehci), urb);
> spin_lock (&ehci->lock);
>
> The comment gives you the reason and is right. The locks must be dr
Am Freitag, 30. März 2007 07:07 schrieb Greg KH:
> On Thu, Mar 29, 2007 at 02:25:34PM +0200, Oliver Neukum wrote:
> > @@ -332,12 +330,12 @@
> >
> > dbg("%s - port %d", __FUNCTION__, port->number);
> >
> > - port->write_urb_busy = 0;
> > if (urb->status) {
> > dbg("%s - non
On Thu, Mar 29, 2007 at 02:25:34PM +0200, Oliver Neukum wrote:
> @@ -332,12 +330,12 @@
>
> dbg("%s - port %d", __FUNCTION__, port->number);
>
> - port->write_urb_busy = 0;
> if (urb->status) {
> dbg("%s - nonzero write bulk status received: %d",
> __FUNCTION__, ur
Hi,
as this driver has a certain example function, I've gone through it with
a fine comb. Here are the bugs with extensive description.
- conformance to coding style
- an URB's status must be read before it is declared non busy
otherwise the URB may have been submitted again and you are
reading a
On Wed, 20 Jul 2005, Hoang Tran wrote:
> *ISSUE*
>
> Wireless WAN PC Card modem devices such as the Novatel Merlin V620/S620
> and Kyocera KPC650 on a 1xEV-DO network experience a stalled data
> connection due to high data rates when operated on Linux kernel 2.4.x
> and 2.6.x. This issue does
Am Mittwoch, 20. Juli 2005 22:53 schrieb Hoang Tran:
> The affected modems are PCMCIA cards that use a USB host controller
> interface to expose a serial device to the Linux operating system. The
> generic usbserial driver can be used to talk to these devices as if they
> were serial modems.
>
*ISSUE*
Wireless WAN PC Card modem devices such as the Novatel Merlin V620/S620
and Kyocera KPC650 on a 1xEV-DO network experience a stalled data
connection due to high data rates when operated on Linux kernel 2.4.x
and 2.6.x. This issue does not occur when the cards are connected at
1xRTT da
36 matches
Mail list logo
