Fix function type warnings:
drivers/usb/media/pwc-if.c:1124: warning: control reaches end of non-void function
drivers/usb/media/pwc-if.c:1855: warning: assignment from incompatible pointer type
changelog: change pwc_video_release() from returning int to void,
as expected by
On Mon, 12 Jan 2004, David Brownell wrote:
> Of course the VT8235 also acts a bit quirky in some cases. It really
> didn't work at all reliably until I added a timer to watch for cases
> where it wasn't issuing some IRQs it should have. There _could_ be
> other problems there which need workaro
Axel Waggershauser wrote:
On Tue, 2004-01-13 at 03:14, David Brownell wrote:
Somewhere there's a patch floating around which makes UHCI wait
for those URBs to complete too. Lacking that patch, you need to
do what all robust USB drivers have always done: wait for all
their urbs to complete.
Sho
Bernd Porr wrote:
Re periodic transfers. I've tested 2.6.1 yesterday (yes, I've got comedi
finally working under 2.6). One interrupt transfer works fine. Two
transfers together not.
With which controller driver -- EHCI, OHCI, or UHCI? (If it's a full
speed device, you might need to use EHCI thro
OK, I'll have to redo this anyway. Do you agree that we need to use
GFP_NOIO in usb_ctrl_msg() due to usb_clear_halt() ?
It would seem so. Though someone pointed out that it ought
to take GFP flags as a parameter ... that's likely a bit too
invasive a change for just now.
- Dave
On Tue, 2004-01-13 at 03:14, David Brownell wrote:
> Somewhere there's a patch floating around which makes UHCI wait
> for those URBs to complete too. Lacking that patch, you need to
> do what all robust USB drivers have always done: wait for all
> their urbs to complete.
Should I wait with a ti
Axel Waggershauser wrote:
OK, I flooded hcd_endpoint_disable() and usb_hcd_giveback_urb() with
printks and found out that the first get called when I unplug the device
and it calls unlink1() with the correct urb then prints (with debugging
enabled) "uhci_hcd :00:07.2: shutdown urb cf02bb00 pipe
Axel Waggershauser wrote:
That recognized, I got the ingenious idea to check the return value of
the unlink call... It returns -EBUSY (-16). So it looks to me like the
controller driver sort of "got stuck" with this urb.
I generally encourage drivers to use async unlink if they're using
the async
On Mon, 2004-01-12 at 23:38, Alan Stern wrote:
> Try adding some printk's to the giveback_urb routine. That will at least
> tell you if the URB is getting stuck in the controller driver or somewhere
> else. You can also try adding some printk's to hcd_endpoint_disable()
> also in the hcd.c sou
Great, thanks.
-Original Message-
From: Greg KH [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 13 January 2004 4:00 AM
To: David Glance
Cc: [EMAIL PROTECTED]
Subject: Re: [PATCH] Missing Makefile line for Lego USB Tower
On Mon, Jan 12, 2004 at 05:11:02PM +0800, David Glance wrote:
> There is a
On Mon, 12 Jan 2004 22:04:16 +0100 (MET)
[EMAIL PROTECTED] wrote:
> > So everybody who does not want to know how integers are represented
> > on the current architecture writes
> > start = p[0] + (p[1] << 8) + (p[2] << 16) + (p[3] << 24);
> > And it just works.
>
> Really,
On Mon, 12 Jan 2004, Axel Waggershauser wrote:
> On Mon, 2004-01-12 at 19:43, Alan Stern wrote:
> >
> > Not really... Your completion routine should get called as soon as the
> > "USB disconnect" message appears in the syslog. Below you said that's
> > what happens on your other system; the que
On Mon, 12 Jan 2004 [EMAIL PROTECTED] wrote:
> [did you write be32 by mistake?]
Alas, yes! How embarrassing... :-(
Alan Stern
---
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management
On Mon, Jan 12, 2004 at 11:53:48AM -0800, Greg KH wrote:
> On Sun, Jan 11, 2004 at 03:29:44PM -0800, Matthew Dharm wrote:
> > This patch (from Alan Stern as157) fixes the non-READ/WRITE paths of the
> > sddr09.c driver to be compliant to the requirements of scatter-gather. It
> > also cleans up MO
[EMAIL PROTECTED] wrote:
Here's one more data point. I added a USB2.0 PCI card to the desktop
machine, and repeated the above steps. The "dd" command worked. I didn't
change the kernel or anything else (it has all USB controller types
built-in).
Interesting. The VT8235 EHCI is a later, and
On Mon, Jan 12, 2004 at 10:42:06PM +0100, Oliver Neukum wrote:
> > Alternatively, pass gfp_flags to usb_reset_device(), specifically to
> > distinguish the normal GFP_KERNEL case from the usb-storage GFP_NOIO:
> > two different kinds of "can sleep" context.
>
> That's an API change.
Which is ok t
On Mon, 2004-01-12 at 19:43, Alan Stern wrote:
> On Mon, 12 Jan 2004, Axel Waggershauser wrote:
> > ...so far so good...
>
> Not really... Your completion routine should get called as soon as the
> "USB disconnect" message appears in the syslog. Below you said that's
> what happens on your other
Am Montag, 12. Januar 2004 19:45 schrieb David Brownell:
> >[EMAIL PROTECTED], 2004-01-12 00:26:13+01:00, [EMAIL PROTECTED]
> > - avoid GFP_KERNEL in block IO path
> >
>
> What you show below is pretty remote form a block IO path...
> >>
> >>No, that'd be the "device vanishes a
Am Montag, 12. Januar 2004 20:31 schrieb [EMAIL PROTECTED]:
> | Let me tell you - I have programmed for twenty years without
> | knowing the meaning of little-endian and big-endian. Yes,
> | they had something to do with the order of bytes in an integer,
> | but there are many stran
Lukas Postupa wrote:
Unloading module ehci_hcd after usb storage hung up does not work;
rmmod "hangs".
Hmm, that symptom could be caused by a bug I noticed a while back.
I didn't have a chance to test the fix, but it compiles and runs
OK in "normal" operations.
See if this patch makes a difference
> So everybody who does not want to know how integers are represented
> on the current architecture writes
> start = p[0] + (p[1] << 8) + (p[2] << 16) + (p[3] << 24);
> And it just works.
Really, do you think your statement is better, clearer, or less
error-prone than t
On Llu, 2004-01-12 at 16:27, Alan Stern wrote:
> On Mon, 12 Jan 2004, Oliver Neukum wrote:
>
> > In 2.4 they all run in interrupt or thread context IIRC.
> > Problematic is the SCSI error handling thread. It can call usb_reset_device()
> > which calls down and does allocations.
> > Does that threa
No idea?
--
Gabucino
MPlayer Core Team
pgp0.pgp
Description: PGP signature
On Mon, 12 Jan 2004 [EMAIL PROTECTED] wrote:
> Let me give another example.
> When reading DOS-type partition tables, one encounters four bytes
> that give the start of a partition. Least significant byte first.
>
> So everybody who does not want to know how integers are represented
> on the curr
On Mon, Jan 12, 2004 at 05:11:02PM +0800, David Glance wrote:
> There is a missing line in drivers/usb/Makefile for legousbtower (I have
> attached it as well as pasted it inline):
Already fixed in my bk tree, and will be sent to Linus when he gets
back.
> diff -Nru linux-2.6.1/drivers/usb/Makefi
On Sun, Jan 11, 2004 at 03:35:27PM -0800, Matthew Dharm wrote:
> Yet another patch from Alan Stern to fix the non-READ/WRITE command paths
> for sg-compliance.
>
> Again, this driver doesn't handle MODE_SENSE_10 properly. A patch to fix
> that will follow shortly.
And I guess I'll wait on this o
On Sun, Jan 11, 2004 at 03:29:44PM -0800, Matthew Dharm wrote:
> This patch (from Alan Stern as157) fixes the non-READ/WRITE paths of the
> sddr09.c driver to be compliant to the requirements of scatter-gather. It
> also cleans up MODE_SENSE processing and reports errors a little better.
>
> This
| Let me tell you - I have programmed for twenty years without
| knowing the meaning of little-endian and big-endian. Yes,
| they had something to do with the order of bytes in an integer,
| but there are many strange architectures and mixed versions,
| and there is no need at a
On Mon, Jan 12, 2004 at 04:44:51PM +0530, mohanlal jangir wrote:
> > I hate to say this, but it sounds like you're in _way_ over your head
> > But, here are a few pointers:
> :-( I am sorry. Being a newbie, my questions might be silly.
>
> I have another question, how driver detects multiple
On Mon, 12 Jan 2004 20:01:17 +0100 (MET) [EMAIL PROTECTED] wrote:
| From: Alan Stern <[EMAIL PROTECTED]>
|
| > > - ptr[4] = MSB_of(info->pagesize>>16);
| > > - ptr[5] = LSB_of(info->pagesize>>16);
| > > - ptr[6] = MSB_of(info->pagesize&0xF
From: Alan Stern <[EMAIL PROTECTED]>
> > - ptr[4] = MSB_of(info->pagesize>>16);
> > - ptr[5] = LSB_of(info->pagesize>>16);
> > - ptr[6] = MSB_of(info->pagesize&0x);
> > - ptr[7] = LSB_of(info->pagesize&0x);
> >
On Mon, 12 Jan 2004, Axel Waggershauser wrote:
> Hi,
>
> I am still working on my driver for our proprietary usb-device. I get a
> kernel panic under the following condition:
>
> 1. usb_submit_urb // bulk in endpoint, urb with usb_complete_t set
> 2. wait_event_interruptible_timeout // about 3 s
[EMAIL PROTECTED], 2004-01-12 00:26:13+01:00, [EMAIL PROTECTED]
- avoid GFP_KERNEL in block IO path
What you show below is pretty remote form a block IO path...
No, that'd be the "device vanishes and re-enumerates" path, which
comes up as an entirely new device. i/o directed at the old one
will l
Benjamin Herrenschmidt wrote:
Hi !
I have very frequent errors of this type with the USB controller
found in the G5s. It's random, a given kernel will always die or
never die apparently, depending on how much flies you had in the
room when building it. Problem has been around since I had the G5
po
Hi,
I am still working on my driver for our proprietary usb-device. I get a
kernel panic under the following condition:
1. usb_submit_urb // bulk in endpoint, urb with usb_complete_t set
2. wait_event_interruptible_timeout // about 3 seconds timeout
3. unplug the device
-> I see "usb 1-2: USB
> I am wondering though if it might make sense to have these things externally
> allocated, that is, make outside requestors pass usb and usb_ctrlrequest
> as arguments.
That would mean exporting knowledge about how these functions work
and would thus make changing them much harder. They should t
> The controller is an EHCI/OHCI, Apple-branded but I suspect it's
> actually a NEC part.
> ohci_hcd 0001:02:0b.0: OHCI Unrecoverable Error, disabled
> drivers/usb/input/hid-core.c: ctrl urb status -2 received
> ohci_hcd 0001:02:0b.0: HC died; cleaning up
> usb 4-2: USB disconnect, address 2
> ohc
On Mon, 12 Jan 2004 10:53:03 -0500 (EST)
Alan Stern <[EMAIL PROTECTED]> wrote:
> > +++ b/drivers/usb/usb.c Mon Jan 12 00:27:37 2004
> > @@ -1198,7 +1198,7 @@
> > int usb_control_msg(struct usb_device *dev, unsigned int pipe, __u8 request, __u8
> > requesttype,
> > __u16
On Mon, 12 Jan 2004, Oliver Neukum wrote:
> In 2.4 they all run in interrupt or thread context IIRC.
> Problematic is the SCSI error handling thread. It can call usb_reset_device()
> which calls down and does allocations.
> Does that thread also do the PF_MEMALLOC trick?
In 2.4 it doesn't, which
Matthew Dharm wrote:
> Did the patch Alan posted make any difference?
>
> I've been getting several reports recently of problems with usb-storage and
> EHCI controllers. If you unload the ehci driver, your device will run at
> 1.1 speeds -- can you try that and see if it works?
>
> Matt
>
> On
On Sun, 11 Jan 2004, Matthew Dharm wrote:
> On Mon, Jan 12, 2004 at 02:44:10AM +0100, [EMAIL PROTECTED] wrote:
> > Hmm. I am not precisely happy with improvements like
> >
> > - ptr[4] = MSB_of(info->pagesize>>16);
> > - ptr[5] = LSB_of(info->pagesize>>16);
> > -
On Mon, 12 Jan 2004, Oliver Neukum wrote:
> diff -Nru a/drivers/usb/usb.c b/drivers/usb/usb.c
> --- a/drivers/usb/usb.c Mon Jan 12 00:27:37 2004
> +++ b/drivers/usb/usb.c Mon Jan 12 00:27:37 2004
> @@ -1198,7 +1198,7 @@
> int usb_control_msg(struct usb_device *dev, unsigned int pipe,
On Sat, 10 Jan 2004 [EMAIL PROTECTED] wrote:
> On Sat, 10 Jan 2004 [EMAIL PROTECTED] wrote:
>
> Here's one more data point. I added a USB2.0 PCI card to the desktop
> machine, and repeated the above steps. The "dd" command worked. I didn't
> change the kernel or anything else (it has all USB
On Mon, 12 Jan 2004, Stavros Markou wrote:
> Hi,
>
> By trying to deregister my driver from the usb subsystem I 've
> discovered that in usb_disconnect at drivers/usb/core/usb.c file :
>
> for (i = 0; i < USB_MAXCHILDREN; i++) {
>struct usb_device **child = dev->children + i;
>
Hi,
By trying to deregister my driver from the usb subsystem I 've
discovered that in usb_disconnect at drivers/usb/core/usb.c file :
for (i = 0; i < USB_MAXCHILDREN; i++) {
struct usb_device **child = dev->children + i;
if (*child)
usb_disconnect(child);
}
*child
> I hate to say this, but it sounds like you're in _way_ over your head
> But, here are a few pointers:
:-( I am sorry. Being a newbie, my questions might be silly.
I have another question, how driver detects multiple memory slots over
device (for CF, SM etc)?
> The glue with the SCSI layer
Alan Stern wrote:
...
On further thought I realized this would have less of an effect than
simply reducing max_sectors even more. Try decreasing it to 64, or even
32. You could go as low as 1 if you want, although I would be surprised
if anything below 8 would make any difference.
With my tests I
Dave,
re the power:
ok. I will. ;-)
Re periodic transfers. I've tested 2.6.1 yesterday (yes,
I've got comedi finally working under 2.6). One interrupt
transfer works fine. Two transfers together not.
I've seen that there's a patch around for periodic
transfers. Has it been applied to 2.6.1? If
There is a missing line in drivers/usb/Makefile for legousbtower (I have
attached it as well as pasted it inline):
diff -Nru linux-2.6.1/drivers/usb/Makefile
linux-2.6.1.patched/drivers/usb/Makefile
--- linux-2.6.1/drivers/usb/Makefile2004-01-09 15:00:03.0 +0800
+++ linux-2.6.1.patche
Am Montag, 12. Januar 2004 08:39 schrieb Matthew Dharm:
> On Sun, Jan 11, 2004 at 08:11:58PM -0800, David Brownell wrote:
> >
> > >>> Plus I'd
> > >>>argue PF_MEMALLOC is a better solution anyway.
> > >>
> > >>It certainly seems like a more comprehensive fix for that
> > >>particular class of pro
Am Montag, 12. Januar 2004 09:14 schrieben Sie:
> Oliver Neukum wrote:
> > Am Montag, 12. Januar 2004 05:08 schrieben Sie:
> >
> >>>[EMAIL PROTECTED], 2004-01-12 00:26:13+01:00, [EMAIL PROTECTED]
> >>> - avoid GFP_KERNEL in block IO path
> >>>
> >>
> >>What you show below is pretty remote form a
On Mon, Jan 12, 2004 at 02:44:10AM +0100, [EMAIL PROTECTED] wrote:
> Hmm. I am not precisely happy with improvements like
>
> - ptr[4] = MSB_of(info->pagesize>>16);
> - ptr[5] = LSB_of(info->pagesize>>16);
> - ptr[6] = MSB_of(info->pagesize&0x);
> -
On Sun, Jan 11, 2004 at 08:11:58PM -0800, David Brownell wrote:
>
> >>>Plus I'd
> >>>argue PF_MEMALLOC is a better solution anyway.
> >>
> >>It certainly seems like a more comprehensive fix for that
> >>particular class of problems! :)
> >
> >
> >Is it really more comprehensive? As I see it,
53 matches
Mail list logo
