On 08/06/2010 10:06 PM, jdmcdaniel3 wrote:
>
> I write software to control systems which include equipment made by the
> company I work for and equipment made by other companies. It is my job
> to make everything work together properly as a system, no matter who
> made it. This is different in that at some point, all things are known
> to me. Either it is made to work, or I toss it out and buy something
> else, if the cost can be controlled. If the costs are high, I toss it
> back upstairs. I have been in the systems business since 1975 and I
> have written binary drivers for all sorts of things in the past.
OK, you certainly have the experience. Now suppose that some customer wants to
use some device that you have never seen. That describes the current case. I am
certain that USB3 works on the developers systems. Even so, your is different.
> Does that mean that anything will work with everything? No not hardly,
> and if there is a good reason to use a certain brand or model over
> another I will use it or stick with it and toss out things not known to
> work. In the case of various USB3 adapters, I surely do not know all of
> the details. However, If something did work in kernel 2.6.31 and it
> does not work under 2.6.34, then the new kernel and its modifications
> are at fault and whom ever caused this issue, knowingly or unknowingly.
> Does that mean that some details are complex and one thing can affect
> another, well it sure can. The fact that the same functionality that
> existed under kernel 2.6.31 has been restored to kernel 2.6.35 shows
> that there are others that decided some sort of action was required, no
> matter what the exact reason might be.
All USB3 adapters will fall back to USB2, just as USB2 will fall back to USB1.1.
Kernel 2.6.31 worked on your device because that kernel never tried to exercise
the enhanced features. In 2.6.34, they tried to use the new capabilities.
Unfortunately, it does not work on your device.
> Stuff is said to roll down hill and I have the advantage of producing
> the final product. I have NEVER failed in my 35 years in working with
> systems to meet the schedule and the specifications and to meet the
> customer requirements. I have failed a few times to make any money, and
> at least one time it caused me to look for a new employer. I understand
> the issues I think, but I do expect a better product in such a thing as
> the kernel. Not that bugs are some sort of surprise. And, notice I did
> not say I never made a mistake. I am in a position to fix my mistakes
> before they can affect others. This is the main difference in what I do
> and how the kernel is developed, and of course the number of people that
> it affects.
You seem not to understand that Linux developers do not have access to every
piece of hardware that people want to use. This is not like you or the Windows
developers for the vendors who know exactly what hardware must be supported.
I have a recent example with the driver for the BCM43xx wireless device. Since
the beginning of Broadcom’s production of these devices, they have contained an
SPROM that is addresses at an MMIO offset of 0x1000. Suddenly, in some but not
all Netbooks, this offset was changed to 0x0800 with nothing mapped at 0x1000.
That alone would have been bad enough, but to make it worse, some but not all of
these boxes freeze when an attempt is made to read a non-existent address. Now,
are the developers responsible for this situation? As I did not have the
hardware, it was difficult to even learn the cause of the freeze. Fortunately, I
had the maintainer of wireless drivers to help debug. He was able to find the
reason for the freeze, but together we were unable to find a workaround until I
got my hands on a box with the trouble.