Device VID 0x3923 (National Instruments) and PID 0x7269 corresponds to the firmware loader personality of the device. Each time you plug in the device, it should initially enumerate as 0x7269 briefly, a driver process will bus load the firmware, and then the device should enumerate as PID 0x726F (for USB-6210).
It would seem, for some reason, that the firmware was not loaded correctly when you plugged in the device the second time. Try rebooting with the device disconnected and then connect it again after the system boots. Does that allow it to work correctly? If not, you can try manually executing /usr/local/bin/niusb9162dlfw to see if it is able to update your device successfully.
Hopefully this helps-
Thank you very much for your timely answer. I try manually executing /usr/local/bin/niusb9162dlfw and it works!!!
It is very helpful.
Try to understand what EXPORT_SYMBOL_GPL, and draw your conclusion.. Logically, this is licensing collision problem that is deliberately put into the code. Fixing it will then require you to change the license to make it compatible, which you have no legal right to do.
well, you could still use something like this
#define EXPORT_SYMBOL_GPL EXPORT_SYMBOL
which will not violate the license of nikal.c or the kernel, it's just unrespectfull. IMHO (I'm not a lawyer), changing MODULE_LICENSE is just a patch which doesn't change the license, it only changes the license reported to the kernel. I didn't read the license of nikal.c though, but either patching is gernerally allowed or not. If it's not allowed, then all threads on this forum regarding making your driver work on current distos are talks about illegal acts.
Let me add something here. First, we are no lawyers but humans. From the latter point of view, NI already violates the GPL by distributing binary kernel modules - it's just not enforced. Why?
Recall the idea behind EXPORT_SYMBOL_GPL. The kernel developers already thought that many vendors (mainly NVIDIA, ATI at that time, but also vendors like NI) violate the GPL by distributing derived kernel work. instead of going to court, they decided to slowly increase the pressure on these vendors by introducing this new macro. This basicly means that the kernel functions your driver uses are deeper kernel functions which make your driver a derived kernel work and therefore it also must be licensed under the GPL. The circumstance that your driver happens to work on 2.6.26 and not on 2.6.27 doesn't change this fact.
So please stop pointing at the kernel developers if your driver doesn't work on current linux distros, but point at your management (or if you don't want to, stop pointing at all).
Recall the idea behind EXPORT_SYMBOL_GPL. The kernel developers already thought that many vendors (mainly NVIDIA, ATI at that time, but also vendors like NI) violate the GPL by distributing derived kernel work. instead of going to court, they decided to slowly increase the pressure on these vendors by introducing this new macro.
Wether or not a driver in the Linux kernel is a derived work is a contentious issue in the kernel developr community. Depending on the kernel developer you ask you will get a different opinion. There have been many flame wars surrounding this topic on lkml and lets not bring those into this forum.
The agreed upon point of EXPORT_SYMBOL_GPL is so kernel developers have the ability to explicilty mark entry points that constitute a derived work and thus can only be used by drivers covered under GPL or compatible licenses. Since the NI driver is not a GPL driver, it is not allowed to use those entry points.
Whether or not other entry points will move to EXPORT_SYMBOL_GPL is up to the maintainers and peer review as they commit patches. There is no mandate that all entry points can and will move to this.
LABVIEW HARDLY WORKS ON VERSIONS ON LINUX THAT NI CLAIMS "IT DOES WORK"
Stop wasting your time on installing Labview on Ubuntu IT DOES NOT work
I spent weeks on installing,... attempting to install Labview Linux on the flavors of Linux that NI claims they work and I was not successful.
Ubuntu defiantly does not work.
Its a shame that NI only puts efforts on Windows version and Mac and Linux are so neglected
Hi , Behzad
Thank you for your advice. I didn't install labview on ubuntu. but I just installed NIDAQ driver on unbuntu 12.04. I want to use python to process signals detected through C programme which can be found as a template in the example files. I am working on it now and hope it works.
If you wanted to automate the loading of the firmware, you should take a look at writing a udev rule to support that. There are plenty of guides online on how to do that for a specific USB vendor/product ID running an action (which is precisely what you want)
Sorry man, that's out of our hands.
Actually it is exactly in your hand. Your fault - you broke it. By not complying to the basic license rules. This behaviour already was illegal for a long time - now the user just is technically protected against doing illegal actions by accident.
Note: violating the GPL means the license is immediately void - you then *may not* use Linux anymore. This is serious, no kindergarten !
Refactoring our driver code to fix this is _HUGE_ amount of work..
The solution is pretty trivial: publish the source under GPL. Period.
Or give us complete specs (of course, *NO* NDA) and some HW, and we'll develop clean IIO drivers within weeks.
But certain folks upstairs probably want to shut down the company.