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
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.
>
34 matches
Mail list logo
