On Sun, Jan 13, 2002 at 07:27:06PM -0800, David Brownell wrote:
> Simpler to just have completion handlers explicitly put urbs on
> lists when they're available for reuse.
In thinking more about this today, and looking at the code a bunch, I
now agree with this. I think I'll play around with the
On Mon, Jan 14, 2002 at 12:27:26PM +0800, Richard CHAN Shih-Ping wrote:
> If usb/ is not correct on sf.net where is the correct location
> of the latest CVS code for linux-usb?
>
> Is there a branch to distinguish 2.4/2.5 stuff?
Please see my previous message about this:
http://marc.the
If usb/ is not correct on sf.net where is the correct location
of the latest CVS code for linux-usb?
Is there a branch to distinguish 2.4/2.5 stuff?
Thanks
Richard Chan
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://li
Hello,
I recently recieved a Diamond Data USB CD-RW of my friend hopefully to keep
but i can't seem to get it to work under linux.
Log INFO:
nitializing USB Mass Storage driver...
usb.c: registered new driver usb-storage
scsi1 : SCSI emulation for USB Mass Storage devices
Vendor: H45 Tech M
> > No HCD could resolve that race, any more than other
> > parts of usbcore could, since it happens after the HCD
> > has given up ownership of the URB.
> >
> > >(or the completion handler could)
> >
> > ONLY completion handlers can do that. HCDs can't, as I
> > just explained above.
>
> O
On Sun, Jan 13, 2002 at 10:24:55AM -0800, Greg KH wrote:
> On Sun, Jan 13, 2002 at 12:58:45PM +0100, Oliver Neukum wrote:
> > 2) skel_write checks for -EINPROGRESS. This is a race.
>
> Yes, but it's a race that _so_ many different drivers have that I don't
> consider it a driver problem. It sho
> > Usbcore can't mark an URB as reusable.
> > Only the HCD can do that without a race
>
> In that context, that's what I meant. From the perspective of
> all drivers except "hub" or HCDs, "usbcore" includes/hides
> all the HCDs. They don't see HCDs, they talk to usbcore
> (which talks to the HC
> > But let me correct myself: even that's not good enough. Drivers
> > always need to explicitly manage URB reuse from completion
> > handlers ... if they expect usbcore to mark URBs as reusable,
> > there's ALWAYS a race on SMPs between completion handler
> > finishing with that URB, and other
Hi,
the vicam driver did some things a V4L driver needs not do on open
and failed to manage the module usage count on probe/disconnect.
The patch applies to 2.4.2-pre11 and should fix the problems.
Regards
Oliver
--- vicam.c.alt Sun Jan 13 20:57:25 2002
+++ vicam.c S
> But let me correct myself: even that's not good enough. Drivers
> always need to explicitly manage URB reuse from completion
> handlers ... if they expect usbcore to mark URBs as reusable,
> there's ALWAYS a race on SMPs between completion handler
> finishing with that URB, and other driver c
> > I thought 2.4 already has a fix for this. The correct test here is
> > whether urb->dev is non-null, yes? Host controllers clear that
> > when they're really done with an URB.
>
> This is most subtle. IMHO too subtle.
It's a side effect of a fix for some related races, as I recall.
But
Title: SecondHome °áÁ¦ ¸ÞÀÏ
SecondHome
À¥È£½ºÆà Á¤º¸
¾È³çÇϽʴϱî?
(ÁÖ)¼¼ÄÁȨÀÔ´Ï´Ù.´ÙÀ½¿¡ ÇØ´ç µÇ´Â ºÐ²²¼´Â ²À Çѹø ÀÌ ±ÛÀ» Àоî ÁֽʽÿÀ.1.
ȨÆäÀÌÁö¸¦ ÀÌ¹Ì ¸¸µå¼ÌÀ¸³ª ¾ÆÁ÷ À¥È£½ºÆà ¾÷ü¸¦ °áÁ¤ÇÏÁö ¸øÇϽŠºÐ2. Ÿ¾÷ü¿¡¼
À¥È£½ºÆà ¼ºñ½º¸¦ ÀÌ¿ëÇÏÁö¸¸ ¼Óµµ³ª ¼ºñ½º µ
> I thought 2.4 already has a fix for this. The correct test here is
> whether urb->dev is non-null, yes? Host controllers clear that
> when they're really done with an URB.
>
> - Dave
This is most subtle. IMHO too subtle. Couldn't we have a clearly
named flag for that and kill EINPROGRESS ou
> > 2) skel_write checks for -EINPROGRESS. This is a race.
>
> Yes, but it's a race that _so_ many different drivers have that I don't
> consider it a driver problem. It should be fixed in the host controller
> and core, and not have every driver have to implement something like a
> "writing" fl
> > 2) skel_write checks for -EINPROGRESS. This is a race.
>
> Yes, but it's a race that _so_ many different drivers have that I don't
> consider it a driver problem. It should be fixed in the host controller
> and core, and not have every driver have to implement something like a
> "writing" fl
On Sunday 13 January 2002 19:20, Greg KH wrote:
> On Sun, Jan 13, 2002 at 07:00:12PM +0100, Oliver Neukum wrote:
> > Hi,
> >
> > I think there's a bug in the way the skeleton driver handles its usage
> > counting. The count is incremented on open() and decremented on
> > release(). However potenti
On Sun, Jan 13, 2002 at 07:11:02PM +0100, Oliver Neukum wrote:
> @@ -488,13 +495,18 @@
>
> dbg(__FUNCTION__ " - minor %d", dev->minor);
>
> - if ((urb->status != -ENOENT) &&
> - (urb->status != -ECONNRESET)) {
> + /* We check for errors and report them
> +unless
Hi,
the module usage count of that driver was broken. The included patch removes
it from open/release, as the chardev code does that already and removed from
probe/disconnect and an owner entry added to the usb_driver structure.
Regards
Oliver
--- auerswald.c.alt Su
On Sun, Jan 13, 2002 at 12:58:45PM +0100, Oliver Neukum wrote:
> Hi,
>
> 1) The check in the write callback will fail in the non error case.
Ah, good catch.
> 2) skel_write checks for -EINPROGRESS. This is a race.
Yes, but it's a race that _so_ many different drivers have that I don't
consider
On Sun, Jan 13, 2002 at 07:00:12PM +0100, Oliver Neukum wrote:
> Hi,
>
> I think there's a bug in the way the skeleton driver handles its usage
> counting. The count is incremented on open() and decremented on release().
> However potentially there can be more open()s than release()s resulting
--- usb-skeleton.c.alt Sun Jan 13 12:35:11 2002
+++ usb-skeleton.c Sun Jan 13 18:48:08 2002
@@ -112,6 +112,7 @@
struct tq_structtqueue; /* task queue for line
discipline waking up */
int open_count; /* number of times t
Hi,
I think there's a bug in the way the skeleton driver handles its usage
counting. The count is incremented on open() and decremented on release().
However potentially there can be more open()s than release()s resulting in an
ununloadable module.
I am afraid that this bug may be more widespr
On Sat, Jan 12, 2002 at 11:21:07PM -0800, Matthew Dharm wrote:
> Attached is a patch against 2.4.18-pre3. Greg, please send this upstream
> for both the 2.4 and 2.5 trees.
Looks good, I've added it to both trees.
thanks,
greg k-h
___
[EMAIL PROTECTE
On Sun, Jan 13, 2002 at 07:00:08AM -0800, Jimmie Mayfield wrote:
> Okay. Here's the amended patch. I've removed the sub-patch for usb/devices.c.
> Everything else is pretty much unchanged. Again, it's presented in two
> parts: the first part is diff'd against the 2.4.17 kernel tree, the secon
On Sat, Jan 12, 2002 at 10:24:15AM -0800, Greg KH wrote:
> On Sat, Jan 12, 2002 at 07:45:35AM -0800, Jimmie Mayfield wrote:
> >
> > Hi all. A few weeks ago I posted a similar patch for the Datafab and Jumpshot
> > drivers to LMKL but wanted to wait until my kernel dev box was back online
> > bef
Hi,
1) The check in the write callback will fail in the non error case.
2) skel_write checks for -EINPROGRESS. This is a race.
As we are dealing with an example I'd like to show how to use a waitqueue.
Your oppinions ?
3) Do you think I should add likely/unlikely to the error handling parts ?
Hi,
I was just inquiring whether anyone has a diamond data usb cd-rw
Regards,
Dylan
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Matthew Dharm <[EMAIL PROTECTED]> writes:
> This should finish off the 2.4.x work for me. After this, I'll be looking
> towards 2.5, unless something comes up to keep me with 2.4 issues.
What about this patch? It makes sure to clean up resources in two
error paths in storage_probe().
--- stora
28 matches
Mail list logo
