On Sat, Feb 02, 2002 at 11:47:02PM +0100, Oliver Neukum wrote:
> Hi,
>
> usbnet is allocating an URB in usbnet_start_xmit().
> usbnet_start_xmit() is called with a spinlock held.
> Thus the usbcore will call kmalloc() with GFP_KERNEL
> and and a spinlock held. Deadlock may result.
> I see no solu
On Sat, Feb 02, 2002 at 11:32:37PM +0100, Oliver Neukum wrote:
> Hi Greg,
>
> you use an atomic counter in usb_alloc_urb without initialising it.
> This works on x86, but is not prortable. Here's a patch that should fix it.
Good catch, sparc might not have worked properly. Patch applied.
thank
On Fri, Feb 01, 2002 at 06:08:46PM -0800, Petko Manolov wrote:
> Hi Greg,
>
> this is syncing 2.4 pegasus driver with recent 2.5
> changes. Since it is fixing a few bugs i hope the
> patch will be applied in 2.4 tree as well.
>
> I tested it on my system and it seems ok.
>
>
>
On Sat, Feb 02, 2002 at 12:33:51PM +0100, Oliver Neukum wrote:
> Hi,
>
> this patch removes an SMP deadlock, removes an nfs deadlock, fixes a
> mem leak should the firmware not be loaded and does a few cleanups.
> I'll do more changes after Brad has sent me the device.
> It applies to 2.5.3. I'll
I have a (Canadian) hauppauge wintv-fm 0573 4d30
As a test to get it working I replaced the usbvision table entry
for the German version, though all the entries seem to have the
same setup values.
In usbvision_probe I had to comment out
if(dev->descriptor.bNumConfigurations != 1)
return NULL;
On Sunday 03 February 2002 00:51, Oliver Neukum wrote:
> Hi,
>
> catc seems to suffer from the same race as pegasus.
> timeout unlinks asynchronously, but xmit does not check.
Sorry. The upper layer protects you. Please disregard.
Regards
Oliver
_
> pegasus_tx_timeout() unlinks the tx_urb asynchronously, as it must.
> However pegasus_start_xmit() uses this urb without checking
> for the unlinking having been done.
The upper layer will not send any packets downstream (i.e.
call pegasus_start_xmit()) because netif_wake_queue() is called
onl
Hi,
catc seems to suffer from the same race as pegasus.
timeout unlinks asynchronously, but xmit does not check.
Regards
Oliver
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lis
On Sunday 03 February 2002 00:10, David Brownell wrote:
> > I see no solution but to alter the API by adding a
> > gfp parameter to usb_alloc_urb.
> >
> > Greg, please decide.
>
> Actually I don't recall any pushback on that, except that
> for backwards compatibility it should probably have a
> ne
> I see no solution but to alter the API by adding a
> gfp parameter to usb_alloc_urb.
>
> Greg, please decide.
Actually I don't recall any pushback on that, except that
for backwards compatibility it should probably have a
new name. (Unless we want to say that 2.5 device drivers
can't be sourc
Hi,
I cannot reach him. Could someone forward him my message
concerning his driver ?
Regards
Oliver
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Hi,
this cleans up module usage counting for stv680
Regards
Oliver
--- stv680.c.altSun Feb 3 00:01:51 2002
+++ stv680.cSun Feb 3 00:03:57 2002
@@ -1155,7 +1155,6 @@
int err = 0;
/* we are called with the BKL held */
- MOD_INC_USE_COU
Hi,
usbnet is allocating an URB in usbnet_start_xmit().
usbnet_start_xmit() is called with a spinlock held.
Thus the usbcore will call kmalloc() with GFP_KERNEL
and and a spinlock held. Deadlock may result.
I see no solution but to alter the API by adding a
gfp parameter to usb_alloc_urb.
Greg,
Hi Greg,
you use an atomic counter in usb_alloc_urb without initialising it.
This works on x86, but is not prortable. Here's a patch that should fix it.
Regards
Oliver
--- drivers/usb/usb.c.alt Sat Feb 2 23:18:47 2002
+++ drivers/usb/usb.c Sat Feb 2 23:27:32 20
The string you are asking about is the SCSI-II CCS definition of that
particular set of key, ASC, and ASCQ values returned by the REQUEST_SENSE
command.
Generally, a device reports that as it's spinning up.
Matt
On Sat, Feb 02, 2002 at 11:42:00AM -0200, Raphael Derosso Pereira - DephiNit wrote:
Howdy,
I'm looking for Thomas Kreiling (guessing that he reads this list). He's
hacked usb/storage/shuttle_usbat.c to make it work read-only to a Microtech
ZiO CF Reader (the email he gives in the comments get's bounced).
I'm about to try (!!) and understand it and make it work rw, but consideri
On Saturday 02 February 2002 21:46, David Brownell wrote:
> > It would seem to me that you are throwing away wake ups
> > needlessly.
>
> If so, it's in a highly non-critical path. Why should anyone care
> if the driver takes an extra couple of milliseconds to close?
Seen that way, why not. The
Hi,
pegasus_tx_timeout() unlinks the tx_urb asynchronously, as it must.
However pegasus_start_xmit() uses this urb without checking
for the unlinking having been done.
This looks suspicious, is there a hidden assumption that the device
will be reset before another packet is sent ?
Regar
> It would seem to me that you are throwing away wake ups
> needlessly.
If so, it's in a highly non-critical path. Why should anyone care
if the driver takes an extra couple of milliseconds to close?
- Dave
___
[EMAIL PROTECTED]
To unsubscribe, us
> > set_current_state (TASK_UNINTERRUPTIBLE);
> > schedule_timeout (UNLINK_TIMEOUT_JIFFIES);
> > dbg ("waited for %d urb completions", temp);
> >
> > looks suspicious. You are setting the task's state just before you
> > schedule.
>
> Hmm, I seem to
> > > You have a PCI device that is the USB controller. You create a child of
> > > that represents the USB bus. Then, devices are added as children of that.
> > >
> > > Logically, couldn't you skip that extra layer of indirection and make USB
> > > devices children of the USB controller? Or, d
> > And there can be a lot more such files. Though that 4KB limit
> > may become an issue at some point.
>
> I doubt it, we are talking one value per file here. I can't see any USB
> driver wanting to go over 4Kb for 1 value (and if it does, I'll change
> it :)
I could see descriptors getting
> this patch is quite trivial.
Patch looks OK (just sets the new usb_driver "owner" field).
Greg, feel free to integrate.
> set_current_state (TASK_UNINTERRUPTIBLE);
> schedule_timeout (UNLINK_TIMEOUT_JIFFIES);
> dbg ("waited for %d urb completion
> My concern is what (if any) assumptions a driver might take about the
> order in which the corresponding completion callbacks are invoked. Would
> it be valid to rely on a fifo-like operation, i.e. the urb which was
> submitted first get completed first?
For your case (c/b URBs queued to one e
Hi,
Take a look at this debug, taken from the initialization of a HP CD-Writer+
8290 (v.1.3c):
Feb 2 10:55:10 mushroom kernel: usb-storage: Command TEST_UNIT_READY (6
bytes)
Feb 2 10:55:10 mushroom kernel: usb-storage: 00 00 00 00 00 00 73 c5 dc be
57 c2
Feb 2 10:55:10 mushroom kernel: usb
Hi,
this patch removes an SMP deadlock, removes an nfs deadlock, fixes a
mem leak should the firmware not be loaded and does a few cleanups.
I'll do more changes after Brad has sent me the device.
It applies to 2.5.3. I'll do a patch against 2.4 as soon as I've established
a 2.4 tree on this box,
Hi,
I'm just wondering about what would be considered a sane assumption
wrt. completion call ordering. I do not care for completion callbacks for
different endpoints - if there were ordering requirements, it would IMHO
be the drivers' job to implement whatever is needed. But I do care for
compl
27 matches
Mail list logo
