RE: driver migration

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> -----Original Message-----
> From: linux-usb-owner@xxxxxxxxxxxxxxx [mailto:linux-usb-
> owner@xxxxxxxxxxxxxxx] On Behalf Of tilman
> Sent: Tuesday, March 29, 2016 04:02
> To: linux-usb@xxxxxxxxxxxxxxx
> Subject: Re: driver migration
> 
> Greg KH <greg@...> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux