Ian Abbott wrote:
On 04/06/2004 15:59, nardelli wrote:
Note that I have not verified any of the below on
hardware associated with drivers/usb/serial/ftdi_sio.c,
only with drivers/usb/serial/visor.c. If anyone has
hardware for this device, I would appreciate your comments.
A memory leak occurs in both drivers/usb/serial/ftdi_sio.c
and drivers/usb/serial/visor.c when the usb device is
unplugged while data is being written to the device. This
patch should clear that up.
The change to ftdi_sio.c looks correct to me.
I made the original change to ftdi_sio.c to allocate the write urbs and
their transfer buffers dynamically (instead of using a preallocated
pool) and I copied that technique from visor.c!
A related problem with the current implementation is that is easy to run
out of memory by running something similar to this:
# cat /dev/zero > /dev/ttyUSB0
That affects both the ftdi_sio and visor drivers.
I believe that I have seen something similiar, but possibly not identical.
When writing alot (I used /dev/urandom instead of /dev/zero), it looks
like a very large percentage of buffers that are being allocated during
writes are not being freed. One test I did indicated that 95% of buffers
were not being freed! I briefly mention some info in
http://lkml.org/lkml/2004/5/25/72, but I wasn't going to go into detail
until I'd found out more info, and verified that my test procedure was
adequate.
My test is pretty simple, print out the address every time a buffer is
allocated, and print out the address every time a buffer is freed. In
this case there is only one location where it is being allocated, but 3
(4 with patch I submitted) where it is being freed. It's simply a matter
of running a command like the one below, and looking to see which addresses
are in there an odd number of times (i.e. allocated, but not freed). Not a
perfect test, but hopefully not embarrassingly bad either.
cat /var/log/messages | egrep 'Allocated|Freed' | tr -s ' ' | cut -d ' ' -f 7 | sort |
uniq -c | sort -n
I'm not sure why such a high percentage would not be freed, but hopefully I'll
figure it out in the next week or two, time permitting.
--
Joe Nardelli
[EMAIL PROTECTED]
-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
