I'm writing a library that interfaces to a Full Speed USB device using libusb. It seens to be working fine, but when I run the code inside GDB or Valgrind, I see in Wireshark that there are CLEAR_TT_BUFFER commands being send to the USB hub (I presume it's the internal one, since I have the device directly attached to the PC), and some packets seem to be lost (this shouldn't happen, as I'm using bulk transfer).
So the question is, what (under which conditions) is issuing those commands, and how do I prevent/detect them?
Related
I want to be able to detect when a new external device is connected to the linux system and upon that send a notification message to a running process.
I was wondering if there is any other solution than periodically scan for /dev/
and detect if anything has changed.
While you can use udev, the underlying mechanism is netlink. Interfaces themselves are not normally in /dev, but do show up under /sys/class/net as sub-directories. However, the hotplug.txt gives a good start to inspecting kernel events. Run the sample code and examine the netlink data when an interface is connected. The text is ASCII that any user space application can parse and use.
I have an Ada program that communicates with an Intellibox Basic(a box that allows you to control trains) that is connected via USB.
Under Windows, I had to install a specific Serial driver (CP210x USB to UART Bridge VCP). With that driver I can communicate perfectly with the box. That means sending commands to the box.
Under Linux I'm communicating via /dev/ttyusb0 and I'm able to get messages from the box, but I can't send commands to the box. Nothing happens. I don't get an error or something.
Is the behavior of GNAT.SerialCommunication differently on Linux ? The program is the same. Do I have to setup certain things to get it to work on Linux ?
For example: A typical 2-byte command has the Command as the first Byte and the CRC check as the second one.
I had trouble with Serial_Communication at some point, where it turned out to be a problem with hardware-handshake being enabled in Linux. It's hard-coded in g-sercom.adb, look for "CRTSCTS". If your Intellibox does not use hardware handshake, Write() will block.
I believe I solved it by removing the CRTSCTS mask from the flags.
I'm a newbie here at this forum. I'm currently stuck with a problem.
I'm a beginner to Linux kernel drivers, and currently involved in developing a Linux SCSI device driver for a block mass storage device. The development platform is on a high-end machine with Fedora 14. The setup is 1 host to one LU/device. To make the long story short, the driver is working in the sense that it initializes without problems, it can detect the device and send scsi frames to it, it can read and write to the device, and I can do stable Iometer read and write tests through the driver. All of that when there is only 1 outstanding command at a time (no queueing).
The problem is, I couldn't get queuing to work. The upper SCSI layers doesn't send me (LLD) more than one commands to be outstanding unless I scsi_done() the first command. I expect that the upper layer can call queuecommand() more than once before I send the commands to the device for processing, then for the device to interrupt me for the response and for LLD to close the command with scsi_done(). Without queuing, our speed is very slow.
I've already tweaked values I thought are connected to queuing, like setting .can_queue and .cmd_per_lun to my target queue_depth in both scsi_host and scsi_host_template. Basically I've played with various values including 1, but to no avail. I also did disable and enable tagging if this has any effect, but still no change. So far I don't remember doing much with scsi_device in the driver, except in slave_configure. Is there anything I'm missing and can still do in driver level? I can't believe Linux would have no support for command queuing. I'm missing something here.
I have a serial GPS connected to an embedded PC via serial<->USB adapter (Prolific PL2303). Every 5 minutes a shell script runs a Python script that reads GPS data via Pyserial then upload them to Internet. If I plug my GPS directly to the PC (via PL2303) everything is ok and my system runs forever BUT if I use a usb HUB between pl2303 and the PC I have a this problem: the Python script runs ok for about 3-6 hours then it goes in a D-state (uninterruptible sleep) and the shell script cannot run it again (I can only shutdown the system, no kill possible). I checked my script and I used usb hubs from various vendors (powered and not) with the same result.
PS my embedded pc (from Embeddedarm) runs an updated Debian Lenny.
Ho can I fix it ?
A process in D state means the kernel (most probably a device driver), has put your process into uninterruptible sleep.
To be honest, there is probably quite little you can do about it as a user, unless you intend to debug the kernel USB stack and/or specific USB chipset device driver.
Here is what would do -
Make sure the kernel configuration of you embedded device has the kernel config option for the magic sysreq key and the run time configuration for it turned on. See: http://en.wikipedia.org/wiki/Magic_SysRq_key on how to do that.
Recreate the problem (have the process get stuck in D state).
Find out the PID of the stuck python script with ps and run strace -p PID on it. This will give you the specific system call that the process is sleeping in.
Send the magic sysreq key command 't', that lists all tasks and their kernel stack to console. Look for the specific task of the python script by PID, see at what part of the kernel code exactly are you stuck.
Open the kernel code and try to debug the problem if you can, or port it to the relevant mailing list if you don't.
One more suggestion would be to try and see if the problem goes away in a more recent kernel version then Debian ships. If so, you know it is a bug fixed in newer version of the kernel and you have the choice of either using the newer version and try to port the fix to the old version you care using.
Good luck! you'll need it...
Ubuntu launchpad has a bug filed that is suspiciously like yours. The workaround suggested is:
modprobe -r pl2303
modprobe pl2303
See if this works around the bug?
The situation is this: I have a USB device (a custom device I'm trying to talk to) with two endpoints, one writing to the device, one reading from the device. Both are bulk transfers. Every communication transaction takes the form of (1) Write a command to the device (2) Read the response. I'm using libusb (version 0.1 rather than the 1.0 beta) to actually perform the communications.
On Windows, all is well. I can connect the device, claim the interface and communicate happily. However, in Ubuntu (a standard Hardy desktop install), whilst I can connect to the device and write to it, all read operations fail with the error "error submitting URB: Invalid argument" reported from libusb (error code -22).
If I check /var/log/messages I see a warning message logged for the same time as the read was attempted: "sysfs: duplicate filename 'usbdev4.3_ep81' can not be created" - which tallies with the device (it is indeed on that bus and it's endpoint 81 I'm trying to read from).
So... anyone seen a similar problem using libusb, or have any idea how to fix it?
Turns out it was a misconfiguration in the descriptors on the device itself. lsusb -v showed an extra interface which was never used, which had a single isochronous endpoint 0x81. Since this was never used (and had never been tested as far as I could see, so quite possibly not even defined correctly) I removed it from the device descriptors completely (in the firmware).
And now I have a fully working device. Why linux refused to read from the device but Windows worked fine I don't know, but it definitely sent me on a wild goose chase.
I haven't used libusb in quite some time -- but the sysfs error indicates that this is likely to be a kernel problem rather than a libusb one, so I'd start by trying to track that one down. (Not much point in trying to work with libusb until you're sure your kernel is talking to the device correctly).
Does the patch at http://kerneltrap.org/mailarchive/linux-usb-devel/2007/10/17/345922 apply to your kernel? (If so, does it fix the issue?)
I had to do some hacking to udev rules to get the device created with the right permissions for libusb to work. Like so:
SUBSYSTEM=="usb" ATTRS{idVendor}=="0a81", ATTRS{idProduct}=="0701", \
MODE="0666" SYMLINK+="missile_launcher"
(This was an usb missile launcher I was writing a driver for.
Also this snippet was required to not clash with the kernel.
if(LIBUSB_HAS_DETACH_KERNEL_DRIVER_NP)
{
// Detach kernel driver (usbhid) from device interface. (Linux hack)
usb_detach_kernel_driver_np(launcher, 0);
usb_detach_kernel_driver_np(launcher, 1);
}
I'm not sure how this relates to your problem, but atleast there are two possible points of failure that might be involved.
You can try WinDriver it's a commercial tool but have free full function evaluation (somehow time limited). You can check with WinDriver and if problem is reproducible it's might be device or your protocol fault. You did not give enough information to determine or analyze.