epic100.c, SMC EtherPower II, SMC83c170/175 "EPIC"

epic100.c, SMC EtherPower II, SMC83c170/175 "EPIC"

[Ingo Rohloff]

Hello,

I have got a "[SMC] 83C170QF" adaptor in my computer and I wasn't
able to use the driver which is in linux-2.4.9.

The sympotms are lot's of messages of this in /var/log/messages:
"kernel: eth0: Too much work at interrupt, IntrStatus=0x008d0004"

This seems to be a known problem; at least I found other people
complaining about the same message in their kernel logs.
The problem has different severity for different people. 
I wasn't able to get the card working at all (basically the
computer hung, while trying to mount several NFS directories).

After searching the web for further information I was able
to obtain a patched version, which was modified Heiko Boch. 
It seems this version is an older linux-2.4.x driver with 
some additional patches.

This version works without glitches on my system with a 
vanilla linux-2.4.9 kernel. 

The homepage of Heiko Boch doesn't seem to exist anymore, so
for all people who use this card and have the above problem,
I put his modified version of epic100.c on my home page at
www.in.tum.de/~rohloff (look for epic100.c). 

I hope that after some testing someone can have a look over
this version, who really can tell what the essential differences
compared to the version in linux-2.4.9 are.

Perhaps this will lead to a working linux-2.4.xx version in the future.

so long
  Ingo

Re: epic100.c, SMC EtherPower II, SMC83c170/175 "EPIC"

[Ingo Rohloff]

Hi,

I posted an error report about the epic100.c module about one
week before.
The sympotms were lot's of messages of this in /var/log/messages:
"kernel: eth0: Too much work at interrupt, IntrStatus=0x008d0004"

After one week of really frustrating debugging and incrementally
morphing the working version of the driver I got into the (for
me) non-working linux-2.4.9 version I finally found out what was
going on: the linux-2.4.9 driver has no bug!

BEWARE: DON'T USE gcc-2.95.2!
I compiled the linux-2.4.9 version with gcc-2.95.2.
And I can _definitely_ confirm that epic100.c triggers a compiler
bug. (I have the erronous assembler code on my harddisk if anyone is
interested.)

Compile the same module with gcc-2.95.3 and the bug is gone
(at least in my case. The assembler code is different and correct.)

conclusion:
Don't use gcc-2.95.2 to compile your kernel!

so long
  Ingo Rohloff

epic100.c, gcc-2.95.2 compiler bug!

[Ingo Rohloff]

Hi,

I posted an error report about the epic100.c module about one
week before.
The sympotms were lot's of messages of this in /var/log/messages:
"kernel: eth0: Too much work at interrupt, IntrStatus=0x008d0004"

After one week of really frustrating debugging and incrementally
morphing the working version of the driver I got into the (for
me) non-working linux-2.4.9 version I finally found out what was
going on: the linux-2.4.9 driver has no bug!

BEWARE: DON'T USE gcc-2.95.2!
I compiled the linux-2.4.9 version with gcc-2.95.2.
And I can _definitely_ confirm that epic100.c triggers a compiler
bug. (I have the erronous assembler code on my harddisk if anyone is
interested.)

Compile the same module with gcc-2.95.3 and the bug is gone
(at least in my case. The assembler code is different and correct.)

conclusion:
Don't use gcc-2.95.2 to compile your kernel!

so long
  Ingo Rohloff

Re: epic100.c, gcc-2.95.2 compiler bug!

[antirez]

On Fri, Sep 07, 2001 at 04:03:15PM +0200, Ingo Rohloff wrote:
> BEWARE: DON'T USE gcc-2.95.2!
> I compiled the linux-2.4.9 version with gcc-2.95.2.
> And I can _definitely_ confirm that epic100.c triggers a compiler
> bug. (I have the erronous assembler code on my harddisk if anyone is
> interested.)

The following seems a gcc 3.0 bug, not sure it was fixed in gcc 3.01.

See the assembly generated with -O3 for the following code:

--------------------------------------------------------------
inline static long QInt(double inval)
{
        long *l;
        char *c = (char*) &inval;
        inval = 68719476991.99;

        l = (long*) (c+2);
        return *l;
}

int main(void)
{
        printf("%lu\n", QInt(OFFENDING_VALUE));
        return 0;
}
---------------------------------------------------------------

the above function is compiled as:

        .file   "test2.c"
        .section        .rodata
.LC0:
        .string "%lu\n"
        .text
        .align 16
.globl main
        .type   main,@function
main:
        pushl   %ebp
        movl    %esp, %ebp
        subl    $48, %esp
*       movl    $16776561, -32(%ebp)
*       movl    -30(%ebp), %eax
*       movl    $1110441984, -28(%ebp)
        pushl   %eax
        pushl   $.LC0
        call    printf
        addl    $16, %esp
        movl    %ebp, %esp
        xorl    %eax, %eax
        popl    %ebp
        ret
.Lfe1:
        .size   main,.Lfe1-main
        .ident  "GCC: (GNU) 3.0"

Note the line I marked with "*".
The double var is 8 byte, it is loaded
moving two 32 bit words in the -32 and -28 offset.
Unfortunatelly with -O3 the "*l" value get
computed between the two 'movl', and not after
the second movl.

This code is really unsane anyway but this seems
a clear gcc 3.0 bug.

I hope that the gcc folks here may report the
problem if not already known.

I didn't tested it but maybe the same problem
exists with other 8 byte types like 'long long'.

regards,
antirez

Re: epic100.c, gcc-2.95.2 compiler bug!

[Jakub Jelinek]

On Fri, Sep 07, 2001 at 04:13:23PM +0200, antirez wrote:
> The following seems a gcc 3.0 bug, not sure it was fixed in gcc 3.01.
> 
> See the assembly generated with -O3 for the following code:

a) what does this have to do with the kernel?
b) it is not a compiler bug, read info gcc about strict-aliasing

	Jakub