Hello,
On Saturday 03 November 2001 23:58, Pete Zaitcev wrote:
> > From: "Nemosoft Unv." <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: [linux-usb-devel] Alert: Red Hat 7.2 has buggy 2.4.9 USB-UHCI
> > driver. Date: Sat, 3 Nov 2001 23:47:59 +0100
> >
> > Today I got the first bug repo
On Sat, 3 Nov 2001, Nemosoft Unv. wrote:
> Hello,
>
> Today I got the first bug report from a user that had upgraded to Red Hat
> 7.2. The kenel shipped with RH 7.2 is 2.4.9, which unfortunately contains
> the buggy usb-uhci driver (you know: solid hang when using USB and isoc
> devices like
> From: "Nemosoft Unv." <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: [linux-usb-devel] Alert: Red Hat 7.2 has buggy 2.4.9 USB-UHCI driver.
> Date: Sat, 3 Nov 2001 23:47:59 +0100
> Today I got the first bug report from a user that had upgraded to Red Hat
> 7.2. The kenel shipped with RH
Hello,
Today I got the first bug report from a user that had upgraded to Red Hat
7.2. The kenel shipped with RH 7.2 is 2.4.9, which unfortunately contains
the buggy usb-uhci driver (you know: solid hang when using USB and isoc
devices like webcams or speakers).
So expect a lot of 'I upgraded
Two questions:
(1) Is it ok to submit an urb during an interrupt context
(actually, URB completion handler)?
I guess the answer is "yes" since it is done on line 576 of
pegasus.c.
(2) Why does the pegasus driver bother to submit a new
URB during completion (in fact it resubmits the same URB
it
Hello,
I have a question regarding the right design of
an USB character driver:
at open(), the device descriptor is allocated from the heap.
Inside the descriptor is the mutex to protect against user space
race conditions. The pointer to the device descriptor is stored
in file->private_data.
a
Am Samstag 03 November 2001 12:40 schrieb Thomas Sailer:
> Oliver Neukum wrote:
> > A look through usbdevfs shows that there's no locking.
>
> ???
>
> usbdevfs has devsem to prevent these races (it's a rwsem,
> reading used to access the device, disconnect requires taking
> the semaphore for writi
On Saturday 03 November 2001 3:59 pm, Thomas Sailer wrote:
> Duncan Sands wrote:
> > races with disconnect. In usb.c there is the usb_disconnect
> > function which first calls driver->disconnect, then only later
>
> Ah ok, you're concerned about the driver ioctl getting called
> via usbdevfs. Th
Duncan Sands wrote:
> races with disconnect. In usb.c there is the usb_disconnect
> function which first calls driver->disconnect, then only later
Ah ok, you're concerned about the driver ioctl getting called
via usbdevfs. The proc_ioctl interface wasn't added by me,
so I don't know the origina
On Saturday 03 November 2001 12:40 pm, Thomas Sailer wrote:
> Oliver Neukum wrote:
> > A look through usbdevfs shows that there's no locking.
>
> ???
>
> usbdevfs has devsem to prevent these races (it's a rwsem,
> reading used to access the device, disconnect requires taking
> the semaphore for wr
Oliver Neukum wrote:
> A look through usbdevfs shows that there's no locking.
???
usbdevfs has devsem to prevent these races (it's a rwsem,
reading used to access the device, disconnect requires taking
the semaphore for writing, thus locking out readers).
That's the way USB locking works. The
11 matches
Mail list logo
