[Home]

Summary:ASTERISK-00083: wcfxs driver crashes when compiled with gcc295
Reporter:jwr (jwr)Labels:
Date Opened:2003-08-11 17:11:10Date Closed:2011-06-07 14:00:38
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) p2.jpg
Description:When the kernel and the zaptel drivers are compiled with gcc295, the wcfxs driver loads, but then oopses when ztmonitor or asterisk is run.

This wouldn't be a problem, except gcc 2.95-3 is the recommended compiler (by some kernel people), and some kernel code will not compile properly using later gcc versions.

This is using Linux 2.4.22-pre7, compiled using gcc 2.95.3 (20010315, release). This gcc is available as the gcc295 RPM package on rpmfind.net and is easily installable alongside the main gcc compiler.

****** ADDITIONAL INFORMATION ******

Contact me if a ksymoopsed oops dump is necessary (if this isn't reproducible elsewhere).

If no one is willing to work on this issue, then I believe at least a big warning is in order.
Comments:By: Mark Spencer (markster) 2003-08-12 17:27:04

Does it oops in the interrupt handler?  Is it possible to get a kymoops printed?
By: jwr (jwr) 2003-08-12 23:41:48

Yes, it does oops in the interrupt handler.

I've enclosed a partial ksymoops (I didn't type in register values) and
attached a JPEG image of the oops in its full glory.


eip: c01129a3
EIP: 0010:[<c01129a3>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010097
Call Trace: [<f89a94e9>] [<f89a4f38>] [<f89a4989>] [<c011bb67>] [<f892fabd>]
 [<c0107e7d>] [<c0107fe6>] [<c0105220>] [<c0105220>] [<c0105220>] [<c0105220>]
 [<c0105243>] [<c01052a9>] [<c0105000>] [<c0105027>]
Code: 8b 01 85 45 fc 74 4c 31 c0 9c 5e fa c7 01 00 00 00 00 83 79


>>EIP; c01129a3 <__wake_up+33/a0>   <=====

Trace; f89a94e9 <END_OF_CODE+11faaa/????>
Trace; f89a4f38 <END_OF_CODE+11b4f9/????>
Trace; f89a4989 <END_OF_CODE+11af4a/????>
Trace; c011bb67 <update_wall_time+b/34>
Trace; f892fabd <END_OF_CODE+a607e/????>
Trace; c0107e7d <handle_IRQ_event+31/5c>
Trace; c0107fe6 <do_IRQ+6a/a8>
Trace; c0105220 <default_idle+0/28>
Trace; c0105220 <default_idle+0/28>
Trace; c0105220 <default_idle+0/28>
Trace; c0105220 <default_idle+0/28>
Trace; c0105243 <default_idle+23/28>
Trace; c01052a9 <cpu_idle+41/54>
Trace; c0105000 <_stext+0/0>
Trace; c0105027 <rest_init+27/28>

Code;  c01129a3 <__wake_up+33/a0>
00000000 <_EIP>:
Code;  c01129a3 <__wake_up+33/a0>   <=====
  0:   8b 01                     mov    (%ecx),%eax   <=====
Code;  c01129a5 <__wake_up+35/a0>
  2:   85 45 fc                  test   %eax,0xfffffffc(%ebp)
Code;  c01129a8 <__wake_up+38/a0>
  5:   74 4c                     je     53 <_EIP+0x53>
Code;  c01129aa <__wake_up+3a/a0>
  7:   31 c0                     xor    %eax,%eax
Code;  c01129ac <__wake_up+3c/a0>
  9:   9c                        pushf  
Code;  c01129ad <__wake_up+3d/a0>
  a:   5e                        pop    %esi
Code;  c01129ae <__wake_up+3e/a0>
  b:   fa                        cli    
Code;  c01129af <__wake_up+3f/a0>
  c:   c7 01 00 00 00 00         movl   $0x0,(%ecx)
Code;  c01129b5 <__wake_up+45/a0>
 12:   83 79 00 00               cmpl   $0x0,0x0(%ecx)

Good luck!
By: Mark Spencer (markster) 2003-08-15 23:31:37

Can you check the compile flags that zaptel is using with those of your main kernel?  Is it only wcfxs that fails?  no other drivers (e.g. wcfxo)?  Also, does it only occur when you actually open it, or as soon as you load the driver, or as soon as you run ztcfg?
By: Mark Spencer (markster) 2003-08-21 10:37:05

Customer seems to have lost contact
By: jwr (jwr) 2003-08-21 14:54:54

Customer has been away for a week, travelling. Please don't discard the work I've put in so far. I will provide you more information, probably later today.
By: jwr (jwr) 2003-08-21 15:21:32

I have just re-verified the problem. To answer your questions:

1) I haven't touched the compile flags either in the kernel or in zaptel. The only thing I have changed is CC=gcc295. So, for the kernel the flags are as in stock 2.4.22-rc2, and for zaptel they are the stock zaptel flags, which for me are:

