[linux-usb-devel] Need help: dl_done_list( ) function not called after submission of a read URB...
Hello... I have this problem when I submit a read URB. After the submission, host controller does not enter the dl_done_list( ) function which I think is responsible for setting up the urb for the next read request. I have no problems with the write process though. I believe that the dl_done_list( ) function must be called after submission of a read or write URB. Because of the issue above, I cannot do anymore read's from the usb channel. What could be the reasons for not calling dl_done_list( ) function after a urb submission??? I am using the generic usblp printer driver to receive my read/write request from an application. I am developing on an arm big endian platform with an OHCI based usb hardware... Thanks. - eman __ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click ___ 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] Fwd: USB Hub Driver
Hi all, I am currently involved in porting the USB stack (linux 2.6.11.11 kernel) on ARM 10 architecture. I have two separate ports on the Root Hub (one EHCI and one OHCI). The Host Controller implements all the standard EHCI and OHCI registers. The only difference is that the stack has been ported onto the AMBA bus directly and does not interface through the PCI as in most cases. I have managed to port the basic stack, though there were some issues regarding the enumeration of an external USB 2.0 hub. Though the hub is getting enumerated, it is unable to detect any devices connected on it. I understand that the linux kernel creates a USB hub deamon (khubd) that manages various devices connected to the ports. There are two distinct issues I am facing. 1.) A device is connected to the hub prior to plugging it into the Root Hub. In this case, once the hub has been detected and the hub scans each of the ports for any device presence by issuing the GET_PORT_STATUS command in the hub_events() routine. I noticed that when a device is detected, the hub issues consecutive GET_PORT_STATUS commands for the hub_debounce period of 100ms (once after each 25ms period for transient removals). In my case the second time I call the GET_PORT_STATUS command, the urb is submitted ( message.c), but it never completes. The code calls wait_for_completion in usb_start_wait_urb() call. I am not understanding why the hub fails to respond. I have checked the submission of the urb till the HCD layer and have confirmed that the ASE bit is set in the EHCI Operation USBCMD register. I believe that the hub responds and the stack recognizes the command through ehci_irq->ehci_work->scan_async->qh_completions->ehci_urb_done->usb_hcd_giveback_urb->complete call stack. But no interrupt is getting raised. 2.) In the second case, when no device is connected on the hub, after the hub enumeration completes, the hub thread (khubd) issues constant IN transactions to check device connection on the hub. Again I have traced the sumission of the Interrupt In URB till the setting of the PSE bit in the USBCMD register. But as expected, I am not receiving the NAK response from the device. Hence not device detection is happening. Could some please suggest any possible reasons for the failure of device detection on the external hub? The stack works successfully for other 2.0 devices such as memory sticks, keyboards, and other mass storage devices. With regards, Kaustubh --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&op=click ___ 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] Re: nokia_dku2 driver is unsuitable for certain Nokia phones
On Wed, Nov 16, 2005 at 04:53:34PM +0300, Alex Kanavin wrote: > On Wed, 9 Nov 2005, Greg KH wrote: > > >>Yeah, but this means dku2 would have to be a fully standalone driver, > >>rather than a plugin to usb-serial. > > > >But that would mean it would actually work :) > > Hi Greg, > > it seems the current dku2 driver made it to 2.6.15-rc1. I think the > discussion made it clear that it should be removed, and reworked into a > more generic driver (that doesn't hardcode endpoints) or taken entirely to > the userspace. Currently it works for some (very few) Nokia phones, does > nothing for most others, and, worst of all, gets in the way of working > OBEX support for some phones. Please remove it. Ok, I'll just drop it entirely, sorry about this. greg k-h --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click ___ 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] Re: USB patches for 2.6.15-rc1??
On Tue, Nov 15, 2005 at 09:48:01AM +0100, David Kubicek wrote: > may I ask you what about the "URB/buffer ring queue" patch I've > submitted months ago for CDC ACM modems and which you accepted into your > tree when Oliver sent it to you for merging like a week ago? It's only been in my tree for a week. It came to me after I had done the big merge cycle with Linus after 2.6.14 came out. For major changes to a driver like this one, I want to get some good testing in the -mm tree, and then it will go into mainline. So, it will be a few more weeks, I'll send it to Linus after 2.6.15 is out. thanks, greg k-h --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click ___ 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 00/02] [RFC] Add dynamic id support to all USB drivers
Here's two patches against the latest -git tree that add the ability to add new vendor/product device id pairs to USB drivers after they have been loaded. It works just like the PCI drivers do, with the exception that only vendor/product can be specified (no class stuff.) I did it this way to make it simpler, as that's almost all anyone ever wants to add. Note that usb-serial drivers do not work properly with these dynamic ids yet, it's going to take some rework of the usb-serial core due to the wierd way it binds drivers to devices to get this to work properly. Comments? thanks, greg k-h --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click ___ 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 01/02] USB: reorg some functions out of the main usb.c file
This will make the dynamic-id stuff easier to do, as it will be
self-contained.
No logic was changed at all.
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
Documentation/DocBook/usb.tmpl |1
drivers/usb/core/Makefile |2
drivers/usb/core/driver.c | 338 +
drivers/usb/core/usb.c | 310 -
drivers/usb/core/usb.h |3
5 files changed, 343 insertions(+), 311 deletions(-)
--- gregkh-2.6.orig/drivers/usb/core/usb.c
+++ gregkh-2.6/drivers/usb/core/usb.c
@@ -52,161 +52,6 @@ static int nousb; /* Disable USB when bu
static DECLARE_RWSEM(usb_all_devices_rwsem);
-static int generic_probe (struct device *dev)
-{
- return 0;
-}
-static int generic_remove (struct device *dev)
-{
- struct usb_device *udev = to_usb_device(dev);
-
- /* if this is only an unbind, not a physical disconnect, then
-* unconfigure the device */
- if (udev->state == USB_STATE_CONFIGURED)
- usb_set_configuration(udev, 0);
-
- /* in case the call failed or the device was suspended */
- if (udev->state >= USB_STATE_CONFIGURED)
- usb_disable_device(udev, 0);
- return 0;
-}
-
-static struct device_driver usb_generic_driver = {
- .owner = THIS_MODULE,
- .name = "usb",
- .bus = &usb_bus_type,
- .probe = generic_probe,
- .remove = generic_remove,
-};
-
-static int usb_generic_driver_data;
-
-/* called from driver core with usb_bus_type.subsys writelock */
-static int usb_probe_interface(struct device *dev)
-{
- struct usb_interface * intf = to_usb_interface(dev);
- struct usb_driver * driver = to_usb_driver(dev->driver);
- const struct usb_device_id *id;
- int error = -ENODEV;
-
- dev_dbg(dev, "%s\n", __FUNCTION__);
-
- if (!driver->probe)
- return error;
- /* FIXME we'd much prefer to just resume it ... */
- if (interface_to_usbdev(intf)->state == USB_STATE_SUSPENDED)
- return -EHOSTUNREACH;
-
- id = usb_match_id (intf, driver->id_table);
- if (id) {
- dev_dbg (dev, "%s - got id\n", __FUNCTION__);
-
- /* Interface "power state" doesn't correspond to any hardware
-* state whatsoever. We use it to record when it's bound to
-* a driver that may start I/0: it's not frozen/quiesced.
-*/
- mark_active(intf);
- intf->condition = USB_INTERFACE_BINDING;
- error = driver->probe (intf, id);
- if (error) {
- mark_quiesced(intf);
- intf->condition = USB_INTERFACE_UNBOUND;
- } else
- intf->condition = USB_INTERFACE_BOUND;
- }
-
- return error;
-}
-
-/* called from driver core with usb_bus_type.subsys writelock */
-static int usb_unbind_interface(struct device *dev)
-{
- struct usb_interface *intf = to_usb_interface(dev);
- struct usb_driver *driver = to_usb_driver(intf->dev.driver);
-
- intf->condition = USB_INTERFACE_UNBINDING;
-
- /* release all urbs for this interface */
- usb_disable_interface(interface_to_usbdev(intf), intf);
-
- if (driver && driver->disconnect)
- driver->disconnect(intf);
-
- /* reset other interface state */
- usb_set_interface(interface_to_usbdev(intf),
- intf->altsetting[0].desc.bInterfaceNumber,
- 0);
- usb_set_intfdata(intf, NULL);
- intf->condition = USB_INTERFACE_UNBOUND;
- mark_quiesced(intf);
-
- return 0;
-}
-
-/**
- * usb_register - register a USB driver
- * @new_driver: USB operations for the driver
- *
- * Registers a USB driver with the USB core. The list of unattached
- * interfaces will be rescanned whenever a new driver is added, allowing
- * the new driver to attach to any recognized devices.
- * Returns a negative error code on failure and 0 on success.
- *
- * NOTE: if you want your driver to use the USB major number, you must call
- * usb_register_dev() to enable that functionality. This function no longer
- * takes care of that.
- */
-int usb_register(struct usb_driver *new_driver)
-{
- int retval = 0;
-
- if (nousb)
- return -ENODEV;
-
- new_driver->driver.name = (char *)new_driver->name;
- new_driver->driver.bus = &usb_bus_type;
- new_driver->driver.probe = usb_probe_interface;
- new_driver->driver.remove = usb_unbind_interface;
- new_driver->driver.owner = new_driver->owner;
-
- usb_lock_all_devices();
- retval = driver_register(&new_driver->driver);
- usb_unlock_all_devices();
-
- if (!retval) {
- pr_info("%s: registered new driver %s\n",
- usbcore_name, new_driver->name);
- usbfs_update_special();
- }
[linux-usb-devel] [PATCH 02/02] USB: add dynamic id functionality to USB core
Echo the usb vendor and product id to the "new_id" file in the driver's
sysfs directory, and then that driver will be able to bind to a device
with those ids if it is present.
Example:
echo 0557 2008 > /sys/bus/usb/drivers/foo_driver/new_id
adds the hex values 0557 and 2008 to the device id table for the foo_driver.
Note, usb-serial drivers do not currently work with this capability yet.
usb-storage also might have some oddities.
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/usb/core/driver.c | 218 +++---
include/linux/usb.h |8 +
2 files changed, 176 insertions(+), 50 deletions(-)
--- gregkh-2.6.orig/drivers/usb/core/driver.c
+++ gregkh-2.6/drivers/usb/core/driver.c
@@ -27,6 +27,15 @@
#include "hcd.h"
#include "usb.h"
+static int usb_match_one_id(struct usb_interface *interface,
+ const struct usb_device_id *id);
+
+struct usb_dynid {
+ struct list_head node;
+ struct usb_device_id id;
+};
+
+
static int generic_probe(struct device *dev)
{
return 0;
@@ -58,6 +67,96 @@ struct device_driver usb_generic_driver
* usb device or a usb interface. */
int usb_generic_driver_data;
+#ifdef CONFIG_HOTPLUG
+
+/*
+ * Adds a new dynamic USBdevice ID to this driver,
+ * and cause the driver to probe for all devices again.
+ */
+static ssize_t store_new_id(struct device_driver *driver,
+ const char *buf, size_t count)
+{
+ struct usb_driver *usb_drv = to_usb_driver(driver);
+ struct usb_dynid *dynid;
+ u32 idVendor = 0;
+ u32 idProduct = 0;
+ int fields = 0;
+
+ fields = sscanf(buf, "%x %x", &idVendor, &idProduct);
+ if (fields < 0)
+ return -EINVAL;
+
+ dynid = kzalloc(sizeof(*dynid), GFP_KERNEL);
+ if (!dynid)
+ return -ENOMEM;
+
+ INIT_LIST_HEAD(&dynid->node);
+ dynid->id.idVendor = idVendor;
+ dynid->id.idProduct = idProduct;
+ dynid->id.match_flags = USB_DEVICE_ID_MATCH_DEVICE;
+
+ spin_lock(&usb_drv->dynids.lock);
+ list_add_tail(&usb_drv->dynids.list, &dynid->node);
+ spin_unlock(&usb_drv->dynids.lock);
+
+ if (get_driver(&usb_drv->driver)) {
+ driver_attach(&usb_drv->driver);
+ put_driver(&usb_drv->driver);
+ }
+
+ return count;
+}
+static DRIVER_ATTR(new_id, S_IWUSR, NULL, store_new_id);
+
+static int usb_create_newid_file(struct usb_driver *usb_drv)
+{
+ int error = 0;
+
+ if (usb_drv->probe != NULL)
+ error = sysfs_create_file(&usb_drv->driver.kobj,
+ &driver_attr_new_id.attr);
+ return error;
+}
+
+static void usb_free_dynids(struct usb_driver *usb_drv)
+{
+ struct usb_dynid *dynid, *n;
+
+ spin_lock(&usb_drv->dynids.lock);
+ list_for_each_entry_safe(dynid, n, &usb_drv->dynids.list, node) {
+ list_del(&dynid->node);
+ kfree(dynid);
+ }
+ spin_unlock(&usb_drv->dynids.lock);
+}
+#else
+static inline int usb_create_newid_file(struct usb_driver *usb_drv)
+{
+ return 0;
+}
+
+static inline void usb_free_dynids(struct usb_driver *usb_drv)
+{
+}
+#endif
+
+static const struct usb_device_id *usb_match_dynamic_id(struct usb_interface
*intf,
+ struct usb_driver *drv)
+{
+ struct usb_dynid *dynid;
+
+ spin_lock(&drv->dynids.lock);
+ list_for_each_entry(dynid, &drv->dynids.list, node) {
+ if (usb_match_one_id(intf, &dynid->id)) {
+ spin_unlock(&drv->dynids.lock);
+ return &dynid->id;
+ }
+ }
+ spin_unlock(&drv->dynids.lock);
+ return NULL;
+}
+
+
/* called from driver core with usb_bus_type.subsys writelock */
static int usb_probe_interface(struct device *dev)
{
@@ -75,6 +174,8 @@ static int usb_probe_interface(struct de
return -EHOSTUNREACH;
id = usb_match_id(intf, driver->id_table);
+ if (!id)
+ id = usb_match_dynamic_id(intf, driver);
if (id) {
dev_dbg(dev, "%s - got id\n", __FUNCTION__);
@@ -120,6 +221,64 @@ static int usb_unbind_interface(struct d
return 0;
}
+/* returns 0 if no match, 1 if match */
+static int usb_match_one_id(struct usb_interface *interface,
+ const struct usb_device_id *id)
+{
+ struct usb_host_interface *intf;
+ struct usb_device *dev;
+
+ /* proc_connectinfo in devio.c may call us with id == NULL. */
+ if (id == NULL)
+ return 0;
+
+ intf = interface->cur_altsetting;
+ dev = interface_to_usbdev(interface);
+
+ if ((id->match_flags & USB_DEVICE_ID_MATCH_VENDOR) &&
+ id->idVendor != le16_to_cpu(dev->descriptor.idVendor))
+ return 0;
+
+ if ((id->match_flags & USB_DEVICE_ID
Re: [linux-usb-devel] Re: [Linux-ATM-General] pushing a NULL skbuff
On Wed, 16 Nov 2005 17:12:52 +0100, Duncan Sands <[EMAIL PROTECTED]> wrote: > With the speedtouch USB modems, the problem people usually see is: > (C) at some point the modem spontaneously disconnects and reconnects > (surprisingly common with some motherboards). pppd takes several seconds > to understand that ATM device 0 has died; until it understands this, it > keeps a connection open, which means that the ATM device hangs around. > The "new" modem (= old one reconnected) creates a new ATM device, which > is given device number 1, because number 0 is still being used by the > old device. The scenario is clear. You know what I personally would do it occured to my code? I would work to create proper orphan mode for opened instances. Then, new device would get assigned number 0, even if someone had device 0 still open. The internal structures for the old "device 0" would have been kept alive by a (counted) reference from the top side as zombies, to disappear when eventually closed. It may be too much work for you, your call. It's easier to suggest than to implement properly (without leaking or other bugs). -- Pete --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click ___ 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] RE: HP iLO needs FSBR
Pete, I've been looking into adjusting IDLE_TIMEOUT. Unfortunately, I've been dealing with some other issues first. Preliminary testing seems to indicate that adjusting the idle timeout will work, but I need to do some more testing. Best Regards, --Chris -Original Message- From: Pete Zaitcev [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 16, 2005 5:05 PM To: Frantz, Chris Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; linux-usb-devel@lists.sourceforge.net; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: HP iLO needs FSBR On Thu, 10 Nov 2005 17:54:25 -0600, "Frantz, Chris" <[EMAIL PROTECTED]> wrote: > I would agree that the patch is questionable. It appears the only > reason that it helps is that it takes advantage of some unintended > behavior of the FSBR implementation in the current UHCI driver. Chris, did you have a chance to test Alan's suggestion to increase the IDLE_TIMEOUT? I have not got an access to a suitable HP box yet (all I found either runs RHEL 3 or has AMD CPUs with OHCI). Clearly, if usb-uhci worked and uhci-hcd fails, there should be a way to fix this whithout making the higher level drivers to adjust. -- Pete --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&op=click ___ 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] HELP: Problem with HP Laserjet 1022 and USB in Linux 2.6.12
On Wednesday November 16, [EMAIL PROTECTED] wrote: > On Wed, 16 Nov 2005 09:54:41 +1100, Neil Brown <[EMAIL PROTECTED]> wrote: > > > > It would also be worthwhile to see if you can get more or less the same > > > effect without all those changes, just by increasing IDLE_TIMEOUT to 1000 > > > ms or something like that. > > > > I did get similar throughput with IDLE_TIMEOUT set to 5. 1000 > > wouldn't be enough with 8K writes, as an 8K write often takes more > > than one second. But I'm happy to redo some tests to be able to give > > you clear before/after results. It'll probably have to wait a week or > > so, as I've spent more time on this that I really should have lately. > > I don't understand why this happens. The HCD (uhci-hcd) knows when > the bus is actually idle, so it can know when to set the timeout. > Strange. The uchi-hcd decides that if a single URB takes longer than 50msec, then continuing with FSBR is a waste of PCI bandwidth, and it switches of FSBR and so it just sends one packet every millisecond (or 2 every 4th millisecond). This makes sense for a device that is sane but slow (though it should try more per frame, and would but for a typo) and doesn't fit well with an insane printer that wants packets in 1msec bursts every 112 msecs. i.e. it doesn't just set the timeout when the bus is idle, but also when the device appears idle, and in my case the appearance is deceiving. NeilBrown --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click ___ 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] Re: HP iLO needs FSBR
On Thu, 10 Nov 2005 17:54:25 -0600, "Frantz, Chris" <[EMAIL PROTECTED]> wrote: > I would agree that the patch is questionable. It appears the only > reason that it helps is that it takes advantage of some unintended > behavior of the FSBR implementation in the current UHCI driver. Chris, did you have a chance to test Alan's suggestion to increase the IDLE_TIMEOUT? I have not got an access to a suitable HP box yet (all I found either runs RHEL 3 or has AMD CPUs with OHCI). Clearly, if usb-uhci worked and uhci-hcd fails, there should be a way to fix this whithout making the higher level drivers to adjust. -- Pete --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click ___ 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] HELP: Problem with HP Laserjet 1022 and USB in Linux 2.6.12
On Wed, 16 Nov 2005 09:54:41 +1100, Neil Brown <[EMAIL PROTECTED]> wrote: > > It would also be worthwhile to see if you can get more or less the same > > effect without all those changes, just by increasing IDLE_TIMEOUT to 1000 > > ms or something like that. > > I did get similar throughput with IDLE_TIMEOUT set to 5. 1000 > wouldn't be enough with 8K writes, as an 8K write often takes more > than one second. But I'm happy to redo some tests to be able to give > you clear before/after results. It'll probably have to wait a week or > so, as I've spent more time on this that I really should have lately. I don't understand why this happens. The HCD (uhci-hcd) knows when the bus is actually idle, so it can know when to set the timeout. Strange. -- Pete --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click ___ 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] HELP: Problem with HP Laserjet 1022 and USB in Linux 2.6.12
On Wednesday November 16, [EMAIL PROTECTED] wrote: > > 64 bytes is probably best. You don't lose any FSBR performance, because > FSBR isn't turned off immediately when an URB completes. Ok, I'll get some new clean traces, but probably not until some time next week. > > That's what I'd like to understand. Even with FSBR on all the time, it > still takes more than 1000 ms to transfer 128 packets (i.e., 8192 > bytes)? Do the packets get sent in fixed-size clumps, or is it more > random? With 64byte writes, there is usually a 112msec delay, sometimes none, sometimes double. See other email. With 8192byte writes, I cannot watch the individual packets, but each 8k urb suffers from 1 to several 112msec delays, which suggests there is clumping within a small window ever 112msecs. > > If the printer was at all sane, it wouldn't take more than 300 ms to > transfer that much data even with FSBR permanently off! I think we can agree the printer is not sane. If it wasn't that I have found other reports of UHCI problems with this printer, I would assume my particular printer had a defect and return it to HP. Maybe I will anyway. > > > But I'm happy to redo some tests to be able to give > > you clear before/after results. It'll probably have to wait a week or > > so, as I've spent more time on this that I really should have lately. > > It might be more interesting to find out how the printer manages to work > more quickly under Windows (assuming it does, of course). If you want to > spend the time, you could try tracing some of that communication. I won't be doing this in the near future, but I am curious, and may give it a try in a few weeks. Thanks, NeilBrown --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click ___ 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] HELP: Problem with HP Laserjet 1022 and USB in Linux 2.6.12
On Wednesday November 16, [EMAIL PROTECTED] wrote: > On Wed, 16 Nov 2005, Neil Brown wrote: > > > I've got piles of usbmon logs, and I'm happy to create more. Could > > you be specific about that would help, and different setting show > > different things differently :-) > > > > For example, I have a rather nice log with 64 byte writes (so there is > > one packet per UDB). If I take the completion time stamps, find the > > remainder after dividing by 111838(microseconds) and graph that I get > > a really interesting graph!! I cannot explain all the features, but > > I'm sure they correlate significantly to some aspect of the printer > > hardware > > If it's so interesting, post it! Well, seeing you asked... This trace was with 64byte writes, and I think NO_FSBR was set by usblp at the time. I took the timestamp of the completion of urbs from usbmon output and took the remainder after dividing by 111838. That number was chosen by starting with 112000 which seemed to be the approximate length of the strange delays, and the making small changes until I got a nice graph. The graph is This has several interesting features. 1/ Packets complete only during a 10msec band every 112msecs (approx). 2/ There seems to be a repeating pattern within that 10msec band. 3/ There is a large jump about packet 11000 4/ There is a distinct change around packets 12900 - 13100. 3 is due to the microsecond counter wrapping and is not related to the usb traffic at all. 2 - if we zoom in on the repeating pattern we get: This shows a regular saw-tooth, with a subsidiary sawtooth on it. If we take just one of those teeth - 4019 to 4082, go back to the data, and get the times between packets completion, we get 3 packets take 2 msecs, several take 112msecs, others take 224msecs. These gaps are actually about 111.98, slightly longer than the overall average of 111.84 4 - if we zoom in on this noise, we see We see that in the middle of a rather long sawtooth, we start getting completion times that are completely out of sync with the 111838 'clock'. Going back to the data for this time range, and plotting inter-completion time again we get This shows packets being completed is much less than 112msecs. The actually numbers are all very close to whole milliseconds, ranging from 2 to 21msec, with modes around 7msec and 25msec. So for this short burst, the printer is accepting data at a reasonable speed (But still well short of 1 packet per msec). Interpretation? Who knows. Maybe there is a clock that ticks every 111.98msec and has a duty cycle that allows packets to arrive during a 1msec period every 111.98msecs. Depending on how that 1msec period aligns with the 1msec usb frame cycle, you get 0, 1, or 2 packets through every 112msecs. But the printer wants that clock to run at 111.84msecs, so it keeps adjusting it. But then why things go crazy and start working better for 200 packets, I have no idea. So... interesting, but very hard to explain. NeilBrown
Re: [linux-usb-devel] Re: [Linux-ATM-General] pushing a NULL skbuff
On Wed, 16 Nov 2005, Duncan Sands wrote: > The problem here is the way ATM connections are opened: you specify > a device number, called the interface number, as well as some other info. > Alternatively, you can specify ATM_ITF_ANY instead of a device number, > and all devices will be queried until one is found that is prepared to > open the connection. > > With the speedtouch USB modems, the problem people usually see is: > > (A) for normal people, the modem is the only ATM device (and there's > only one modem). Thus this is ATM device zero. > > (B) people connect using pppd; pppd doesn't support ATM_ITF_ANY, so > most people specify that the connection should be to device number 0. > pppd is usually run from a hotplug or init script. > > (C) at some point the modem spontaneously disconnects and reconnects > (surprisingly common with some motherboards). pppd takes several seconds > to understand that ATM device 0 has died; until it understands this, it > keeps a connection open, which means that the ATM device hangs around. > The "new" modem (= old one reconnected) creates a new ATM device, which > is given device number 1, because number 0 is still being used by the > old device. > > (D) a new instance of pppd is launched from a hotplug script, or the > old instance of pppd tries to open a new connection once it understands > that the old connection has died. It tries to connect to device 0, but > there is no longer any device 0, only device 1, so the connection attempt > fails. > > (E) the user notices that there is no internet connection and wonders why. > The user runs pppd by hand - and it still fails to connect (no device 0). > Eventually the user gives up and reboots the machine. This sounds like an application problem. Isn't it possible to add support for ATM_ITF_ANY to pppd? It's a mistake to used fixed identification numbers in a situation where devices can be added or removed at random and the numbers changed accordingly. Alan Stern --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click ___ 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] Re: [PATCH] - Fixes NULL pointer deference in usb-serial driver.
On Wed, 16 Nov 2005 09:49:27 -0800
Greg KH <[EMAIL PROTECTED]> wrote:
| On Wed, Nov 16, 2005 at 03:55:40PM -0200, Luiz Fernando Capitulino wrote:
| > On Wed, 16 Nov 2005 09:24:16 -0800
| > Greg KH <[EMAIL PROTECTED]> wrote:
| >
| > | On Wed, Nov 16, 2005 at 03:16:34PM -0200, Luiz Fernando Capitulino wrote:
| > | > Hi Greg,
| > | >
| > | > If I run several instances of this program in parallel:
| > | >
| > | > #include
| > | > #include
| > | > #include
| > | > #include
| > | > #include
| > | > #include
| > | > #include
| > | > #include
| > | > #include
| > | > #include
| > | >
| > | > int main(int argc, char *argv[])
| > | > {
| > | > int ret, fd;
| > | > char *port;
| > | > struct termios tio, original;
| > | >
| > | > port = argv[1];
| > | > if (!port)
| > | > port = "/dev/ttyUSB0";
| > | >
| > | > fd = open(port, O_RDWR | O_NONBLOCK | O_NOCTTY);
| > | > if (fd < 0) {
| > | > perror("open()");
| > | > exit(1);
| > | > }
| > | >
| > | > usleep(100);
| > | > ret = tcgetattr(fd, &original);
| > | > if (ret < 0) {
| > | > perror("tcgetattr()");
| > | > exit(1);
| > | > }
| > | >
| > | > ret = close(fd);
| > | > if (ret) {
| > | > perror("close()");
| > | > exit(1);
| > | > }
| > | >
| > | > return 0;
| > | > }
| > | >
| > | > with a Siemens CX65 mobile (which uses the pl2303 driver), I get the
| > | > following NULL pointer deference:
| > | >
| > | > Nov 15 12:32:19 tirion kernel: [ 147.009410] Unable to handle kernel
NULL pointer dereference at virtual address 00a4
| > | > Nov 15 12:32:19 tirion kernel: [ 147.009430] printing eip:
| > | > Nov 15 12:32:19 tirion kernel: [ 147.009436] d0a1f888
| > | > Nov 15 12:32:19 tirion kernel: [ 147.009441] *pde =
| > | > Nov 15 12:32:19 tirion kernel: [ 147.009449] Oops: [#1]
| > | > Nov 15 12:32:19 tirion kernel: [ 147.009454] DEBUG_PAGEALLOC
| > | > Nov 15 12:32:19 tirion kernel: [ 147.009461] Modules linked in: pl2303
usbserial ide_cd cdrom e100 mii uhci_hcd ehci_hcd usbcore quota_v2 snd_cs46xx
snd_rawmidi snd_seq_device snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd
soundcore snd_page_alloc
| > | > Nov 15 12:32:19 tirion kernel: [ 147.009504] CPU:0
| > | > Nov 15 12:32:19 tirion kernel: [ 147.009507] EIP:
0060:[pg0+275417224/1070101504]Not tainted VLI
| > | > Nov 15 12:32:19 tirion kernel: [ 147.009512] EFLAGS: 00210246
(2.6.15-rc1y-gee90f62b)
| > | > Nov 15 12:32:19 tirion kernel: [ 147.009548] EIP is at
serial_ioctl+0x28/0xd0 [usbserial]
| > | > Nov 15 12:32:19 tirion kernel: [ 147.009558] eax: ebx:
ecx: 5401 edx: c99c4f58
| > | > Nov 15 12:32:19 tirion kernel: [ 147.009569] esi: ffed edi:
5401 ebp: c94c3f3c esp: c94c3f18
| > | > Nov 15 12:32:19 tirion kernel: [ 147.009578] ds: 007b es: 007b ss:
0068
| > | > Nov 15 12:32:19 tirion kernel: [ 147.009588] Process termios_set (pid:
3091, threadinfo=c94c2000 task=c9ba6ad0)
| > | > Nov 15 12:32:19 tirion kernel: [ 147.009595] Stack: c95c1b7c
b7f014e0 c94c3f5c c0144ed6 c99c4f58 cb0eedf8 d0a1f860
| > | > Nov 15 12:32:19 tirion kernel: [ 147.009618]c9bd6000 c94c3f60
c01f5c23 bfc7c010 c9bd6000 5401 c99c4f58 c02eda60
| > | > Nov 15 12:32:19 tirion kernel: [ 147.009640]c99c4f58 c01f5970
c94c3f78 c0164ac8 bfc7c010 c99c4f58 0003
| > | > Nov 15 12:32:19 tirion kernel: [ 147.009662] Call Trace:
| > | > Nov 15 12:32:19 tirion kernel: [ 147.009668] [show_stack+122/144]
show_stack+0x7a/0x90
| > | > Nov 15 12:32:19 tirion kernel: [ 147.009689] [show_registers+330/432]
show_registers+0x14a/0x1b0
| > | > Nov 15 12:32:19 tirion kernel: [ 147.009702] [die+220/352]
die+0xdc/0x160
| > | > Nov 15 12:32:19 tirion kernel: [ 147.009714] [do_page_fault+724/1461]
do_page_fault+0x2d4/0x5b5
| > | > Nov 15 12:32:19 tirion kernel: [ 147.009738] [error_code+79/84]
error_code+0x4f/0x54
| > | > Nov 15 12:32:19 tirion kernel: [ 147.009750] [tty_ioctl+691/944]
tty_ioctl+0x2b3/0x3b0
| > | > Nov 15 12:32:19 tirion kernel: [ 147.009768] [do_ioctl+72/112]
do_ioctl+0x48/0x70
| > | > Nov 15 12:32:19 tirion kernel: [ 147.009786] [vfs_ioctl+95/416]
vfs_ioctl+0x5f/0x1a0
| > | > Nov 15 12:32:19 tirion kernel: [ 147.009798] [sys_ioctl+57/96]
sys_ioctl+0x39/0x60
| > | > Nov 15 12:32:19 tirion kernel: [ 147.009809] [syscall_call+7/11]
syscall_call+0x7/0xb
| > | > Nov 15 12:32:19 tirion kernel: [ 147.009820] Code: ef eb 88 55 89 e5
83 ec 24 89 75 f8 be ed ff ff ff 89 7d fc 89 cf 89 5d f4 89 55 f0 8b 98 b4 09
00 00 a1 04 59 a2 d0 85 c0 75 78 <8b> 83 a4 00 00 00 85 c0 74 3e 8b 03 8b 70 04
8b 86 fc 00 00 00
| > | >
| > | > The deference is at drivers/usb/serial/usb-serial.c:352. The first fix
I
| > | > thought was jus
[linux-usb-devel] Re: [PATCH] - Fixes NULL pointer deference in usb-serial driver.
On Wed, Nov 16, 2005 at 09:24:16AM -0800, Greg KH wrote: > On Wed, Nov 16, 2005 at 03:16:34PM -0200, Luiz Fernando Capitulino wrote: > > 1. Process A calls open() and tcgetattr(). When it calls close(), the > > specific > > driver function put it to sleep at usb_serial.c:242 (I'm using pl2303 > > driver) > > > > 2. Process B calls open() and before the call to tcgetattr() it is put to > > sleep. > > > > 3. Process A wakes up and finish the close procedure (which resets > > 'port->tty->driver_data') > > > > 4. Process B wakes up, executes serial_ioctl() and gets a NULL pointer in > > 'port->tty->driver_data'. > > Ugh, the tty core should really protect us from stuff like this, > unfortunately, there is no locking there, yet. People are working on > it... No. It is quite correct to have an overlapping open and close with TTYs. In fact, it's something which is rather fundamental to TTYs. Consider: you have a modem connected to a serial like. You want to use it for both callin and dial out. Your box runs a getty on the line. The getty opens the port in non- blocking mode, configures it, closes it and then re-opens it in blocking mode. The open call waits for the DCD line to become active. Meanwhile, you want to use the modem to call out, so you open the port in non-blocking mode. This succeeds, and you eventually finish using the port. You close it. This triggers a hang up in the usual way and _then_ causes the first open call to return an EAGAIN error. Hint: there's a VERY good reason the serial_core layer exists and it's to get these kind of semantics (and bugs) centralised in one place rather than spread across thousands of drivers. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click ___ 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] Re: [PATCH] - Fixes NULL pointer deference in usb-serial driver.
On Wed, Nov 16, 2005 at 03:55:40PM -0200, Luiz Fernando Capitulino wrote:
> On Wed, 16 Nov 2005 09:24:16 -0800
> Greg KH <[EMAIL PROTECTED]> wrote:
>
> | On Wed, Nov 16, 2005 at 03:16:34PM -0200, Luiz Fernando Capitulino wrote:
> | > Hi Greg,
> | >
> | > If I run several instances of this program in parallel:
> | >
> | > #include
> | > #include
> | > #include
> | > #include
> | > #include
> | > #include
> | > #include
> | > #include
> | > #include
> | > #include
> | >
> | > int main(int argc, char *argv[])
> | > {
> | > int ret, fd;
> | > char *port;
> | > struct termios tio, original;
> | >
> | > port = argv[1];
> | > if (!port)
> | > port = "/dev/ttyUSB0";
> | >
> | > fd = open(port, O_RDWR | O_NONBLOCK | O_NOCTTY);
> | > if (fd < 0) {
> | > perror("open()");
> | > exit(1);
> | > }
> | >
> | > usleep(100);
> | > ret = tcgetattr(fd, &original);
> | > if (ret < 0) {
> | > perror("tcgetattr()");
> | > exit(1);
> | > }
> | >
> | > ret = close(fd);
> | > if (ret) {
> | > perror("close()");
> | > exit(1);
> | > }
> | >
> | > return 0;
> | > }
> | >
> | > with a Siemens CX65 mobile (which uses the pl2303 driver), I get the
> | > following NULL pointer deference:
> | >
> | > Nov 15 12:32:19 tirion kernel: [ 147.009410] Unable to handle kernel
> NULL pointer dereference at virtual address 00a4
> | > Nov 15 12:32:19 tirion kernel: [ 147.009430] printing eip:
> | > Nov 15 12:32:19 tirion kernel: [ 147.009436] d0a1f888
> | > Nov 15 12:32:19 tirion kernel: [ 147.009441] *pde =
> | > Nov 15 12:32:19 tirion kernel: [ 147.009449] Oops: [#1]
> | > Nov 15 12:32:19 tirion kernel: [ 147.009454] DEBUG_PAGEALLOC
> | > Nov 15 12:32:19 tirion kernel: [ 147.009461] Modules linked in: pl2303
> usbserial ide_cd cdrom e100 mii uhci_hcd ehci_hcd usbcore quota_v2 snd_cs46xx
> snd_rawmidi snd_seq_device snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd
> soundcore snd_page_alloc
> | > Nov 15 12:32:19 tirion kernel: [ 147.009504] CPU:0
> | > Nov 15 12:32:19 tirion kernel: [ 147.009507] EIP:
> 0060:[pg0+275417224/1070101504]Not tainted VLI
> | > Nov 15 12:32:19 tirion kernel: [ 147.009512] EFLAGS: 00210246
> (2.6.15-rc1y-gee90f62b)
> | > Nov 15 12:32:19 tirion kernel: [ 147.009548] EIP is at
> serial_ioctl+0x28/0xd0 [usbserial]
> | > Nov 15 12:32:19 tirion kernel: [ 147.009558] eax: ebx:
> ecx: 5401 edx: c99c4f58
> | > Nov 15 12:32:19 tirion kernel: [ 147.009569] esi: ffed edi:
> 5401 ebp: c94c3f3c esp: c94c3f18
> | > Nov 15 12:32:19 tirion kernel: [ 147.009578] ds: 007b es: 007b ss:
> 0068
> | > Nov 15 12:32:19 tirion kernel: [ 147.009588] Process termios_set (pid:
> 3091, threadinfo=c94c2000 task=c9ba6ad0)
> | > Nov 15 12:32:19 tirion kernel: [ 147.009595] Stack: c95c1b7c
> b7f014e0 c94c3f5c c0144ed6 c99c4f58 cb0eedf8 d0a1f860
> | > Nov 15 12:32:19 tirion kernel: [ 147.009618]c9bd6000 c94c3f60
> c01f5c23 bfc7c010 c9bd6000 5401 c99c4f58 c02eda60
> | > Nov 15 12:32:19 tirion kernel: [ 147.009640]c99c4f58 c01f5970
> c94c3f78 c0164ac8 bfc7c010 c99c4f58 0003
> | > Nov 15 12:32:19 tirion kernel: [ 147.009662] Call Trace:
> | > Nov 15 12:32:19 tirion kernel: [ 147.009668] [show_stack+122/144]
> show_stack+0x7a/0x90
> | > Nov 15 12:32:19 tirion kernel: [ 147.009689] [show_registers+330/432]
> show_registers+0x14a/0x1b0
> | > Nov 15 12:32:19 tirion kernel: [ 147.009702] [die+220/352]
> die+0xdc/0x160
> | > Nov 15 12:32:19 tirion kernel: [ 147.009714] [do_page_fault+724/1461]
> do_page_fault+0x2d4/0x5b5
> | > Nov 15 12:32:19 tirion kernel: [ 147.009738] [error_code+79/84]
> error_code+0x4f/0x54
> | > Nov 15 12:32:19 tirion kernel: [ 147.009750] [tty_ioctl+691/944]
> tty_ioctl+0x2b3/0x3b0
> | > Nov 15 12:32:19 tirion kernel: [ 147.009768] [do_ioctl+72/112]
> do_ioctl+0x48/0x70
> | > Nov 15 12:32:19 tirion kernel: [ 147.009786] [vfs_ioctl+95/416]
> vfs_ioctl+0x5f/0x1a0
> | > Nov 15 12:32:19 tirion kernel: [ 147.009798] [sys_ioctl+57/96]
> sys_ioctl+0x39/0x60
> | > Nov 15 12:32:19 tirion kernel: [ 147.009809] [syscall_call+7/11]
> syscall_call+0x7/0xb
> | > Nov 15 12:32:19 tirion kernel: [ 147.009820] Code: ef eb 88 55 89 e5 83
> ec 24 89 75 f8 be ed ff ff ff 89 7d fc 89 cf 89 5d f4 89 55 f0 8b 98 b4 09 00
> 00 a1 04 59 a2 d0 85 c0 75 78 <8b> 83 a4 00 00 00 85 c0 74 3e 8b 03 8b 70 04
> 8b 86 fc 00 00 00
> | >
> | > The deference is at drivers/usb/serial/usb-serial.c:352. The first fix I
> | > thought was just to check if 'port' is NULL, and to return '-ENODEV' if
> so.
> | > I did that, but it brought up another problem: when the bug is triggered
> | > (ie, 'port' is NULL) the serial port in use becomes invalid, and I have to
> | > replug the device's cable. This will force the device to take the next
> free
> | > port.
> | >
> |
[linux-usb-devel] Re: [PATCH] - Fixes NULL pointer deference in usb-serial driver.
On Wed, 16 Nov 2005 09:24:16 -0800
Greg KH <[EMAIL PROTECTED]> wrote:
| On Wed, Nov 16, 2005 at 03:16:34PM -0200, Luiz Fernando Capitulino wrote:
| > Hi Greg,
| >
| > If I run several instances of this program in parallel:
| >
| > #include
| > #include
| > #include
| > #include
| > #include
| > #include
| > #include
| > #include
| > #include
| > #include
| >
| > int main(int argc, char *argv[])
| > {
| > int ret, fd;
| > char *port;
| > struct termios tio, original;
| >
| > port = argv[1];
| > if (!port)
| > port = "/dev/ttyUSB0";
| >
| > fd = open(port, O_RDWR | O_NONBLOCK | O_NOCTTY);
| > if (fd < 0) {
| > perror("open()");
| > exit(1);
| > }
| >
| > usleep(100);
| > ret = tcgetattr(fd, &original);
| > if (ret < 0) {
| > perror("tcgetattr()");
| > exit(1);
| > }
| >
| > ret = close(fd);
| > if (ret) {
| > perror("close()");
| > exit(1);
| > }
| >
| > return 0;
| > }
| >
| > with a Siemens CX65 mobile (which uses the pl2303 driver), I get the
| > following NULL pointer deference:
| >
| > Nov 15 12:32:19 tirion kernel: [ 147.009410] Unable to handle kernel NULL
pointer dereference at virtual address 00a4
| > Nov 15 12:32:19 tirion kernel: [ 147.009430] printing eip:
| > Nov 15 12:32:19 tirion kernel: [ 147.009436] d0a1f888
| > Nov 15 12:32:19 tirion kernel: [ 147.009441] *pde =
| > Nov 15 12:32:19 tirion kernel: [ 147.009449] Oops: [#1]
| > Nov 15 12:32:19 tirion kernel: [ 147.009454] DEBUG_PAGEALLOC
| > Nov 15 12:32:19 tirion kernel: [ 147.009461] Modules linked in: pl2303
usbserial ide_cd cdrom e100 mii uhci_hcd ehci_hcd usbcore quota_v2 snd_cs46xx
snd_rawmidi snd_seq_device snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd
soundcore snd_page_alloc
| > Nov 15 12:32:19 tirion kernel: [ 147.009504] CPU:0
| > Nov 15 12:32:19 tirion kernel: [ 147.009507] EIP:
0060:[pg0+275417224/1070101504]Not tainted VLI
| > Nov 15 12:32:19 tirion kernel: [ 147.009512] EFLAGS: 00210246
(2.6.15-rc1y-gee90f62b)
| > Nov 15 12:32:19 tirion kernel: [ 147.009548] EIP is at
serial_ioctl+0x28/0xd0 [usbserial]
| > Nov 15 12:32:19 tirion kernel: [ 147.009558] eax: ebx:
ecx: 5401 edx: c99c4f58
| > Nov 15 12:32:19 tirion kernel: [ 147.009569] esi: ffed edi: 5401
ebp: c94c3f3c esp: c94c3f18
| > Nov 15 12:32:19 tirion kernel: [ 147.009578] ds: 007b es: 007b ss: 0068
| > Nov 15 12:32:19 tirion kernel: [ 147.009588] Process termios_set (pid:
3091, threadinfo=c94c2000 task=c9ba6ad0)
| > Nov 15 12:32:19 tirion kernel: [ 147.009595] Stack: c95c1b7c
b7f014e0 c94c3f5c c0144ed6 c99c4f58 cb0eedf8 d0a1f860
| > Nov 15 12:32:19 tirion kernel: [ 147.009618]c9bd6000 c94c3f60
c01f5c23 bfc7c010 c9bd6000 5401 c99c4f58 c02eda60
| > Nov 15 12:32:19 tirion kernel: [ 147.009640]c99c4f58 c01f5970
c94c3f78 c0164ac8 bfc7c010 c99c4f58 0003
| > Nov 15 12:32:19 tirion kernel: [ 147.009662] Call Trace:
| > Nov 15 12:32:19 tirion kernel: [ 147.009668] [show_stack+122/144]
show_stack+0x7a/0x90
| > Nov 15 12:32:19 tirion kernel: [ 147.009689] [show_registers+330/432]
show_registers+0x14a/0x1b0
| > Nov 15 12:32:19 tirion kernel: [ 147.009702] [die+220/352] die+0xdc/0x160
| > Nov 15 12:32:19 tirion kernel: [ 147.009714] [do_page_fault+724/1461]
do_page_fault+0x2d4/0x5b5
| > Nov 15 12:32:19 tirion kernel: [ 147.009738] [error_code+79/84]
error_code+0x4f/0x54
| > Nov 15 12:32:19 tirion kernel: [ 147.009750] [tty_ioctl+691/944]
tty_ioctl+0x2b3/0x3b0
| > Nov 15 12:32:19 tirion kernel: [ 147.009768] [do_ioctl+72/112]
do_ioctl+0x48/0x70
| > Nov 15 12:32:19 tirion kernel: [ 147.009786] [vfs_ioctl+95/416]
vfs_ioctl+0x5f/0x1a0
| > Nov 15 12:32:19 tirion kernel: [ 147.009798] [sys_ioctl+57/96]
sys_ioctl+0x39/0x60
| > Nov 15 12:32:19 tirion kernel: [ 147.009809] [syscall_call+7/11]
syscall_call+0x7/0xb
| > Nov 15 12:32:19 tirion kernel: [ 147.009820] Code: ef eb 88 55 89 e5 83 ec
24 89 75 f8 be ed ff ff ff 89 7d fc 89 cf 89 5d f4 89 55 f0 8b 98 b4 09 00 00
a1 04 59 a2 d0 85 c0 75 78 <8b> 83 a4 00 00 00 85 c0 74 3e 8b 03 8b 70 04 8b 86
fc 00 00 00
| >
| > The deference is at drivers/usb/serial/usb-serial.c:352. The first fix I
| > thought was just to check if 'port' is NULL, and to return '-ENODEV' if so.
| > I did that, but it brought up another problem: when the bug is triggered
| > (ie, 'port' is NULL) the serial port in use becomes invalid, and I have to
| > replug the device's cable. This will force the device to take the next free
| > port.
| >
| > We cannot live with this of course, because the numbers of ports is
| > limited.
| >
| > My guess is:
| >
| > 1. Process A calls open() and tcgetattr(). When it calls close(), the
specific
| > driver function put it to sleep at usb_serial.c:242 (I'm using pl2303
driv
[linux-usb-devel] Re: [PATCH] - Fixes NULL pointer deference in usb-serial driver.
On Wed, Nov 16, 2005 at 03:16:34PM -0200, Luiz Fernando Capitulino wrote:
> Hi Greg,
>
> If I run several instances of this program in parallel:
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> int main(int argc, char *argv[])
> {
> int ret, fd;
> char *port;
> struct termios tio, original;
>
> port = argv[1];
> if (!port)
> port = "/dev/ttyUSB0";
>
> fd = open(port, O_RDWR | O_NONBLOCK | O_NOCTTY);
> if (fd < 0) {
> perror("open()");
> exit(1);
> }
>
> usleep(100);
> ret = tcgetattr(fd, &original);
> if (ret < 0) {
> perror("tcgetattr()");
> exit(1);
> }
>
> ret = close(fd);
> if (ret) {
> perror("close()");
> exit(1);
> }
>
> return 0;
> }
>
> with a Siemens CX65 mobile (which uses the pl2303 driver), I get the
> following NULL pointer deference:
>
> Nov 15 12:32:19 tirion kernel: [ 147.009410] Unable to handle kernel NULL
> pointer dereference at virtual address 00a4
> Nov 15 12:32:19 tirion kernel: [ 147.009430] printing eip:
> Nov 15 12:32:19 tirion kernel: [ 147.009436] d0a1f888
> Nov 15 12:32:19 tirion kernel: [ 147.009441] *pde =
> Nov 15 12:32:19 tirion kernel: [ 147.009449] Oops: [#1]
> Nov 15 12:32:19 tirion kernel: [ 147.009454] DEBUG_PAGEALLOC
> Nov 15 12:32:19 tirion kernel: [ 147.009461] Modules linked in: pl2303
> usbserial ide_cd cdrom e100 mii uhci_hcd ehci_hcd usbcore quota_v2 snd_cs46xx
> snd_rawmidi snd_seq_device snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd
> soundcore snd_page_alloc
> Nov 15 12:32:19 tirion kernel: [ 147.009504] CPU:0
> Nov 15 12:32:19 tirion kernel: [ 147.009507] EIP:
> 0060:[pg0+275417224/1070101504]Not tainted VLI
> Nov 15 12:32:19 tirion kernel: [ 147.009512] EFLAGS: 00210246
> (2.6.15-rc1y-gee90f62b)
> Nov 15 12:32:19 tirion kernel: [ 147.009548] EIP is at
> serial_ioctl+0x28/0xd0 [usbserial]
> Nov 15 12:32:19 tirion kernel: [ 147.009558] eax: ebx:
> ecx: 5401 edx: c99c4f58
> Nov 15 12:32:19 tirion kernel: [ 147.009569] esi: ffed edi: 5401
> ebp: c94c3f3c esp: c94c3f18
> Nov 15 12:32:19 tirion kernel: [ 147.009578] ds: 007b es: 007b ss: 0068
> Nov 15 12:32:19 tirion kernel: [ 147.009588] Process termios_set (pid: 3091,
> threadinfo=c94c2000 task=c9ba6ad0)
> Nov 15 12:32:19 tirion kernel: [ 147.009595] Stack: c95c1b7c
> b7f014e0 c94c3f5c c0144ed6 c99c4f58 cb0eedf8 d0a1f860
> Nov 15 12:32:19 tirion kernel: [ 147.009618]c9bd6000 c94c3f60
> c01f5c23 bfc7c010 c9bd6000 5401 c99c4f58 c02eda60
> Nov 15 12:32:19 tirion kernel: [ 147.009640]c99c4f58 c01f5970
> c94c3f78 c0164ac8 bfc7c010 c99c4f58 0003
> Nov 15 12:32:19 tirion kernel: [ 147.009662] Call Trace:
> Nov 15 12:32:19 tirion kernel: [ 147.009668] [show_stack+122/144]
> show_stack+0x7a/0x90
> Nov 15 12:32:19 tirion kernel: [ 147.009689] [show_registers+330/432]
> show_registers+0x14a/0x1b0
> Nov 15 12:32:19 tirion kernel: [ 147.009702] [die+220/352] die+0xdc/0x160
> Nov 15 12:32:19 tirion kernel: [ 147.009714] [do_page_fault+724/1461]
> do_page_fault+0x2d4/0x5b5
> Nov 15 12:32:19 tirion kernel: [ 147.009738] [error_code+79/84]
> error_code+0x4f/0x54
> Nov 15 12:32:19 tirion kernel: [ 147.009750] [tty_ioctl+691/944]
> tty_ioctl+0x2b3/0x3b0
> Nov 15 12:32:19 tirion kernel: [ 147.009768] [do_ioctl+72/112]
> do_ioctl+0x48/0x70
> Nov 15 12:32:19 tirion kernel: [ 147.009786] [vfs_ioctl+95/416]
> vfs_ioctl+0x5f/0x1a0
> Nov 15 12:32:19 tirion kernel: [ 147.009798] [sys_ioctl+57/96]
> sys_ioctl+0x39/0x60
> Nov 15 12:32:19 tirion kernel: [ 147.009809] [syscall_call+7/11]
> syscall_call+0x7/0xb
> Nov 15 12:32:19 tirion kernel: [ 147.009820] Code: ef eb 88 55 89 e5 83 ec
> 24 89 75 f8 be ed ff ff ff 89 7d fc 89 cf 89 5d f4 89 55 f0 8b 98 b4 09 00 00
> a1 04 59 a2 d0 85 c0 75 78 <8b> 83 a4 00 00 00 85 c0 74 3e 8b 03 8b 70 04 8b
> 86 fc 00 00 00
>
> The deference is at drivers/usb/serial/usb-serial.c:352. The first fix I
> thought was just to check if 'port' is NULL, and to return '-ENODEV' if so.
> I did that, but it brought up another problem: when the bug is triggered
> (ie, 'port' is NULL) the serial port in use becomes invalid, and I have to
> replug the device's cable. This will force the device to take the next free
> port.
>
> We cannot live with this of course, because the numbers of ports is
> limited.
>
> My guess is:
>
> 1. Process A calls open() and tcgetattr(). When it calls close(), the specific
> driver function put it to sleep at usb_serial.c:242 (I'm using pl2303 driver)
>
> 2. Process B calls open() and before the call to tcgetattr() it is put to
> sleep.
>
> 3. Process A wakes up and finish the close procedure (which resets
> 'po
[linux-usb-devel] [PATCH] - Removes unused data from pl2303 driver.
Hi Greg,
This patch removes unused data from pl2303 driver.
Signed-off-by: Luiz Capitulino <[EMAIL PROTECTED]>
drivers/usb/serial/pl2303.c |4
1 files changed, 4 deletions(-)
diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
--- a/drivers/usb/serial/pl2303.c
+++ b/drivers/usb/serial/pl2303.c
@@ -39,11 +39,7 @@
static int debug;
#define PL2303_CLOSING_WAIT(30*HZ)
-
#define PL2303_BUF_SIZE1024
-#define PL2303_TMP_BUF_SIZE1024
-
-static DECLARE_MUTEX(pl2303_tmp_buf_sem);
struct pl2303_buf {
unsigned intbuf_size;
--
Luiz Fernando N. Capitulino
---
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
___
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] - Fixes NULL pointer deference in usb-serial driver.
Hi Greg,
If I run several instances of this program in parallel:
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
int main(int argc, char *argv[])
{
int ret, fd;
char *port;
struct termios tio, original;
port = argv[1];
if (!port)
port = "/dev/ttyUSB0";
fd = open(port, O_RDWR | O_NONBLOCK | O_NOCTTY);
if (fd < 0) {
perror("open()");
exit(1);
}
usleep(100);
ret = tcgetattr(fd, &original);
if (ret < 0) {
perror("tcgetattr()");
exit(1);
}
ret = close(fd);
if (ret) {
perror("close()");
exit(1);
}
return 0;
}
with a Siemens CX65 mobile (which uses the pl2303 driver), I get the
following NULL pointer deference:
Nov 15 12:32:19 tirion kernel: [ 147.009410] Unable to handle kernel NULL
pointer dereference at virtual address 00a4
Nov 15 12:32:19 tirion kernel: [ 147.009430] printing eip:
Nov 15 12:32:19 tirion kernel: [ 147.009436] d0a1f888
Nov 15 12:32:19 tirion kernel: [ 147.009441] *pde =
Nov 15 12:32:19 tirion kernel: [ 147.009449] Oops: [#1]
Nov 15 12:32:19 tirion kernel: [ 147.009454] DEBUG_PAGEALLOC
Nov 15 12:32:19 tirion kernel: [ 147.009461] Modules linked in: pl2303
usbserial ide_cd cdrom e100 mii uhci_hcd ehci_hcd usbcore quota_v2 snd_cs46xx
snd_rawmidi snd_seq_device snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd
soundcore snd_page_alloc
Nov 15 12:32:19 tirion kernel: [ 147.009504] CPU:0
Nov 15 12:32:19 tirion kernel: [ 147.009507] EIP:
0060:[pg0+275417224/1070101504]Not tainted VLI
Nov 15 12:32:19 tirion kernel: [ 147.009512] EFLAGS: 00210246
(2.6.15-rc1y-gee90f62b)
Nov 15 12:32:19 tirion kernel: [ 147.009548] EIP is at serial_ioctl+0x28/0xd0
[usbserial]
Nov 15 12:32:19 tirion kernel: [ 147.009558] eax: ebx:
ecx: 5401 edx: c99c4f58
Nov 15 12:32:19 tirion kernel: [ 147.009569] esi: ffed edi: 5401
ebp: c94c3f3c esp: c94c3f18
Nov 15 12:32:19 tirion kernel: [ 147.009578] ds: 007b es: 007b ss: 0068
Nov 15 12:32:19 tirion kernel: [ 147.009588] Process termios_set (pid: 3091,
threadinfo=c94c2000 task=c9ba6ad0)
Nov 15 12:32:19 tirion kernel: [ 147.009595] Stack: c95c1b7c b7f014e0
c94c3f5c c0144ed6 c99c4f58 cb0eedf8 d0a1f860
Nov 15 12:32:19 tirion kernel: [ 147.009618]c9bd6000 c94c3f60 c01f5c23
bfc7c010 c9bd6000 5401 c99c4f58 c02eda60
Nov 15 12:32:19 tirion kernel: [ 147.009640]c99c4f58 c01f5970 c94c3f78
c0164ac8 bfc7c010 c99c4f58 0003
Nov 15 12:32:19 tirion kernel: [ 147.009662] Call Trace:
Nov 15 12:32:19 tirion kernel: [ 147.009668] [show_stack+122/144]
show_stack+0x7a/0x90
Nov 15 12:32:19 tirion kernel: [ 147.009689] [show_registers+330/432]
show_registers+0x14a/0x1b0
Nov 15 12:32:19 tirion kernel: [ 147.009702] [die+220/352] die+0xdc/0x160
Nov 15 12:32:19 tirion kernel: [ 147.009714] [do_page_fault+724/1461]
do_page_fault+0x2d4/0x5b5
Nov 15 12:32:19 tirion kernel: [ 147.009738] [error_code+79/84]
error_code+0x4f/0x54
Nov 15 12:32:19 tirion kernel: [ 147.009750] [tty_ioctl+691/944]
tty_ioctl+0x2b3/0x3b0
Nov 15 12:32:19 tirion kernel: [ 147.009768] [do_ioctl+72/112]
do_ioctl+0x48/0x70
Nov 15 12:32:19 tirion kernel: [ 147.009786] [vfs_ioctl+95/416]
vfs_ioctl+0x5f/0x1a0
Nov 15 12:32:19 tirion kernel: [ 147.009798] [sys_ioctl+57/96]
sys_ioctl+0x39/0x60
Nov 15 12:32:19 tirion kernel: [ 147.009809] [syscall_call+7/11]
syscall_call+0x7/0xb
Nov 15 12:32:19 tirion kernel: [ 147.009820] Code: ef eb 88 55 89 e5 83 ec 24
89 75 f8 be ed ff ff ff 89 7d fc 89 cf 89 5d f4 89 55 f0 8b 98 b4 09 00 00 a1
04 59 a2 d0 85 c0 75 78 <8b> 83 a4 00 00 00 85 c0 74 3e 8b 03 8b 70 04 8b 86 fc
00 00 00
The deference is at drivers/usb/serial/usb-serial.c:352. The first fix I
thought was just to check if 'port' is NULL, and to return '-ENODEV' if so.
I did that, but it brought up another problem: when the bug is triggered
(ie, 'port' is NULL) the serial port in use becomes invalid, and I have to
replug the device's cable. This will force the device to take the next free
port.
We cannot live with this of course, because the numbers of ports is
limited.
My guess is:
1. Process A calls open() and tcgetattr(). When it calls close(), the specific
driver function put it to sleep at usb_serial.c:242 (I'm using pl2303 driver)
2. Process B calls open() and before the call to tcgetattr() it is put to
sleep.
3. Process A wakes up and finish the close procedure (which resets
'port->tty->driver_data')
4. Process B wakes up, executes serial_ioctl() and gets a NULL pointer in
'port->tty->driver_data'.
So, based on my guess the right fix _seems_ to be serialize the construction
and destruction of 'port'. The following patch does that, I can run hundreds
Re: [linux-usb-devel] EHCI Split Isochronous issues
On Wednesday 16 November 2005 2:53 am, Manjunath B S wrote: > b. When I try to dump raw data onto the dsp device file, the Host > Controller issues a FATAL. This problem is easily reproduced by > dumping a very large file onto the dsp device file. Yes, the ISO support is still EXPERIMENTAL. Seems to work OK until multi-microframe transactions kick in. I never had time to put together a good enough test setup for those. > While looking into the sources, I found a couple of issues and have > fixed the same. I would like to confirm the changes before submission. > > i. In the scan_periodic() (ehci-sched.c) the ISO caching is not taken > into consideration and in case of periodically scheduled SITD's with > IOC set, the interrupt is raised with the precision as configured by > log2_irq_thresh parameter (ehci-hcd.c). When the IOC is raised, the > periodic schedule is altered. Section 4.7.2.1 of the EHCI spec says that the caching applies to how the controller prefetches schedule information ... so it's used when scheduling, not when scanning for completions. I'm not sure why you think scan_periodic() should care about how many (S)ITDs may have been cached, since they're only removed from the schedule when they've completed. Are you thinking that the caching affects writeback for partial (S)ITD completion? I don't see that written in the spec, but then I did find the whole "scheduling threshold" discussion to be weak. > ii. With the Interrupt threshold configured for 125 us and the SITD > completing early in the frame, the Interrupt is raised and the > schedule altered, while the Host Controller is still in the same > frame. Some Host Controllers (including the one I'm working on) report > a fatal in these circumstances, in spite of "live" checks in the > scan_periodic logic. The "active" tests are to make sure that when the HC hasn't yet finished with an (S)ITD, the HCD knows it has to re-scan. What's the mechanism you're thinking for the FATAL error? Would it suffice to stop scanning (S)ITD entries -- only if caching is done! -- as soon as an active one is found? That'd get tricky, since not all (S)ITDs cause IRQs, and the interrupt QH entries would still need to be scanned... I don't much like the way ISO data structures work. It'd be better (from the software perspective) if ISO transfers just had queues of TDs ... that is, working more like OHCI than like UHCI. > In my opinion, we should refrain from scanning the live frame which > the Host Controller is currently reading and read only till the end of > previous frame. Why? >But this logic with Interrupt threshold less than 1 ms > precision will break the Isochronous behaviour 'coz it will not read > the last completed packet descriptor. Could you explain? It's intended to work regardless of the IRQ threshold, by scanning everything that could have been completed since the last IRQ. >I've configured the Interrupt > threshold to be 1ms and have tested the logic and it is working fine. A high IRQ threshold (increased latency) will slow down various things that don't relate to ISO transfers at all. > c. The function tt_no_collision() (ehci-sched.c) called from > sitd_slot_ok(), is passed wrong period. tt_no_collision() expects the > period in terms of frames. The call passes "period_uframes << 3", which is the period in frames... > d. In the function sitd_slot_ok(), we are scanning from the first > frame till the end, and tt_no_collision() also scans every frame in > the schedule, is it not sufficient to call tt_no_collision() only once > instead of calling it in a loop in sitd_slot_ok() ?? The scheduling decision is supposed to make sure that the specified slot will always be available. If it only checked one frame, it would overlook collisions in other frames. That said, Dan Streetman is looking at some updates to the TT scheduling logic which should give denser packing of the available TT slots. - Dave --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click ___ 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] Re: [Linux-ATM-General] pushing a NULL skbuff
Hi Alan, thanks for taking the time to reply. > > I think it's safe to assume that if a USB device is disconnected and > > reconnected > > then the old USB device will have called shutdown_atm_dev (this is called > > in the > > disconnect method) before the new USB device creates an ATM device (this is > > done > > in the probe method or later). But I'm not sure. It might not be true if > > someone > > managed to unplug from one port and plug into another in less than 200 > > milliseconds. > > It also might not be true I suppose if the device was disconnected by the > > hub due > > to some kind of electrical problem, and reassigned by the hub to a > > different port > > (I don't know if any hubs play this kind of trick). I guess that any kind > > of > > disconnect/reconnect on the same USB port, real or logical, will see the > > old device > > disconnected before the new device is probed. Maybe some of the USB guys > > can > > confirm this. > > It is true that disconnect on a port will always complete before a > reconnect on that same port begins. It will also complete before > reconnect on another port, although here you're getting into a murky area. > For instance, what if someone has two of these USB ATM devices and plugs > the second one in just before disconnecting the first? > > A driver should be robust enough to work in any situation, regardless of > the order of disconnect and probe calls. The only reason for possible > problems would be if the driver had a notion of "device identity" -- that > is, it could tell if two different instances actually were the same > device. The problem here is the way ATM connections are opened: you specify a device number, called the interface number, as well as some other info. Alternatively, you can specify ATM_ITF_ANY instead of a device number, and all devices will be queried until one is found that is prepared to open the connection. With the speedtouch USB modems, the problem people usually see is: (A) for normal people, the modem is the only ATM device (and there's only one modem). Thus this is ATM device zero. (B) people connect using pppd; pppd doesn't support ATM_ITF_ANY, so most people specify that the connection should be to device number 0. pppd is usually run from a hotplug or init script. (C) at some point the modem spontaneously disconnects and reconnects (surprisingly common with some motherboards). pppd takes several seconds to understand that ATM device 0 has died; until it understands this, it keeps a connection open, which means that the ATM device hangs around. The "new" modem (= old one reconnected) creates a new ATM device, which is given device number 1, because number 0 is still being used by the old device. (D) a new instance of pppd is launched from a hotplug script, or the old instance of pppd tries to open a new connection once it understands that the old connection has died. It tries to connect to device 0, but there is no longer any device 0, only device 1, so the connection attempt fails. (E) the user notices that there is no internet connection and wonders why. The user runs pppd by hand - and it still fails to connect (no device 0). Eventually the user gives up and reboots the machine. Ciao, Duncan. --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click ___ 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] HELP: Problem with HP Laserjet 1022 and USB in Linux 2.6.12
On Wed, 16 Nov 2005, Neil Brown wrote: > I've got piles of usbmon logs, and I'm happy to create more. Could > you be specific about that would help, and different setting show > different things differently :-) > > For example, I have a rather nice log with 64 byte writes (so there is > one packet per UDB). If I take the completion time stamps, find the > remainder after dividing by 111838(microseconds) and graph that I get > a really interesting graph!! I cannot explain all the features, but > I'm sure they correlate significantly to some aspect of the printer > hardware If it's so interesting, post it! > I guess the question is what size write request would be most helpful. > 8192bytes means there is plenty of opportunity for FSBR to push lots > of packets out, but it means that each record reported by usbmon > corresponds to 128 packets, so you lose a lot of detail. > 64bytes gives more detail, but with less chance for FSBR to have an > effect (as usblp only submits one URB at a time). > Maybe 512 would be a reasonable compromise? 64 bytes is probably best. You don't lose any FSBR performance, because FSBR isn't turned off immediately when an URB completes. > > It would also be worthwhile to see if you can get more or less the same > > effect without all those changes, just by increasing IDLE_TIMEOUT to 1000 > > ms or something like that. > > I did get similar throughput with IDLE_TIMEOUT set to 5. 1000 > wouldn't be enough with 8K writes, as an 8K write often takes more > than one second. That's what I'd like to understand. Even with FSBR on all the time, it still takes more than 1000 ms to transfer 128 packets (i.e., 8192 bytes)? Do the packets get sent in fixed-size clumps, or is it more random? If the printer was at all sane, it wouldn't take more than 300 ms to transfer that much data even with FSBR permanently off! > But I'm happy to redo some tests to be able to give > you clear before/after results. It'll probably have to wait a week or > so, as I've spent more time on this that I really should have lately. It might be more interesting to find out how the printer manages to work more quickly under Windows (assuming it does, of course). If you want to spend the time, you could try tracing some of that communication. Alan Stern --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click ___ 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 stack hangs after sporadic disconnect
On Tue, 15 Nov 2005, Jan Kiszka wrote: > Trace attached. One ehci_endpoint_disable call actually does not return. > > I furthermore had my box running without ehci for about 8 hours today, > and no disconnect occured. > > Next step? Unfortunately the stack trace doesn't mention khubd. Undoubtedly the trace overran the kernel's log buffer. You could try reconfiguring the kernel to increase the log-buffer size. Still, the log definitely shows that there's something wrong with ehci_endpoint_disable. Perhaps David Brownell will be able to give you more advice about where to look more closely. Alan Stern > Nov 15 19:27:29 nibbler -- MARK -- > Nov 15 19:47:30 nibbler -- MARK -- > Nov 15 20:07:30 nibbler -- MARK -- > Nov 15 20:07:39 nibbler kernel: hub 4-0:1.0: state 5 ports 6 chg evt 0008 > Nov 15 20:07:39 nibbler kernel: ehci_hcd :00:10.3: GetStatus port 3 > status 00180b POWER sig=j PEC CSC CONNECT > Nov 15 20:07:39 nibbler kernel: hub 4-0:1.0: port 3, status 0501, change > 0003, 480 Mb/s > Nov 15 20:07:39 nibbler kernel: usb 4-3: USB disconnect, address 2 > Nov 15 20:07:39 nibbler kernel: usb 4-3: usb_disable_device nuking all URBs > Nov 15 20:07:39 nibbler kernel: ehci_endpoint_disable:enter > Nov 15 20:07:39 nibbler kernel: ehci_endpoint_disable:exit > Nov 15 20:07:39 nibbler kernel: ehci_endpoint_disable:enter > Nov 15 20:07:39 nibbler kernel: ehci_endpoint_disable:exit > Nov 15 20:07:39 nibbler kernel: ehci_endpoint_disable:enter > Nov 15 20:07:39 nibbler kernel: ehci_endpoint_disable:exit > Nov 15 20:07:39 nibbler kernel: ehci_hcd :00:10.3: shutdown urb c6b55820 > pipe c0008280 ep1in-bulk > Nov 15 20:07:39 nibbler kernel: ehci_endpoint_disable:enter > Nov 15 20:27:30 nibbler -- MARK -- > Nov 15 20:47:30 nibbler -- MARK -- > Nov 15 21:07:31 nibbler -- MARK -- --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click ___ 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] Re: [Linux-ATM-General] pushing a NULL skbuff
On Wed, 16 Nov 2005, Duncan Sands wrote: > I think it's safe to assume that if a USB device is disconnected and > reconnected > then the old USB device will have called shutdown_atm_dev (this is called in > the > disconnect method) before the new USB device creates an ATM device (this is > done > in the probe method or later). But I'm not sure. It might not be true if > someone > managed to unplug from one port and plug into another in less than 200 > milliseconds. > It also might not be true I suppose if the device was disconnected by the hub > due > to some kind of electrical problem, and reassigned by the hub to a different > port > (I don't know if any hubs play this kind of trick). I guess that any kind of > disconnect/reconnect on the same USB port, real or logical, will see the old > device > disconnected before the new device is probed. Maybe some of the USB guys can > confirm this. It is true that disconnect on a port will always complete before a reconnect on that same port begins. It will also complete before reconnect on another port, although here you're getting into a murky area. For instance, what if someone has two of these USB ATM devices and plugs the second one in just before disconnecting the first? A driver should be robust enough to work in any situation, regardless of the order of disconnect and probe calls. The only reason for possible problems would be if the driver had a notion of "device identity" -- that is, it could tell if two different instances actually were the same device. Alan Stern --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click ___ 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] Asking for advice on extending a USB 2.0 interface in OMAP5912 platform
On Wednesday 16 November 2005 5:50 am, Li Weichen wrote: > Hi everyone, > > I am working on a project in which a USB 2.0 interface is required to hook > up a USB 802.11g wlan card. The CPU is OMAP5912, it only integrates a USB > 1.1 interface. So I need to extend a USB 2.0 interface. Does anyone have > any kind advices on the interface chip or driver or any related information? The full speed host interface on OMAP 5912 is USB 2.0 compatible, so you should be all set. Unless you mean "high speed usb"? In which case, you'll need some external chip. Your TI contacts should be able to point you towards some high speed USB solutions that work with OMAP. - Dave --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click ___ 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.14] ftdi_sio: new IDs for KOBIL devices
From: Ian Abbott <[EMAIL PROTECTED]>
Hi Greg,
This patch adds two new devices to the ftdi_sio driver's device ID
table. The device IDs were supplied by Stefan Nies of KOBIL Systems for
two of their devices using the FTDI chip.
Please apply, thanks!
Signed-off-by: Ian Abbott <[EMAIL PROTECTED]>
diff -ur a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
--- a/drivers/usb/serial/ftdi_sio.c 2005-11-16 14:04:51.0 +
+++ b/drivers/usb/serial/ftdi_sio.c 2005-11-16 14:09:35.0 +
@@ -471,6 +471,8 @@
{ USB_DEVICE(FTDI_VID, FTDI_MHAM_Y6_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_MHAM_Y8_PID) },
{ USB_DEVICE(EVOLUTION_VID, EVOLUTION_ER1_PID) },
+ { USB_DEVICE(KOBIL_VID, KOBIL_CONV_B1_PID) },
+ { USB_DEVICE(KOBIL_VID, KOBIL_CONV_KAAN_PID) },
{ }, /* Optional parameter entry */
{ } /* Terminating entry */
};
diff -ur a/drivers/usb/serial/ftdi_sio.h b/drivers/usb/serial/ftdi_sio.h
--- a/drivers/usb/serial/ftdi_sio.h 2005-11-16 14:04:51.0 +
+++ b/drivers/usb/serial/ftdi_sio.h 2005-11-16 14:08:28.0 +
@@ -128,6 +128,13 @@
#define SEALEVEL_2803_8_PID 0X2883 /* SeaLINK+8 (2803) Port 8 */
/*
+ * The following are the values for two KOBIL chipcard terminals.
+ */
+#define KOBIL_VID 0x0d46 /* KOBIL Vendor ID */
+#define KOBIL_CONV_B1_PID 0x2020 /* KOBIL Konverter for B1 */
+#define KOBIL_CONV_KAAN_PID 0x2021 /* KOBIL_Konverter for KAAN */
+
+/*
* DSS-20 Sync Station for Sony Ericsson P800
*/
[linux-usb-devel] Re: [Linux-ATM-General] pushing a NULL skbuff
Hi Mitch, > Or we can just ressurect the patch I made 2 years ago that just kills > ATM_ITF_ANY since it's a really bad idea and always was: > http://sourceforge.net/mailarchive/message.php?msg_id=6032218 > (Note: that patch also adds auto-loading of devices) why is it a bad idea? > The real problems of having an ATM device asynchronously dissappear needs > some work to fix -- probably dead atm_dev's need to be garbage-collected > after the final VCC close happens (but have them disappear from atm_devs > immediately). It requires some thought to get the API ramifications right > but it's not impossible. Are you talking about the problem that you might try to connect to a dead device? Otherwise, I don't see that there is a problem (well, there is a problem with pppoatm, but that's different). > But don't paper over the problem by recommending people use ATM_ITF_ANY. > That's seriously the wrong thing to do. I think it's safe to assume that if a USB device is disconnected and reconnected then the old USB device will have called shutdown_atm_dev (this is called in the disconnect method) before the new USB device creates an ATM device (this is done in the probe method or later). But I'm not sure. It might not be true if someone managed to unplug from one port and plug into another in less than 200 milliseconds. It also might not be true I suppose if the device was disconnected by the hub due to some kind of electrical problem, and reassigned by the hub to a different port (I don't know if any hubs play this kind of trick). I guess that any kind of disconnect/reconnect on the same USB port, real or logical, will see the old device disconnected before the new device is probed. Maybe some of the USB guys can confirm this. In that case, we only need to be able to handle attempts to open a connection in the following situation: - there are some dead devices for which shutdown_atm_dev has been called; these devices would have accepted a connection when they were alive, but now their open methods will return a failure code - there is a live device, added after the other devices were marked as dead, which will accept the connection if asked; the connection should be made to this device Currently ATM_ITF_ANY handles this: it walks all devices, dead or alive, and tries the find one that will accept a connection. What is wrong with that? If instead ATM_ITF_ANY just tried the most recently added device, that would work too in this case, but it seems like a pointless loss of functionality. Autoloading of devices doesn't help in this case since the USB device is either plugged in (and thus exists as an ATM device), or it isn't, and no software can make it so! (Though you could generate a message asking the user to plug it in ;) ). As you can see, I'm confused by your statement that ATM_ITF_ANY is a bad idea: it seems like a fine idea to me. All the best, Duncan. --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click ___ 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] Re: nokia_dku2 driver is unsuitable for certain Nokia phones
On Wed, 9 Nov 2005, Greg KH wrote: Yeah, but this means dku2 would have to be a fully standalone driver, rather than a plugin to usb-serial. But that would mean it would actually work :) Hi Greg, it seems the current dku2 driver made it to 2.6.15-rc1. I think the discussion made it clear that it should be removed, and reworked into a more generic driver (that doesn't hardcode endpoints) or taken entirely to the userspace. Currently it works for some (very few) Nokia phones, does nothing for most others, and, worst of all, gets in the way of working OBEX support for some phones. Please remove it. Alexander Homepage: http://www.sensi.org/~ak/ --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click ___ 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] Asking for advice on extending a USB 2.0 interface in OMAP5912 platform
Hi everyone, I am working on a project in which a USB 2.0 interface is required to hook up a USB 802.11g wlan card. The CPU is OMAP5912, it only integrates a USB 1.1 interface. So I need to extend a USB 2.0 interface. Does anyone have any kind advices on the interface chip or driver or any related information? Thank you in advance and best regards! Li Weichen 2005-11-16 --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click ___ 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] EHCI Split Isochronous issues
Hello All, I am currently working on a proprietary MIPS based platform running ported 2.6.11.11 Kernel. I'm testing the EHCI Split Isochronous functionality with a Yamaha USB Speaker connected to the board and am seeing a couple of issues: a. The Kernel used to crash in the function tt_no_collision() (ehci-sched.c) while dumping raw data to the dsp device file (/dev/dsp) and I'd patched the same. I see that this bug has been fixed in the latest kernel sources (2.6.14). b. When I try to dump raw data onto the dsp device file, the Host Controller issues a FATAL. This problem is easily reproduced by dumping a very large file onto the dsp device file. All the EHCI configurations were found to be correct and the Interrupt threshold (log2_irq_thresh) was unchanged to raise interrupts at 125 us precision. The Host Controller has the capability to cache a single uframe. The length of the periodic schedule is 1024. While looking into the sources, I found a couple of issues and have fixed the same. I would like to confirm the changes before submission. i. In the scan_periodic() (ehci-sched.c) the ISO caching is not taken into consideration and in case of periodically scheduled SITD's with IOC set, the interrupt is raised with the precision as configured by log2_irq_thresh parameter (ehci-hcd.c). When the IOC is raised, the periodic schedule is altered. ii. With the Interrupt threshold configured for 125 us and the SITD completing early in the frame, the Interrupt is raised and the schedule altered, while the Host Controller is still in the same frame. Some Host Controllers (including the one I'm working on) report a fatal in these circumstances, in spite of "live" checks in the scan_periodic logic. In my opinion, we should refrain from scanning the live frame which the Host Controller is currently reading and read only till the end of previous frame. But this logic with Interrupt threshold less than 1 ms precision will break the Isochronous behaviour 'coz it will not read the last completed packet descriptor. I've configured the Interrupt threshold to be 1ms and have tested the logic and it is working fine. c. The function tt_no_collision() (ehci-sched.c) called from sitd_slot_ok(), is passed wrong period. tt_no_collision() expects the period in terms of frames. d. In the function sitd_slot_ok(), we are scanning from the first frame till the end, and tt_no_collision() also scans every frame in the schedule, is it not sufficient to call tt_no_collision() only once instead of calling it in a loop in sitd_slot_ok() ?? Kernel supports EHCI completely including the EXPERIMENTAL Split ISO. The functionality was tested with the ALSA USB audio driver with full ALSA support and the standalone USB audio class driver. The Host controller on the board does not sit over the PCI and sits over a proprietary bus and a glue logic had been added to the same. Please let me know your comments on the above changes/suggestions. Regards, /Manjunath B.S. --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
