Re: [linux-usb-devel] kernel panic in 2.5.65

2003-03-20 Thread David Brownell

I get the following log each time I disconnect a hub (had to type it
from the display, so its not complete). I do not have the problem with
2.5.64.


I see something like this also when unloading a host controller driver.
I had one of those, then it went away when I removed that check
of yours that prevents disconnect() callbacks from cleaning up
using usb_unlink_urb() calls!  That is, a 6b6b6b6b kind of oops like
you described below -- odd.
However, there's another one I'm seeing too.  It seems to happen
when usb-storage hits some kind of trouble, and a couple times
I've seen usb_reset_device() calls on the stack.  That one could
be partly because of some other patches though.
- Dave


Do you have CONFIG_DEBUG_SLAB and CONFIG_KALLSYMS enabled?  To me it
looks like we are submitting a urb that has already been freed, and we
oops in usb_submit_urb() as we are passed a pointer of 6b6b6b6b.






---
This SF.net email is sponsored by: Tablet PC.  
Does your code think in ink? You could win a Tablet PC. 
Get a free Tablet PC hat just for playing. What are you waiting for? 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


whiteheat - Re: [linux-usb-devel] usb-serial driver audit

2003-03-20 Thread Oliver Neukum

>   whiteheat.c

whiteheat_attach:

usb_clear_halt(serial->dev, pipe);
ret = usb_bulk_msg (serial->dev, pipe, command, sizeof(command), &alen, 
COMMAND_TIMEOUT);
DMA on stack

whiteheat_write:

result = usb_submit_urb(urb, GFP_ATOMIC);
no need for ATOMIC here

static void command_port_read_callback:
spin_lock_irqsave(&command_info->lock, flags);
no need to save flags, you are in irq context

static int firm_send_command:
retval = usb_submit_urb (command_port->write_urb, GFP_KERNEL);
illegal while holding a spinlock, logic looks fishy

static int start_command_port:
spin_lock_irqsave(&command_info->lock, flags);
if (!command_info->port_running) {
/* Work around HCD bugs */
usb_clear_halt(serial->dev, command_port->read_urb->pipe);

command_port->read_urb->dev = serial->dev;
retval = usb_submit_urb(command_port->read_urb, GFP_KERNEL);
major brokenness -
A - using usb_clear_halt with a spinlock held is absolutely illegal
B - if you have to submit an URB with a spinlock held, you _must_ use GFP_ATOMIC

static int start_port_read:
retval = usb_submit_urb(urb, GFP_KERNEL);
use GFP_ATOMIC

static void stop_command_port (and other places):
spin_lock_irqsave(&command_info->lock, flags);
command_info->port_running--;
if (!command_info->port_running)
usb_unlink_urb(command_port->read_urb);
you must use asynchrnous unlink here.

HTH
Oliver




---
This SF.net email is sponsored by: Tablet PC.  
Does your code think in ink? You could win a Tablet PC. 
Get a free Tablet PC hat just for playing. What are you waiting for? 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


[linux-usb-devel] usb-serial driver audit

2003-03-20 Thread Greg KH
Hi all,

Since the big usb-serial semaphore has been gone for the usb-serial
drivers for a while now in 2.5, I've been trying to audit all of the
drivers to make sure that they are still SMP safe.  I think I've either
fixed up, or validated that there are no problems in the following
drivers:
belkin_sa.c
digi_acceleport.c
empeg.c
ir-usb.c
kl5kusb105.c
mct_u232.c
omninet.c
pl2303.c
safe_serial.c
visor.c

I'll still work on the following drivers:
io_edgeport.c
io_ti.c
keyspan.c
keyspan_pda.c

But that still leaves a number of drivers left.  If the
owners/maintainers of the following drivers can check to make sure their
locking is safe, I would really appreciate it:
cyberjack.c
ftdi_sio.c
ipaq.c
kobil_sct.c
whiteheat.c

The last one, whiteheat.c does look like it has locking, but it's wrong,
and will spit out nasty messages to the kernel log when you run it with
CONFIG_DEBUG_SPINLOCK_SLEEP enabled.

Thanks,

greg k-h


---
This SF.net email is sponsored by: Tablet PC.  
Does your code think in ink? You could win a Tablet PC. 
Get a free Tablet PC hat just for playing. What are you waiting for? 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


Re: [linux-usb-devel] Belkin Compact Flash card reader

2003-03-20 Thread Matthew Dharm
On Thu, Mar 20, 2003 at 05:01:46PM -0500, Alan Stern wrote:
> On Thu, 20 Mar 2003, Dave Turner wrote:
> 
> > On Thu, 20 Mar 2003 at 10:47am, Alan Stern wrote:
> > 
> > > Can you post an extract from the kernel log under 2.4.21-rc5 with
> > > usb-storage debugging turned on?
> > 
> > Sure thing.
> > 
> > Linux version 2.4.21-pre5 ([EMAIL PROTECTED]) (gcc version 2.95.3 20010315
> > (release)) #1 Wed Mar 19 16:17:04 GMT 2003
> 
> Believe it or not, this is failing in a very different and much more 
> interesting way than it did under the earlier version of Linux you posted 
> before.
> 
> [Matt: Do you have any idea why (in the part of the log I snipped) the 
> SCSI layer issues READ-CAPACITY three times in a row when each time the
> sense code indicates medium not present?  Once ought to be enough.  Has
> this been changed in 2.5?]

No idea why this was implemented that way, but it is.  AFAIK, it has not
been changed.

> After inserting a 1Gb Microdrive into the card reader and attempting to 
> mount it (following a successful MODE-SENSE):
> 
> > usb-storage: queuecommand() called
> > usb-storage: *** thread awakened.
> > usb-storage: Command READ_10 (10 bytes)
> > usb-storage: 28 00 00 00 00 00 00 00 08 00 9b cf
> > usb-storage: Bulk command S 0x43425355 T 0x14 Trg 0 LUN 0 L 4096 F 128 CL 10
> > usb-storage: Bulk command transfer result=0
> > usb-storage: usb_stor_transfer_partial(): xfer 4096 bytes
> > usb-storage: command_abort() called
> > usb-storage: usb_stor_bulk_msg() returned -104 xferred 0/4096
> 
> So at this point the urb's completion routine has been called.  -104 is
> -ECONNRESET, indicating the urb was unlinked by the abort routine.

That timeout should be about 20 seconds or so.

> > usb-storage: usb_stor_transfer_partial(): transfer aborted
> > usb-storage: Bulk data transfer result 0x3
> > usb-storage: -- transport indicates command was aborted
> > usb-storage: scsi command aborted
> > usb-storage: *** thread sleeping.
> > usb-storage: queuecommand() called
> > usb-storage: *** thread awakened.
> > usb-storage: Command TEST_UNIT_READY (6 bytes)
> > usb-storage: 00 00 00 00 00 00 00 00 08 00 9b cf
> > usb-storage: Bulk command S 0x43425355 T 0x14 Trg 0 LUN 0 L 0 F 0 CL 6
> > uhci.c: uhci_submit_urb: urb not available to submit (status = -104)
> 
> What's that?!  Any ideas from anybody?

I've never seen it before.  I'm wondering if the URB didn't get aborted
properly.

Matt

-- 
Matthew Dharm  Home: [EMAIL PROTECTED] 
Maintainer, Linux USB Mass Storage Driver

I think the problem is there's a nut loose on your keyboard.
-- Greg to Customer
User Friendly, 1/5/1999 


pgp0.pgp
Description: PGP signature


[linux-usb-devel] Re: [PATCH] USB changes for 2.5.65

2003-03-20 Thread Greg KH
ChangeSet 1.1143.1.3, 2003/03/19 11:23:08-08:00, [EMAIL PROTECTED]

[PATCH] USB speedtouch: get rid of atmsar

There are really only two patches: add atmsar stuff into
speedtouch.c; and update the Makefile.  The other changes
are: delete atmsar.c and atmsar.h, rename speedtouch.c to
speedtch.c.


 drivers/usb/misc/atmsar.c |  380 --
 drivers/usb/misc/atmsar.h |   87 --
 drivers/usb/misc/speedtouch.c | 1216 -
 drivers/usb/misc/Makefile |2 
 drivers/usb/misc/speedtch.c   | 1514 ++
 5 files changed, 1514 insertions(+), 1685 deletions(-)


diff -Nru a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile
--- a/drivers/usb/misc/Makefile Thu Mar 20 15:04:07 2003
+++ b/drivers/usb/misc/Makefile Thu Mar 20 15:04:07 2003
@@ -12,5 +12,3 @@
 obj-$(CONFIG_USB_TEST) += usbtest.o
 obj-$(CONFIG_USB_TIGL) += tiglusb.o
 obj-$(CONFIG_USB_USS720)   += uss720.o
-
-speedtch-objs := speedtouch.o atmsar.o
diff -Nru a/drivers/usb/misc/atmsar.c b/drivers/usb/misc/atmsar.c
--- a/drivers/usb/misc/atmsar.c Thu Mar 20 15:04:07 2003
+++ /dev/null   Wed Dec 31 16:00:00 1969
@@ -1,380 +0,0 @@
-/**
- *  atmsar.c  --  General SAR library for ATM devices.
- *
- *  Copyright (C) 2000, Johan Verrept
- *
- *  This program is free software; you can redistribute it and/or modify it
- *  under the terms of the GNU General Public License as published by the Free
- *  Software Foundation; either version 2 of the License, or (at your option)
- *  any later version.
- *
- *  This program is distributed in the hope that it will be useful, but WITHOUT
- *  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- *  FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- *  more details.
- *
- *  You should have received a copy of the GNU General Public License along with
- *  this program; if not, write to the Free Software Foundation, Inc., 59
- *  Temple Place - Suite 330, Boston, MA  02111-1307, USA.
- *
- **/
-
-/*
- *  Written by Johan Verrept ([EMAIL PROTECTED])
- *
- *  0.2.4A:- Version for inclusion in 2.5 series kernel
- * - Modifications by Richard Purdie ([EMAIL PROTECTED])
- * - replaced "sarlib" with "atmsar"
- * - adaptations for inclusion in kernel tree
- *
- *  0.2.4: - Fixed wrong buffer overrun check in atmsar_decode_rawcell()
- * reported by Stephen Robinson <[EMAIL PROTECTED]>
- * - Fixed bug when input skb did not contain a multple of 52/53
- * bytes (would happen when the speedtouch device resynced)
- * also reported by Stephen Robinson <[EMAIL PROTECTED]>
- *
- *  0.2.3: - Fixed wrong allocation size. caused memory corruption in some
- * cases. Reported by Vladimir Dergachev <[EMAIL PROTECTED]>
- * - Added some comments
- *
- *  0.2.2: - Fixed CRCASM
- * patch from Linus Flannagan <[EMAIL PROTECTED]>
- * - Fixed problem when user did NOT use the
- * ATMSAR_USE_53BYTE_CELL flag.
- * reported by  Piers Scannell <[EMAIL PROTECTED]>
- * - No more in-buffer rewriting for cloned buffers.
- * - Removed the PII specific CFLAGS in the Makefile.
- *
- *  0.2.1: - removed dependency on alloc_tx. tis presented problems when
- * using this with the br2684 code.
- *
- *  0.2:   - added AAL0 reassembly
- * - added alloc_tx support
- * - replaced alloc_skb in decode functions to dev_alloc_skb to
- * allow calling from interrupt
- * - fixed embarassing AAL5 bug. I was setting the pti bit in the
- * wrong byte...
- * - fixed another emabrassing bug.. picked up the wrong crc type
- * and forgot to invert the crc result...
- * - fixed AAL5 length calculations.
- * - removed automatic skb freeing from encode functions.
- * This caused problems because i did kfree_skb it, while it
- * needed to be popped. I cannot determine though whether it
- * needs to be popped or not. Figu'e it out ye'self ;-)
- * - added mru field. This is the buffersize. atmsar_decode_aal0
- * will use when it allocates a receive buffer. A stop gap for
- * real buffer management.
- *
- *  0.1:   - library created.
- * - only contains AAL5, AAL0 can be easily added. (actually, only
- * AAL0 reassembly is missing)
- *
- */
-
-#include 
-#include "atmsar.h"
-
-/***
- **
- **  things to remember
- **
- ***/
-
-/*
-  1. the atmsar_vcc_data list pointer MUST be initialized to NULL
-  2. atmsar_encode_rawcell will drop incomplete cel

[linux-usb-devel] Re: [PATCH] USB changes for 2.5.65

2003-03-20 Thread Greg KH
ChangeSet 1.1143.1.9, 2003/03/20 14:00:11-08:00, [EMAIL PROTECTED]

[PATCH] USB: Update for usb-skeleton

My update for usb-skeleton seems to have gotten lost in the shuffle, so
here it is again -- all wrapped up in one nice little patch.  It's been
tested by three different people and passed with flying colors.  Please
apply.


 drivers/usb/usb-skeleton.c |  229 +
 1 files changed, 148 insertions(+), 81 deletions(-)


diff -Nru a/drivers/usb/usb-skeleton.c b/drivers/usb/usb-skeleton.c
--- a/drivers/usb/usb-skeleton.cThu Mar 20 15:03:18 2003
+++ b/drivers/usb/usb-skeleton.cThu Mar 20 15:03:18 2003
@@ -1,5 +1,5 @@
 /*
- * USB Skeleton driver - 0.9
+ * USB Skeleton driver - 1.0
  *
  * Copyright (c) 2001-2002 Greg Kroah-Hartman ([EMAIL PROTECTED])
  *
@@ -12,14 +12,17 @@
  * USB driver quickly.  The design of it is based on the usb-serial and
  * dc2xx drivers.
  *
- * Thanks to Oliver Neukum and David Brownell for their help in debugging
- * this driver.
+ * Thanks to Oliver Neukum, David Brownell, and Alan Stern for their help
+ * in debugging this driver.
  *
- * TODO:
- * - fix urb->status race condition in write sequence
  *
  * History:
  *
+ * 2003-02-25 - 1.0 - fix races involving urb->status, unlink_urb(), and
+ * disconnect.  Fix transfer amount in read().  Use
+ * macros instead of magic numbers in probe().  Change
+ * size variables to size_t.  Show how to eliminate
+ * DMA bounce buffer.
  * 2002_12_12 - 0.9 - compile fixes and got rid of fixed minor array.
  * 2002_09_26 - 0.8 - changes due to USB core conversion to struct device
  * driver.
@@ -33,7 +36,7 @@
  * 2001_05_29 - 0.3 - more bug fixes based on review from linux-usb-devel
  * 2001_05_24 - 0.2 - bug fixes based on review from linux-usb-devel people
  * 2001_05_01 - 0.1 - first version
- * 
+ *
  */
 
 #include 
@@ -42,8 +45,8 @@
 #include 
 #include 
 #include 
-#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -60,7 +63,7 @@
 
 
 /* Version Information */
-#define DRIVER_VERSION "v0.4"
+#define DRIVER_VERSION "v1.0"
 #define DRIVER_AUTHOR "Greg Kroah-Hartman, [EMAIL PROTECTED]"
 #define DRIVER_DESC "USB Skeleton Driver"
 
@@ -101,15 +104,16 @@
charnum_bulk_out;   /* number of bulk out 
endpoints we have */
 
unsigned char * bulk_in_buffer; /* the buffer to receive data 
*/
-   int bulk_in_size;   /* the size of the receive 
buffer */
+   size_t  bulk_in_size;   /* the size of the receive 
buffer */
__u8bulk_in_endpointAddr;   /* the address of the bulk in 
endpoint */
 
unsigned char * bulk_out_buffer;/* the buffer to send data */
-   int bulk_out_size;  /* the size of the send buffer 
*/
+   size_t  bulk_out_size;  /* the size of the send buffer 
*/
struct urb *write_urb;  /* the urb used to send data */
__u8bulk_out_endpointAddr;  /* the address of the bulk out 
endpoint */
+   atomic_twrite_busy; /* true iff write urb is busy 
*/
+   struct completion   write_finished; /* wait for the write to 
finish */
 
-   struct work_struct  work;   /* work queue entry for line 
discipline waking up */
int open;   /* if the port is open or not 
*/
struct semaphoresem;/* locks this structure */
 };
