ibmtr.o does not like 2.4 [Was: IBM Model 350 does not like 2.4]

2001-02-06 Thread J Sloan 

Hi,

Just to follow up on my own post, the problem is
way down in the network driver layer, specifically
in the ibmtr driver - it seems to be happy with 2.2,
and barfs with 2.4 - for now I replaced it with an
IBM pci card (olympic driver) and 2.4 is now solid
on the machine that had serious problems using
the isa token ring card.

I'l have a look at ibmtr if nobody beats me to it.

jjs

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

IBM Model 350 does not like 2.4

2001-02-05 Thread J J Sloan 

Hi All,

I have 10 systems running 2.4 that are rock solid, but I have
1 system that has problems with 2.4. The box had run perfectly
for 46 days with 2.2.19pre2, and today I installed 2.4.1-ac3
to see how it would go. It seemed to run fine for a few minutes,
then the old problem reasserted itself:

"df" gives a segmentation fault:

iron: /root
(tty/dev/pts/0): bash: 1040 > df
Filesystem   1k-blocks  Used Available Use% Mounted on
/dev/hda1  1007960457996498760  48% /
/dev/hda3  1198496   1082264 55352  96% /usr
Segmentation fault

Initial look at the oops implicates the sunrpc code.

This is Red Hat 7.0 with all updates applied running on a
humble pentium 166 (IBM model 350). The identical oops
occurs whether the kernel is compiled with kgcc or gcc-2.96 .

Hope this helps,

jjs

decoded ksymoops follows:

ksymoops 2.3.4 on i586 2.4.1-ac3.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.1-ac3/ (default)
 -m /boot/System.map (specified)

Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not 
found in System.map.  Ignoring ksyms_base entry
Unable to handle kernel paging request at virtual address feff3112
c482dab4
*pde = 
Oops: 
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: feff310a   ebx: feff310a   ecx:    edx: c36c5b20
esi: c36ef610   edi: c36c5b20   ebp:    esp: c1d31d14
ds: 0018   es: 0018   ss: 0018
Process df (pid: 1305, stackpage=c1d31000)
Stack: 08040016 c08c7300 4000 c01b291e  c36c5b20 c36c5b20 c482db9a
   c36c5b20 c1d31da0 c36c5b20 c1d31dd4 c1d31d98 c482dc9f c36c5b20 
   c1d31da0 c1d31e80 c482951a c1d31da0  c1d31da0 c36efc10 c482940c
Call Trace: [] [] [] [] [] 
[] []
   [] [] [] [] []
Code: 66 83 7b 08 00 75 15 a1 68 2a 29 c0 39 43 04 79 0b 8b 03 89

>>EIP; c482dab4 <[sunrpc]rpcauth_gc_credcache+2c/b0>   <=
Trace; c01b291e 
Trace; c482db9a <[sunrpc]rpcauth_lookup_credcache+36/8c>
Trace; c482dc9f <[sunrpc]rpcauth_bindcred+3b/54>
Trace; c482951a <[sunrpc]rpc_call_setup+36/64>
Trace; c482940c <[sunrpc]rpc_call_sync+64/9c>
Trace; c482bfc0 <[sunrpc]rpc_run_timer+0/44>
Trace; c485f4a8 <[nfs]nfs_proc_statfs+58/7c>
Trace; c01e177a 
Trace; c4858aef <[nfs]nfs_statfs+33/180>
Trace; c012c0da 
Trace; c012c125 
Trace; c0108e0b 
Code;  c482dab4 <[sunrpc]rpcauth_gc_credcache+2c/b0>
 <_EIP>:
Code;  c482dab4 <[sunrpc]rpcauth_gc_credcache+2c/b0>   <=
   0:   66 83 7b 08 00cmpw   $0x0,0x8(%ebx)   <=
Code;  c482dab9 <[sunrpc]rpcauth_gc_credcache+31/b0>
   5:   75 15 jne1c <_EIP+0x1c> c482dad0 
<[sunrpc]rpcauth_gc_credcache+48/b0>
Code;  c482dabb <[sunrpc]rpcauth_gc_credcache+33/b0>
   7:   a1 68 2a 29 c0mov0xc0292a68,%eax
Code;  c482dac0 <[sunrpc]rpcauth_gc_credcache+38/b0>
   c:   39 43 04  cmp%eax,0x4(%ebx)
Code;  c482dac3 <[sunrpc]rpcauth_gc_credcache+3b/b0>
   f:   79 0b jns1c <_EIP+0x1c> c482dad0 
<[sunrpc]rpcauth_gc_credcache+48/b0>
Code;  c482dac5 <[sunrpc]rpcauth_gc_credcache+3d/b0>
  11:   8b 03 mov(%ebx),%eax
Code;  c482dac7 <[sunrpc]rpcauth_gc_credcache+3f/b0>
  13:   89 00 mov%eax,(%eax)

Unable to handle kernel paging request at virtual address feff3112
c482dab4
*pde = 
Oops: 
CPU:0
EIP:0010:[]
EFLAGS: 00010286
eax: 00010a9d   ebx: feff310a   ecx:    edx: c36c5b20
esi:    edi: c36c5b20   ebp:    esp: c1d31d14
ds: 0018   es: 0018   ss: 0018
Process df (pid: 1308, stackpage=c1d31000)
Stack: 08048000 c08c7240 4000 c1d31d4c  c36c5b20 c36c5b20 c482db9a
   c36c5b20 c1d31da0 c36c5b20 c1d31dd4 c1d31d98 c482dc9f c36c5b20 
   c1d31da0 c1d31e80 c482951a c1d31da0  c1d31da0 c36efc10 c482940c
Call Trace: [] [] [] [] [] 
[] []
   [] [] [] []
Code: 66 83 7b 08 00 75 15 a1 68 2a 29 c0 39 43 04 79 0b 8b 03 89

>>EIP; c482dab4 <[sunrpc]rpcauth_gc_credcache+2c/b0>   <=
Trace; c482db9a <[sunrpc]rpcauth_lookup_credcache+36/8c>
Trace; c482dc9f <[sunrpc]rpcauth_bindcred+3b/54>
Trace; c482951a <[sunrpc]rpc_call_setup+36/64>
Trace; c482940c <[sunrpc]rpc_call_sync+64/9c>
Trace; c482bfc0 <[sunrpc]rpc_run_timer+0/44>
Trace; c485f4a8 <[nfs]nfs_proc_statfs+58/7c>
Trace; c01e177a 
Trace; c4858aef <[nfs]nfs_statfs+33/180>
Trace; c012c0da 
Trace; c012c125 
Trace; c0108e0b 
Code;  c482dab4 <[sunrpc]rpcauth_gc_credcache+2c/b0>
 <_EIP>:
Code;  c482dab4 <[sunrpc]rpcauth_gc_credcache+2c/b0>   <=
   0:   66 83 7b 08 00cmpw   $0x0,0x8(%ebx)   <=
Code;  c482dab9 <[sunrpc]rpcauth_gc_credcache+31/b0>
   5:   75 15 jne1c <_EIP+0x1c> c482dad0 
<[sunrpc]rpcauth_gc_credcache+48/b0>
Code;  c482dabb <[sunrpc]rpcauth_gc_credcache+33/b0>
   7:   a1 68 2a 29 c0mov0xc0292a68,