I sent the strings to Vojtech, but there is little hope.
He says this happens when the communication goes haywire
I presume the bit banging is overlayed on buttons and
the sound card does not deliver them in a timely manner
or something of that nature.

Does the hardware work with 2.2.x ?

I suspect that testing on 2.2 may be troublesome.

What is the joystick exactly? MS ships several of
them under the same marketing name. Please copy
all labels that may be found on it, including the
FCC ID and moldings.

For the joystick:
part no. 63545
FCC ID: C3KMJ1

It did work before with RedHat 6.x with the 2.2.x kernel.

I am sorry, but I overestimated my deductive abilities here.
Also, the goddamn Microsoft got a cart-blanche with C3K ID class.

What is the marketing name of this joystick ("SideWinder 3DPro"
by any chance?) and how many buttons has it got?
As you can see, I am trying to identify the thing...

Thanks.

Yep, its the Microsoft SideWinder 3D Pro. There are 4 buttons and a hat on the
stick, a throttle lever on the side, 4 buttons on the base, and one switch on
the underside. Its a pretty old one, too. 95 or 96 if I remember correctly.

The mysterious part is that the stick worked under 2.2.
I looked at the differences and there is nothing that
can matter.

Would it be asking too much to recompile the module
with "#undef SW_DEBUG" replaced by "#define SW_DEBUG 1",
near the line 46? If you do it, please upload the dmesg
output as an bug attachement.

Well, it shouldn't have been a problem, but when I tried to compile a new kernel
from the 2.4.3 source, I got this pile of errors:

make[2]: Entering directory `/usr/src/linux-2.4.3/drivers/char'
gcc -D__KERNEL__ -I/usr/src/linux-2.4.3/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -fno-strict-aliasing -fno-common -Wno-unused -pipe
-mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include
/usr/src/linux-2.4.3/include/linux/modversions.h   -c -o lp.o lp.c
In file included from /usr/src/linux-2.4.3/include/linux/spinlock.h:35,
                 from /usr/src/linux-2.4.3/include/linux/module.h:11,
                 from lp.c:114:
/usr/src/linux-2.4.3/include/asm/spinlock.h:9: nondigits in number and not
hexadecimal
/usr/src/linux-2.4.3/include/asm/spinlock.h:9: nondigits in number and not
hexadecimal
/usr/src/linux-2.4.3/include/asm/spinlock.h:9: parse error before `1b7d4074'
/usr/src/linux-2.4.3/include/asm/spinlock.h:10: `printk_R_ver_str' declared as
function returning a function
/usr/src/linux-2.4.3/include/asm/spinlock.h:10: warning: function declaration
isn't a prototype
In file included from /usr/src/linux-2.4.3/include/linux/prefetch.h:13,
                 from /usr/src/linux-2.4.3/include/linux/list.h:6,
                 from /usr/src/linux-2.4.3/include/linux/module.h:12,
                 from lp.c:114:
/usr/src/linux-2.4.3/include/asm/processor.h:51: warning: parameter names
(without types) in function declaration
/usr/src/linux-2.4.3/include/asm/processor.h:51: field
`loops_per_jiffy_R_ver_str' declared as a function
/usr/src/linux-2.4.3/include/asm/processor.h:72: nondigits in number and not
hexadecimal
/usr/src/linux-2.4.3/include/asm/processor.h:72: nondigits in number and not
hexadecimal
/usr/src/linux-2.4.3/include/asm/processor.h:72: nondigits in number and not
hexadecimal
/usr/src/linux-2.4.3/include/asm/processor.h:72: parse error before `65dda927'
/usr/src/linux-2.4.3/include/asm/processor.h:72: warning: function declaration
isn't a prototype
/usr/src/linux-2.4.3/include/asm/processor.h:251: warning: parameter names
(without types) in function declaration
/usr/src/linux-2.4.3/include/asm/processor.h:430: missing white space after
number `7e9'
/usr/src/linux-2.4.3/include/asm/processor.h:430: parse error before `7e9'
/usr/src/linux-2.4.3/include/asm/processor.h:430: `kernel_thread_R_ver_str'
declared as function returning a function
/usr/src/linux-2.4.3/include/asm/processor.h:430: warning: function declaration
isn't a prototype
/usr/src/linux-2.4.3/include/linux/module.h:175: `inter_module_get_R_ver_str'
declared as function returning a function
/usr/src/linux-2.4.3/include/linux/module.h:175: warning: parameter names
(without types) in function declaration
/usr/src/linux-2.4.3/include/linux/module.h:176:
`inter_module_get_request_R_ver_str' declared as function returning a function
/usr/src/linux-2.4.3/include/linux/module.h:176: warning: parameter names
(without types) in function declaration
/usr/src/linux-2.4.3/include/linux/module.h:177: nondigits in number and not
hexadecimal
/usr/src/linux-2.4.3/include/linux/module.h:177: nondigits in number and not
hexadecimal
/usr/src/linux-2.4.3/include/linux/module.h:177: nondigits in number and not
hexadecimal
/usr/src/linux-2.4.3/include/linux/module.h:177: parse error before `6b99f7d8'
/usr/src/linux-2.4.3/include/linux/module.h:177: `inter_module_put_R_ver_str'
declared as function returning a function
/usr/src/linux-2.4.3/include/linux/module.h:177: warning: function declaration
isn't a prototype
/usr/src/linux-2.4.3/include/linux/module.h:186: `try_inc_mod_count_R_ver_str'
declared as function returning a function
/usr/src/linux-2.4.3/include/linux/module.h:186: warning: parameter names
(without types) in function declaration
make[2]: *** [lp.o] Error 1
make[2]: Leaving directory `/usr/src/linux-2.4.3/drivers/char'
make[1]: *** [_modsubdir_char] Error 2
make[1]: Leaving directory `/usr/src/linux-2.4.3/drivers'
make: *** [_mod_drivers] Error 2

Did saving .config and "make mrproper" help?

nope, it didn't help

ok, I was able to build a new kernel by setting "Creative Ensoniq AudioPCI 97
(ES1371)" in the sound section to NO. (you might want to have someone check that
out...) Anyway, when I set #define SW_DEBUG 1 as you suggested, the driver
worked, which seemed strange. I looked through the code for the driver, and the
only thing this could materially effect is lines 59-63:

#ifdef SW_DEBUG
#define dbg(format, arg...) printk(KERN_DEBUG __FILE__ ": " format "\n" , ## arg)
#else
#define dbg(format, arg...) do {} while (0)
#endif

SW_DEBUG 1 means that dbg will actually take some time, and since this function
is often called immediately after udelay(SW_TIMEOUT), this has the effect of
increasing the delay. Next, I'm going to test this theory by not defining
SW_DEBUG and setting SW_TIMEOUT to a greater value.

Thanks, great work!

Vojtech wrote me that the pattern of the bit string
looks as if the joystick switched into 3-bit mode
while the driver expected it to be in 1-bit mode.
He also wrote that he never managed those devices
to work reliably under varying circumstances.
Quite possible a timing issue somewhere.

Do not do in-line delays with  for(i=0;i<100000;i++){wmb();}
Use calibrated functions udelay() and mdelay().

Got it. On line 632 of sidewinder.c, add udelay(SW_TIMEOUT). This is in the
sw_connect function right before the switch statement. I'd attach a patch file,
but its a one line fix.

A change that you describe places the udelay in the part of
the loop that has no time sensitive code below, and at the
end of the probing function. This just makes no sense.
I suspect we are not on the same page here. Please post
a proposed patch after all.

Also, how about this:

--- linux-2.4.8-ac9/drivers/char/joystick/sidewinder.c	Wed Aug 22 11:01:46 2001
+++ linux-2.4.8-ac9-niph/drivers/char/joystick/sidewinder.c	Fri Aug 24 23:25:25 2001
@@ -619,7 +619,7 @@
 
 	do {
 
	k--;
-
	udelay(SW_TIMEOUT);
+
	udelay(2 * SW_TIMEOUT);	/* P3: test. was one SW_TIMEOUT */
 
	i = sw_read_packet(gameport, buf, SW_LENGTH, 0);	/* Read data packet */
 
	dbg("Init 3: Mode %d. Length %d. Last %d. Tries %d.", m, i, l, k);
 

Well, it does make sense if we go through the loop more than once. I don't have
any specs for the joystick, but I knew that "#define SW_DEBUG 1" worked, so I
took a purely experimental approach. First I tried changing the value of
SW_TIMEOUT, but that didn't work. Then I found each instance of dbg() without a
udelay(SW_TIMEOUT) near it. One at a time, I added a udelay(SW_TIMEOUT) by the
dbg() until the driver worked, which was at the line I gave you. It turns out
that it does matter whether we have the extra delay the first time through the
loop. I tried the change you suggested, and it didn't work. But, if I move the
extra delay to the end of the loop, it does.

--- linux-2.4/drivers/char/joystick/sidewinder.c.orig	Fri Aug 24 00:01:01 2001+++ linux-2.4/drivers/char/joystick/sidewinder.c	Sat Aug 25 19:54:36 2001@@ -665,7 +665,7 @@
 
				break;
 
		}
 
	}
-
+
	udelay(SW_TIMEOUT);
 	} while (k && (sw->type == -1));
 
 	if (sw->type == -1) {

I wish I could say the above fix is perfect, but its not. I've been using it for
a while now, and every once in a while the joystick will not be detected
correctly. This is much better than before, when it was never detected....
Anyway, I'm going to try tweaking SW_TIMEOUT some more to see if I can get
things more reliable.

The thing is so unstable that I do not see how I can help.
Mind if I close with WONTFIX? I cannot go for NOTABUG, because
there is no way to tell what is going on even.