On Sat, 7 Jun 2003, Martin Kittel wrote:
> Hi,
>
> while battling to get my Praktica DC1.3 digital camera to work I noticed
> what seems to be a problem in the usb-storage driver.
>
> I am using kernel 2.4.21-rc6 with the ACPI-patches applied. The camera
> uses transparent SCSI and bulk-only t
David:
Did you ever come to any decision about whether to let the root hub
status URB timer continue to run during a PM suspend as opposed to
restarting it during a PM resume? Just curious...
Alan Stern
---
This SF.net email is sponsored b
Please see the attached file.
Alan Stern wrote:
To sum up, DMA I/O buffers should be allocated separately from regular
data structures, using kmalloc(). Multiple buffers with non-overlapping
lifetimes can share a region like a C union. Multiple output buffers with
overlapping lifetimes can share a region like a C struct. On
Olaf Hering wrote:
-strncpy(info.driver, SHORT_DRIVER_DESC, ETHTOOL_BUSINFO_LEN);
+strncpy(info.driver, driver_name, ETHTOOL_BUSINFO_LEN);
strlcpy?
---
This SF.net email is sponsored by: Etnus, makers of Total
On Thu, Jun 05, 2003 at 08:59:25PM -0400, Pete Zaitcev wrote:
>
> It looks pretty clear.
>
> 1. The usbserial sets tty->low_latency by default.
>Thus, tty_flip_buffer_push falls through to flush_to_ldisc.
>
> 2. Likely, he PDA continuously sends crap, so when app opens a port (kudzu?),
>
On Fri, Jun 06, Greg KH wrote:
> On Fri, Jun 06, 2003 at 04:49:55PM +0200, Olaf Hering wrote:
> > Hi,
> >
> > ethtool -i ethX should return the driver name instead of a 'verbose'
> > string. Other tools rely on the output.
> > 2.5 might need a similar fix.
>
> Applied to my 2.4 tree (along with
Hi,
while battling to get my Praktica DC1.3 digital camera to work I noticed
what seems to be a problem in the usb-storage driver.
I am using kernel 2.4.21-rc6 with the ACPI-patches applied. The camera
uses transparent SCSI and bulk-only transport,
In function usb_stor_transfer_partial in driv
On Fri, Jun 06, Greg KH wrote:
> On Fri, Jun 06, 2003 at 04:49:55PM +0200, Olaf Hering wrote:
> > Hi,
> >
> > ethtool -i ethX should return the driver name instead of a 'verbose'
> > string. Other tools rely on the output.
> > 2.5 might need a similar fix.
>
> Applied to my 2.4 tree (along with
On Fri, Jun 06, 2003 at 04:49:55PM +0200, Olaf Hering wrote:
> Hi,
>
> ethtool -i ethX should return the driver name instead of a 'verbose'
> string. Other tools rely on the output.
> 2.5 might need a similar fix.
Applied to my 2.4 tree (along with the pegasus fix). Can you send me a
2.5 version
On Fri, Jun 06, 2003 at 07:53:16PM +0200, Oliver Neukum wrote:
> Hi,
>
> using gcc3.3 I no longer care about compiler warnings, but here's the
> obvious fix.
Applied, thanks.
greg k-h
---
This SF.net email is sponsored by: Etnus, makers of T
On Thu, Jun 05, 2003 at 11:23:51PM -0700, Joe Burks wrote:
> I noticed a version of vicam.c a few revisions ago had all the /proc fs
> writing removed because I was incorrectly using potentially tainted user
> space pointers. Here's a patch which I think fixes the pointer issue and
> restores t
On Fri, Jun 06, 2003 at 04:51:50PM -0400, Alan Stern wrote:
> This revised version of my earlier patch allocates the transfer buffers
> correctly.
Applied, thanks.
greg k-h
---
This SF.net email is sponsored by: Etnus, makers of TotalView, T
On Fri, Jun 06, 2003 at 04:53:47PM -0400, Alan Stern wrote:
> As requested by David Brownell, this patch removes the usb_ prefix from
> the static functions in hub.c. It also multiplies the timeouts for
> GET_STATUS and GET_DESCRIPTOR control transfers by USB_CTRL_GET_TIMEOUT.
Applied, thanks.
Am Freitag, 6. Juni 2003 22:51 schrieb Alan Stern:
> This revised version of my earlier patch allocates the transfer buffers
> correctly.
Since the hub driver is kind of exemplary, how about using
usb_buffer_alloc() ?
Regards
Oliver
-
I hear this from people who do CONFIG_HID_INPUT=m:
: USB HID v1.10 Mouse [Logitech USB Mouse] on usb1:3.0
See that funny colon in the begining? I think this should be
the patch, but I'm not sure how to reproduce and test.
-- Pete
--- linux-2.4.21-rc2-ac2/drivers/usb/hid.h 2003-04-24 11:42:
As requested by David Brownell, this patch removes the usb_ prefix from
the static functions in hub.c. It also multiplies the timeouts for
GET_STATUS and GET_DESCRIPTOR control transfers by USB_CTRL_GET_TIMEOUT.
Alan Stern
# This is a BitKeeper generated patch for the following project:
# Pro
This revised version of my earlier patch allocates the transfer buffers
correctly.
Alan Stern
# This is a BitKeeper generated patch for the following project:
# Project Name: greg k-h's linux 2.5 USB kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This
Your message
To: [EMAIL PROTECTED]
Subject: Re: Your application
Sent:Fri, 6 Jun 2003 08:08:17 -0700
did not reach the following recipient(s):
[EMAIL PROTECTED] on Fri, 6 Jun 2003 13:09:07 -0700
The recipient name is not recognized
The MTS-ID of the original message is
Alan Stern wrote:
I stand corrected. Is it true to say that (unless one uses
usb_buffer_alloc() or something similar) the recommendations in my earlier
post are accurate?
I didn't notice anything wrong, but then I skimmed
some of the details too.
- Dave
--
David:
In case it's not obvious, the first snapshot in Andras's tarball during a
problem period is the ehci-193837 directory.
Alan Stern
On Fri, 6 Jun 2003, Major A wrote:
> Done that -- I've attached a complete log and a tarball of the sysfs
> copies, each a directory with the time in its nam
On Fri, 6 Jun 2003, David Brownell wrote:
> Alan Stern wrote:
> >
> > The first restriction is that some architectures (which ones? -- I don't
> > know) are unable to perform DMA to addresses on the stack. So all I/O
> > buffers _must_ be allocated using kmalloc() or something similar; they
> >
On Fri, Jun 06, 2003, Duncan Sands <[EMAIL PROTECTED]> wrote:
> > It will only set SPD if short packets were ok.
>
> OK, I was confused: I thought SPD meant short packets
> get signalled as an error, but in fact it means they just
> get signalled (a good thing if you want short packets),
> right?
> It will only set SPD if short packets were ok.
OK, I was confused: I thought SPD meant short packets
get signalled as an error, but in fact it means they just
get signalled (a good thing if you want short packets),
right?
Sorry about the noise,
Duncan.
---
On Fri, Jun 06, 2003, Duncan Sands <[EMAIL PROTECTED]> wrote:
> diff -Nru a/drivers/usb/host/uhci-hcd.c b/drivers/usb/host/uhci-hcd.c
> --- a/drivers/usb/host/uhci-hcd.c Fri Jun 6 11:35:55 2003
> +++ b/drivers/usb/host/uhci-hcd.c Fri Jun 6 11:35:55 2003
> @@ -831,7 +831,7 @@
>*/
>
> Andras, if you notice distinct pauses, and this is on 2.5 (seems to be),
> then there's more information available. Basically, the sysfs files
> for EHCI (enabled with CONFIG_USB_DEBUG) may have relevant information.
Yes, it's 2.5.70-bk8.
> Make sure you're running a kernel with the kernel ha
> From: "Christopher Hoover" <[EMAIL PROTECTED]>
> Date: Fri, 6 Jun 2003 10:58:50 -0700
> > So all I/O buffers _must_ be allocated using kmalloc()
>
> Use GFP_DMA flag on the kmalloc() call, too, whenever possible.
> This will help avoid bounce buffering on some systems.
Wrong!!! Where did yo
Christopher Hoover wrote:
So all I/O buffers _must_ be allocated using kmalloc()
Use GFP_DMA flag on the kmalloc() call, too, whenever possible.
^
I'll disagree. As a rule, avoid that unless you know you need it.
In most cases, U
On Fri, Jun 06, Olaf Hering wrote:
> Hi,
>
> ethtool -i ethX should return the driver name instead of a 'verbose'
> string. Other tools rely on the output.
> 2.5 might need a similar fix.
>
> smirnow:~ # ethtool -i eth0
> driver: 3c59x
> version: LK1.1.16
> firmware-version:
> bus-info: 00:0a.
Alan Stern wrote:
The first restriction is that some architectures (which ones? -- I don't
know) are unable to perform DMA to addresses on the stack. So all I/O
buffers _must_ be allocated using kmalloc() or something similar; they
_cannot_ be automatic local variables. (What about static allocat
Strangely, I didn't see this on the list, looked poorly? Anyway,
here's the deal:
kernel BUG at sched.c:999!
EIP is at schedule [kernel] 0x2aa (2.4.20-13.9)
eax: 0001 ebx: c3ad8c74 ecx: c0349d64 edx: c0349d5c
esi: c0348000 edi: c3ad8c7c ebp: c0349d54 esp: c0349d44
ds: 0068 es: 00
> So all I/O buffers _must_ be allocated using kmalloc()
Use GFP_DMA flag on the kmalloc() call, too, whenever possible.
/* Flag - indicates that the buffer will be suitable for DMA. Ignored
on some
platforms, used as appropriate on others */
#define GFP_DMA __GFP_DMA
This will
Hi,
using gcc3.3 I no longer care about compiler warnings, but here's the
obvious fix.
Regards
Oliver
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
=
On Fri, 6 Jun 2003, Jeff Garzik wrote:
> Olaf Hering wrote:
> > Hi,
> >
> > ethtool -i ethX should return the driver name instead of a 'verbose'
> > string. Other tools rely on the output.
> > 2.5 might need a similar fix.
> >
> > smirnow:~ # ethtool -i eth0
> > driver: 3c59x
> > version: LK1.1.16
Hello,
I'm trying to get my digisette AR100 mp3 player to
work with linux and libusb and seem to have reached an
impasse so I'm looking for suggestions on how to
proceed. I had posted this message to the users
mailing list, where a response from Brad Hards
suggested that this list would be more a
> The second restriction is that some architectures don't maintain their
> cache coherently when DMA takes place. This means that input buffers
> _must_ be allocated in a region containing no data the CPU will touch
> during the input operation. For if the CPU touches data D lying in the
> same
Dzuy Nguyen wrote:
Hello,
that many other USB drivers don't handle multiple config i.e.
if(dev->descriptor.bNumConfiguration != 1) return NULL
A better solution would be to check whether the active
configuration is the one the driver knows how to handle;
assuming that it even matters. Some d
[from home]
> Sure looks like your storage device isn't responding, then.
The storage device is not ours - the host is.
I have run with:
* an Apacer (AP-MSCRU10)
* Sony digital camera
> You seem to think it's not a bug in your device; why?
The storage device works without problems with several
> [EMAIL PROTECTED] wrote:
>
> >>More details needed ... like, which HCD, does this repeat
> >>with different HCDs, and what do you mean by "outbound"?
> >>
> >
> >
> > Sorry. uhci. I haven't tried ohci.
>
> Then try "usb-uhci" to see if it behaves differently.
I am using usb-uhci (lazy f
On Fri, 6 Jun 2003 17:53:30 +0200 Daniele Bellucci <[EMAIL PROTECTED]> wrote:
| Is still needed to implement LP_ABORTOPEN + O_NONBLOCK in usb printer device drive?
| (look at usblp.c for TODO)
Not my call, but I would say Yes, so that the (parallel) char/lp.c
and usb/class/usblp.c behave in the s
> Sorry, I misspoke in my original message. I didn't mean
> usb_reset_config(); I was thinking about drivers that want to change to a
> different configuration during their probe(). How do you plan to
> accomodate that?
Let the perverts use a workqueue.
Regards
Oliver
Alan Stern wrote:
Sorry, I misspoke in my original message. I didn't mean
usb_reset_config(); I was thinking about drivers that want to change to a
different configuration during their probe(). How do you plan to
accomodate that?
As I said earlier on a different thread: by adding a new
"stru
Alan Stern wrote:
On Thu, 5 Jun 2003, David Brownell wrote:
Yes, something like usb_reset_config(dev) call is needed.
As well as converting code to use it, instead of the
current calls to usb_set_configuration() in drivers.
I want to echo Oliver's sentiment; this is a great patch.
Needed a few o
Is still needed to implement LP_ABORTOPEN + O_NONBLOCK in usb printer device drive?
(look at usblp.c for TODO)
-
PGP PKEY http://pgp
On Fri, 6 Jun 2003, David Brownell wrote:
> The way I see it, usb_reset_config(dev) should actually be
> easy ... but it'll necessarily have significant restrictions
> when used on devices with multiple interfaces. Basically,
> don't use it unless you're the only driver bound (or being
> bound) t
On Fri, 6 Jun 2003, Matthias Fuchs wrote:
> >>mount -t ext2 /dev/sda1 /mnt does not return
> > Have you tried mounting it read-only? Also, can you tell where the mount
> > process is hung? Try Alt-SysRq-T (and make sure you have enabled the
> > Magic SysRq key in your kernel).
>
> Since my sy
For the benefit of those who, like myself, still find the whole question
of cache-DMA interactions a bit confusing, here is a summary of what I've
learned. Implicit is that we are writing for a least-common-denominator
architecture. On the x86 none of these restrictions apply and most of
the cons
Olaf Hering wrote:
Hi,
ethtool -i ethX should return the driver name instead of a 'verbose'
string. Other tools rely on the output.
2.5 might need a similar fix.
smirnow:~ # ethtool -i eth0
driver: 3c59x
version: LK1.1.16
firmware-version:
bus-info: 00:0a.0
smirnow:~ # ethtool -i eth1
driver: Peg
Alan Stern wrote:
On Thu, 5 Jun 2003, David Brownell wrote:
Yes, something like usb_reset_config(dev) call is needed.
As well as converting code to use it, instead of the
current calls to usb_set_configuration() in drivers.
I want to echo Oliver's sentiment; this is a great patch.
Needed a few o
Hi,
ethtool -i ethX should return the driver name instead of a 'verbose'
string. Other tools rely on the output.
2.5 might need a similar fix.
smirnow:~ # ethtool -i eth0
driver: 3c59x
version: LK1.1.16
firmware-version:
bus-info: 00:0a.0
smirnow:~ # ethtool -i eth1
driver: Pegasus/Pegasus II US
David:
I'm going to have to ask for your help in tracing this any farther.
Here's a commented log extract from Andras:
On Thu, 5 Jun 2003, Major A wrote:
> Now, with the disk connected directly, I can see a bit more output
> though:
>
> > Jun 5 20:53:25 ventus kernel: usb-storage: Bulk comman
ChangeSet 1.1303.2.4, 2003/06/05 01:27:46-07:00, [EMAIL PROTECTED]
[PATCH] USB: usb_set_configuration in empeg.c
you should not drop errors.
- proper error detection during initialisation
drivers/usb/serial/empeg.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff -Nru a/
> > > I don't follow you. What's inefficient about this? It looks like the
> > > decision of whether or not to call dma_cache_wback_inv() has nothing to
> > > do with what other data is stored in the same memory block with the
> > > output buffer. And there's nothing that indicates
> > > dma_ca
ChangeSet 1.1303.2.2, 2003/06/05 01:27:20-07:00, [EMAIL PROTECTED]
[PATCH] USB: kerneldoc for gadget API
Here's the non-inlined doc for the gadget API.
Documentation/DocBook/Makefile|3
Documentation/DocBook/gadget.tmpl | 966 ++
2 files changed, 9
On Thu, 5 Jun 2003, David Brownell wrote:
> Oliver Neukum wrote:
> > Am Donnerstag, 5. Juni 2003 22:16 schrieb David Brownell:
> >>In short, usb_set_configuration() now does what
> >>it's supposed to do: it changes the device config,
> >>and all usbcore state depending on it.
> >
> >
> > Way co
Hi,
Here are some more USB changes and fixes for 2.5.70. These include a
documentaton update for the USB gadget drivers, and a bug fix for USB
keyboards that was caused by the previous patches sent to you.
Please pull from: bk://kernel.bkbits.net/gregkh/linux/linus-2.5
Patches will be posted t
ChangeSet 1.1303.2.3, 2003/06/05 01:27:33-07:00, [EMAIL PROTECTED]
[PATCH] USB: cut usb_set_config from hpusbscsi
this cuts out old cruft.
drivers/usb/image/hpusbscsi.c | 11 ---
1 files changed, 11 deletions(-)
diff -Nru a/drivers/usb/image/hpusbscsi.c b/drivers/usb/image/hpusbscs
ChangeSet 1.1303.2.1, 2003/06/05 01:12:30-07:00, [EMAIL PROTECTED]
[PATCH] USB: fix keyboard leds
> Ben, it looks like your patch broke something for USB keyboards, any
> idea?
Yep, my patch killed hid-input from scanning HID_OUTPUT_REPORT's. Fixed
with this patch for 2.5.70+bk. I'll send one fo
Am Donnerstag, 5. Juni 2003 22:16 schrieb David Brownell:
> This patch:
>
> - moves the config-specific sysfs updates out of
> usb_new_device() into usb_set_configuration(),
> where it belongs.
>
> - makes usb_set_configuration() get rid of sysfs
> state for the previous configurati
Hello,
I'm new to USB programming and I'm trying to get the usbvision driver to work
with my Haugepauge USB WinTV-FM card.
The trouble I'm running into is in usbvision_probe() function. I also notice
that many other USB drivers don't handle multiple config i.e.
if(dev->descriptor.bNumConfigur
On Thu, 5 Jun 2003, Oliver Neukum wrote:
> > > extern inline dma_addr_t pci_map_single(struct pci_dev *hwdev, void *ptr,
> > > size_t size, int direction)
> > > {
> > > if (direction == PCI_DMA_NONE)
> > > BUG();
> > >
> > > #ifndef CONFIG_COHERENT_IO
[EMAIL PROTECTED] wrote:
More details needed ... like, which HCD, does this repeat
with different HCDs, and what do you mean by "outbound"?
Sorry. uhci. I haven't tried ohci.
Then try "usb-uhci" to see if it behaves differently.
Outbound means from the host to the device, to endpoint 0, us
On Thu, 5 Jun 2003, Major A wrote:
> > Maybe the best thing to try would be to repeat that test, but with more
> > debugging output. Do you think you can insert
> >
> > printk(KERN_INFO "%s %d\n", __FUNCTION__, __LINE__);
> >
> > statements at various judicious places in the usb_physical_r
This patch:
- moves the config-specific sysfs updates out of
usb_new_device() into usb_set_configuration(),
where it belongs.
- makes usb_set_configuration() get rid of sysfs
state for the previous configuration, including
driver unbinding
- makes the bConfigurationValue device attr
On 5 Jun 2003 at 11:27, David Brownell wrote:
> [EMAIL PROTECTED] wrote:
> > Writing a device driver for a vendor interface. 2.4.20 kernel.
> > This device has only an interrupt in endpoint plus the control
> > endpoints.
> >
> > When I submit an outbound control urb, the data goes to the dev
Sign from
God