gcc295 -I/usr/src/linux-2.4/include -O6 -DMODULE -D__KERNEL__ -DEXPORT_SYMTAB -I/usr/src/linux/drivers/net -Wall -I. -Wstrict-prototypes -fomit-frame-pointer -I/usr/src/linux/drivers/net/wan -I /usr/src/linux/include -I/usr/src/linux/include/net -DMODVERSIONS -include /usr/src/linux/include/linux/modversions.h  -DECHO_CAN_MARK2 -DCONFIG_ZAPATA_PPP -DTORMENTA_BASE=0xd0000 -DDEFAULT_TONE_ZONE=0 -DSTANDALONE_ZAPATA -c zaptel.c

2) I can only verify wcfxs, because I only have the TDM400P in that machine.

3) It occurs when I open the device. Module loading works fine, ztcfg runs fine and doesn't complain. Opening the device (even by doing "cat /dev/zap/1") produces an immediate oops and freezes the machine.

I have also verified that the card is perfectly usable in this machine with the exact same kernel and zaptel versions compiled with gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7). The problem only occurs when compiling with gcc295.

Also, I have verified (twice) that the kernel and the zaptel drivers are compiled from scratch using the same compiler.

If you want to test with gcc-2.95 and you are on a RedHat system, there is a 'gcc295' package on rpmfind.net which makes this very easy. You get an additional 'gcc295' compiler.
By: Mark Spencer (markster) 2003-08-21 16:05:54

Any unusual compile flags (e.g. MMX)?
By: jwr (jwr) 2003-08-21 16:31:18

The processor type selected is Pentium-4, the architecture for gcc is i686. I haven't tweaked any flags manually.

What could be important, I do have HIGHMEM support (4GB) enabled, as this machine has 1GB of RAM.

An example of the kernel compile command line:

gcc295 -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686  -DUTS_MACHINE='"i386"' -DKBUILD_BASENAME=version -c -o init/version.o init/version.c
By: Mark Spencer (markster) 2003-08-21 19:16:49

Does making the zaptel compile flags match the kernel compile flags make a difference?
By: jwr (jwr) 2003-08-25 20:07:45

Sorry -- I'll be away for a week (possibly two, travelling) and unable to remotely test this. I do want to get back to it after I come back, unless you manage to resolve the issue.
By: Mark Spencer (markster) 2003-09-10 13:20:22

Any status update on this?
By: jwr (jwr) 2003-09-18 22:44:38

I have now verified this and matching the flags doesn't seem to make a difference.

After modifications to the Makefile, zaptel gets compiled with the following flags:

gcc295 -I/usr/src/linux-2.4/include -O6 -DMODULE -D__KERNEL__ -DEXPORT_SYMTAB -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -DUTS_MACHINE='"i386"'  -DMODVERSIONS -include /usr/src/linux/include/linux/modversions.h  -DECHO_CAN_MARK2 -DCONFIG_ZAPATA_PPP -DTORMENTA_BASE=0xd0000 -DDEFAULT_TONE_ZONE=0 -DSTANDALONE_ZAPATA -c wcfxs.c

(/usr/src/linux pointing to the appropriate tree, of course).

No difference, still oopses upon open.
By: Mark Spencer (markster) 2003-09-24 08:42:10

What about compiling without optimizations?