@@ -118,6 +122,8 @@
 /* the global usb devfs handle */
 extern devfs_handle_t usb_devfs_handle;
 
+/* prevent races between open() and disconnect() */
+static DECLARE_MUTEX (disconnect_sem);
 
 /* local function prototypes */
 static ssize_t skel_read   (struct file *file, char *buffer, size_t count, loff_t 
*ppos);
@@ -125,7 +131,7 @@
 static int skel_ioctl  (struct inode *inode, struct file *file, unsigned int 
cmd, unsigned long arg);
 static int skel_open   (struct inode *inode, struct file *file);
 static int skel_release(struct inode *inode, struct file *file);
-   
+
 static int skel_probe  (struct usb_interface *intf, const struct 
usb_device_id *id);
 static void skel_disconnect(struct usb_interface *intf);
 
@@ -138,7 +144,7 @@
  * to have a node in the /dev directory. If the USB
  * device were for a network interface then the driver
  * would use "struct net_driver" instead, and a serial
- * device would use "struct tty_driver". 
+ * device would use "struct tty_driver".
  */
 static struct file_operations skel_fops = {
/*
@@ -167,7 +173,7 @@
.ioctl =skel_ioctl,
.open = skel_open,
.release =  skel_release,
-};  
+};
 

[linux-usb-devel] Re: [PATCH] USB changes for 2.5.65

2003-03-20 Thread Greg KH
ChangeSet 1.1143.1.8, 2003/03/20 13:54:20-08:00, [EMAIL PROTECTED]

[PATCH] USB: pegasus: fix up GFP_DMA usages.  (bugzilla.kernel.org #418)


 drivers/usb/net/pegasus.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)


diff -Nru a/drivers/usb/net/pegasus.c b/drivers/usb/net/pegasus.c
--- a/drivers/usb/net/pegasus.c Thu Mar 20 15:03:26 2003
+++ b/drivers/usb/net/pegasus.c Thu Mar 20 15:03:26 2003
@@ -121,7 +121,7 @@
char *buffer;
DECLARE_WAITQUEUE(wait, current);
 
-   buffer = kmalloc(size, GFP_DMA);
+   buffer = kmalloc(size, GFP_KERNEL);
if (!buffer) {
warn("%s: looks like we're out of memory", __FUNCTION__);
return -ENOMEM;
@@ -170,7 +170,7 @@
char *buffer;
DECLARE_WAITQUEUE(wait, current);
 
-   buffer = kmalloc(size, GFP_DMA);
+   buffer = kmalloc(size, GFP_KERNEL);
if (!buffer) {
warn("%s: looks like we're out of memory", __FUNCTION__);
return -ENOMEM;
@@ -218,7 +218,7 @@
char *tmp;
DECLARE_WAITQUEUE(wait, current);
 
-   tmp = kmalloc(1, GFP_DMA);
+   tmp = kmalloc(1, GFP_KERNEL);
if (!tmp) {
warn("%s: looks like we're out of memory", __FUNCTION__);
return -ENOMEM;



---
This SF.net email is sponsored by: Tablet PC.  
Does your code think in ink? You could win a Tablet PC. 
Get a free Tablet PC hat just for playing. What are you waiting for? 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


[linux-usb-devel] [PATCH] USB changes for 2.5.65

2003-03-20 Thread Greg KH
ChangeSet 1.1143.1.1, 2003/03/19 11:21:52-08:00, [EMAIL PROTECTED]

[PATCH] USB: fix to synchronous API regarding memory allocation

some part of the synchronous API is used in the block io error handling
code paths. Therefore it may use only GFP_NOIO, not GFP_KERNEL.
  - avoid deadlock due to wrong memory allocation in block io path


 drivers/usb/core/message.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)


diff -Nru a/drivers/usb/core/message.c b/drivers/usb/core/message.c
--- a/drivers/usb/core/message.cThu Mar 20 15:04:24 2003
+++ b/drivers/usb/core/message.cThu Mar 20 15:04:24 2003
@@ -88,7 +88,7 @@
int retv;
int length;
 
-   urb = usb_alloc_urb(0, GFP_KERNEL);
+   urb = usb_alloc_urb(0, GFP_NOIO);
if (!urb)
return -ENOMEM;
   
@@ -131,7 +131,7 @@
 int usb_control_msg(struct usb_device *dev, unsigned int pipe, __u8 request, __u8 
requesttype,
 __u16 value, __u16 index, void *data, __u16 size, int timeout)
 {
-   struct usb_ctrlrequest *dr = kmalloc(sizeof(struct usb_ctrlrequest), 
GFP_KERNEL);
+   struct usb_ctrlrequest *dr = kmalloc(sizeof(struct usb_ctrlrequest), GFP_NOIO);
int ret;

if (!dr)



---
This SF.net email is sponsored by: Tablet PC.  
Does your code think in ink? You could win a Tablet PC. 
Get a free Tablet PC hat just for playing. What are you waiting for? 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


[linux-usb-devel] Re: [PATCH] USB changes for 2.5.65

2003-03-20 Thread Greg KH
ChangeSet 1.1143.1.11, 2003/03/20 14:03:46-08:00, [EMAIL PROTECTED]

[PATCH] USB: new ids for scanner driver

This patch adds new vendor/product ids for various scanners.


 drivers/usb/image/scanner.c |5 +++--
 drivers/usb/image/scanner.h |   13 +
 2 files changed, 16 insertions(+), 2 deletions(-)


diff -Nru a/drivers/usb/image/scanner.c b/drivers/usb/image/scanner.c
--- a/drivers/usb/image/scanner.c   Thu Mar 20 15:03:01 2003
+++ b/drivers/usb/image/scanner.c   Thu Mar 20 15:03:01 2003
@@ -347,8 +347,9 @@
  *- Don't print errors when the device is busy.
  *  
  * 0.4.11  2003-02-25
- *- Added vendor/product ids for Artec, Avision, Brother, Medion, Primax,
- *  Prolink, Fujitsu, Plustek, and SYSCAN scanners.
+ *- Added vendor/product ids for Artec, Avision, Brother, Canon, Compaq,
+ *  Fujitsu, Hewlett-Packard, Lexmark, LG Electronics, Medion, Microtek,
+ *  Primax, Prolink,  Plustek, SYSCAN, Trust and UMAX scanners.
  *- Fixed generation of devfs names if dynamic minors are disabled.
  *- Used kobject reference counting to free the scn struct when the device
  *  is closed and disconnected. Avoids crashes when writing to a 
diff -Nru a/drivers/usb/image/scanner.h b/drivers/usb/image/scanner.h
--- a/drivers/usb/image/scanner.h   Thu Mar 20 15:03:01 2003
+++ b/drivers/usb/image/scanner.h   Thu Mar 20 15:03:01 2003
@@ -105,6 +105,7 @@
{ USB_DEVICE(0x0638, 0x0a10) }, /* iVina FB1600 (=Umax Astra 4500) */
/* Benq: see Acer */
/* Brother */
+   { USB_DEVICE(0x04f9, 0x010f) }, /* MFC 5100C */
{ USB_DEVICE(0x04f9, 0x0111) }, /* MFC 6800 */
/* Canon */
{ USB_DEVICE(0x04a9, 0x2201) }, /* CanoScan FB320U */
@@ -118,9 +119,11 @@
{ USB_DEVICE(0x04a9, 0x220c) }, /* CanoScan D1250U2 */
{ USB_DEVICE(0x04a9, 0x220d) }, /* CanoScan N670U/N676U/LIDE 20 */
{ USB_DEVICE(0x04a9, 0x220e) }, /* CanoScan N1240U/LIDE 30 */
+   { USB_DEVICE(0x04a9, 0x2213) }, /* LIDE 50 */
{ USB_DEVICE(0x04a9, 0x3042) }, /* FS4000US */
/* Colorado -- See Primax/Colorado below */
/* Compaq */
+   { USB_DEVICE(0x049f, 0x001a) }, /* S4 100 */
{ USB_DEVICE(0x049f, 0x0021) }, /* S200 */
/* Epson -- See Seiko/Epson below */
/* Fujitsu */
@@ -152,6 +155,8 @@
{ USB_DEVICE(0x03f0, 0x0705) }, /* ScanJet 4400C */
//  { USB_DEVICE(0x03f0, 0x0801) }, /* ScanJet 7400C - NOT SUPPORTED - use 
hpusbscsi driver */
{ USB_DEVICE(0x03f0, 0x0901) }, /* ScanJet 2300C */
+   { USB_DEVICE(0x03F0, 0x1005) }, /* ScanJet 5400C */
+   { USB_DEVICE(0x03F0, 0x1105) }, /* ScanJet 5470C */
{ USB_DEVICE(0x03f0, 0x1305) }, /* Scanjet 4570c */
{ USB_DEVICE(0x03f0, 0x2005) }, /* ScanJet 3570c */
{ USB_DEVICE(0x03f0, 0x2205) }, /* ScanJet 3500c */
@@ -159,12 +164,16 @@
{ USB_DEVICE(0x0638, 0x0268) }, /* 1200U */
/* Lexmark */
{ USB_DEVICE(0x043d, 0x002d) }, /* X70/X73 */
+   { USB_DEVICE(0x043d, 0x003d) }, /* X83 */
+   /* LG Electronics */
+   { USB_DEVICE(0x0461, 0x0364) }, /* Scanworks 600U (repackaged Primax?) */
/* Medion */
{ USB_DEVICE(0x0461, 0x0377) }, /* MD 5345 - repackaged Primax? */
/* Memorex */
{ USB_DEVICE(0x0461, 0x0346) }, /* 6136u - repackaged Primax ? */
/* Microtek */
{ USB_DEVICE(0x05da, 0x30ce) }, /* ScanMaker 3800 */
+   { USB_DEVICE(0x05da, 0x30cf) }, /* ScanMaker 4800 */
/* The following SCSI-over-USB Microtek devices are supported by the
   microtek driver: Enable SCSI and USB Microtek in kernel config */
//  { USB_DEVICE(0x05da, 0x0099) }, /* ScanMaker X6 - X6U */
@@ -259,7 +268,11 @@
{ USB_DEVICE(0x04b8, 0x0802) }, /* Stylus CX3200 */
/* SYSCAN */
{ USB_DEVICE(0x0a82, 0x4600) }, /* TravelScan 460/464 */
+   /* Trust */
+   { USB_DEVICE(0x05cb, 0x1483) }, /* CombiScan 19200 */
+   { USB_DEVICE(0x05d8, 0x4006) }, /* Easy Webscan 19200 (repackaged Artec?) */
/* Umax */
+   { USB_DEVICE(0x05d8, 0x4009) }, /* Astraslim (actually Artec?) */
{ USB_DEVICE(0x1606, 0x0010) }, /* Astra 1220U */
{ USB_DEVICE(0x1606, 0x0030) }, /* Astra 2000U */
{ USB_DEVICE(0x1606, 0x0060) }, /* Astra 3400U/3450U */



---
This SF.net email is sponsored by: Tablet PC.  
Does your code think in ink? You could win a Tablet PC. 
Get a free Tablet PC hat just for playing. What are you waiting for? 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


[linux-usb-devel] [BK PATCH] USB changes for 2.5.65

2003-03-20 Thread Greg KH
Hi,

Here are some small USB changes.  Some speedtouch movements, and some
small bugfixes, nothing major.  There is a bug when removing hubs that
is still present in 2.5.65, that I can reproduce but haven't tracked
down yet...

Please pull from:  bk://linuxusb.bkbits.net/linus-2.5

thanks,

greg k-h


 drivers/usb/misc/atmsar.c  |  380 --
 drivers/usb/misc/atmsar.h  |   87 --
 drivers/usb/misc/speedtouch.c  | 1216 
 drivers/usb/core/hub.c |   27 
 drivers/usb/core/message.c |4 
 drivers/usb/host/ehci-dbg.c|6 
 drivers/usb/host/ehci-hcd.c|   15 
 drivers/usb/image/scanner.c|5 
 drivers/usb/image/scanner.h|   13 
 drivers/usb/input/hid-core.c   |4 
 drivers/usb/misc/Makefile  |2 
 drivers/usb/misc/speedtch.c| 1514 +
 drivers/usb/misc/speedtouch.c  |   53 -
 drivers/usb/net/cdc-ether.c|   20 
 drivers/usb/net/pegasus.c  |6 
 drivers/usb/serial/whiteheat.c |2 
 drivers/usb/usb-skeleton.c |  229 --
 17 files changed, 1747 insertions(+), 1836 deletions(-)
-

[EMAIL PROTECTED], 2003-03-20 14:03:46-08:00, [EMAIL PROTECTED]
  [PATCH] USB: new ids for scanner driver
  
  This patch adds new vendor/product ids for various scanners.

 drivers/usb/image/scanner.c |5 +++--
 drivers/usb/image/scanner.h |   13 +
 2 files changed, 16 insertions(+), 2 deletions(-)
--

[EMAIL PROTECTED], 2003-03-20 14:03:23-08:00, [EMAIL PROTECTED]
  [PATCH] USB HID: Ignore P5 Data Glove (2.4 and 2.5 patches)
  
As requested, here are the 2.4 (latest BK tree) and 2.5 (latest bk
tree) patches to ignore the non-HID Essential Reality Data Glove
  
(again, user-space lib to access this device via /proc/bus/usb
 is available at http://www.evillabs.net/~jmcc/p5)

 drivers/usb/input/hid-core.c |4 
 1 files changed, 4 insertions(+)
--

[EMAIL PROTECTED], 2003-03-20 14:00:11-08:00, [EMAIL PROTECTED]
  [PATCH] USB: Update for usb-skeleton
  
  My update for usb-skeleton seems to have gotten lost in the shuffle, so
  here it is again -- all wrapped up in one nice little patch.  It's been
  tested by three different people and passed with flying colors.  Please
  apply.

 drivers/usb/usb-skeleton.c |  229 +
 1 files changed, 148 insertions(+), 81 deletions(-)
--

[EMAIL PROTECTED], 2003-03-20 13:54:20-08:00, [EMAIL PROTECTED]
  [PATCH] USB: pegasus: fix up GFP_DMA usages.  (bugzilla.kernel.org #418)

 drivers/usb/net/pegasus.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)
--

[EMAIL PROTECTED], 2003-03-20 13:43:12-08:00, [EMAIL PROTECTED]
  [PATCH] USB: whiteheat bugfix (bugzilla.kernel.org #314)

 drivers/usb/serial/whiteheat.c |2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)
--

[EMAIL PROTECTED], 2003-03-19 15:41:50-08:00, [EMAIL PROTECTED]
  [PATCH] USB: reduce stack usage in cdc-ether
  
  This patch to 2.5.64 reduces the large stack usage in
  log_device_info() [and makes it static to boot].

 drivers/usb/net/cdc-ether.c |   20 
 1 files changed, 16 insertions(+), 4 deletions(-)
--

[EMAIL PROTECTED], 2003-03-19 15:41:23-08:00, [EMAIL PROTECTED]
  [PATCH] USB: Memleak in drivers/usb/hub.c::usb_reset_device
  
  Hello!
  
  On Fri, Mar 14, 2003 at 11:37:19AM -0800, Greg KH wrote:
  > >There seems to be a memleak in drivers/usb/hub.c::usb_reset_device()
  > >on error exit path. See the patch.
  > >Found with help of smatch + enhanced unfree script.
  > And yes, as David said, there is another kind of error in this area for
  > 2.5.  Patches to clean that up would be appreciated.
  
  Ok, I guess something like that should work:

 drivers/usb/core/hub.c |   27 ++-
 1 files changed, 18 insertions(+), 9 deletions(-)
--

[EMAIL PROTECTED], 2003-03-19 13:09:22-08:00, [EMAIL PROTECTED]
  [PATCH] USB: ehci-hcd, prink tweaks
  
  A not-very interesting patch, it just cleans up
  some debug output.

 drivers/usb/host/ehci-dbg.c |6 +++---
 drivers/usb/host/ehci-hcd.c |   15 ---
 2 files changed, 11 insertions(+), 10 deletions(-)
--

[EMAIL PROTECTED], 2003-03-19 11:23:08-08:00, [EMAIL PROTECTED]
  [PATCH] USB speedtouch: get rid of atmsar
  
  There are really only two patches: add atmsar stuff into
  speedtouch.c; and update the Makefile.  The other changes
  are: delete atmsar.c and atmsar.h, rename speedtouch.c to
  speedtch.c.

 drivers/usb/misc/atmsar.c |  380 --
 drivers/usb/misc/atmsar.h |   87 --
 drivers/usb/misc/speedtouch.c | 1216 -
 drivers/usb/misc/Makefile |2 
 drivers/usb/misc/speedtch.c   | 1514 ++
 5 files changed, 1514 insertions(+), 1685 deletions(-)
--

[EMAIL PROTECTED], 2003-03-19 11:22:14-08:00, [EMAIL PROTECTED]
  [PATCH] USB speedtouch: cosmetic comment cha

[linux-usb-devel] Re: [PATCH] USB changes for 2.5.65

2003-03-20 Thread Greg KH
ChangeSet 1.1143.1.5, 2003/03/19 15:41:23-08:00, [EMAIL PROTECTED]

[PATCH] USB: Memleak in drivers/usb/hub.c::usb_reset_device

Hello!

On Fri, Mar 14, 2003 at 11:37:19AM -0800, Greg KH wrote:
> >There seems to be a memleak in drivers/usb/hub.c::usb_reset_device()
> >on error exit path. See the patch.
> >Found with help of smatch + enhanced unfree script.
> And yes, as David said, there is another kind of error in this area for
> 2.5.  Patches to clean that up would be appreciated.

Ok, I guess something like that should work:


 drivers/usb/core/hub.c |   27 ++-
 1 files changed, 18 insertions(+), 9 deletions(-)


diff -Nru a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
--- a/drivers/usb/core/hub.cThu Mar 20 15:03:51 2003
+++ b/drivers/usb/core/hub.cThu Mar 20 15:03:51 2003
@@ -1175,7 +1175,7 @@
 int usb_reset_device(struct usb_device *dev)
 {
struct usb_device *parent = dev->parent;
-   struct usb_device_descriptor descriptor;
+   struct usb_device_descriptor *descriptor;
int i, ret, port = -1;
 
if (!parent) {
@@ -1224,17 +1224,24 @@
 * If nothing changed, we reprogram the configuration and then
 * the alternate settings.
 */
-   ret = usb_get_descriptor(dev, USB_DT_DEVICE, 0, &descriptor,
-   sizeof(descriptor));
-   if (ret < 0)
+   descriptor = kmalloc(sizeof *descriptor, GFP_NOIO);
+   if (!descriptor) {
+   return -ENOMEM;
+   }
+   ret = usb_get_descriptor(dev, USB_DT_DEVICE, 0, descriptor,
+   sizeof(*descriptor));
+   if (ret < 0) {
+   kfree(descriptor);
return ret;
+   }
 
-   le16_to_cpus(&descriptor.bcdUSB);
-   le16_to_cpus(&descriptor.idVendor);
-   le16_to_cpus(&descriptor.idProduct);
-   le16_to_cpus(&descriptor.bcdDevice);
+   le16_to_cpus(&descriptor->bcdUSB);
+   le16_to_cpus(&descriptor->idVendor);
+   le16_to_cpus(&descriptor->idProduct);
+   le16_to_cpus(&descriptor->bcdDevice);
 
-   if (memcmp(&dev->descriptor, &descriptor, sizeof(descriptor))) {
+   if (memcmp(&dev->descriptor, descriptor, sizeof(*descriptor))) {
+   kfree(descriptor);
usb_destroy_configuration(dev);
 
ret = usb_get_device_descriptor(dev);
@@ -1267,6 +1274,8 @@
 
return 1;
}
+
+   kfree(descriptor);
 
ret = usb_set_configuration(dev, dev->actconfig->desc.bConfigurationValue);
if (ret < 0) {



---
This SF.net email is sponsored by: Tablet PC.  
Does your code think in ink? You could win a Tablet PC. 
Get a free Tablet PC hat just for playing. What are you waiting for? 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


[linux-usb-devel] Re: [PATCH] USB changes for 2.5.65

2003-03-20 Thread Greg KH
ChangeSet 1.1143.1.10, 2003/03/20 14:03:23-08:00, [EMAIL PROTECTED]

[PATCH] USB HID: Ignore P5 Data Glove (2.4 and 2.5 patches)

  As requested, here are the 2.4 (latest BK tree) and 2.5 (latest bk
  tree) patches to ignore the non-HID Essential Reality Data Glove

  (again, user-space lib to access this device via /proc/bus/usb
   is available at http://www.evillabs.net/~jmcc/p5)


 drivers/usb/input/hid-core.c |4 
 1 files changed, 4 insertions(+)


diff -Nru a/drivers/usb/input/hid-core.c b/drivers/usb/input/hid-core.c
--- a/drivers/usb/input/hid-core.c  Thu Mar 20 15:03:10 2003
+++ b/drivers/usb/input/hid-core.c  Thu Mar 20 15:03:10 2003
@@ -1334,6 +1334,9 @@
 #define USB_VENDOR_ID_TANGTOP  0x0d3d
 #define USB_DEVICE_ID_TANGTOP_USBPS2   0x0001
 
+#define USB_VENDOR_ID_ESSENTIAL_REALITY0x0d7f
+#define USB_DEVICE_ID_ESSENTIAL_REALITY_P5 0x0100
+
 struct hid_blacklist {
__u16 idVendor;
__u16 idProduct;
@@ -1377,6 +1380,7 @@
{ USB_VENDOR_ID_ONTRAK, USB_DEVICE_ID_ONTRAK_ADU100 + 400, HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_ONTRAK, USB_DEVICE_ID_ONTRAK_ADU100 + 500, HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_TANGTOP, USB_DEVICE_ID_TANGTOP_USBPS2, HID_QUIRK_NOGET },
+   { USB_VENDOR_ID_ESSENTIAL_REALITY, USB_DEVICE_ID_ESSENTIAL_REALITY_P5, 
HID_QUIRK_IGNORE },
{ 0, 0 }
 };
 



---
This SF.net email is sponsored by: Tablet PC.  
Does your code think in ink? You could win a Tablet PC. 
Get a free Tablet PC hat just for playing. What are you waiting for? 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


[linux-usb-devel] Re: [PATCH] USB changes for 2.5.65

2003-03-20 Thread Greg KH
ChangeSet 1.1143.1.7, 2003/03/20 13:43:12-08:00, [EMAIL PROTECTED]

[PATCH] USB: whiteheat bugfix (bugzilla.kernel.org #314)


 drivers/usb/serial/whiteheat.c |2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)


diff -Nru a/drivers/usb/serial/whiteheat.c b/drivers/usb/serial/whiteheat.c
--- a/drivers/usb/serial/whiteheat.cThu Mar 20 15:03:34 2003
+++ b/drivers/usb/serial/whiteheat.cThu Mar 20 15:03:34 2003
@@ -783,7 +783,7 @@
if (info->mcr & UART_MCR_RTS)
modem_signals |= TIOCM_RTS;

-   if (copy_to_user((unsigned int *)arg, &modem_signals, 
sizeof(unsigned int)));
+   if (copy_to_user((unsigned int *)arg, &modem_signals, 
sizeof(unsigned int)))
return -EFAULT;
 
break;



---
This SF.net email is sponsored by: Tablet PC.  
Does your code think in ink? You could win a Tablet PC. 
Get a free Tablet PC hat just for playing. What are you waiting for? 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


[linux-usb-devel] Re: [PATCH] USB changes for 2.5.65

2003-03-20 Thread Greg KH
ChangeSet 1.1143.1.2, 2003/03/19 11:22:14-08:00, [EMAIL PROTECTED]

[PATCH] USB speedtouch: cosmetic comment changes


 drivers/usb/misc/speedtouch.c |   53 +++---
 1 files changed, 14 insertions(+), 39 deletions(-)


diff -Nru a/drivers/usb/misc/speedtouch.c b/drivers/usb/misc/speedtouch.c
--- a/drivers/usb/misc/speedtouch.c Thu Mar 20 15:04:16 2003
+++ b/drivers/usb/misc/speedtouch.c Thu Mar 20 15:04:16 2003
@@ -690,15 +690,9 @@
 }
 
 
-/
-**   ATM   **
-/
-
-/***
-*
-* init functions
-*
-/
+/**
+**  ATM  **
+**/
 
 static void udsl_atm_dev_close (struct atm_dev *dev)
 {
@@ -718,13 +712,6 @@
dev->dev_data = NULL;
 }
 
-
-/***
-*
-* ATM helper functions
-*
-/
-
 static int udsl_atm_proc_read (struct atm_dev *atm_dev, loff_t *pos, char *page)
 {
struct udsl_instance_data *instance = atm_dev->dev_data;
@@ -778,13 +765,6 @@
return 0;
 }
 
-
-/***
-*
-* SAR driver entries
-*
-/
-
 static int udsl_atm_open (struct atm_vcc *vcc, short vpi, int vci)
 {
struct udsl_instance_data *instance = vcc->dev->dev_data;
@@ -866,9 +846,9 @@
 }
 
 
-/
-**   USB   **
-/
+/**
+**  USB  **
+**/
 
 static int udsl_usb_ioctl (struct usb_interface *intf, unsigned int code, void 
*user_data)
 {
@@ -1180,11 +1160,9 @@
 }
 
 
-/***
-*
-* Driver Init
-*
-/
+/***
+**  init  **
+***/
 
 static int __init udsl_usb_init (void)
 {
@@ -1215,13 +1193,11 @@
 MODULE_LICENSE ("GPL");
 
 
-#ifdef DEBUG_PACKET
-/***
-*
-* Debug
-*
-***/
+/
+**  debug  **
+/
 
+#ifdef DEBUG_PACKET
 static int udsl_print_packet (const unsigned char *data, int len)
 {
unsigned char buffer [256];
@@ -1237,5 +1213,4 @@
}
return i;
 }
-
-#endif /* PACKETDEBUG */
+#endif



---
This SF.net email is sponsored by: Tablet PC.  
Does your code think in ink? You could win a Tablet PC. 
Get a free Tablet PC hat just for playing. What are you waiting for? 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


[linux-usb-devel] Re: [PATCH] USB changes for 2.5.65

2003-03-20 Thread Greg KH
ChangeSet 1.1143.1.4, 2003/03/19 13:09:22-08:00, [EMAIL PROTECTED]

[PATCH] USB: ehci-hcd, prink tweaks

A not-very interesting patch, it just cleans up
some debug output.


 drivers/usb/host/ehci-dbg.c |6 +++---
 drivers/usb/host/ehci-hcd.c |   15 ---
 2 files changed, 11 insertions(+), 10 deletions(-)


diff -Nru a/drivers/usb/host/ehci-dbg.c b/drivers/usb/host/ehci-dbg.c
--- a/drivers/usb/host/ehci-dbg.c   Thu Mar 20 15:03:59 2003
+++ b/drivers/usb/host/ehci-dbg.c   Thu Mar 20 15:03:59 2003
@@ -117,10 +117,10 @@
 static void __attribute__((__unused__))
 dbg_qh (char *label, struct ehci_hcd *ehci, struct ehci_qh *qh)
 {
-   dbg ("%s %p info1 %x info2 %x hw_curr %x qtd_next %x", label,
-   qh, qh->hw_info1, qh->hw_info2,
+   dbg ("%s %p n%08x info1 %x info2 %x hw_curr %x qtd_next %x", label,
+   qh, qh->hw_next, qh->hw_info1, qh->hw_info2,
qh->hw_current, qh->hw_qtd_next);
-   dbg ("  alt+errs= %x, token= %x, page0= %x, page1= %x",
+   dbg ("  alt+nak+t= %x, token= %x, page0= %x, page1= %x",
qh->hw_alt_next, qh->hw_token,
qh->hw_buf [0], qh->hw_buf [1]);
if (qh->hw_buf [2]) {
diff -Nru a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
--- a/drivers/usb/host/ehci-hcd.c   Thu Mar 20 15:03:59 2003
+++ b/drivers/usb/host/ehci-hcd.c   Thu Mar 20 15:03:59 2003
@@ -576,7 +576,7 @@
int ports;
int i;
 
-   dbg ("%s: suspend to %d", hcd_to_bus (hcd)->bus_name, state);
+   ehci_dbg (ehci, "suspend to %d\n", state);
 
ports = HCS_N_PORTS (ehci->hcs_params);
 
@@ -593,7 +593,7 @@
if ((temp & PORT_PE) == 0
|| (temp & PORT_OWNER) != 0)
continue;
-dbg ("%s: suspend port %d", hcd_to_bus (hcd)->bus_name, i);
+   ehci_dbg (ehci, "suspend port %d", i);
temp |= PORT_SUSPEND;
writel (temp, &ehci->regs->port_status [i]);
}
@@ -615,7 +615,7 @@
int ports;
int i;
 
-   dbg ("%s: resume", hcd_to_bus (hcd)->bus_name);
+   ehci_dbg (ehci, "resume\n");
 
ports = HCS_N_PORTS (ehci->hcs_params);
 
@@ -635,7 +635,7 @@
if ((temp & PORT_PE) == 0
|| (temp & PORT_SUSPEND) != 0)
continue;
-dbg ("%s: resume port %d", hcd_to_bus (hcd)->bus_name, i);
+   ehci_dbg (ehci, "resume port %d", i);
temp |= PORT_RESUME;
writel (temp, &ehci->regs->port_status [i]);
readl (&ehci->regs->command);   /* unblock posted writes */
@@ -880,8 +880,8 @@
/* ASSERT:  no requests/urbs are still linked (so no TDs) */
/* ASSERT:  nobody can be submitting urbs for this any more */
 
-   dbg ("%s: free_config devnum %d",
-   hcd_to_bus (hcd)->bus_name, udev->devnum);
+   ehci_dbg (ehci, "free_config %s devnum %d\n",
+   udev->devpath, udev->devnum);
 
spin_lock_irqsave (&ehci->lock, flags);
for (i = 0; i < 32; i++) {
@@ -912,7 +912,8 @@
dev->ep [i] = 0;
if (qh->qh_state == QH_STATE_IDLE)
goto idle;
-   dbg ("free_config, async ep 0x%02x qh %p", i, qh);
+   ehci_dbg (ehci, "free_config, async ep 0x%02x qh %p",
+   i, qh);
 
/* scan_async() empties the ring as it does its work,
 * using IAA, but doesn't (yet?) turn it off.  if it



---
This SF.net email is sponsored by: Tablet PC.  
Does your code think in ink? You could win a Tablet PC. 
Get a free Tablet PC hat just for playing. What are you waiting for? 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


[linux-usb-devel] Re: [PATCH] USB changes for 2.5.65

2003-03-20 Thread Greg KH
ChangeSet 1.1143.1.6, 2003/03/19 15:41:50-08:00, [EMAIL PROTECTED]

[PATCH] USB: reduce stack usage in cdc-ether

This patch to 2.5.64 reduces the large stack usage in
log_device_info() [and makes it static to boot].


 drivers/usb/net/cdc-ether.c |   20 
 1 files changed, 16 insertions(+), 4 deletions(-)


diff -Nru a/drivers/usb/net/cdc-ether.c b/drivers/usb/net/cdc-ether.c
--- a/drivers/usb/net/cdc-ether.c   Thu Mar 20 15:03:43 2003
+++ b/drivers/usb/net/cdc-ether.c   Thu Mar 20 15:03:43 2003
@@ -1064,15 +1064,23 @@
 // Used by driver's probe routine 
 //
 
-void log_device_info(ether_dev_t *ether_dev)
+static void log_device_info(ether_dev_t *ether_dev)
 {
int len;
int string_num;
-   unsigned char manu[256];
-   unsigned char prod[256];
-   unsigned char sern[256];
+   unsigned char *manu = NULL;
+   unsigned char *prod = NULL;
+   unsigned char *sern = NULL;
unsigned char *mac_addr;
 
+   manu = kmalloc(256, GFP_KERNEL);
+   prod = kmalloc(256, GFP_KERNEL);
+   sern = kmalloc(256, GFP_KERNEL);
+   if (!manu || !prod || !sern) {
+   dbg("no mem for log_device_info");
+   goto fini;
+   }
+
// Default empty strings in case we don't find a real one
manu[0] = 0x00;
prod[0] = 0x00;
@@ -1113,6 +1121,10 @@
  ether_dev->net->name, manu, prod, sern, mac_addr[0], 
  mac_addr[1], mac_addr[2], mac_addr[3], mac_addr[4], 
  mac_addr[5] );
+fini:
+   kfree(manu);
+   kfree(prod);
+   kfree(sern);
 }
 
 /* Forward declaration */



---
This SF.net email is sponsored by: Tablet PC.  
Does your code think in ink? You could win a Tablet PC. 
Get a free Tablet PC hat just for playing. What are you waiting for? 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


[linux-usb-devel] Re: [PATCH 2.4] USB: New ids for scanner driver

2003-03-20 Thread Greg KH
On Thu, Mar 20, 2003 at 05:19:22PM +0100, Henning Meier-Geinitz wrote:
> Hi,
> 
> this patch adds some more vendor/product ids for the USB scanner driver.

Applied, thanks.

greg k-h


---
This SF.net email is sponsored by: Tablet PC.  
Does your code think in ink? You could win a Tablet PC. 
Get a free Tablet PC hat just for playing. What are you waiting for? 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


Re: [linux-usb-devel] kernel panic in 2.5.65

2003-03-20 Thread Greg KH
On Thu, Mar 20, 2003 at 02:29:17PM +0100, Spang Oliver wrote:
> Hi All,
> 
> I get the following log each time I disconnect a hub (had to type it
> from the display, so its not complete). I do not have the problem with
> 2.5.64.

I see something like this also when unloading a host controller driver.

Do you have CONFIG_DEBUG_SLAB and CONFIG_KALLSYMS enabled?  To me it
looks like we are submitting a urb that has already been freed, and we
oops in usb_submit_urb() as we are passed a pointer of 6b6b6b6b.

thanks,

greg k-h


---
This SF.net email is sponsored by: Tablet PC.  
Does your code think in ink? You could win a Tablet PC. 
Get a free Tablet PC hat just for playing. What are you waiting for? 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


[linux-usb-devel] Re: [PATCH 2.5] USB: new ids for scanner driver

2003-03-20 Thread Greg KH
On Thu, Mar 20, 2003 at 05:34:39PM +0100, Henning Meier-Geinitz wrote:
> Hi,
> 
> This patch adds new vendor/product ids for various scanners.

Applied, thanks.

greg k-h


---
This SF.net email is sponsored by: Tablet PC.  
Does your code think in ink? You could win a Tablet PC. 
Get a free Tablet PC hat just for playing. What are you waiting for? 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


Re: [linux-usb-devel] Belkin Compact Flash card reader

2003-03-20 Thread Alan Stern
On Thu, 20 Mar 2003, Dave Turner wrote:

> On Thu, 20 Mar 2003 at 10:47am, Alan Stern wrote:
> 
> > Can you post an extract from the kernel log under 2.4.21-rc5 with
> > usb-storage debugging turned on?
> 
> Sure thing.
> 
> Linux version 2.4.21-pre5 ([EMAIL PROTECTED]) (gcc version 2.95.3 20010315
> (release)) #1 Wed Mar 19 16:17:04 GMT 2003

Believe it or not, this is failing in a very different and much more 
interesting way than it did under the earlier version of Linux you posted 
before.

[Matt: Do you have any idea why (in the part of the log I snipped) the 
SCSI layer issues READ-CAPACITY three times in a row when each time the
sense code indicates medium not present?  Once ought to be enough.  Has
this been changed in 2.5?]

After inserting a 1Gb Microdrive into the card reader and attempting to 
mount it (following a successful MODE-SENSE):

> usb-storage: queuecommand() called
> usb-storage: *** thread awakened.
> usb-storage: Command READ_10 (10 bytes)
> usb-storage: 28 00 00 00 00 00 00 00 08 00 9b cf
> usb-storage: Bulk command S 0x43425355 T 0x14 Trg 0 LUN 0 L 4096 F 128 CL 10
> usb-storage: Bulk command transfer result=0
> usb-storage: usb_stor_transfer_partial(): xfer 4096 bytes
> usb-storage: command_abort() called
> usb-storage: usb_stor_bulk_msg() returned -104 xferred 0/4096

So at this point the urb's completion routine has been called.  -104 is
-ECONNRESET, indicating the urb was unlinked by the abort routine.

> usb-storage: usb_stor_transfer_partial(): transfer aborted
> usb-storage: Bulk data transfer result 0x3
> usb-storage: -- transport indicates command was aborted
> usb-storage: scsi command aborted
> usb-storage: *** thread sleeping.
> usb-storage: queuecommand() called
> usb-storage: *** thread awakened.
> usb-storage: Command TEST_UNIT_READY (6 bytes)
> usb-storage: 00 00 00 00 00 00 00 00 08 00 9b cf
> usb-storage: Bulk command S 0x43425355 T 0x14 Trg 0 LUN 0 L 0 F 0 CL 6
> uhci.c: uhci_submit_urb: urb not available to submit (status = -104)

What's that?!  Any ideas from anybody?

> usb-storage: Bulk command transfer result=-22

-EINVAL, for whatever good that does.  At this point everything goes to pot.

> usb-storage: -- transport indicates error, resetting
> usb-storage: Bulk reset requested
> usb_control/bulk_msg: timeout
> usb-storage: Bulk soft reset failed -110
> usb-storage: scsi cmd done, result=0x7
> usb-storage: *** thread sleeping.
> usb-storage: device_reset() called
> usb-storage: Bulk reset requested
> uhci.c: uhci_result_control() failed with status 44
> [cf9f80f0] link (0f9f8062) element (0f9f91e0)
>   0: [cf9f91e0] link (0f9f9210) e0 Stalled CRC/Timeo Length=7 MaxLen=7 DT0 EndPt=0 
> Dev=5, PID=2d(SETUP) (buf=0f1cac80)
>   1: [cf9f9210] link (0001) e3 IOC Active Length=0 MaxLen=7ff DT1 EndPt=0 Dev=5, 
> PID=69(IN) (buf=)
> 
> usb-storage: Bulk soft reset failed -110

I won't include the rest of the kernel log; it just gets worse.

Can anyone help?

Alan Stern







---
This SF.net email is sponsored by: Tablet PC.  
Does your code think in ink? You could win a Tablet PC. 
Get a free Tablet PC hat just for playing. What are you waiting for? 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


Re: [linux-usb-devel] question on interaction with driver core

2003-03-20 Thread Oliver Neukum
Am Donnerstag, 20. März 2003 22:01 schrieb Matthew Dharm:
> In my experience, resetting is rare.  If you do need it, it's probably
> because the device isn't compliant and wasn't going to work anyway.
>
> So, why don't we just move the reset into the core, and then every driver
> (including usb-storage) can get reset all at once?  That sidesteps the
> issue, I think.

I am afraid that the core can't do it either because the driver/core
interface lacks the necessary primitives.

Doing a disconnect/probe cycle is the wrong way, because

A the device doesn't go away, most drivers have the same problem as storage
B it allocates memory (due to device removal notification) in the error handler

We can do it, but it means introducing new primitives.

Regards
Oliver



---
This SF.net email is sponsored by: Tablet PC.
Does your code think in ink? You could win a Tablet PC.
Get a free Tablet PC hat just for playing. What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


Re: [linux-usb-devel] question on interaction with driver core

2003-03-20 Thread Matthew Dharm
In my experience, resetting is rare.  If you do need it, it's probably
because the device isn't compliant and wasn't going to work anyway.

So, why don't we just move the reset into the core, and then every driver
(including usb-storage) can get reset all at once?  That sidesteps the
issue, I think.

Matt

On Thu, Mar 20, 2003 at 09:01:49PM +0100, Oliver Neukum wrote:
> 
> > I've actually been thinking along those lines, too... but, given the new
> > design where devices aren't 'remembered', doing the above would disconnect
> > a device and create a new one (as seen by the user).  It kinda defeats the
> > entire purpose of the reset (which is to try to get back to a good state).
> >
> > My guess is that we just have to make a decision on reset-recovery: Is it
> > worth it?  If not, let's just implement Alan's suggestion and be done with
> > it.
> 
> Well, you have a lot of storage devices. Do you need resetting for a working
> error recovery? If so we probably need it. A robust system needs some form
> of error recovery.
> 
> As a practical matter we could limit resetting to devices with only one
> interface, which is the vast majority (strictly speaking this needs to be
> locked against configuration changes). In this case the disconnect/probe
> cycle can be dropped.
> 
>   Regards
>   Oliver

-- 
Matthew Dharm  Home: [EMAIL PROTECTED] 
Maintainer, Linux USB Mass Storage Driver

E:  You run this ship with Windows?!  YOU IDIOT!
L:  Give me a break, it came bundled with the computer!
-- ESR and Lan Solaris
User Friendly, 12/8/1998


pgp0.pgp
Description: PGP signature


Re: [linux-usb-devel] kernel panic in 2.5.65

2003-03-20 Thread David Brownell
Spang Oliver wrote:
Hi All,

I get the following log each time I disconnect a hub (had to type it from the display, so its not complete). I do not have the problem with 2.5.64.
A more complete oops trace would help of course; if you
could use a serial console, or even just hack the stack dump
code to be smart enough to filter out those "ADDR+0x0" cases
and the stack contents, that'd help keep the EIP and maybe
"what blew up" lines visible.
All we can tell is that some urb callback function had a
problem -- not what function, or even what the issue was.
Another approach might be "objdump -dr hub.o" to see if
those instructions were somewhere in that code.
- Dave



regards,
Oliver
ds: 007b   es: 007b   ss:0068
Process swapper (pid: 0, threadinfo=c02d6000 task=c0275360
Stack: 0082 c10c8520 08048034 c10db1c0 c3f43400 c4841e17 0034 0020
   c10db1c0 c02d7fa0 c3f435a8 c4844559 c10db1c0 c02d7fa0 c02d7fa0 0246
   c482f453 c3f43400 c10db1c0 c02d7fa0 c3f43400 0003 0009 c02d7fa0
Call Trace:
[] hub_irq+0x97/0xd0 [usbcore]
[] usb_hcd_giveback_urb+0x39/0x50 [usbcore]
[] uhci_finish_completion+0x33/0x50 [uhci_hcd]
[] usb_hcd_irq+0x1f/0x40 [usbcore]
[] handle_IRQ_event+0x3a/0x60
[] do_IRQ+0x78/0xe0
[] default_idle+0x0/0x30
[] default_idle+0x0/0x30
[] common_interrupt+0x18/0x20
[] default_idle+0x0/0x30
[] default_idle+0x0/0x30
[] default_idle+0x24/0x30
[] cpu_idle+0x32/0x50
[] _stext+0x0/0x20
Code: 8b 75 08 85 f6 0f 85 a2 01 00 00 8b 5d 60 85 db 0f 84 97 01
 <0>Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing
-
Oliver Spang
[EMAIL PROTECTED]




---
This SF.net email is sponsored by: Tablet PC.  
Does your code think in ink? You could win a Tablet PC. 
Get a free Tablet PC hat just for playing. What are you waiting for? 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


Re: [linux-usb-devel] question on interaction with driver core

2003-03-20 Thread Oliver Neukum

> I've actually been thinking along those lines, too... but, given the new
> design where devices aren't 'remembered', doing the above would disconnect
> a device and create a new one (as seen by the user).  It kinda defeats the
> entire purpose of the reset (which is to try to get back to a good state).
>
> My guess is that we just have to make a decision on reset-recovery: Is it
> worth it?  If not, let's just implement Alan's suggestion and be done with
> it.

Well, you have a lot of storage devices. Do you need resetting for a working
error recovery? If so we probably need it. A robust system needs some form
of error recovery.

As a practical matter we could limit resetting to devices with only one
interface, which is the vast majority (strictly speaking this needs to be
locked against configuration changes). In this case the disconnect/probe
cycle can be dropped.

Regards
Oliver



---
This SF.net email is sponsored by: Tablet PC.  
Does your code think in ink? You could win a Tablet PC. 
Get a free Tablet PC hat just for playing. What are you waiting for? 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


Re: [linux-usb-devel] e400: host controller halted. very bad

2003-03-20 Thread Johannes Erdfelt
On Tue, Mar 18, 2003, Duncan Sands <[EMAIL PROTECTED]> wrote:
> This is with latest Linus BK.  From the system log, during boot:
> 
> kernel: drivers/usb/class/usblp.c: usblp0: nonzero read/write bulk status received: 
> -104
> kernel: drivers/usb/class/usblp.c: usblp0: error -104 reading from printer
> kernel: drivers/usb/host/uhci-hcd.c: e400: host controller process error. something 
> bad happened
> kernel: drivers/usb/host/uhci-hcd.c: e400: host controller halted. very bad
> ptal-mlcd: ERROR at ExMgr.cpp:2844, dev=, pid=512, 
> e=4 llioService: llioWrite returns -1, expected=6! 
> ptal-mlcd: ERROR at ExMgr.cpp:902, dev=, pid=512, 
> e=4 exClose(reason=0x0011) 

Known problem. I have a couple of reports of this. I haven't had much
luck reproducing it reliably.

JE



---
This SF.net email is sponsored by: Tablet PC.  
Does your code think in ink? You could win a Tablet PC. 
Get a free Tablet PC hat just for playing. What are you waiting for? 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


Re: [linux-usb-devel] question on interaction with driver core

2003-03-20 Thread Matthew Dharm
On Thu, Mar 20, 2003 at 11:32:45AM -0500, Alan Stern wrote:
> Requiring every driver which might be bound to an interface that is part
> of a storage device to avoid GFP_KERNEL feels too draconian to me.  Maybe
> it would be better simply to remove the usb_reset_device() call from
> usb-storage, or to implement it differently.  For example, usb-storage's
> function for handling an emulated SCSI bus reset (which is where
> usb_reset_device() gets called) might mark the device as bad, fail the
> reset call, fail all following SCSI calls, disconnect itself (telling SCSI
> that the device is gone), and then reset the device and be re-probed.  
> I'm not really recommending this, but at least it would mean any other
> drivers bound to that same device wouldn't be forced to avoid ever waiting
> on I/O.

I've actually been thinking along those lines, too... but, given the new
design where devices aren't 'remembered', doing the above would disconnect
a device and create a new one (as seen by the user).  It kinda defeats the
entire purpose of the reset (which is to try to get back to a good state).

My guess is that we just have to make a decision on reset-recovery: Is it
worth it?  If not, let's just implement Alan's suggestion and be done with
it.

Matt

-- 
Matthew Dharm  Home: [EMAIL PROTECTED] 
Maintainer, Linux USB Mass Storage Driver

NYET! The evil stops here!
-- Pitr
User Friendly, 6/22/1998


pgp0.pgp
Description: PGP signature


Re: [linux-usb-devel] Belkin Compact Flash card reader

2003-03-20 Thread Dave Turner
On Thu, 20 Mar 2003 at 10:47am, Alan Stern wrote:

> Can you post an extract from the kernel log under 2.4.21-rc5 with
> usb-storage debugging turned on?

Sure thing.

Linux version 2.4.21-pre5 ([EMAIL PROTECTED]) (gcc version 2.95.3 20010315
(release)) #1 Wed Mar 19 16:17:04 GMT 2003

[snip]

usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
uhci.c: USB Universal Host Controller Interface driver v1.1
PCI: Found IRQ 11 for device 00:07.2
PCI: Sharing IRQ 11 with 00:07.3
PCI: Sharing IRQ 11 with 00:0b.0
uhci.c: USB UHCI at I/O 0xc400, IRQ 11
usb.c: new USB bus registered, assigned bus number 1
uhci.c: detected 2 ports
usb.c: kmalloc IF cfefcbc0, numif 1
usb.c: new device strings: Mfr=0, Product=2, SerialNumber=1
usb.c: USB device number 1 default language ID 0x0
Product: USB UHCI-alt Root Hub
SerialNumber: c400
hub.c: USB hub found
hub.c: 2 ports detected
hub.c: standalone hub
hub.c: ganged power switching
hub.c: global over-current protection
hub.c: Port indicators are not supported
hub.c: power on to power good time: 2ms
hub.c: hub controller current requirement: 0mA
hub.c: port removable status: RR
hub.c: local power source is good
hub.c: no over-current condition exists
hub.c: enabling power on all ports
usb.c: hub driver claimed interface cfefcbc0
usb.c: kusbd: /sbin/hotplug add 1
usb.c: kusbd policy returned 0xfffe
PCI: Found IRQ 11 for device 00:07.3
PCI: Sharing IRQ 11 with 00:07.2
PCI: Sharing IRQ 11 with 00:0b.0
uhci.c: USB UHCI at I/O 0xc800, IRQ 11
usb.c: new USB bus registered, assigned bus number 2
uhci.c: detected 2 ports
usb.c: kmalloc IF cfefcdc0, numif 1
usb.c: new device strings: Mfr=0, Product=2, SerialNumber=1
usb.c: USB device number 1 default language ID 0x0
Product: USB UHCI-alt Root Hub
SerialNumber: c800
hub.c: USB hub found
hub.c: 2 ports detected
hub.c: standalone hub
hub.c: ganged power switching
hub.c: global over-current protection
hub.c: Port indicators are not supported
hub.c: power on to power good time: 2ms
hub.c: hub controller current requirement: 0mA
hub.c: port removable status: RR
hub.c: local power source is good
hub.c: no over-current condition exists
hub.c: enabling power on all ports
usb.c: hub driver claimed interface cfefcdc0
usb.c: kusbd: /sbin/hotplug add 1
usb.c: kusbd policy returned 0xfffe
uhci.c: root-hub INT complete: port1: 48a port2: 48a data: 6
uhci.c: c400: suspend_hc
hub.c: port 1, portstatus 100, change 3, 12 Mb/s
hub.c: port 1 connection change
hub.c: port 1, portstatus 100, change 3, 12 Mb/s
hub.c: port 2, portstatus 100, change 3, 12 Mb/s
hub.c: port 2 connection change
hub.c: port 2, portstatus 100, change 3, 12 Mb/s
uhci.c: root-hub INT complete: port1: 48a port2: 48a data: 6
uhci.c: c800: suspend_hc
hub.c: port 1, portstatus 100, change 3, 12 Mb/s
hub.c: port 1 connection change
hub.c: port 1, portstatus 100, change 3, 12 Mb/s
hub.c: port 2, portstatus 100, change 3, 12 Mb/s
hub.c: port 2 connection change
hub.c: port 2, portstatus 100, change 3, 12 Mb/s
uhci.c: root-hub INT complete: port1: 488 port2: 488 data: 6
hub.c: port 1, portstatus 100, change 2, 12 Mb/s
hub.c: port 1 enable change, status 100
hub.c: port 2, portstatus 100, change 2, 12 Mb/s
hub.c: port 2 enable change, status 100
uhci.c: root-hub INT complete: port1: 488 port2: 488 data: 6
hub.c: port 1, portstatus 100, change 2, 12 Mb/s
hub.c: port 1 enable change, status 100
hub.c: port 2, portstatus 100, change 2, 12 Mb/s
hub.c: port 2 enable change, status 100

Insert card reader

uhci.c: c800: wakeup_hc
uhci.c: root-hub INT complete: port1: 493 port2: 480 data: 2
hub.c: port 1, portstatus 101, change 1, 12 Mb/s
hub.c: port 1 connection change
hub.c: port 1, portstatus 101, change 1, 12 Mb/s
hub.c: port 1, portstatus 101, change 0, 12 Mb/s
hub.c: port 1, portstatus 101, change 0, 12 Mb/s
hub.c: port 1, portstatus 101, change 0, 12 Mb/s
hub.c: port 1, portstatus 101, change 0, 12 Mb/s
hub.c: port 1, portstatus 103, change 0, 12 Mb/s
hub.c: new USB device 00:07.3-1, assigned address 5
usb.c: kmalloc IF cf1ca900, numif 1
usb.c: new device strings: Mfr=1, Product=2, SerialNumber=3
usb.c: USB device number 5 default language ID 0x409
Manufacturer:
Product: USB CompactFlash
SerialNumber: 58F14C32F1
usb.c: unhandled interfaces on device
usb.c: USB device 5 (vend/prod 0x55aa/0xb000) is not claimed by any active driver.
  Length  = 18
  DescriptorType  = 01
  USB version = 1.10
  Vendor:Product  = 55aa:b000
  MaxPacketSize0  = 8
  NumConfigurations   = 1
  Device version  = 5.00
  Device Class:SubClass:Protocol = 00:00:00
Per-interface classes
Configuration:
  bLength =9
  bDescriptorType =   02
  wTotalLength= 0020
  bNumInterfaces  =   01
  bConfigurationValue =   01
  iConfiguration  =   00
  bmAttributes=   80
  MaxPower=  100mA

  Interface: 0
  Alternate Setting:  0
bLength =9
bDescriptorType =   04
bInterfaceNumber=   00
   

[linux-usb-devel] [PATCH 2.5] USB: new ids for scanner driver

2003-03-20 Thread Henning Meier-Geinitz
Hi,

This patch adds new vendor/product ids for various scanners.

Bye,
  Henning
  
diff -u -r linux-2.5.65/drivers/usb/image/scanner.c 
linux-2.5.65-newids6/drivers/usb/image/scanner.c
--- linux-2.5.65/drivers/usb/image/scanner.c2003-03-17 22:43:50.0 +0100
+++ linux-2.5.65-newids6/drivers/usb/image/scanner.c2003-03-20 17:31:08.0 
+0100
@@ -347,8 +347,9 @@
  *- Don't print errors when the device is busy.
  *  
  * 0.4.11  2003-02-25
- *- Added vendor/product ids for Artec, Avision, Brother, Medion, Primax,
- *  Prolink, Fujitsu, Plustek, and SYSCAN scanners.
+ *- Added vendor/product ids for Artec, Avision, Brother, Canon, Compaq,
+ *  Fujitsu, Hewlett-Packard, Lexmark, LG Electronics, Medion, Microtek,
+ *  Primax, Prolink,  Plustek, SYSCAN, Trust and UMAX scanners.
  *- Fixed generation of devfs names if dynamic minors are disabled.
  *- Used kobject reference counting to free the scn struct when the device
  *  is closed and disconnected. Avoids crashes when writing to a 
diff -u -r linux-2.5.65/drivers/usb/image/scanner.h 
linux-2.5.65-newids6/drivers/usb/image/scanner.h
--- linux-2.5.65/drivers/usb/image/scanner.h2003-03-17 22:44:04.0 +0100
+++ linux-2.5.65-newids6/drivers/usb/image/scanner.h2003-03-20 17:22:21.0 
+0100
@@ -105,6 +105,7 @@
{ USB_DEVICE(0x0638, 0x0a10) }, /* iVina FB1600 (=Umax Astra 4500) */
/* Benq: see Acer */
/* Brother */
+   { USB_DEVICE(0x04f9, 0x010f) }, /* MFC 5100C */
{ USB_DEVICE(0x04f9, 0x0111) }, /* MFC 6800 */
/* Canon */
{ USB_DEVICE(0x04a9, 0x2201) }, /* CanoScan FB320U */
@@ -118,9 +119,11 @@
{ USB_DEVICE(0x04a9, 0x220c) }, /* CanoScan D1250U2 */
{ USB_DEVICE(0x04a9, 0x220d) }, /* CanoScan N670U/N676U/LIDE 20 */
{ USB_DEVICE(0x04a9, 0x220e) }, /* CanoScan N1240U/LIDE 30 */
+   { USB_DEVICE(0x04a9, 0x2213) }, /* LIDE 50 */
{ USB_DEVICE(0x04a9, 0x3042) }, /* FS4000US */
/* Colorado -- See Primax/Colorado below */
/* Compaq */
+   { USB_DEVICE(0x049f, 0x001a) }, /* S4 100 */
{ USB_DEVICE(0x049f, 0x0021) }, /* S200 */
/* Epson -- See Seiko/Epson below */
/* Fujitsu */
@@ -152,6 +155,8 @@
{ USB_DEVICE(0x03f0, 0x0705) }, /* ScanJet 4400C */
//  { USB_DEVICE(0x03f0, 0x0801) }, /* ScanJet 7400C - NOT SUPPORTED - use 
hpusbscsi driver */
{ USB_DEVICE(0x03f0, 0x0901) }, /* ScanJet 2300C */
+   { USB_DEVICE(0x03F0, 0x1005) }, /* ScanJet 5400C */
+   { USB_DEVICE(0x03F0, 0x1105) }, /* ScanJet 5470C */
{ USB_DEVICE(0x03f0, 0x1305) }, /* Scanjet 4570c */
{ USB_DEVICE(0x03f0, 0x2005) }, /* ScanJet 3570c */
{ USB_DEVICE(0x03f0, 0x2205) }, /* ScanJet 3500c */
@@ -159,12 +164,16 @@
{ USB_DEVICE(0x0638, 0x0268) }, /* 1200U */
/* Lexmark */
{ USB_DEVICE(0x043d, 0x002d) }, /* X70/X73 */
+   { USB_DEVICE(0x043d, 0x003d) }, /* X83 */
+   /* LG Electronics */
+   { USB_DEVICE(0x0461, 0x0364) }, /* Scanworks 600U (repackaged Primax?) */
/* Medion */
{ USB_DEVICE(0x0461, 0x0377) }, /* MD 5345 - repackaged Primax? */
/* Memorex */
{ USB_DEVICE(0x0461, 0x0346) }, /* 6136u - repackaged Primax ? */
/* Microtek */
{ USB_DEVICE(0x05da, 0x30ce) }, /* ScanMaker 3800 */
+   { USB_DEVICE(0x05da, 0x30cf) }, /* ScanMaker 4800 */
/* The following SCSI-over-USB Microtek devices are supported by the
   microtek driver: Enable SCSI and USB Microtek in kernel config */
//  { USB_DEVICE(0x05da, 0x0099) }, /* ScanMaker X6 - X6U */
@@ -259,7 +268,11 @@
{ USB_DEVICE(0x04b8, 0x0802) }, /* Stylus CX3200 */
/* SYSCAN */
{ USB_DEVICE(0x0a82, 0x4600) }, /* TravelScan 460/464 */
+   /* Trust */
+   { USB_DEVICE(0x05cb, 0x1483) }, /* CombiScan 19200 */
+   { USB_DEVICE(0x05d8, 0x4006) }, /* Easy Webscan 19200 (repackaged Artec?) */
/* Umax */
+   { USB_DEVICE(0x05d8, 0x4009) }, /* Astraslim (actually Artec?) */
{ USB_DEVICE(0x1606, 0x0010) }, /* Astra 1220U */
{ USB_DEVICE(0x1606, 0x0030) }, /* Astra 2000U */
{ USB_DEVICE(0x1606, 0x0060) }, /* Astra 3400U/3450U */


---
This SF.net email is sponsored by: Tablet PC.  
Does your code think in ink? You could win a Tablet PC. 
Get a free Tablet PC hat just for playing. What are you waiting for? 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


Re: [linux-usb-devel] question on interaction with driver core

2003-03-20 Thread Alan Stern
On Wed, 19 Mar 2003, Matthew Dharm wrote:

> I'm not certain this is a problem...
> 
> I know blocking is legal in the SCSI error-handling context.  Other I/O
> will continue during this time.
> 
> I have to think about this some more
> 
> Matt
> 
> On Thu, Mar 20, 2003 at 12:48:02AM +0100, Oliver Neukum wrote:
> > Am Mittwoch, 19. März 2003 23:46 schrieb Greg KH:
> > > On Fri, Mar 14, 2003 at 07:56:27AM -0800, David Brownell wrote:
> > > > Oliver Neukum wrote:
> > > > >am I right in assuming that any disconnects/probes _must_ be done
> > > > > through driver core? Or is calling usb_device_remove() directly still
> > > > > legal?
> > > >
> > > > I'm not even sure why usb_device_{probe,remove}() are even exported.
> > >
> > > Someone needs to fix up the usb-storage driver for these functions to be
> > > made private.
> > 
> > I just thought about this. It's much less trivial than I thought.
> > The patch I made for cleaning up reset is crap.
> > We cannot ignore it either. Today I saw a mouse with memory stick
> > reader. If this is HID+storage, multiinterface devices are no longer
> > theory.
> > 
> > The problem is somewhat involved and I might even be wrong.
> > Upon device reset the interfaces whose drivers do not make a reset
> > must be notified that they cannot use the device while we reset it.
> > Currently this is done via disconnect()ing all interfaces.
> > This is potentially lethal. This is done as part of the block io error
> > handling path. This means that all memory allocations must be made
> > GFP_NOIO or GFP_ATOMIC. Now please correct me if I am wrong,
> > but the hotplugging subsystem does exactly that, doesn't it?
> > 
> > Regards
> > Oliver


Oliver is right, this is a problem.

usb_device_{probe,remove} could be made private to the core if the core 
would handle device resets correctly.  Read this comment from 
usb_device_reset() in core/hub.c:

/*
 * WARNING - If a driver calls usb_reset_device, you should simulate a
 * disconnect() and probe() for other interfaces you doesn't claim. This
 * is left up to the driver writer right now. This insures other drivers
 * have a chance to re-setup their interface.
 *
 * Take a look at proc_resetdevice in devio.c for some sample code to
 * do this.
 */

That's bad design.

What's needed is some way to notify a driver that someone else is about to 
reset the device.  This has to be done for every driver bound to an 
interface on that device, excepting (perhaps) the one requesting the reset 
since it is already aware of what's going on.  Ideally the drivers should 
be given a chance to put things into a quiescent state, and only after 
everyone is ready should the reset take place.  Then the drivers should be 
notified once the reset is complete.

Of course, there are potential error paths that must be handled: the 
device might get unplugged during this procedure, or its descriptors might 
change somehow (which would require disconnecting all the interfaces and 
starting from scratch).

Yes it's awkward, but it seems unavoidable given that it is only possible 
to reset an entire USB device.

Requiring every driver which might be bound to an interface that is part
of a storage device to avoid GFP_KERNEL feels too draconian to me.  Maybe
it would be better simply to remove the usb_reset_device() call from
usb-storage, or to implement it differently.  For example, usb-storage's
function for handling an emulated SCSI bus reset (which is where
usb_reset_device() gets called) might mark the device as bad, fail the
reset call, fail all following SCSI calls, disconnect itself (telling SCSI
that the device is gone), and then reset the device and be re-probed.  
I'm not really recommending this, but at least it would mean any other
drivers bound to that same device wouldn't be forced to avoid ever waiting
on I/O.

Alan Stern



---
This SF.net email is sponsored by: Tablet PC.  
Does your code think in ink? You could win a Tablet PC. 
Get a free Tablet PC hat just for playing. What are you waiting for? 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


Re: [linux-usb-devel] cleanup of synchronous API

2003-03-20 Thread David Brownell
Here's an updated version of Oliver's patch, changing:

 - uses "struct completion" for simplicity

 - the wait_event_timeout() logic is now like the other macros
   which can return before the event happens:  returns a value
 - clarity for MAX_SCHEDULE_TIMEOUT scenarios, by using the
   standard "timeouts are long" calling convention internally
 - uses only the async primitives

 - restores a warning when the request times out.

 - can use dev_dbg() calls in drivers/usb/core/message.c

Still needs more testing (notably the timeout paths!) and cleanup,
but I thought it'd be good to send this one around.
- Dave

--- 1.22/drivers/usb/core/message.c Wed Mar  5 07:24:34 2003
+++ edited/drivers/usb/core/message.c   Wed Mar 19 23:18:46 2003
@@ -2,6 +2,14 @@
  * message.c - synchronous message handling
  */
 
+#include 
+
+#ifdef CONFIG_USB_DEBUG
+   #define DEBUG
+#else
+   #undef DEBUG
+#endif
+
 #include  /* for scatterlist macros */
 #include 
 #include 
@@ -11,78 +19,57 @@
 
 #include "hcd.h"   /* for usbcore internals */
 
-struct usb_api_data {
-   wait_queue_head_t wqh;
-   int done;
-};
-
-static void usb_api_blocking_completion(struct urb *urb, struct pt_regs *regs)
+static void done (struct urb *urb, struct pt_regs *regs)
 {
-   struct usb_api_data *awd = (struct usb_api_data *)urb->context;
-
-   awd->done = 1;
-   wmb();
-   wake_up(&awd->wqh);
+   dev_dbg (&urb->dev->dev, "urb %p done\n", urb);
+   complete ((struct completion *)urb->context);
 }
 
 // Starts urb and waits for completion or timeout
-static int usb_start_wait_urb(struct urb *urb, int timeout, int* actual_length)
+static int usb_start_wait_urb(struct urb *urb, long timeout, int *actual_length)
 { 
-   DECLARE_WAITQUEUE(wait, current);
-   struct usb_api_data awd;
+   DECLARE_COMPLETION (wait);
int status;
 
-   init_waitqueue_head(&awd.wqh);  
-   awd.done = 0;
+   might_sleep();
 
-   set_current_state(TASK_UNINTERRUPTIBLE);
-   add_wait_queue(&awd.wqh, &wait);
-
-   urb->context = &awd;
-   status = usb_submit_urb(urb, GFP_ATOMIC);
+   urb->context = &wait;
+   urb->complete = done;
+   urb->transfer_flags |= URB_ASYNC_UNLINK;
+   status = usb_submit_urb (urb, GFP_NOIO);
if (status) {
// something went wrong
-   usb_free_urb(urb);
-   set_current_state(TASK_RUNNING);
-   remove_wait_queue(&awd.wqh, &wait);
return status;
}
 
-   while (timeout && !awd.done)
-   {
-   timeout = schedule_timeout(timeout);
-   set_current_state(TASK_UNINTERRUPTIBLE);
-   rmb();
-   }
-
-   set_current_state(TASK_RUNNING);
-   remove_wait_queue(&awd.wqh, &wait);
-
-   if (!timeout && !awd.done) {
-   if (urb->status != -EINPROGRESS) {  /* No callback?!! */
-   printk(KERN_ERR "usb: raced timeout, "
-   "pipe 0x%x status %d time left %d\n",
-   urb->pipe, urb->status, timeout);
-   status = urb->status;
-   } else {
-   warn("usb_control/bulk_msg: timeout");
-   usb_unlink_urb(urb);  // remove urb safely
-   status = -ETIMEDOUT;
+   /* cancel request if we time out */
+   if (wait_event_timeout (wait.wait, wait.done, timeout) == 0) {
+   if ((status = usb_unlink_urb (urb)) == -EINPROGRESS)
+   wait_event (wait.wait, wait.done);
+   /* patch status unless we raced a "real" completion */
+   if (urb->status == -ECONNRESET) {
+   dev_warn (&urb->dev->dev,
+   "timeout urb for ep%d%s (len %d/%d)\n",
+   usb_pipeendpoint (urb->pipe),
+   usb_pipein (urb->pipe) ? "in" : "out",
+   urb->actual_length,
+   urb->transfer_buffer_length);
+   urb->status = -ETIME;
}
-   } else
-   status = urb->status;
+   }
+   status = urb->status;
 
if (actual_length)
*actual_length = urb->actual_length;
-
-   usb_free_urb(urb);
-   return status;
+   
+   return status;
 }
 
 /*---*/
 // returns status (negative) or length (positive)
 int usb_internal_control_msg(struct usb_device *usb_dev, unsigned int pipe, 
-   struct usb_ctrlrequest *cmd,  void *data, int len, int 
timeout)
+   struct usb_ctrlrequest *cmd,  void *data, int len,
+   int timeout /* 0 means MAX_SCHEDULE_TIMEOUT */ )
 {
struct urb *urb;
int retv;
@@ -93,9 +80,12 @@
return -ENOMEM;
   
usb_fill_con

Re: [linux-usb-devel] cleanup of synchronous API

2003-03-20 Thread Oliver Neukum
Am Donnerstag, 20. März 2003 17:03 schrieb Alan Stern:
> On Thu, 20 Mar 2003, Oliver Neukum wrote:
> > > were doing it, I'd not use the synchronous unlink call;
> > > "ought not" to matter, but we can be more sure than that.
> >
> > That's dangerous. We must have absolute confidence about whether
> > the message has gone over the wire or not.
> > Suppose it's a reset. We'd have a device at address zero without knowing
> > it. So this seems to be the easiest way.
>
> Correct me if this is wrong, but it's not so easy to tell whether or not a
> message has gone over the wire.  With UHCI, it would be necessary to
> unlink it and then wait for the start of the next frame to be certain.
> And even then, for bulk OUT messages you face the possibility that the
> message was received correctly by the device but the ACK handshake was
> lost, so the host doesn't _know_ that the message was received.

Is this the case for control mesages as well?
I am not familiar with the controlers at hardware level, I must admit.

> In this case, it's very easy to use an asynchronous unlink rather than a
> synchronous one.  All you have to do is wait for the struct completion
> again after the unlink call, with no timeout.  Given that this whole
> matter revolves around updating the synchronous API interface, it's
> probably best not to use one synchronous call within the implementation of
> another.

Why? It seems obvious to me to use synchronous calls in a synchronous call.

Regards
Oliver



---
This SF.net email is sponsored by: Tablet PC.
Does your code think in ink? You could win a Tablet PC.
Get a free Tablet PC hat just for playing. What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


[linux-usb-devel] [PATCH 2.4] USB: New ids for scanner driver

2003-03-20 Thread Henning Meier-Geinitz
Hi,

this patch adds some more vendor/product ids for the USB scanner driver.

Bye,
  Henning
  
diff -u -r linux-2.4.21-pre5.newids5/drivers/usb/scanner.c 
linux-2.4.21-pre5.newids6/drivers/usb/scanner.c
--- linux-2.4.21-pre5.newids5/drivers/usb/scanner.c 2003-02-28 13:48:29.0 
+0100
+++ linux-2.4.21-pre5.newids6/drivers/usb/scanner.c 2003-03-20 16:35:52.0 
+0100
@@ -1,7 +1,7 @@
 /* -*- linux-c -*- */
 
 /* 
- * Driver for USB Scanners (linux-2.4.21)
+ * Driver for USB Scanners (linux-2.4)
  *
  * Copyright (C) 1999, 2000, 2001, 2002 David E. Nelson
  * Copyright (C) 2002, 2003 Henning Meier-Geinitz
@@ -350,8 +350,9 @@
  *- Don't print errors when the device is busy.
  *  
  * 0.4.11  2003-02-25
- *- Added vendor/product ids for Artec, Avision, Brother, Medion, Primax,
- *  Prolink, Fujitsu, Plustek, and SYSCAN scanners.
+ *- Added vendor/product ids for Artec, Avision, Brother, Canon, Compaq,
+ *  Fujitsu, Hewlett-Packard, Lexmark, LG Electronics, Medion, Microtek,
+ *  Primax, Prolink,  Plustek, SYSCAN, Trust and UMAX scanners.
  *
  * TODO
  *- Performance
Nur in linux-2.4.21-pre5.newids6/drivers/usb/: scanner.c~.
diff -u -r linux-2.4.21-pre5.newids5/drivers/usb/scanner.h 
linux-2.4.21-pre5.newids6/drivers/usb/scanner.h
--- linux-2.4.21-pre5.newids5/drivers/usb/scanner.h 2003-02-28 13:48:29.0 
+0100
+++ linux-2.4.21-pre5.newids6/drivers/usb/scanner.h 2003-03-20 16:41:11.0 
+0100
@@ -1,5 +1,5 @@
 /*
- * Driver for USB Scanners (linux-2.4.21)
+ * Driver for USB Scanners (linux-2.4)
  *
  * Copyright (C) 1999, 2000, 2001, 2002 David E. Nelson
  * Previously maintained by Brian Beattie
@@ -105,6 +105,7 @@
{ USB_DEVICE(0x0638, 0x0a10) }, /* iVina FB1600 (=Umax Astra 4500) */
/* Benq: see Acer */
/* Brother */
+   { USB_DEVICE(0x04f9, 0x010f) }, /* MFC 5100C */
{ USB_DEVICE(0x04f9, 0x0111) }, /* MFC 6800 */
/* Canon */
{ USB_DEVICE(0x04a9, 0x2201) }, /* CanoScan FB320U */
@@ -118,9 +119,11 @@
{ USB_DEVICE(0x04a9, 0x220c) }, /* CanoScan D1250U2 */
{ USB_DEVICE(0x04a9, 0x220d) }, /* CanoScan N670U/N676U/LIDE 20 */
{ USB_DEVICE(0x04a9, 0x220e) }, /* CanoScan N1240U/LIDE 30 */
+   { USB_DEVICE(0x04a9, 0x2213) }, /* LIDE 50 */
{ USB_DEVICE(0x04a9, 0x3042) }, /* FS4000US */
/* Colorado -- See Primax/Colorado below */
/* Compaq */
+   { USB_DEVICE(0x049f, 0x001a) }, /* S4 100 */
{ USB_DEVICE(0x049f, 0x0021) }, /* S200 */
/* Epson -- See Seiko/Epson below */
/* Fujitsu */
@@ -152,6 +155,8 @@
{ USB_DEVICE(0x03f0, 0x0705) }, /* ScanJet 4400C */
//  { USB_DEVICE(0x03f0, 0x0801) }, /* ScanJet 7400C - NOT SUPPORTED - use 
hpusbscsi driver */
{ USB_DEVICE(0x03f0, 0x0901) }, /* ScanJet 2300C */
+   { USB_DEVICE(0x03F0, 0x1005) }, /* ScanJet 5400C */
+   { USB_DEVICE(0x03F0, 0x1105) }, /* ScanJet 5470C */
{ USB_DEVICE(0x03f0, 0x1305) }, /* Scanjet 4570c */
{ USB_DEVICE(0x03f0, 0x2005) }, /* ScanJet 3570c */
{ USB_DEVICE(0x03f0, 0x2205) }, /* ScanJet 3500c */
@@ -159,12 +164,16 @@
{ USB_DEVICE(0x0638, 0x0268) }, /* 1200U */
/* Lexmark */
{ USB_DEVICE(0x043d, 0x002d) }, /* X70/X73 */
+   { USB_DEVICE(0x043d, 0x003d) }, /* X83 */
+   /* LG Electronics */
+   { USB_DEVICE(0x0461, 0x0364) }, /* Scanworks 600U (repackaged Primax?) */
/* Medion */
{ USB_DEVICE(0x0461, 0x0377) }, /* MD 5345 - repackaged Primax? */
/* Memorex */
{ USB_DEVICE(0x0461, 0x0346) }, /* 6136u - repackaged Primax ? */
/* Microtek */
{ USB_DEVICE(0x05da, 0x30ce) }, /* ScanMaker 3800 */
+   { USB_DEVICE(0x05da, 0x30cf) }, /* ScanMaker 4800 */
/* The following SCSI-over-USB Microtek devices are supported by the
   microtek driver: Enable SCSI and USB Microtek in kernel config */
//  { USB_DEVICE(0x05da, 0x0099) }, /* ScanMaker X6 - X6U */
@@ -259,7 +268,11 @@
{ USB_DEVICE(0x04b8, 0x0802) }, /* Stylus CX3200 */
/* SYSCAN */
{ USB_DEVICE(0x0a82, 0x4600) }, /* TravelScan 460/464 */
+   /* Trust */
+   { USB_DEVICE(0x05cb, 0x1483) }, /* CombiScan 19200 */
+   { USB_DEVICE(0x05d8, 0x4006) }, /* Easy Webscan 19200 (repackaged Artec?) */
/* Umax */
+   { USB_DEVICE(0x05d8, 0x4009) }, /* Astraslim (actually Artec?) */
{ USB_DEVICE(0x1606, 0x0010) }, /* Astra 1220U */
{ USB_DEVICE(0x1606, 0x0030) }, /* Astra 2000U */
{ USB_DEVICE(0x1606, 0x0060) }, /* Astra 3400U/3450U */


---
This SF.net email is sponsored by: Tablet PC.  
Does your code think in ink? You could win a Tablet PC. 
Get a free Tablet PC hat just for playing. What are you waiting for? 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
[EMAIL PROTEC

Re: [linux-usb-devel] cleanup of synchronous API

2003-03-20 Thread Alan Stern
On Thu, 20 Mar 2003, Oliver Neukum wrote:

> > were doing it, I'd not use the synchronous unlink call;
> > "ought not" to matter, but we can be more sure than that.
> 
> That's dangerous. We must have absolute confidence about whether
> the message has gone over the wire or not.
> Suppose it's a reset. We'd have a device at address zero without knowing
> it. So this seems to be the easiest way.

Correct me if this is wrong, but it's not so easy to tell whether or not a
message has gone over the wire.  With UHCI, it would be necessary to
unlink it and then wait for the start of the next frame to be certain.  
And even then, for bulk OUT messages you face the possibility that the
message was received correctly by the device but the ACK handshake was
lost, so the host doesn't _know_ that the message was received.

In this case, it's very easy to use an asynchronous unlink rather than a
synchronous one.  All you have to do is wait for the struct completion
again after the unlink call, with no timeout.  Given that this whole
matter revolves around updating the synchronous API interface, it's
probably best not to use one synchronous call within the implementation of
another.

Alan Stern




---
This SF.net email is sponsored by: Tablet PC.  
Does your code think in ink? You could win a Tablet PC. 
Get a free Tablet PC hat just for playing. What are you waiting for? 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


Re: [linux-usb-devel] Belkin Compact Flash card reader

2003-03-20 Thread Alan Stern
On Wed, 19 Mar 2003, Dave Turner wrote:

> On Wed, 19 Mar 2003 at 10:05am, Alan Stern wrote:
> 
> > Dave:
> >
> > You didn't say what version of Linux you were running.  Try installing
> > 2.4.21-current and see if that makes a difference.  A couple of changes
> > were made to the usb-storage driver fairly recently that might address
> > the problem you see.
> >
> > Alan Stern
> 
> Apologies, those logs were from 2.4.20. 2.4.21-rc5 fails similarly.
> 
> Dave

Can you post an extract from the kernel log under 2.4.21-rc5 with
usb-storage debugging turned on?

Alan Stern




---
This SF.net email is sponsored by: Tablet PC.  
Does your code think in ink? You could win a Tablet PC. 
Get a free Tablet PC hat just for playing. What are you waiting for? 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


[linux-usb-devel] kernel panic in 2.5.65

2003-03-20 Thread Spang Oliver
Hi All,

I get the following log each time I disconnect a hub (had to type it from the display, 
so its not complete). I do not have the problem with 2.5.64.

regards,
Oliver

ds: 007b   es: 007b   ss:0068
Process swapper (pid: 0, threadinfo=c02d6000 task=c0275360
Stack: 0082 c10c8520 08048034 c10db1c0 c3f43400 c4841e17 0034 0020
   c10db1c0 c02d7fa0 c3f435a8 c4844559 c10db1c0 c02d7fa0 c02d7fa0 0246
   c482f453 c3f43400 c10db1c0 c02d7fa0 c3f43400 0003 0009 c02d7fa0
Call Trace:
[] hub_irq+0x97/0xd0 [usbcore]
[] usb_hcd_giveback_urb+0x39/0x50 [usbcore]
[] uhci_finish_completion+0x33/0x50 [uhci_hcd]
[] usb_hcd_irq+0x1f/0x40 [usbcore]
[] handle_IRQ_event+0x3a/0x60
[] do_IRQ+0x78/0xe0
[] default_idle+0x0/0x30
[] default_idle+0x0/0x30
[] common_interrupt+0x18/0x20
[] default_idle+0x0/0x30
[] default_idle+0x0/0x30
[] default_idle+0x24/0x30
[] cpu_idle+0x32/0x50
[] _stext+0x0/0x20

Code: 8b 75 08 85 f6 0f 85 a2 01 00 00 8b 5d 60 85 db 0f 84 97 01
 <0>Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing

-
Oliver Spang
[EMAIL PROTECTED]


---
This SF.net email is sponsored by: Tablet PC.  
Does your code think in ink? You could win a Tablet PC. 
Get a free Tablet PC hat just for playing. What are you waiting for? 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel