Re: wavelan has fatal error with 2.4.0 (but worked in 2.4.0-test12)

Re: wavelan has fatal error with 2.4.0 (but worked in 2.4.0-test12)

[Jean Tourrilhes]

On Tue, Jan 09, 2001 at 07:17:01AM -0500, John Ruttenberg wrote:
> I get:
> 
>     Jan  9 07:04:51 mojo cardmgr[511]: socket 1: Digital RoamAbout/DS
>     Jan  9 07:04:52 mojo cardmgr[511]: executing: 'modprobe wavelan_cs'
>     Jan  9 07:04:52 mojo cardmgr[511]: + /lib/modules/2.4.0-test11/pcmcia/wavelan_cs.o: unresolved symbol __bad_udelay
>     Jan  9 07:04:52 mojo cardmgr[511]: + /lib/modules/2.4.0-test11/pcmcia/wavelan_cs.o: insmod /lib/modules/2.4.0-test11/pcmcia/wavelan_cs.o failed
>     Jan  9 07:04:52 mojo cardmgr[511]: + /lib/modules/2.4.0-test11/pcmcia/wavelan_cs.o: insmod wavelan_cs failed
>     Jan  9 07:04:52 mojo cardmgr[511]: modprobe exited with status 255
>     Jan  9 07:04:52 mojo cardmgr[511]: executing: 'insmod /lib/modules/2.4.0/pcmcia/wavelan_cs.o'
>     Jan  9 07:04:52 mojo cardmgr[511]: + /lib/modules/2.4.0/pcmcia/wavelan_cs.o: unresolved symbol __bad_udelay
>     Jan  9 07:04:52 mojo cardmgr[511]: insmod exited with status 1

	This is a bug with the definition of udelay(). Somebody tried
to be too clever with udelay(), and the end result is that it breaks
perfectly good and valid code.
	Therefore, it should be reported as such on LKML, a bug in udelay().

	I think that Alan has a ugly workaround for this driver (or
maybe it's only for wavelan.c) in the ac4 tree, so please check
there. For my part, I insist that the code is correct, that replacing
an inline function by a #define is going backwards and that udelay()
should be fixed one way or another (easy, just define __bad_udelay()
as returning a compilation warning or an error message).
	Also, please remember that the version of wavelan_cs.c in the
kernel is outdated with respect to the version in the Pcmcia package.

	That's it...

	Jean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: wavelan has fatal error with 2.4.0 (but worked in 2.4.0-test12)

[Alan Cox]

> 	This is a bug with the definition of udelay(). Somebody tried
> to be too clever with udelay(), and the end result is that it breaks
> perfectly good and valid code.
> 	Therefore, it should be reported as such on LKML, a bug in udelay().

It is a bug in the driver.

> there. For my part, I insist that the code is correct, that replacing
> an inline function by a #define is going backwards and that udelay()
> should be fixed one way or another (easy, just define __bad_udelay()
> as returning a compilation warning or an error message).

You can't #define a function to a #warning or #error in C. Language limitation

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: wavelan has fatal error with 2.4.0 (but worked in 2.4.0-test12)

[Jean Tourrilhes]

On Tue, Jan 09, 2001 at 05:13:42PM +0000, Alan Cox wrote:
> > 	This is a bug with the definition of udelay(). Somebody tried
> > to be too clever with udelay(), and the end result is that it breaks
> > perfectly good and valid code.
> > 	Therefore, it should be reported as such on LKML, a bug in udelay().
> 
> It is a bug in the driver.

	Please check again the code and point me the invalid
udelay(). You will realise that there is no delay in the driver that
is longer than 100ms.
	The bug is that udelay() can't be passed a variable but only a
constant. Therefore bug in udelay().

> > there. For my part, I insist that the code is correct, that replacing
> > an inline function by a #define is going backwards and that udelay()
> > should be fixed one way or another (easy, just define __bad_udelay()
> > as returning a compilation warning or an error message).
> 
> You can't #define a function to a #warning or #error in C. Language limitation

	Yes. Tough.

	Jean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: wavelan has fatal error with 2.4.0 (but worked in 2.4.0-test12)

[Alan Cox]

> > It is a bug in the driver.
> 
> 	Please check again the code and point me the invalid
> udelay(). You will realise that there is no delay in the driver that
> is longer than 100ms.

The udelay limit is set a lot lower than 100mS. It has to be somewhat lower
otherwise you have to do two levels of loops which will throw small udelay
timings a fair whack.

> 	The bug is that udelay() can't be passed a variable but only a
> constant. Therefore bug in udelay().

Sounds like a compiler bug.

#define udelay(n) (__builtin_constant_p(n) ? \
	((n) > 20000 ? __bad_udelay() : __const_udelay((n) * 0x10c6ul)) : \
	__udelay(n))

non constants are covered.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: wavelan has fatal error with 2.4.0 (but worked in 2.4.0-test12)

[Jean Tourrilhes]

On Tue, Jan 09, 2001 at 05:48:47PM +0000, Alan Cox wrote:
> > > It is a bug in the driver.
> > 
> > 	Please check again the code and point me the invalid
> > udelay(). You will realise that there is no delay in the driver that
> > is longer than 100ms.
> 
> The udelay limit is set a lot lower than 100mS. It has to be somewhat lower
> otherwise you have to do two levels of loops which will throw small udelay
> timings a fair whack.

	Sorry, I mixed up my units. All the delays are lower than 100us.

> > 	The bug is that udelay() can't be passed a variable but only a
> > constant. Therefore bug in udelay().
> 
> Sounds like a compiler bug.
> 
> #define udelay(n) (__builtin_constant_p(n) ? \
> 	((n) > 20000 ? __bad_udelay() : __const_udelay((n) * 0x10c6ul)) : \
> 	__udelay(n))
> 
> non constants are covered.

	Therefore, compiler bug. Ouch !

	Jean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/