Hi,
I think I found a problem somewhere in the kernel 2.4.31. Let me explain
why. I was writing a USB 2.0 driver for a asynchronous scanner, i.e, paper
can be fed through the scanner at any time (similar to a lottery scanner or
ATM). This scanner, developed by PDI, has three bulk endpoints and no
interrupt endpoint. One endpoint is for sending commands, such as DPI,
color, .... One other endpoint is used to retrieve the image data as soon
is the image is fed through the scanner while the other endpoint while the
other endpoint is used by the scanner to send any other significant data.
The scanner driver I developed was initially developed on the kernel 2.6.11
and everything functioned properly. However, when one of the company's
customer indicated that they need this driver to work on Slackware 10.2
with kernel 2.4.31, I had to port this driver for that kernel. The driver
is ported and works properly in normal circumstances. However, when I
remove the USB cable from the scanner, it is impossible to reconnect to
that scanner until the next reboot. Naturally, I thought that I had a bug
in the driver and I started investigating. I found that kernel was looping
forever in the following module:
static void ehci_free_config (struct usb_hcd *hcd, struct usb_device *udev)
and more specifically in
if (qh->qh_state == QH_STATE_LINKED)
start_unlink_async (ehci, qh);
while (qh->qh_state != QH_STATE_IDLE
&& ehci->hcd.state != USB_STATE_HALT) {
spin_unlock_irqrestore (&ehci->lock, flags);
wait_ms (1);
spin_lock_irqsave (&ehci->lock, flags);
}
qh->qh_state value remains at the value 2 and
ehci->hcd.state remains at the value 1
and that is why I can never reconnect to my driver when I reconnect the USB
cable.
Now, I was at a loss. I changed my scanner_probe function and added the
following instructions at the end of the probe functions (Those code lines
are normally located in my scanner_open function). Since this is a
asynchronous scanner, I need to setup a callback for both scanner bulk
endpoints that can send data at any time. When I added those lines to the
code, I noticed the same hanging behavior after I disconnected the USB
cable from the scanner. However, when I only submit one endpoint urb, then
everything works except for the fact that I lose all the data from one of
my endpoints and is naturally not acceptable. Since this driver really does
not execute any extra code, I must consider this a defect for the 2.4.31
kernel. Naturally, the unlinking of the urb's happen in the scanner
disconnect function and that is where the anomaly manifests itself.
// Fill img_urb and Submit it
FILL_BULK_URB(dev->img_urb, dev->udev,
usb_rcvbulkpipe(dev->udev,
dev->img_in_ep_addr),
dev->img_in_buffer, dev->img_in_bufsize,
image_callback_fun, dev);
usb_submit_urb (dev->img_urb);
// Fill cmd_urb and Submit it
FILL_BULK_URB(dev->cmd_urb, dev->udev,
usb_rcvbulkpipe(dev->udev,
dev->cmd_in_ep_addr),
dev->cmd_in_buffer, dev->cmd_in_bufsize,
command_callback_fun, dev);
usb_submit_urb (dev->cmd_urb);
I found some sample code for other USB scanner drivers, but most scanner
drivers have a synchronous behavior, i.e. you send a command to the scanner
and it responds. I hope that someone can help me
Regards,
Arsene
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
