driver migration
Dear all a couple of years ago I wrote a driver for a serial dongle. I did not add it to the linux source because the dongle requires a firmware to be downloaded to the device (ezusb). The manufacturer, IO-DATA, did not want me to use their firmware. I am now in the process to move the driver from kernel version 3.0.x to kernel version 3.13.0 (ubuntu 14.02 runs with it). Once this works, I will migrate it once more to a kernel on the main line (hoping that there are not to many changes in the framework between 3.13.0 and 4.5). a) I can compile the driver, and insert it. It downloads the firmware to the serial dongle. The device reenumerates then, but the driver fails to attach to the device. It hangs while allocating the memory for the urbs of the write pool usb messages. It then behaves like a time bomb: The load slowly increase, and eventually, the system stops and I need to reboot the system. Any thoughts on how to trace down the root cause and fix it ? Here the sys log indicating this: usb 3-3: usbrsa_attach [ 5017.515778] usb-serial (null):allocate_write_urbs() [ 5039.595625] [ cut here [ 5039.595642] WARNING: CPU: 4 PID: 71 at /build/linux-faWYrf/linux-3.13.0/kernel/watchdog.c:245 watchdog_overflow_callback+0x9c/0xd0() [ 5039.595644] Watchdog detected hard LOCKUP on cpu 4 And here the part of the log after the enumeration sequence: [ 492.820632] usb 3-3: Product: USB-RS232C CONVERTER [ 492.820638] usb 3-3: Manufacturer: I-O DATA DEVICE,Inc. [ 492.820642] usb 3-3: SerialNumber: USB-RSA Rev.1 [ 492.821209] usbrsa 3-3:1.0: IO-DATA - USB-RSA converter detected [ 492.821225] usbrsa_attach start [ 492.821230] usb 3-3: usbrsa_attach b) The driver requires the modules ezusb, and usb-serial. The usb serial driver framework does not offer to use the module_init function any longer. What would be the appropriate place the corresponding request_module commands? Many thanks Tilman -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: driver migration
I moved the initialization and clean up code from the init_callback/release callback to the port_init/port_remove callback. This did not help. What prevents the driver from crashing is to initialize the spinlock via spin_lock_init(&priv->lock). Not sure if I originally had forgotten the command, and the driver worked despite an uninitialized spinlock with kernel V3.17, or whether the spin_lock_init procedure was added in kernel version later than 3.17. When issuing a write command to the driver via echo "text" > /dev/ttyUSB0, there is a delay of about 30 Seconds until echo completes (echo is blocking for 30 seconds). This is also observable in the syslog. usbrsa_close is started only around 30 secs after completion of the write function usbrsa_write and the write completion handlers. I would think this might be related to a change in the scheduling mechanism since 3.17. I wonder whether this can be fixed by using usb_serial_port_softint(port) at the right places. It apparently calls the kernel schedulding interface ( usb_serial_port_softint calls schedule_work). I would appreciate a hint on how to prevent the blocking and an explanaion of what usb_serial_port_softint is intented to do. Many thanks Tilman [ 7315.882927] usbrsa ttyUSB0: usbrsa_write_callback - length = 2, data = 0d 0a [ 7315.882932] usbrsa ttyUSB0: usbrsa_write_callback(): Returned URB 1 [ 7315.882938] usbrsa_status_callback: nofTxBytesFree=4074,nofRxBytesReceived=0 [ 7315.883002] usbrsa_status_callback: nofTxBytesFree=4072,nofRxBytesReceived=0 [ 7346.332061] usbrsa_close - start [ 7346.332070] usbrsa ttyUSB0: usbrsa_close - port 0 start [ 7346.332076] usbrsa ttyUSB0: send_baudrate_lcr_register() CFLAG=3261 [ 7346.332080] usbrsa ttyUSB0: send_baudrate_lcr_register() ST16C550.DLL=50;ST16C550.DLM=0;ST16C550.LCR=3 [ 7346.332130] usbrsa ttyUSB0: usbrsa_baudrate_lcr_callback() - port = 0, ep=0xc0028300 [ 7346.332142] usbrsa ttyUSB0: send_baudrate_lcr_register() leaving [ 7346.332146] usbrsa ttyUSB0: usbrsa_close - #retries=3 [ 7346.332148] usbrsa_close - end [ 7346.332151] usbrsa ttyUSB0: usbrsa_close - end [ 7346.332163] usbrsa ttyUSB0: usbrsa_status_callback(): wake_up -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: driver migration
On Sun, Mar 27, 2016 at 11:40:51PM +, tilman wrote: > I moved the initialization and clean up code from the init_callback/release > callback to the port_init/port_remove callback. We have no context here at all, sorry, so there's really nothing we can do to help you out... good luck, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: driver migration
Greg KH writes:
Dear Greg
> > I moved the initialization and clean up code from the init_callback/release
> > callback to the port_init/port_remove callback.
I am referring to your last posting on Feb 25th:
gkh> Release your port data in the port_remove callback, not the release
gkh> callback. The release callback is for when your whole device is
gkh> removed, not the individual ports.
In addition, I initialized a spinlock as part of setting up the data
structures in the port_init callback routine. Since then, the driver is no
longer crashing, and also the load no longer slowly builds up causing the
machine to eventually freeze.
One problem solved.
Next problem:
When issuing a write command to the driver via echo "text" > /dev/ttyUSB0,
there is a delay of about 30 seconds until echo completes (echo is blocking
for 30 seconds). The timestamp in the syslog also show this: usbrsa_close is
started only around 30 secs (see below below @ 7346.332061) after completion
of the write completion handlers.
The routine usbrsa_status_callback that was started first by usbrsa_open,
and is then being continuously called by itself, does not block.
(For the source code of the involved routines, please see below)
With the ancient kernel version 3.17, this was working fine.
I would not think that the 30 seconds blockng are not random but are related
to a timeout of any kind.
1) I wonder what the kernel is doing between usbrsa_write and usbrsa_close.
it seems not to be executing code within the driver. What can cause the 30
seconds of blocking/what is the kernel waiting for?
2) I have seen other drivers calling usb_serial_port_softint from various
places. What exaclty does usb_serial_port_softint/schedule_word that is
called by usb_serial_port_softint?
Many thanks
Tilman
Syslog:
===
...
[ 7315.882626] usbrsa_open - port=0
[ 7315.882666] usbrsa ttyUSB0: usbrsa_write_room(): Pool=640;usbrsa.tx=4084
[ 7315.882673] usbrsa ttyUSB0: usbrsa_write - port 0 START
[ 7315.882676] usbrsa_write; private struct =8803ff468c00
[ 7315.882682] usbrsa ttyUSB0: usbrsa_write - port 0; bytes=10 := count=10 :
nofTxBytesFree=4084
[ 7315.882688] usbrsa ttyUSB0: usbrsa_write - poolsize 10, urb_index 0
[ 7315.882694] usbrsa ttyUSB0: usbrsa_write - port 0;URB allocated=0
[ 7315.882699] usbrsa ttyUSB0: usbrsa_write - port 0;bytes in urb=10
[ 7315.882705] usbrsa ttyUSB0: usbrsa_write - length = 10, data = 31 32 33
34 35 36 37 38 39 30
[ 7315.882711] usbrsa ttyUSB0: usbrsa_write - port 0;sent=10;count=0;
nof_bytes_to_be_sent=0;bytes=10
[ 7315.882714] usbrsa ttyUSB0: usbrsa_write() End - sent=10
[ 7315.882722] usbrsa ttyUSB0: usbrsa_write_room(): Pool=576;usbrsa.tx=4084
[ 7315.882726] usbrsa ttyUSB0: usbrsa_write - port 0 START
[ 7315.882729] usbrsa_write; private struct =8803ff468c00
[ 7315.882734] usbrsa ttyUSB0: usbrsa_write - port 0; bytes=2 := count=2 :
nofTxBytesFree=4084
[ 7315.882738] usbrsa ttyUSB0: usbrsa_write - poolsize 10, urb_index 1
[ 7315.882742] usbrsa ttyUSB0: usbrsa_write - port 0;URB allocated=1
[ 7315.882745] usbrsa ttyUSB0: usbrsa_write - port 0;bytes in urb=2
[ 7315.882748] usbrsa ttyUSB0: usbrsa_write - length = 2, data = 0d 0a
[ 7315.882753] usbrsa ttyUSB0: usbrsa_write - port 0;sent=2;count=0;
nof_bytes_to_be_sent=0;bytes=2
[ 7315.882756] usbrsa ttyUSB0: usbrsa_write() End - sent=2
[ 7315.882769] usbrsa ttyUSB0: usbrsa_write_callback() - port = 0, ep
=0xc0018380
[ 7315.882776] usbrsa ttyUSB0: usbrsa_write_callback - length = 10, data =
31 32 33 34 35 36 37 38 39 30
[ 7315.882781] usbrsa ttyUSB0: usbrsa_write_callback(): Returned URB 0
[ 7315.882918] usbrsa ttyUSB0: usbrsa_write_callback() - port = 0, ep
=0xc0018380
[ 7315.882927] usbrsa ttyUSB0: usbrsa_write_callback - length = 2, data = 0d 0a
[ 7315.882932] usbrsa ttyUSB0: usbrsa_write_callback(): Returned URB 1
[ 7315.882938] usbrsa_status_callback: nofTxBytesFree=4074,nofRxBytesReceived=0
[ 7315.883002] usbrsa_status_callback: nofTxBytesFree=4072,nofRxBytesReceived=0
[ 7346.332061] usbrsa_close - start
[ 7346.332070] usbrsa ttyUSB0: usbrsa_close - port 0 start
[ 7346.332076] usbrsa ttyUSB0: send_baudrate_lcr_register() CFLAG=3261
[ 7346.332080] usbrsa ttyUSB0: send_baudrate_lcr_register()
ST16C550.DLL=50;ST16C550.DLM=0;ST16C550.LCR=3
[ 7346.332130] usbrsa ttyUSB0: usbrsa_baudrate_lcr_callback() - port = 0,
ep=0xc0028300
[ 7346.332142] usbrsa ttyUSB0: send_baudrate_lcr_register() leaving
[ 7346.332146] usbrsa ttyUSB0: usbrsa_close - #retries=3
[ 7346.332148] usbrsa_close - end
[ 7346.332151] usbrsa ttyUSB0: usbrsa_close - end
[ 7346.332163] usbrsa ttyUSB0: usbrsa_status_callback(): wake_up
Source code Excerpt:
=
static struct usb_serial_driver usbrsa_enumerated_device =
{
.driver = {
.owner =THIS_MODULE,
.name = "usbrsa",
},
.description = "IO-DATA - USB-RSA",
.id_table = id_table_std,
.num_ports =1
Re: driver migration
On Tue, Mar 29, 2016 at 09:01:43AM +, tilman wrote: > Greg KH writes: > > Dear Greg > > > > I moved the initialization and clean up code from the > > > init_callback/release > > > callback to the port_init/port_remove callback. > > I am referring to your last posting on Feb 25th: > gkh> Release your port data in the port_remove callback, not the release > gkh> callback. The release callback is for when your whole device is > gkh> removed, not the individual ports. Please always include proper context, as I average about 1000 emails a day receiving and about 100 written. > In addition, I initialized a spinlock as part of setting up the data > structures in the port_init callback routine. Since then, the driver is no > longer crashing, and also the load no longer slowly builds up causing the > machine to eventually freeze. > > One problem solved. Problem of what? What type of driver is this? Why not post the updated code so that everyone can see it and possibly help out with it? Note, run it through checkpatch.pl first so we don't get annoyed by any obvious issues that aren't addressed. Without the code, there's almost nothing we can do, sorry. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: driver migration
> -Original Message- > From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb- > ow...@vger.kernel.org] On Behalf Of tilman > Sent: Tuesday, March 29, 2016 04:02 > To: linux-usb@vger.kernel.org > Subject: Re: driver migration > > Greg KH writes: > > Dear Greg > > > > I moved the initialization and clean up code from the > > > init_callback/release > > > callback to the port_init/port_remove callback. > > I am referring to your last posting on Feb 25th: > gkh> Release your port data in the port_remove callback, not the release > gkh> callback. The release callback is for when your whole device is > gkh> removed, not the individual ports. > > In addition, I initialized a spinlock as part of setting up the data > structures in the port_init callback routine. Since then, the driver is no > longer crashing, and also the load no longer slowly builds up causing the > machine to eventually freeze. > > One problem solved. > > Next problem: > When issuing a write command to the driver via echo "text" > /dev/ttyUSB0, > there is a delay of about 30 seconds until echo completes (echo is blocking > for 30 seconds). The timestamp in the syslog also show this: usbrsa_close is > started only around 30 secs (see below below @ 7346.332061) after > completion > of the write completion handlers. > The routine usbrsa_status_callback that was started first by usbrsa_open, > and is then being continuously called by itself, does not block. > (For the source code of the involved routines, please see below) > > > With the ancient kernel version 3.17, this was working fine. > I would not think that the 30 seconds blockng are not random but are related > to a timeout of any kind. > > 1) I wonder what the kernel is doing between usbrsa_write and > usbrsa_close. > it seems not to be executing code within the driver. What can cause the 30 > seconds of blocking/what is the kernel waiting for? [...] Just a wild guess - this 30-second delay before close can happen because usbserial is waiting for data to be transmitted, before closing the port. If you know that your data have been transmitted, perhaps you didn't properly tell usbserial that your write operation has finished. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: driver migration
Konstantin Shkolnyy writes:
> Just a wild guess - this 30-second delay before close can happen because
usbserial is waiting for data to be
> transmitted, before closing the port.
> If you know that your data have been transmitted, perhaps you didn't
properly tell usbserial that your
> write operation has finished.
Konstantin
thank you for your suggestion.
I have implemented a dedicated write routine for the driver, and it is
returning the value 11 (for 11 sent characters downstream). The urb ia then
put back into the pool, and then the blocking starts. stty -f /dev/ttyUSB0
300 seems never to finish, while echo "0123456789" > /dev/ttyUSB0
reproducibly finish after 30 seconds. I will post the complete source code
in response to Greg's posting.
Tilman
= syslog ==
sbrsa_write; private struct =880307620e00
{103936.132220] usbrsa ttyUSB0: usbrsa_write - port 0; bytes=11 := count=11
: nofTxBytesFree=4085
[103936.132226] usbrsa ttyUSB0: usbrsa_write - poolsize 10, urb_index 0
[103936.132231] usbrsa ttyUSB0: usbrsa_write - port 0;URB allocated=0
[103936.132237] usbrsa ttyUSB0: usbrsa_write - port 0;bytes in urb=11
[103936.132245] usbrsa ttyUSB0: usbrsa_write - length = 11, data = 30 31 32
33 34 35 36 37 38 39 0a
[103936.132255] usbrsa ttyUSB0: usbrsa_write - port 0;sent=11;count=0;
nof_bytes_to_be_sent=0;bytes=11
[103936.132261] usbrsa ttyUSB0: usbrsa_write() End - sent=11
[103936.132306] usbrsa ttyUSB0: usbrsa_write_callback() - port = 0, ep
=0xc0018f80
[103936.132319] usbrsa ttyUSB0: usbrsa_write_callback - length = 11, data =
30 31 32 33 34 35 36 37 38 39 0a
[103936.132326] usbrsa ttyUSB0: usbrsa_write_callback(): Returned URB 0
sbrsa_status_callback: nofTxBytesFree=4074,nofRxBytesReceived=0
[103938.129140] usbrsa ttyUSB0: usbrsa_status_callback():
usb_serial_port_softint
..
[103966.130101] usbrsa ttyUSB0: usbrsa_status_callback():
usb_serial_port_softint
[103966.654158] usbrsa_close - start
[103966.654167] usbrsa ttyUSB0: usbrsa_close - port 0 start
[103966.654172] usbrsa ttyUSB0: send_baudrate_lcr_register()
.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: driver migration
Hi Greg Kind of Driver: Driver for a dongle usb-> serial Manufacturer: Io-Data Device: USB-RSA (based on EZUSB-CHip) Goal: Port the driver that was working on kernel version 3.17 to current kernel version Problem Description: - The driver initializes properly, and downloads the firmware. - When issuing echo "0123456789" > /dev/ttyUSB0, the data is sent downstream to the device. echo then blocks for 30 seconds. usbrsa_close is then called. With it, also echo terminates (return code = 0) - When issuing stty -F /dev/ttyUSB0 300, the command is apparently executed. stty however blocks (as it seems indefinitely). usbrsa_close is only called once I cancel stty with CTRL-C Remark: From what I can see, the driver does not block within the driver code but somewhere else. For log and source code, please look below (As you suggested, I scanned the source with checkpatch.pl. I have removed all errors). gkh> Why not post the updated gkh> code so that everyone can see it and possibly help out with it? No issue with that -- just wanted to save everybody from utterly long postings. = command: echo "0123456789" > /dev/ttyUSB0 SYSLOG: [105791.355511] tty ttyUSB0: usbrsa_init_termios() [105791.355528] usbrsa_open; priv=880307620e00 [105791.355533] usbrsa ttyUSB0: usbrsa_open - port 0 [105791.355536] usbrsa ttyUSB0: usbrsa_set_termios - port 0 [105791.355539] usbrsa ttyUSB0: usbrsa_set_termios - baudrate = 300 [105791.355543] usbrsa ttyUSB0: send_baudrate_lcr_register() CFLAG=1207 SPEED=300 ep=2 [105791.355547] usbrsa ttyUSB0: send_baudrate_lcr_register() ST16C550.DLL=74;ST16C550.DLM=6;ST16C550.LCR=3 [105791.355615] usbrsa ttyUSB0: usbrsa_baudrate_lcr_callback() - port = 0, ep=0xc0010f00 [105791.355656] usbrsa ttyUSB0: send_baudrate_lcr_register() leaving [105791.355669] usbrsa ttyUSB0: usbrsa_open - port 0: leaving [105791.355712] usbrsa ttyUSB0: usbrsa_status_callback(): usb_serial_port_softint [105791.355724] usbrsa_write; private struct =880307620e00 [105791.355729] usbrsa ttyUSB0: usbrsa_write - port 0; bytes=11 := count=11 : nofTxBytesFree=4063 [105791.355734] usbrsa ttyUSB0: usbrsa_write - poolsize 10, urb_index 0 [105791.355739] usbrsa ttyUSB0: usbrsa_write - port 0;URB allocated=0 [105791.355744] usbrsa ttyUSB0: usbrsa_write - port 0;bytes in urb=11 [105791.355748] usbrsa ttyUSB0: usbrsa_write - length = 11, data = 30 31 32 33 34 35 36 37 38 39 0a [105791.355753] usbrsa ttyUSB0: usbrsa_write - port 0;sent=11;count=0; nof_bytes_to_be_sent=0;bytes=11 [105791.355756] usbrsa ttyUSB0: usbrsa_write() End - sent=11 [105791.355801] usbrsa ttyUSB0: usbrsa_write_callback() - port = 0, ep =0xc0018f80 [105791.355809] usbrsa ttyUSB0: usbrsa_write_callback - length = 11, data = 30 31 32 33 34 35 36 37 38 39 0a [105791.355817] usbrsa ttyUSB0: usbrsa_write_callback(): Returned URB 0 [105791.355958] usbrsa_status_callback: nofTxBytesFree=4052,nofRxBytesReceived=0 ... (here the blocking of "echo" starts) [105793.353318] usbrsa ttyUSB0: usbrsa_status_callback(): usb_serial_port_softint [105795.353432] usbrsa ttyUSB0: usbrsa_status_callback(): usb_serial_port_softint ... (repeats every 2 seconds for around 30 seconds) usbrsa_status_callback(): usb_serial_port_softint [105821.354309] usbrsa ttyUSB0: usbrsa_status_callback(): usb_serial_port_softint [105821.766319] usbrsa_close - start [105821.766328] usbrsa ttyUSB0: usbrsa_close - port 0 start [105821.766334] usbrsa ttyUSB0: send_baudrate_lcr_register() CFLAG=1207 SPEED=300 ep=5 [105821.766338] usbrsa ttyUSB0: send_baudrate_lcr_register() ST16C550.DLL=74;ST16C550.DLM=6;ST16C550.LCR=3 [105821.766380] usbrsa ttyUSB0: usbrsa_baudrate_lcr_callback() - port = 0, ep=0xc0028f00 [105821.766392] usbrsa ttyUSB0: send_baudrate_lcr_register() leaving [105821.766395] usbrsa ttyUSB0: usbrsa_close - #retries=3 [105821.766397] usbrsa_close - end [105821.766399] usbrsa ttyUSB0: usbrsa_close - end [105821.766416] usbrsa ttyUSB0: usbrsa_status_callback(): wake_up ... (echo terminates). command: stty -F /dev/ttyUSB0 300 SYSLOG: [106202.139819] usbrsa_open; priv=880307620e00 [106202.139824] usbrsa ttyUSB0: usbrsa_open - port 0 [106202.139827] usbrsa ttyUSB0: usbrsa_set_termios - port 0 [106202.139830] usbrsa ttyUSB0: usbrsa_set_termios - baudrate = 300 [106202.139834] usbrsa ttyUSB0: send_baudrate_lcr_register() CFLAG=1207 SPEED=300 ep=2 [106202.139838] usbrsa ttyUSB0: send_baudrate_lcr_register() ST16C550.DLL=74;ST16C550.DLM=6;ST16C550.LCR=3 [106202.139924] usbrsa ttyUSB0: usbrsa_baudrate_lcr_callback() - port = 0, ep=0xc0010f00 [106202.139949] usbrsa ttyUSB0: send_baudrate_lcr_register() leaving [106202.139958] usbrsa ttyUSB0: usbrsa_open - port 0: leaving [106202.139978] usbrsa ttyUSB0: usbrsa_ioctl() cmd 0x5401 [106202.139982] usbrsa ttyUSB0: usbrsa_ioctl(): TCGETS -- not implemented [106202.139986] usbrsa ttyUSB0: usbrsa_ioctl() leaving [106202.139996] usbrsa ttyUSB0: usbrsa_status_callback(): usb_serial_port_softint [106202.140016] usbrsa ttyUSB0: usbrsa_ioctl()
Re: driver migration
Hello Kind of Driver: Driver for a dongle usb-> serial Manufacturer: Io-Data Device: USB-RSA (based on EZUSB-CHip) Reference: My last post from 2016-04-02 19:49:40 GMT Description: The blocking behaviour that I reported in my last post seems to be induced by the set_bit and submit_urb in usbrsa_write. If I comment them, the "echo" or "stty" commands no longer block. If I only comment submit_urb, I experience blocking. For the complete source code, please refer to my posting from 2016-04-02 19:49:40 GMT usbrsa_write . dev_dbg(&port->dev, "%s - port %d;URB allocated=%d", __func__, port->port_number, urb_index); /* reserve urb */ /* if I comment set_bit and submit_urb, I do not observe * blocking any longer */ set_bit(urb_index, &priv->write_urb_pool_lock); urb = priv->write_urb_pool[urb_index]; spin_unlock_irqrestore(&priv->lock, flags); /* copy data from userspace into urb transfer buffer */ bytes = (nof_bytes_to_be_sent > port->bulk_out_size) ? port->bulk_out_size : nof_bytes_to_be_sent; ... dev_dbg(&port->dev, "%s - port %d;bytes in urb=%d", __func__, port->port_number, bytes); usb_serial_debug_data(&port->dev, __func__, bytes, urb->transfer_buffer); urb->dev = serial->dev; urb->transfer_buffer_length = bytes; /* sent urb to USB-RSA */ //retval = usb_submit_urb(urb, GFP_ATOMIC); .. Thanks Tilman -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: driver migration
On Mon, Feb 15, 2016 at 11:30:43PM +, tilman wrote: > Dear all > > a couple of years ago I wrote a driver for a serial dongle. > I did not add it to the linux source because the dongle requires a firmware > to be downloaded to the device (ezusb). > The manufacturer, IO-DATA, did not want me to use > their firmware. Why did they not want you to use their firmware in their device? > I am now in the process to move the driver from kernel version 3.0.x to > kernel version 3.13.0 (ubuntu 14.02 runs with it). 3.13 is a very old and obsolete kernel version, not much we even remember about it :) > Once this works, I will migrate it once more to a kernel on the main line > (hoping that there are not to many changes in the framework between 3.13.0 > and 4.5). > > > a) I can compile the driver, and insert it. > It downloads the firmware to the serial dongle. > The device reenumerates then, but the driver fails to attach to the device. > It hangs while allocating the memory for the urbs of the write pool usb > messages. > It then behaves like a time bomb: The load slowly > increase, and eventually, the system stops and I need to reboot the system. > > > Any thoughts on how to trace down the root cause and fix it ? It's impossible to say without seeing the code, sorry. good luck, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: driver migration
Greg KH writes: > > On Mon, Feb 15, 2016 at 11:30:43PM +, tilman wrote: > > Dear all > > > > a couple of years ago I wrote a driver for a serial dongle. > > I did not add it to the linux source because the dongle requires a firmware > > to be downloaded to the device (ezusb). > > The manufacturer, IO-DATA, did not want me to use > > their firmware. > > Why did they not want you to use their firmware in their device? They did not say. I would think that they feared that users would come to them in case the driver does not work. For the successor model, the offer a linux driver however. I have disassembled the firmware however. If I can make some time, I can rewrite the firmware which would avoid this issue. First step however is to get the driver working again. > > It's impossible to say without seeing the code, sorry. Below, it comes... Thanks Tilman /// usbrsa.c /* * Driver for IO-Data's USB RSA serial dongle * Copyright (C) 2012 * Tilman Glotzner(tilmanglotz...@gmail.com) * * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * * * USB-RSA by IO-DATA * USB to serial convertor * === * * Remark: The device uses an AN2131Q (Eazy USB) and a ST16C550(UART) * * End Points: * * * End Point: EP1OUT * Direction: Host to Device * Type: Bulk Transfer * Size: 64 bytes * Desc: Data to be transmitted * Format: 64 bytes of data * * * End Point: EP2OUT * Direction: Host to Device * Type: Bulk Transfer * Size: 3 bytes * Desc: Set baud rate counter and Line Control Register * of the ST16C550. Receiver Interrupts are turned ON, * i.e. Modem status IR, RX line status IR, and * RX holding register IR * Format: * Byte0: Low Byte of counter (DLL) * Byte1: High Byte of counter (DLM) * Byte2: Line Control Register (LCR) * - Bit 0: Word Length 0 * - Bit 1: Word Length 1 * - Bit 2: Stop Bits * - Bit 3: Parity Enable * - Bit 4: Parity Even * - Bit 5: Set Parity * - Bit 6: Set Break * - Bit 7: Counter Register Enable (needs to be set to '0') * * * End Point: EP3OUT * Direction: Host to Device * Type: Bulk Transfer * Size: 1 bytes * Desc: Set modem control register of the ST16C550 * Format: * Byte0: Modem Control Register * - Bit0: DTR * - Bit1: RTS * - Bit2: OP1 * - Bit3: OP2 * - Bit4: Diagnostics mode * * * End Point: EP4OUT * Direction: Host to Device * Type: Bulk Transfer * Size: 0 bytes * Desc: Reset EP1OUT and EP1IN (Tx/Rx pipes) * Format: n.a. * * * End Point: EP5OUT * Direction: Host to Device * Type: Bulk Transfer * Size: 3 bytes * Desc: Set baud rate counter and Line Control Register * of the ST16C550. Receiver Interrupts are turned OFF, * i.e. Modem status IR, RX line status IR, and * RX holding register IR * Format: * Byte0: Low Byte of counter (DLL) * Byte1: High Byte of counter (DLM) * Byte2: Line Control Register (LCR) * - Bit 0: Word Length 0 * - Bit 1: Word Length 1 * - Bit 2: Stop Bits * - Bit 3: Parity Enable * - Bit 4: Parity Even * - Bit 5: Set Parity * - Bit 6: Set Break * - Bit 7: Counter Register Enable (needs to be set to '0') * * * End Point: EP1IN * Direction: Device to Host * Type: Bulk Transfer * Size: 64 bytes * Desc: Data received by USB-RSA * Format: 64 bytes of data * * * End Point: EP2IN * Direction: Device to Host * Type: Bulk Transfer * Size: 1 byte * Desc: Read Modem Status Register of ST16C550 * Format: * Byte0: Modem Status Register * - Bit0: Delta CTS * - Bit1: Delta DSR * - Bit2: Delta RI *
Re: driver migration
Hello I configured and setup a more recent kernel: V4.5.0-rc4 The driver compiles and inserts. When I plugin the USB-Dongle, the machine freezes (not sure whether it freezes during the firmware download or after it once it has reenumerated). I could observe a kernel oops message starting with BUG. Probably a null pointer dereference... Cheers Tilman -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: driver migration
On Fri, Feb 19, 2016 at 06:49:50AM +, tilman wrote: > Hello > > I configured and setup a more recent kernel: V4.5.0-rc4 > > The driver compiles and inserts. What driver? You have provided no context here :( > When I plugin the USB-Dongle, the machine > freezes (not sure whether it freezes during the firmware download or after > it once it has reenumerated). Your kernel logs should show you this. > I could observe a kernel oops message starting with BUG. Probably a null > pointer dereference... The kernel logs can provide you with a full traceback, we can't do much without that. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: driver migration
Greg KH writes: > > On Fri, Feb 19, 2016 at 06:49:50AM +, tilman wrote: > > Hello > > > > I configured and setup a more recent kernel: V4.5.0-rc4 > > > > The driver compiles and inserts. > > What driver? You have provided no context here :( My apologies -- what I meant to say was: I inserted the compile usbrsa driver. The code of the driver I posted on Feb 16th. > > > When I plugin the USB-Dongle, the machine > > freezes (not sure whether it freezes during the firmware download or after > > it once it has reenumerated). > > Your kernel logs should show you this. The kernel freezes before it can log the kernel oops: Feb 19 07:26:35 btron kernel: [ 241.247360] usbcore: registered new interface d river usbrsa Feb 19 07:26:35 btron kernel: [ 241.247388] usbserial: USB Serial support regis tered for IO-DATA - USB-RSA - (prerenumeration) Feb 19 07:26:35 btron kernel: [ 241.247412] usbserial: USB Serial support regis tered for IO-DATA - USB-RSA ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ > The kernel logs can provide you with a full traceback, we can't do much > without that. I understand that and I would love to provide one -- there is however no traceback logged. All I have is a kernel message on the console: BUG: unable to handle kernel paging request at ... When I had the driver running on the kernel version 3.13.0, things started to go wrong in usbrsa_attach of the usbrsa driver (see first posting on Feb 16th) I will comment out all functional parts of the driver, and check if it still fails. If it no longer crashes, I will comment in procedure by procedure until it crashes hoping that I can isolate the problem that way ... If there are better/faster debugging techniques I would love to learn about them :-) Thanks Tilman -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: driver migration
On Fri, Feb 19, 2016 at 08:55:33PM +, tilman wrote: > Greg KH writes: > > > > > On Fri, Feb 19, 2016 at 06:49:50AM +, tilman wrote: > > > Hello > > > > > > I configured and setup a more recent kernel: V4.5.0-rc4 > > > > > > The driver compiles and inserts. > > > > What driver? You have provided no context here :( > My apologies -- what I meant to say was: I inserted the compile usbrsa > driver. The code of the driver I posted on Feb 16th. > > > > > > When I plugin the USB-Dongle, the machine > > > freezes (not sure whether it freezes during the firmware download or after > > > it once it has reenumerated). > > > > Your kernel logs should show you this. > > The kernel freezes before it can log the kernel oops: > > Feb 19 07:26:35 btron kernel: [ 241.247360] usbcore: registered new > interface d > river usbrsa > Feb 19 07:26:35 btron kernel: [ 241.247388] usbserial: USB Serial support > regis > tered for IO-DATA - USB-RSA - (prerenumeration) > Feb 19 07:26:35 btron kernel: [ 241.247412] usbserial: USB Serial support > regis > tered for IO-DATA - USB-RSA > > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ > > > > The kernel logs can provide you with a full traceback, we can't do much > > without that. > I understand that and I would love to provide one -- there is however no > traceback logged. All I have is a kernel message on the console: > > BUG: unable to handle kernel paging request at ... > > When I had the driver running on the kernel version 3.13.0, things started > to go wrong in usbrsa_attach of the usbrsa driver (see first posting on Feb > 16th) > > I will comment out all functional parts of the driver, and check if it still > fails. If it no longer crashes, I will comment in procedure by procedure > until it crashes hoping that I can isolate the problem that way ... > If there are better/faster debugging techniques I would love to learn about > them :-) You can use ftrace to help you watch the flow of your driver before it crashes, or just printk, as you have found out, is the best way to debug things. best of luck, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: driver migration
Hello
> You can use ftrace to help you watch the flow of your driver before it
> crashes, or just printk, as you have found out, is the best way to debug
> things.
Thanks for the hints. I will give ftrace a go.
It takes me around 5-7 minutes to see the kernel crash, and then reboot,
make changes, and try again (more if I use eclipse). I am wondering, if
there are ways to allow faster turnaround times. Maybe, it would be an
option to run the tests in an emulator, such as qemu? Any experience with that?
The first crash that is also logged I am getting in
usbrsa_allocate_write_urbs when calling spin_lock_irqsave. I see no obvious
mistakes, and on an old 3.0.x kernel, this was running fine. Any suggestion
of what am I doing wrong here?
printk("%s -- clear_bit",__func__);
spin_lock_irqsave(&priv_data->lock,flags);
clear_bit( i,&priv_data->write_urb_pool_lock);
spin_unlock_irqrestore(&priv_data->lock,flags);
printk("%s -- clear_bit end",__func__);
Here the log:
usbrsa: module verification failed: signature and/o
r required key missing - tainting kernel
usbcore: registered new interface driver usbrsa
usbserial: USB Serial support registered for IO-DAT
A - USB-RSA - (prerenumeration) usbserial: USB Serial support registered
for IO-DATA - USB-RSA
usb 3-3: new full-speed USB device number 2 using x
hci_hcd
usb 3-3: New USB device found, idVendor=04bb, idPro
duct=0a01
usb 3-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
usb 3-3: usbrsa_firmware_download
usb 3-3: usbrsa_firmware_download(): Firmware downloaded.
usb 3-3: usbrsa_firmware_download(): Device with new firmware reset.
usbrsa 3-3:1.0: IO-DATA - USB-RSA - (prerenumeration) converter detected
Feb 22 07:48:52 btron mtp-probe: checking bus 3, device 2:
"/sys/devices/pci:00/:00:14.0/usb3/3-3"
mtp-probe: bus: 3, device: 2 was not an MTP device
usb 3-3: USB disconnect, device number 2
usbrsa 3-3:1.0: device disconnected
usb 3-3: new full-speed USB device number 3 using xhci_hcd
usb 3-3: New USB device found, idVendor=04bb, idProduct=0a02
usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 3-3: Product: USB-RS232C CONVERTER
usb 3-3: Manufacturer: I-O DATA DEVICE,Inc.
usb 3-3: SerialNumber: USB-RSA Rev.1䰑羐
USB-RSA converter detected
usbrsa_attach start
usb 3-3: usbrsa_attach
usbrsa_attach about to enter
'usbrsa_allocate_write_urbs'usbrsa_allocate_write_urbs() Mark 1
usb-serial (null): usbrsa_allocate_write_urbs()
usbrsa_allocate_write_urbs() Mark 2usbrsa_allocate_write_urbs; i=0
usbrsa_allocate_write_urbs; Mark3
usbrsa_allocate_write_urbs; Mark4
usbrsa_allocate_write_urbs -- clear_bit
BUG: unable to handle kernel paging request at 1ddc00017654
IP: [] native_queued_spin_lock_slowpath+0x104/0x190
PGD 0
Oops: 0002 [#1] SMP
Modules linked in: usbrsa(OE) usbserial ezusb drbg ansi_cprng ctr ccm bnep
rfcomm dm_crypt nfsd auth_rpcgss nfs_acl nfs lockd grace sunrpc binfmt_misc
fscache nls_iso8859_1 uvcvideo videobuf2_vmalloc videobuf2_memops
videobuf2_v4l2 videobuf2_core videodev arc4 iwldvm mac80211
snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec
btusb intel_rapl x86_pkg_temp_thermal intel_powerclamp btrtl btbcm coretemp
snd_hda_core btintel snd_hwdep kvm_intel iwlwifi bluetooth kvm snd_pcm
snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq irqbypass mei_me
snd_seq_device snd_timer snd cfg80211 mei asus_nb_wmi asus_wmi sparse_keymap
crct10dif_pclmul soundcore crc32_pclmul ghash_clmulni_intel aesni_intel
shpchp lpc_ich aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd joydev
serio_raw mac_hid parport_pc ppdev lp parport nouveau i915 mxm_wmi ttm
i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops
drm ahci psmouse alx libahci mdio wmi video
CPU: 4 PID: 37 Comm: kworker/4:0 Tainted: G OE 4.5.0-rc4-custom #1
Hardware name: ASUSTeK COMPUTER INC. N56VZ/N56VZ, BIOS N56VZ.215 11/02/2012
Workqueue: usb_hub_wq hub_event
task: 88041c54d7c0 ti: 88041c57c000 task.ti 88041c57c000
RIP: 0010:[] []
native_queued_spin_lock_slowpath+0x104/0x190
RSP: 0018:88041c57f700 EFLAGS: 00010002
RAX: 39df RBX: 0282 RCX: 0014
RDX: 1ddc00017654 RSI: e78092ef RDI: 8800b971aa10
RBP: 88041c57f700 R08: 88042ef17640 R09:
R10: 0005 R11: 04b7 R12:
R13: 8800b971aa10 R14: 88041aaaca80 R15:
FS: () GS:88042ef0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 1ddc00017654 CR3: 01c0c000 CR4: 001406e0
Stack:
88041c57f710 811726fd 88041c57f728 817a47e7
8800b971aa00 88041c57f760 a09e7655 0002
88041c6ab800 88041c6ab810 88041a1aaa80 a09ea000
Call Trace:
[] queued_spin_lock_slowpath+0xb/0xf
[] _raw_spin_lock_irqsave+0x37/0x40
[] usbrsa_attach+0x1b5/0x660 [usbrsa]
[] usb_
Re: driver migration
On Mon, Feb 22, 2016 at 07:34:08AM +, tilman wrote: > > Hello > > > You can use ftrace to help you watch the flow of your driver before it > > crashes, or just printk, as you have found out, is the best way to debug > > things. > Thanks for the hints. I will give ftrace a go. > It takes me around 5-7 minutes to see the kernel crash, and then reboot, > make changes, and try again (more if I use eclipse). I am wondering, if > there are ways to allow faster turnaround times. Maybe, it would be an > option to run the tests in an emulator, such as qemu? Any experience with > that? Using an emulator doesn't usually work for working with a "real device" like you are doing now. You might be able to map your device into qemu, as it does have USB support, but I have never tried that out. I suggest staying away from eclipse, that's not needed for kernel development. Other than that, it's just normal debugging, good luck with that :) greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: driver migration
> I suggest staying away from eclipse, that's not needed for kernel
> development. Other than that, it's just normal debugging, good luck
> with that :)
I resorted to good old vi as the editor that starts up fastest :-)
And I traced down the problem -- but not the root cause:
In usbrsa_attach, I allocate a private struct for port specific/driver
specific data:
static int usbrsa_attach(struct usb_serial *serial)
{
int i = 0;
int ret = 0;
struct usb_serial_port* serport;
struct usbrsa_port_private* priv = NULL;
...
for (i = 0; i < serial->num_ports; i++)
{
serport = serial->port[i];
// allocate struct for driver's private data
priv = kmalloc(sizeof(struct usbrsa_port_private), GFP_KERNEL);
usb_set_serial_port_data(serport,priv);
...
}
In usbrsa_release, the pointer to the private struct has become a NULL
pointer -- even though the pointer was not manipulated in between by
usbrsa_open or usbrsa_write. In fact, I have dumped the pointer in all other
functions like usbrsa_open, usbrsa_writeroom etc., and it is correct. The
null pointer in usbrsa_release then leads to a pointer dereferencing error
in release_baudrate_lcr_urb(priv);
static void usbrsa_release(struct usb_serial *serial)
{
int i;
struct usbrsa_port_private* priv;
struct usb_serial_port* serport;
...
for (i = 0; i < serial->num_ports; i++)
{
printk("%s: Mark1\n",__func__);
serport = serial->port[i];
priv = usb_get_serial_port_data(serport);
printk("%s: Mark2\n",__func__);
printk("%s: private struct at %p\n",__func__,priv);
printk("%s: Mark2a ",__func__);
release_baudrate_lcr_urb(priv);
Here the kernel log
[ 1856.366874] usbrsa_release: Mark2
[ 1856.366876] usbrsa_release: private struct at (null)
[ 1856.366878] usbrsa_release: Mark2a release_baudrate_lcr_urb: Start
[ 1856.366904] BUG: unable to handle kernel NULL pointer dereference at
0102
This could mean that usb_get_serial_port_data does not always work correctly
-- which I find rather unlikely. Are there any limitations known, for
instance when using the usb_get_serial_port_data in an SMP environment? Any
suggestions in which direction to dig?
Thanks Tilman
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: driver migration
On Wed, Feb 24, 2016 at 11:22:49PM +, tilman wrote:
>
> > I suggest staying away from eclipse, that's not needed for kernel
> > development. Other than that, it's just normal debugging, good luck
> > with that :)
> I resorted to good old vi as the editor that starts up fastest :-)
>
> And I traced down the problem -- but not the root cause:
>
> In usbrsa_attach, I allocate a private struct for port specific/driver
> specific data:
>
> static int usbrsa_attach(struct usb_serial *serial)
> {
> int i = 0;
> int ret = 0;
> struct usb_serial_port* serport;
> struct usbrsa_port_private* priv = NULL;
> ...
> for (i = 0; i < serial->num_ports; i++)
> {
> serport = serial->port[i];
>
> // allocate struct for driver's private data
> priv = kmalloc(sizeof(struct usbrsa_port_private),
> GFP_KERNEL);
>
> usb_set_serial_port_data(serport,priv);
> ...
> }
>
>
> In usbrsa_release, the pointer to the private struct has become a NULL
> pointer -- even though the pointer was not manipulated in between by
> usbrsa_open or usbrsa_write. In fact, I have dumped the pointer in all other
> functions like usbrsa_open, usbrsa_writeroom etc., and it is correct. The
> null pointer in usbrsa_release then leads to a pointer dereferencing error
> in release_baudrate_lcr_urb(priv);
>
> static void usbrsa_release(struct usb_serial *serial)
> {
> int i;
> struct usbrsa_port_private* priv;
> struct usb_serial_port* serport;
> ...
>
> for (i = 0; i < serial->num_ports; i++)
> {
>printk("%s: Mark1\n",__func__);
> serport = serial->port[i];
> priv = usb_get_serial_port_data(serport);
> printk("%s: Mark2\n",__func__);
> printk("%s: private struct at %p\n",__func__,priv);
> printk("%s: Mark2a ",__func__);
> release_baudrate_lcr_urb(priv);
>
> Here the kernel log
> [ 1856.366874] usbrsa_release: Mark2
> [ 1856.366876] usbrsa_release: private struct at (null)
> [ 1856.366878] usbrsa_release: Mark2a release_baudrate_lcr_urb: Start
> [ 1856.366904] BUG: unable to handle kernel NULL pointer dereference at
> 0102
>
> This could mean that usb_get_serial_port_data does not always work correctly
> -- which I find rather unlikely. Are there any limitations known, for
> instance when using the usb_get_serial_port_data in an SMP environment? Any
> suggestions in which direction to dig?
Release your port data in the port_remove callback, not the release
callback. The release callback is for when your whole device is
removed, not the individual ports.
Try that and see what happens...
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
