[linux-usb-devel] [PATCH pd55] Add all Logitech Harmonies to HID blacklist
This patch adds the entire range of Logitech's ProductIDs that are reserved for their Harmony remotes. The in-kernel HID driver can't do anything with these, and now there is a GPL user-space application that can handle them: http://www.sf.net/projects/harmonycontrol Signed-off-by: Phil Dibowitz <[EMAIL PROTECTED]> -- Phil Dibowitz [EMAIL PROTECTED] Open Source software and tech docsInsanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ "Never write it in C if you can do it in 'awk'; Never do it in 'awk' if 'sed' can handle it; Never use 'sed' when 'tr' can do the job; Never invoke 'tr' when 'cat' is sufficient; Avoid using 'cat' whenever possible" -- Taylor's Laws of Programming This patch adds the entire range of Logitech's ProductIDs that are reserved for their Harmony remotes. The in-kernel HID driver can't do anything with these, and now there is a GPL user-space application that can handle them: http://www.sf.net/projects/harmonycontrol Signed-off-by: Phil Dibowitz <[EMAIL PROTECTED]> --- linux-2.6.22-rc3-dev-phil/drivers/hid/usbhid/hid-quirks.c | 132 ++ 1 file changed, 132 insertions(+) diff -puN drivers/hid/usbhid/hid-quirks.c~usb_hid_ignore_harmony drivers/hid/usbhid/hid-quirks.c --- linux-2.6.22-rc3-dev/drivers/hid/usbhid/hid-quirks.c~usb_hid_ignore_harmony 2007-07-23 23:55:12.0 -0700 +++ linux-2.6.22-rc3-dev-phil/drivers/hid/usbhid/hid-quirks.c 2007-07-25 23:39:39.0 -0700 @@ -195,6 +195,70 @@ #define USB_VENDOR_ID_LOGITECH 0x046d #define USB_DEVICE_ID_LOGITECH_RECEIVER 0xc101 +#define USB_DEVICE_ID_LOGITECH_HARMONY 0xc110 +#define USB_DEVICE_ID_LOGITECH_HARMONY_2 0xc111 +#define USB_DEVICE_ID_LOGITECH_HARMONY_3 0xc112 +#define USB_DEVICE_ID_LOGITECH_HARMONY_4 0xc113 +#define USB_DEVICE_ID_LOGITECH_HARMONY_5 0xc114 +#define USB_DEVICE_ID_LOGITECH_HARMONY_6 0xc115 +#define USB_DEVICE_ID_LOGITECH_HARMONY_7 0xc116 +#define USB_DEVICE_ID_LOGITECH_HARMONY_8 0xc117 +#define USB_DEVICE_ID_LOGITECH_HARMONY_9 0xc118 +#define USB_DEVICE_ID_LOGITECH_HARMONY_10 0xc119 +#define USB_DEVICE_ID_LOGITECH_HARMONY_11 0xc11a +#define USB_DEVICE_ID_LOGITECH_HARMONY_12 0xc11b +#define USB_DEVICE_ID_LOGITECH_HARMONY_13 0xc11c +#define USB_DEVICE_ID_LOGITECH_HARMONY_14 0xc11d +#define USB_DEVICE_ID_LOGITECH_HARMONY_15 0xc11e +#define USB_DEVICE_ID_LOGITECH_HARMONY_16 0xc11f +#define USB_DEVICE_ID_LOGITECH_HARMONY_17 0xc120 +#define USB_DEVICE_ID_LOGITECH_HARMONY_18 0xc121 +#define USB_DEVICE_ID_LOGITECH_HARMONY_19 0xc122 +#define USB_DEVICE_ID_LOGITECH_HARMONY_20 0xc123 +#define USB_DEVICE_ID_LOGITECH_HARMONY_21 0xc124 +#define USB_DEVICE_ID_LOGITECH_HARMONY_22 0xc125 +#define USB_DEVICE_ID_LOGITECH_HARMONY_23 0xc126 +#define USB_DEVICE_ID_LOGITECH_HARMONY_24 0xc127 +#define USB_DEVICE_ID_LOGITECH_HARMONY_25 0xc128 +#define USB_DEVICE_ID_LOGITECH_HARMONY_26 0xc129 +#define USB_DEVICE_ID_LOGITECH_HARMONY_27 0xc12a +#define USB_DEVICE_ID_LOGITECH_HARMONY_28 0xc12b +#define USB_DEVICE_ID_LOGITECH_HARMONY_29 0xc12c +#define USB_DEVICE_ID_LOGITECH_HARMONY_30 0xc12d +#define USB_DEVICE_ID_LOGITECH_HARMONY_31 0xc12e +#define USB_DEVICE_ID_LOGITECH_HARMONY_32 0xc12f +#define USB_DEVICE_ID_LOGITECH_HARMONY_33 0xc130 +#define USB_DEVICE_ID_LOGITECH_HARMONY_34 0xc131 +#define USB_DEVICE_ID_LOGITECH_HARMONY_35 0xc132 +#define USB_DEVICE_ID_LOGITECH_HARMONY_36 0xc133 +#define USB_DEVICE_ID_LOGITECH_HARMONY_37 0xc134 +#define USB_DEVICE_ID_LOGITECH_HARMONY_38 0xc135 +#define USB_DEVICE_ID_LOGITECH_HARMONY_39 0xc136 +#define USB_DEVICE_ID_LOGITECH_HARMONY_40 0xc137 +#define USB_DEVICE_ID_LOGITECH_HARMONY_41 0xc138 +#define USB_DEVICE_ID_LOGITECH_HARMONY_42 0xc139 +#define USB_DEVICE_ID_LOGITECH_HARMONY_43 0xc13a +#define USB_DEVICE_ID_LOGITECH_HARMONY_44 0xc13b +#define USB_DEVICE_ID_LOGITECH_HARMONY_45 0xc13c +#define USB_DEVICE_ID_LOGITECH_HARMONY_46 0xc13d +#define USB_DEVICE_ID_LOGITECH_HARMONY_47 0xc13e +#define USB_DEVICE_ID_LOGITECH_HARMONY_48 0xc13f +#define USB_DEVICE_ID_LOGITECH_HARMONY_49 0xc140 +#define USB_DEVICE_ID_LOGITECH_HARMONY_50 0xc141 +#define USB_DEVICE_ID_LOGITECH_HARMONY_51 0xc142 +#define USB_DEVICE_ID_LOGITECH_HARMONY_52 0xc143 +#define USB_DEVICE_ID_LOGITECH_HARMONY_53 0xc144 +#define USB_DEVICE_ID_LOGITECH_HARMONY_54 0xc145 +#define USB_DEVICE_ID_LOGITECH_HARMONY_55 0xc146 +#define USB_DEVICE_ID_LOGITECH_HARMONY_56 0xc147 +#define USB_DEVICE_ID_LOGITECH_HARMONY_57 0xc148 +#define USB_DEVICE_ID_LOGITECH_HARMONY_58 0xc149 +#define USB_DEVICE_ID_LOGITECH_HARMONY_59 0xc14a +#define USB_DEVICE_ID_LOGITECH_HARMONY_60 0xc14b +#define USB_DEVICE_ID_LOGITECH_HARMONY_61 0xc14c +#define USB_DEVICE_ID_LOGITECH_HARMONY_62 0xc14d +#define USB_DEVICE_ID_LOGITECH_HARMONY_63 0xc14e +#define USB_DEVICE_ID_LOGITECH_HARMONY_64 0xc14f #define USB_DEVICE_ID_LOGITECH_WHEEL 0xc294 #define USB_DEVICE_ID_S510_RECEIVER 0xc50c #define USB_DEVICE_ID_S510_RECEIVER_2 0xc517 @@ -209,6 +273,9 @@ #define USB_DE
[linux-usb-devel] iuu_phoenix driver crash the kernel... help needed
Hi all,
I just have rewritten the driver to do a constant polling. This imply that
the module work in interrupt context.
The driver works for a while but after some time ( 1 to 120 seconds
it
depends ), the driver produce a Oops.
But the oops dont give any error on the driver function but show a page
allocation problem in other part of the kernel
Here the oops is in
usbserial but yesterday before activation kernel debug, it was in the
raid_one module !
Here the code , I tried different spin_lock_irq but without any changes.
If I comment the bulk_write and just do a read polling, The polling is
stable ( but this is normal, because the module will never see any character
coming from the device because the device never receive any data
).
Here is the code that cause the problem: ( It is just a part of the code.
This is enough to see all things related to my problem - All spin_lock are
removed for the moment.. I know it is quite dangerous but the module call
all callback function in a kind of chain order. The oops follow the code )
Some explanations:
The code ( not shown here ) iuu_open do a rxcmd with a completion pointer
equal to iuu_uart_read_callback.
So the polling begin in this function. In the same time, iuu_uart_write is
called in a process context to just fill writebuf.
So we have:
1.From tty: character -> iuu_uart_write -> writebuf
2.Polling: iuu_uart_read_callback ->
if character in device buffer -> read_buf -> rxcmd
if no character in buf and reset is waiting -> iuu_reset ->
rxcmd
if no character in device and no reset is waiting -> rxcmd
rxcmd point at completion to iuu_uart_read_callback
--Code--
/* non interrupt context functions */
static int read_immediate(struct usb_serial_port *port, u8 *buf,
u8 count);
static int iuu_uart_baud(struct usb_serial_port *port, u_int32_t baud,
u_int32_t *actual, u_int8_t parity);
static int bulk_immediate(struct usb_serial_port *port, u8 *buf,
u8 count);
static int iuu_ioctl(struct usb_serial_port *port, struct file *file,
unsigned int cmd, unsigned long arg);
static int iuu_tiocmset(struct usb_serial_port *port, struct file *file,
unsigned int set, unsigned int clear);
static int iuu_tiocmget(struct usb_serial_port *port, struct file *file);
static int iuu_uart_write(struct usb_serial_port *port,
const u8 *buf, int count);
static int iuu_uart_on(struct usb_serial_port *port);
static int iuu_uart_off(struct usb_serial_port *port);
/* polled functions (interrupt context) */
static void iuu_uart_read_callback (struct urb *urb);
static int iuu_read_buf(struct usb_serial_port *port ,u8 len);
static void read_buf_callback (struct urb *urb);
static int iuu_bulk_write(struct usb_serial_port *port);
static void iuu_rxcmd (struct urb *urb);
static void read_rxcmd_callback (struct urb *urb);
static int iuu_status(struct usb_serial_port *port);
static void iuu_status_callback(struct urb *urb);
static void iuu_update_status_callback(struct urb *urb);
static int iuu_reset(struct usb_serial_port *port, u_int8_t wt);
/* structures definitions */
static struct usb_serial_driver iuu_device = {
.driver = {
.owner = THIS_MODULE,
.name = "IUU Phoenix",
},
.id_table = id_table,
.num_interrupt_in = NUM_DONT_CARE,
.num_bulk_in = 1,
.num_bulk_out = 1,
.num_ports = 1,
.open = iuu_open,
.close = iuu_close,
.write = iuu_uart_write,
.read_bulk_callback = iuu_uart_read_callback,
.ioctl = iuu_ioctl,
.tiocmget = iuu_tiocmget,
.tiocmset = iuu_tiocmset,
.attach = iuu_startup,
.shutdown = iuu_shutdown,
};
struct iuu_private {
spinlock_t lock; /* store irq state */
wait_queue_head_t delta_msr_wait;
u8 line_control;
u8 line_status;
u8 termios_initialized;
int TIOSTATUS; /* store IUART SIGNAL for tiocmget call */
u8 reset; /* if 1 reset is needed */
int poll; /* number of poll */
u8 *writebuf; /* buffer for writing to device */
int writelen; /* num of byte to write to device */
u8 *buf; /* used for initialize speed */
u8 *dbgbuf; /* debug buffer */
u8 len;
};
static int iuu_alloc_buf (struct usb_serial_port *port) {
struct iuu_private *priv = usb_get_serial_port_data(port);
priv->buf = kmalloc(256,GFP_KERNEL);
priv->dbgbuf = kmalloc(256,GFP_KERNEL);
priv->writebuf = kmalloc(256,GFP_KERNEL);
if ( !priv->buf || !priv->dbgbuf || !priv->writebuf )
return 1 ;
return 0;
}
static int iuu_free_buf (struct us
Re: [linux-usb-devel] commands to unconfigured usb device
On Wednesday 25 July 2007, Gabriel Maganis wrote: > Hello, > Section 9.4 of the USB spec says that devices should respond to > the standard requests like GET_STATUS even if they haven't been > configured yet or given an address. How could one do that without a > pointer to a struct usb_device? You can't do it without a usb_device handle ... which basically means that only usbcore (or maybe usbfs) will access devices in those states. During enumeration, usbcore makes lots of requests to devices that aren't configured, and even a bunch to devices before they are addressed. - Dave - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [patch 2.6.23-rc1-git] ohci-hcd works around more Compaq/ZF-Micro quirks
On Wed, Jul 25, 2007 at 01:13:39PM -0700, David Brownell wrote: > On Wednesday 25 July 2007, Mike Nuss wrote: > > Either way, this patch in its current form isn't safe. > > Darn. OK, I'm sure Greg will know not to merge it. Yup, consider it dropped, thanks for letting me know. thanks, greg k-h - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] commands to unconfigured usb device
Hello, Section 9.4 of the USB spec says that devices should respond to the standard requests like GET_STATUS even if they haven't been configured yet or given an address. How could one do that without a pointer to a struct usb_device? The usb routines like usb_control_msg all take a struct usb_device* as one of their parameters. Thanks... - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [GIT PATCH] more USB patches for 2.6.22
On Thu, 19 Jul 2007, Greg KH wrote: > > Here are some more USB patches and fixes against your 2.6.22 git tree. > > They add a new usb gadget driver, more urb->status cleanups, a new sysfs > attribute to get the raw config of the usb device, and some bugfixes and > documentation updates. I have a flaky(?) USB multi-card reader, and I just got an oops with it on x86-64. It was preceded by some of the IO errors: end_request: I/O error, dev sdc, sector 0 sd 11:0:0:1: [sdc] Result: hostbyte=0x07 driverbyte=0x00 end_request: I/O error, dev sdc, sector 0 Buffer I/O error on device sdc, logical block 0 usb 2-5: reset high speed USB device using ehci_hcd and address 10 usb 2-5: reset high speed USB device using ehci_hcd and address 10 usb 2-5: reset high speed USB device using ehci_hcd and address 10 usb 2-5: reset high speed USB device using ehci_hcd and address 10 usb 2-5: reset high speed USB device using ehci_hcd and address 10 usb 2-5: reset high speed USB device using ehci_hcd and address 10 usb 2-5: device descriptor read/all, error 0 but the oops itself happened when I then removed the USB device due to the errors, causing this: usb 2-5: USB disconnect, address 10 sd 11:0:0:1: [sdc] Result: hostbyte=0x07 driverbyte=0x00 end_request: I/O error, dev sdc, sector 0 Buffer I/O error on device sdc, logical block 0 sd 11:0:0:1: [sdc] Result: hostbyte=0x07 driverbyte=0x00 end_request: I/O error, dev sdc, sector 0 Buffer I/O error on device sdc, logical block 0 sd 11:0:0:1: [sdc] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdc, sector 0 Buffer I/O error on device sdc, logical block 0 sd 11:0:0:1: [sdc] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdc, sector 0 Buffer I/O error on device sdc, logical block 0 sd 11:0:0:1: [sdc] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdc, sector 0 Buffer I/O error on device sdc, logical block 0 Dev sdc: unable to read RDB block 0 sd 11:0:0:1: [sdc] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdc, sector 0 Buffer I/O error on device sdc, logical block 0 unable to read partition table sd 11:0:0:1: [sdc] Attached SCSI removable disk sd 11:0:0:1: Attached scsi generic sg3 type 0 usb-storage: device scan complete and finally the oops itself: general protection fault: [1] SMP CPU 0 Modules linked in: Pid: 214, comm: khubd Not tainted 2.6.22-g20082208 #56 RIP: 0010:[] [] kfree+0x27/0x81 RSP: 0018:81012bd0dd90 EFLAGS: 00010212 RAX: 037d001b2d7d01b8 RBX: 81000100 RCX: 80314f0f RDX: 81012337b738 RSI: 037c811b2e7d01b8 RDI: ff241b0cff251c0b RBP: ff241b0cff251c0b R08: 8062eed0 R09: 81012bc0f430 R10: 0287 R11: 803ed953 R12: 81008642f140 R13: R14: 1540 R15: 0008 FS: () GS:806a() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: 2b02340410a0 CR3: 00010bd4b000 CR4: 06e0 Process khubd (pid: 214, threadinfo 81012bd0c000, task 81012bed36b0) Stack: 81012337b738 81011e9fa800 81008642f140 803f50c4 81012337b738 81011e9fa800 8064ae70 81011e9fa888 81012ad60978 81012ad60800 81012ad60800 803ed96c Call Trace: [] usb_destroy_configuration+0x85/0xee [] usb_release_dev+0x19/0x55 [] kobject_cleanup+0x52/0x70 [] kobject_release+0x0/0x9 [] kref_put+0x5d/0x68 [] hub_thread+0x390/0xb27 [] autoremove_wake_function+0x0/0x2e [] hub_thread+0x0/0xb27 [] kthread+0x47/0x76 [] child_rip+0xa/0x12 [] kthread+0x0/0x76 [] child_rip+0x0/0x12 Code: 48 8b 06 25 00 40 02 00 48 3d 00 40 02 00 75 04 48 8b 76 10 RIP [] kfree+0x27/0x81 RSP Looks like another reference counting bug... Linus - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] e-mail
On Wednesday 25 July 2007, Nielsen Tina wrote: And sent a pdf spam. SA has tools to stop this crap. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Can you buy friendship? You not only can, you must. It's the only way to obtain friends. Everything worthwhile has a price. -- Robert J. Ringer - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Bug in EHCI split-interrupt handling
OK, I'm seeing an issue that I'm pretty sure is the same thing... the keyboard is all kind of goofy (loses keys, repeats keys), then quits working, then the system locks up, only when my patch is enabled and I'm getting (faked) cpu frequency transitions. It definitely appears to be some incompatibilty between the nVidia EHCI controller and my patch. I'm debugging now. (And struggling to remember how this all works! I don't work with the USB code every day.) Thanks Stuart -Original Message- From: Hayes, Stuart Sent: Wednesday, July 25, 2007 1:50 PM To: 'Pete Zaitcev' Cc: [EMAIL PROTECTED]; linux-usb-devel@lists.sourceforge.net Subject: RE: Bug in EHCI split-interrupt handling I'm working on it, Pete. I've got a system with an nVidia EHCI controller (unfortunately it's an Intel box, not AMD, since the failing systems are AMD), and I'm working to reproduce the issue. I acknowledge that this issue is probably caused by this patch. I suspect that what's going on is that the nVidia EHCI controller isn't responding to the "inactivate" bit correctly. I think I will find the answer more quickly (and I'll be more certain that I've got the right answer) if I can work on a system that exhibits the problem. Thanks Stuart -Original Message- From: Pete Zaitcev [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 25, 2007 1:45 PM To: Hayes, Stuart Cc: [EMAIL PROTECTED]; linux-usb-devel@lists.sourceforge.net; [EMAIL PROTECTED] Subject: Re: Bug in EHCI split-interrupt handling On Wed, 25 Jul 2007 08:13:45 -0500, <[EMAIL PROTECTED]> wrote: > [...] and maybe the inactivate bit was set early enough that > actual_length never got initialized to anything and the -4 was just > leftover in that memory space...? I suggest this without looking at > the code--I don't know if that's actually possible. No, Stuart, this won't do. I need you to look at the code, because: a) I have explored the obvious avenues already, and b) We know that unsetting CONFIG_CPU_FREQ clears the issue. The initialization of actual_length is done unconditionally in usb_submit_urb, it was the first thing I checked! I have two vague hypotheses (-sii?) currently: #1 Somehow your patch conflicts with the insertion code which moves dummy qTD around. #2 The length in QH gets desynched from length in QTD, and we have a pice of code which takes the qh->hw_token and uses it for length calculation against qtd->length. -- Pete - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [patch 2.6.23-rc1-git] ohci-hcd works around more Compaq/ZF-Micro quirks
On Wednesday 25 July 2007, Mike Nuss wrote: > David Brownell wrote: > > > > This fix enhances the scope of the existing OHCI_QUIRK_ZFMICRO flag: > > > > 1. A watchdog routine periodically scans the OHCI structures to check > > for orphaned TDs. In these cases the TD is taken back from the > > controller and completed normally. > > Of course, just after I verified and signed off on the final version of > this patch, a problem has cropped up. grrr... > This just showed up in the log of > one of my test systems: > > user.warn kernel: ohci_hcd :00:13.0: Reclaiming orphaned TD c3f41380 > user.err kernel: ohci_hcd :00:13.0: bad entry 3f41381 > > The first message indicates that my watchdog was triggered and the TD > was taken back from the HC. The second message seems to indicate that > the HC did, in fact, later complete the TD. > > I can think of two explanations for this: > > 1. We aren't waiting long enough between the time the TD is popped off > the queue and the time it's taken back through the donelist. If that's > the case, I don't know how long would be reasonable. The worst case should be seven frames (maximum time any WDH irq would be deferred) and two WDH irqs. That would even cover that mostly-safe assumption that multi-TD interrupt transfers aren't happening (they're pretty rare with full speed hardware). > 2. The logic is too naive. The quirk assumes that if HeadP and DoneP > remain equal (meaning that the HC's queue is empty) for at least one > frame, but the HCD still sees an outstanding TD, then that TD must be > lost. But it may be that even though the queue is still empty, there > were intervening transactions in the meantime (it was momentarily > nonempty, but is now empty again). I'm missing something. No matter what, the HCD has a record that some TD *was* queued, but it's not yet been handed back through the donelist. Oh ... I guess you're thinking that "which TD" needs tracking? You could do that easily enough; you're already tracking the ED, just save a TD pointer too. > Either way, this patch in its current form isn't safe. Darn. OK, I'm sure Greg will know not to merge it. - Dave - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [patch 2.6.23-rc1-git] ohci-hcd works around more Compaq/ZF-Micro quirks
On Wed, 25 Jul 2007, Mike Nuss wrote: > 2. The logic is too naive. The quirk assumes that if HeadP and DoneP > remain equal (meaning that the HC's queue is empty) for at least one > frame, but the HCD still sees an outstanding TD, then that TD must be > lost. But it may be that even though the queue is still empty, there > were intervening transactions in the meantime (it was momentarily > nonempty, but is now empty again). In that case, I could fix it by > verifying that the second time around, if HeadP and TailP are still > equal, they point to a *different* dummy than they did before. I don't > know how that comparison would be done - a simple address check may not > be sufficient, because the DMA allocation code will give out the same > addresses for new TDs after the old ones are retired. Surely the correct way to do this is to look for cases where a TD isn't on the donelist but its ED's HeadP has pointed to a later TD for at least one frame. It doesn't matter whether HeadP == TailP or not; what matters is that the queue pointer passed beyond the TD in question sufficiently long ago. Alan Stern - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [patch 2.6.23-rc1-git] ohci-hcd works around more Compaq/ZF-Micro quirks
David Brownell wrote: > > This fix enhances the scope of the existing OHCI_QUIRK_ZFMICRO flag: > > 1. A watchdog routine periodically scans the OHCI structures to check > for orphaned TDs. In these cases the TD is taken back from the > controller and completed normally. Of course, just after I verified and signed off on the final version of this patch, a problem has cropped up. This just showed up in the log of one of my test systems: user.warn kernel: ohci_hcd :00:13.0: Reclaiming orphaned TD c3f41380 user.err kernel: ohci_hcd :00:13.0: bad entry 3f41381 The first message indicates that my watchdog was triggered and the TD was taken back from the HC. The second message seems to indicate that the HC did, in fact, later complete the TD. I can think of two explanations for this: 1. We aren't waiting long enough between the time the TD is popped off the queue and the time it's taken back through the donelist. If that's the case, I don't know how long would be reasonable. 2. The logic is too naive. The quirk assumes that if HeadP and DoneP remain equal (meaning that the HC's queue is empty) for at least one frame, but the HCD still sees an outstanding TD, then that TD must be lost. But it may be that even though the queue is still empty, there were intervening transactions in the meantime (it was momentarily nonempty, but is now empty again). In that case, I could fix it by verifying that the second time around, if HeadP and TailP are still equal, they point to a *different* dummy than they did before. I don't know how that comparison would be done - a simple address check may not be sufficient, because the DMA allocation code will give out the same addresses for new TDs after the old ones are retired. Either way, this patch in its current form isn't safe. Mike - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [patch 2.6.23-rc1-git] ohci-hcd works around more Compaq/ZF-Micro quirks
From: Mike Nuss <[EMAIL PROTECTED]>
The ZF Micro OHCI controller exhibits unexpected behavior that seems to be
related to high load. Under certain conditions, the controller will
complete a TD, remove it from the endpoint's queue, and fail to add it to
the donelist. This causes the endpoint to appear to stop responding. Worse,
if the device is removed while in that state, OHCI will hang while waiting
for the orphaned TD to complete. The situation is not recoverable without
rebooting.
This fix enhances the scope of the existing OHCI_QUIRK_ZFMICRO flag:
1. A watchdog routine periodically scans the OHCI structures to check
for orphaned TDs. In these cases the TD is taken back from the
controller and completed normally.
2. If a device is removed while the endpoint is hung but before the
watchdog catches the situation, any outstanding TDs are taken back
from the controller in the 'sanitize' phase.
The ohci-hcd driver used to print "INTR_SF lossage" in this situation;
this changes it to the universally accurate "ED unlink timeout". Other
instances of this message presumably have different root causes.
Both this Compaq quirk and a NEC quirk are now properly compiled out for
non-PCI builds of this driver.
Signed-off-by: Mike Nuss <[EMAIL PROTECTED]>
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
drivers/usb/host/ohci-hcd.c | 151
drivers/usb/host/ohci-mem.c |1
drivers/usb/host/ohci-pci.c | 22 ++
drivers/usb/host/ohci-q.c | 113 +++-
drivers/usb/host/ohci.h | 25 +++
5 files changed, 238 insertions(+), 74 deletions(-)
--- g26.orig/drivers/usb/host/ohci-hcd.c2007-07-25 09:07:21.0
-0700
+++ g26/drivers/usb/host/ohci-hcd.c 2007-07-25 09:39:08.0 -0700
@@ -81,7 +81,6 @@ static void ohci_dump (struct ohci_hcd *
static int ohci_init (struct ohci_hcd *ohci);
static void ohci_stop (struct usb_hcd *hcd);
static int ohci_restart (struct ohci_hcd *ohci);
-static void ohci_quirk_nec_worker (struct work_struct *work);
#include "ohci-hub.c"
#include "ohci-dbg.c"
@@ -314,6 +313,8 @@ rescan:
if (!HC_IS_RUNNING (hcd->state)) {
sanitize:
ed->state = ED_IDLE;
+ if (quirk_zfmicro(ohci) && ed->type == PIPE_INTERRUPT)
+ ohci->eds_scheduled--;
finish_unlinks (ohci, 0);
}
@@ -321,7 +322,11 @@ sanitize:
case ED_UNLINK: /* wait for hw to finish? */
/* major IRQ delivery trouble loses INTR_SF too... */
if (limit-- == 0) {
- ohci_warn (ohci, "IRQ INTR_SF lossage\n");
+ ohci_warn(ohci, "ED unlink timeout\n");
+ if (quirk_zfmicro(ohci)) {
+ ohci_warn(ohci, "Attempting ZF TD recovery\n");
+ ohci->ed_to_check = ed;
+ }
goto sanitize;
}
spin_unlock_irqrestore (&ohci->lock, flags);
@@ -379,6 +384,89 @@ ohci_shutdown (struct usb_hcd *hcd)
(void) ohci_readl (ohci, &ohci->regs->control);
}
+static int check_ed(struct ohci_hcd *ohci, struct ed *ed)
+{
+ return (hc32_to_cpu(ohci, ed->hwINFO) & ED_IN) != 0
+ && (hc32_to_cpu(ohci, ed->hwHeadP) & TD_MASK)
+ == (hc32_to_cpu(ohci, ed->hwTailP) & TD_MASK)
+ && !list_empty(&ed->td_list);
+}
+
+/* ZF Micro watchdog timer callback. The ZF Micro chipset sometimes completes
+ * an interrupt TD but neglects to add it to the donelist. On systems with
+ * this chipset, we need to periodically check the state of the queues to look
+ * for such "lost" TDs.
+ */
+static void unlink_watchdog_func(unsigned long _ohci)
+{
+ longflags;
+ unsignedmax;
+ unsignedseen_count = 0;
+ unsignedi;
+ struct ed **seen = NULL;
+ struct ohci_hcd *ohci = (struct ohci_hcd *) _ohci;
+
+ spin_lock_irqsave(&ohci->lock, flags);
+ max = ohci->eds_scheduled;
+ if (!max)
+ goto done;
+
+ seen = kcalloc(max, sizeof *seen, GFP_ATOMIC);
+ if (!seen)
+ goto out;
+
+ for (i = 0; i < NUM_INTS; i++) {
+ struct ed *ed = ohci->periodic[i];
+
+ while (ed) {
+ unsignedtemp;
+
+ /* scan this branch of the periodic schedule tree */
+ for (temp = 0; temp < seen_count; temp++) {
+ if (seen[temp] == ed) {
+ /* we've checked it and what's after */
+ ed = NULL;
+ break;
+ }
+ }
+ if (!ed)
+ break;
+
Re: [linux-usb-devel] Bug in EHCI split-interrupt handling
I'm working on it, Pete. I've got a system with an nVidia EHCI controller (unfortunately it's an Intel box, not AMD, since the failing systems are AMD), and I'm working to reproduce the issue. I acknowledge that this issue is probably caused by this patch. I suspect that what's going on is that the nVidia EHCI controller isn't responding to the "inactivate" bit correctly. I think I will find the answer more quickly (and I'll be more certain that I've got the right answer) if I can work on a system that exhibits the problem. Thanks Stuart -Original Message- From: Pete Zaitcev [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 25, 2007 1:45 PM To: Hayes, Stuart Cc: [EMAIL PROTECTED]; linux-usb-devel@lists.sourceforge.net; [EMAIL PROTECTED] Subject: Re: Bug in EHCI split-interrupt handling On Wed, 25 Jul 2007 08:13:45 -0500, <[EMAIL PROTECTED]> wrote: > [...] and maybe the inactivate bit was set early enough that > actual_length never got initialized to anything and the -4 was just > leftover in that memory space...? I suggest this without looking at > the code--I don't know if that's actually possible. No, Stuart, this won't do. I need you to look at the code, because: a) I have explored the obvious avenues already, and b) We know that unsetting CONFIG_CPU_FREQ clears the issue. The initialization of actual_length is done unconditionally in usb_submit_urb, it was the first thing I checked! I have two vague hypotheses (-sii?) currently: #1 Somehow your patch conflicts with the insertion code which moves dummy qTD around. #2 The length in QH gets desynched from length in QTD, and we have a pice of code which takes the qh->hw_token and uses it for length calculation against qtd->length. -- Pete - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] usb_control_msg() reads 0 bytes in Linux 2.6.23-rc1
On Wed, 25 Jul 2007 08:30:40 +0200, Wolfgang Mües <[EMAIL PROTECTED]> wrote: > Pete, > > On Dienstag, 24. Juli 2007, Pete Zaitcev wrote: > > Please keep in mind that all this discussion about short reads has > > nothing to do with your real problem (e.g. the device which used to > > reply with a stall stopped to do so, or it continues to reply with a > > stall token, but EHCI fails to report the stall up the stack...) > > Note that this is the control endpoint. This stall is a "protocoll > stall". The device should respond normal to the next control message, > and the host stack should not block the control endpoint. > > This is different from all other endpoints. Quite true, and I'm aware. But it might have helped Pavel if you didn't cut him out of cc: list. -- Pete - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Bug in EHCI split-interrupt handling
On Wed, 25 Jul 2007 08:13:45 -0500, <[EMAIL PROTECTED]> wrote: > [...] and maybe the inactivate bit was set early enough that > actual_length never got initialized to anything and the -4 was just > leftover in that memory space...? I suggest this without looking at the > code--I don't know if that's actually possible. No, Stuart, this won't do. I need you to look at the code, because: a) I have explored the obvious avenues already, and b) We know that unsetting CONFIG_CPU_FREQ clears the issue. The initialization of actual_length is done unconditionally in usb_submit_urb, it was the first thing I checked! I have two vague hypotheses (-sii?) currently: #1 Somehow your patch conflicts with the insertion code which moves dummy qTD around. #2 The length in QH gets desynched from length in QTD, and we have a pice of code which takes the qh->hw_token and uses it for length calculation against qtd->length. -- Pete - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] hid keyboard packet from interrupt IN pipe
On Wed, 25 Jul 2007, Gabriel Maganis wrote: > Hello, > Is there anyway I can get an hid keyboard (a Dell, in my case) to > send the host packets via the interrupt IN pipe i.e. something like > emulating keypresses? Sure there is. Just plug it into your computer and make sure the usbhid driver is loaded. Alan Stern - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.23-rc1: USB hard disk broken
On Wed, Jul 25, 2007 at 10:24:36 +0200, Oliver Neukum wrote: > Am Mittwoch 25 Juli 2007 schrieb Tino Keitel: > > Hi, > > > > I just tried 2.6.23-rc1 and shortly after the boot my external USB hard > > disk went mad. [...] > Please recompile with CONFIG_USB_DEBUG set. > > Regards > Oliver I tried, but it didn't happen again. Regards, Tino - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] hid keyboard packet from interrupt IN pipe
Hello, Is there anyway I can get an hid keyboard (a Dell, in my case) to send the host packets via the interrupt IN pipe i.e. something like emulating keypresses? Thanks... - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] aio_run_iocb should always retry
On Jul 24, 2007, at 11:10 PM, David Brownell wrote: > On Tuesday 24 July 2007, Zach Brown wrote: >> So, the sad story is that the cancellation support in fs/aio.c is a >> mess. Before we get lost on those details can we talk about simply >> not allowing cancelation of these usbfs2 aio read requests? If they >> guarantee forward progress > > Nope ... if there were progress, cancelation wouldn't be needed! Well, it was worth a shot. > that notion with filesystem stacks has been a headache. So there's > a fair amount of interest in throwing baby out with bathwater. :( Nonsense. - z - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] Stall control endpoint when file storage class request wValue != 0
On Wed, 25 Jul 2007, luislloret wrote: > From: Luis Lloret <[EMAIL PROTECTED]> > > This patch makes the File Storage Gadget stall the control endpoint > when a MSC class request is made with wValue != 0. This change makes > some MSC compliance test warnings disappear. > > Signed-off-by: Luis Lloret <[EMAIL PROTECTED]> > --- > > Thanks again, Alan, for your patience. I didn't know gmail's web editor > traded tabs for spaces. > So here is the patch again... Once again your email program has let you down. It inserted a space character in the second column where there should only be a tab. You might have better luck adding the patch as an attachment instead of putting it inline. Or better yet, use something other than gmail. (Try mailing the patch to yourself and see what happens when you try to apply it; then you'll know whether it worked.) Alan Stern - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB Driver help needed
On Tue, 24 Jul 2007, Ron Gage wrote: > OK, here is what I have done. After opening the dev, setting the > configuration and claiming the interface, I am sending a control message > of bRequestType = 0x42, bRequest of 0x06, all other values = 0. This > is the first "out up" packet sent to the device according to SnoopyPro. Once again: The lines in the log don't correspond to packets! I suppose you're talking about the "5 out up" report, which is the first "out up" in the log. The transfer described by that report plus the preceding "5 out down" actually was composed of 6 packets (at least). Stop using the wrong word. > The transfer from this times out so I'm obviously missing something. It sounds like you're missing URB 4, which is a vendor-specific IN transfer. I don't know that duplicating it will fix your timeout, but as long as you're trying to reproduce what Windows does you should include it. > Of > course, the report immediately before this one is an "out down" but you > suggested that these aren't of concern. FWIW: this is a "Vendor > Endpoint" function (0019) and has the illogical bRequestType of 0x00. Like I said before, the "Function: 0019" part is Windows-internal and meaningless in Linux. > I > know - can't trust the down reports in Snoopy - I'm going to look for a > different USB analyser. I'm wondering if there is more to this transfer > than meets the eye though since it's already "off the books" as far as > the standard goes. It is not "off the books"; you're just reading the wrong part of the log. You should be reading the data from the "5 out up" report, not the "5 out down". For some reason you seem to think those two reports refer to different transfers -- they don't, they both refer to URB 5. > The first question that seems germane: is the value of "PipeHandle" > important? Is there a clean way to set it (I'm using libusb for now). PipeHandle is another Windows-internal thing. It is meaningless for Linux. Alan Stern - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Bug in EHCI split-interrupt handling
I don't see how my patch could cause a transfer to return an actual_length of -4. If it is my patch causing this problem, I suspect it would be because the nVidia EHCI controller handles the "inactivate" bit in an unexpected (and probably out of spec) way--I was able to test with Broadcom & Intel, but I didn't have an nVidia EHCI controller to test on. I guess it's possible that, when the "inactivate" bit is set, the nVidia EHCI controller sets the status to make it look like that transaction is finished, and maybe the inactivate bit was set early enough that actual_length never got initialized to anything and the -4 was just leftover in that memory space...? I suggest this without looking at the code--I don't know if that's actually possible. I'll try to locate a box with an nVidia EHCI controller today and see if I can reproduce this. Stuart -Original Message- From: Alan Stern [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 24, 2007 5:07 PM To: Pete Zaitcev Cc: Hayes, Stuart; USB development list Subject: Re: Bug in EHCI split-interrupt handling On Tue, 24 Jul 2007, Pete Zaitcev wrote: > On Tue, 24 Jul 2007 15:44:23 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> wrote: > > > http://bugzilla.kernel.org/show_bug.cgi?id=8535 > > > > contains logs suggestive of problems with EHCI split-interrupt > > handling. See in particular comment #33; the usbmon log in comment > > #32 contains a line in which a low-speed interrupt URB returns with > > status equal to 0 and actual_length set to -4. > > Nicolas sent me a trace out of band which had a similar entry: > 8100057f6100 1467276128 C Ii:2:004:1 0:8 -4 > > > Obviously this should never happen. Can anybody offer tips on where > > to go searching through the driver code for a solution? > > I'm going to double-check that usbmon is not deceiving you. It sure > looks totally bogus. Maybe I mixed up fields in a union somewhere. Maybe. Stuart Hayes has just added comment #42 in which he suggests this problem may be caused by the cpufreq adjustment patch he wrote. Stuart, could your patch cause a 4-byte low-speed interrupt transfer to return an actual_length of -4? Alan Stern - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] some software u [EMAIL PROTECTED]
Wed, 25 Jul 2007 16:31:35 -0100: Dear Sir , DONT BE SILLY TO PAY HUNDREDS FOR SOFTWARE. Just check it out and get the most wanted latest 2007 edition softwared at dirt cheap rates. http://sosokjfijkho.blogspot.com/ Microsoft Vista , office 2007/ Adobe / Macromedia / Corel and others Download Now http://soskjiakkiyll.blogspot.com/ Download now before prices increase! Regards, Online Microsoft Store Internet Marketing Manager http://sorankjmanio.blogspot.com/ disastrous. Even a general recognmition by society to admit and are several advantages to working within a large information base that thrilling. One spends all one's life in an interactive understand this;that the computer in the home and workplace is contacts and to to relay ideas is anyone's speculation. The the reluctant are coerced into dealing with the computer and its - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] Stall control endpoint when file storage class request wValue != 0
From: Luis Lloret <[EMAIL PROTECTED]>
This patch makes the File Storage Gadget stall the control endpoint
when a MSC class request is made with wValue != 0. This change makes
some MSC compliance test warnings disappear.
Signed-off-by: Luis Lloret <[EMAIL PROTECTED]>
---
Thanks again, Alan, for your patience. I didn't know gmail's web editor
traded tabs for spaces.
So here is the patch again...
--- linux-2.6.21.5/drivers/usb/gadget/file_storage.c.orig 2007-07-23
13:54:53.0 +0200
+++ linux-2.6.21.5/drivers/usb/gadget/file_storage.c2007-07-24
09:11:19.0 +0200
@@ -1296,6 +1296,7 @@ static int class_setup_req(struct fsg_de
struct usb_request *req = fsg->ep0req;
int value = -EOPNOTSUPP;
u16 w_index = le16_to_cpu(ctrl->wIndex);
+ u16 w_value = le16_to_cpu(ctrl->wValue);
u16 w_length = le16_to_cpu(ctrl->wLength);
if (!fsg->config)
@@ -1309,7 +1310,7 @@ static int class_setup_req(struct fsg_de
if (ctrl->bRequestType != (USB_DIR_OUT |
USB_TYPE_CLASS | USB_RECIP_INTERFACE))
break;
- if (w_index != 0) {
+ if (w_index != 0 || w_value != 0) {
value = -EDOM;
break;
}
@@ -1325,7 +1326,7 @@ static int class_setup_req(struct fsg_de
if (ctrl->bRequestType != (USB_DIR_IN |
USB_TYPE_CLASS | USB_RECIP_INTERFACE))
break;
- if (w_index != 0) {
+ if (w_index != 0 || w_value != 0) {
value = -EDOM;
break;
}
@@ -1344,7 +1345,7 @@ static int class_setup_req(struct fsg_de
if (ctrl->bRequestType != (USB_DIR_OUT |
USB_TYPE_CLASS | USB_RECIP_INTERFACE))
break;
- if (w_index != 0) {
+ if (w_index != 0 || w_value != 0) {
value = -EDOM;
break;
}
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.23-rc1: USB hard disk broken
Am Mittwoch 25 Juli 2007 schrieb Tino Keitel:
> Hi,
>
> I just tried 2.6.23-rc1 and shortly after the boot my external USB hard
> disk went mad.
>
> I all started with these kernel messages:
>
> kern.info: usb 1-6: USB disconnect, address 5
> kern.info: sd 4:0:0:0: [sdb] Result: hostbyte=0x07 driverbyte=0x00
> kern.warn: end_request: I/O error, dev sdb, sector 68479
> kern.alert: I/O error in filesystem ("dm-2") meta-data dev dm-2 block
> 0x6c7fa20
> ("xfs_trans_read_buf") error 5 buf count 8192
>
> The full kernel log can be found here:
>
> http://tikei.de/kernel.log
>
> And the config:
>
> http://tikei.de/kernel.config
>
> Needless to say that it all worked fine with 2.6.22.
Please recompile with CONFIG_USB_DEBUG set.
Regards
Oliver
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] usb-serial: fix oti6858.c segfault in termios handling
The oti6858 usb serial driver should use
kernel_termios_to_user_termios/
user_termios_to_kernel_termios to avoid segfaults because the kernel
uses a structure differing from that of user space with a different
size.
Signed-off-by: Thomas Viehmann <[EMAIL PROTECTED]>
---
I'm don't know the least thing about the type casting (it is lifted
from kobil_sct.c), but I do get better success with the patch...
--- linux-2.6.23-rc1/drivers/usb/serial/oti6858.c.orig
+++ linux-2.6.23-rc1/drivers/usb/serial/oti6858.c
@@ -818,19 +818,22 @@
switch (cmd) {
case TCGETS:
- if (copy_to_user(user_arg, port->tty->termios,
- sizeof(struct
ktermios))) {
+ if (kernel_termios_to_user_termios(
+(struct ktermios __user
*)arg,
+port->tty->termios))
return -EFAULT;
- }
return 0;
case TCSETS:
case TCSETSW: case TCSETSF: -
if (copy_from_user(port->tty->termios, user_arg,
- sizeof(struct
ktermios))) {
+ if
(user_termios_to_kernel_termios(port->tty->termios,
+ (struct ktermios
__user *)arg))
return -EFAULT;
- }
oti6858_set_termios(port, NULL);
return 0;
--
Thomas Viehmann, http://thomas.viehmann.net/
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
