
This package is beta-software.
Although it is working on several machines, it still may cause bugs on others.
The following contains a guide for kernel-hackers to find the error
when a kernel-panic happens. You can use this procedure for finding any
error in the kernel, not only errors of isdn4linux. In that case you only have
to use the zSystem.map instead of icn.map or isdn.map:

A kernel-panic looks like the following:

Unable to handle kernel NULL pointer dereference at virtual address c0000008
current->tss.cr3 = 00255000, 4r3 = 00255000
*pde = 00102067
*pte = 00000027
Oops: 0000
EIP:    0010:01822532
EFLAGS: 00010206
eax: 00000000   ebx: 000000e2   ecx: 000003ff   edx: 00000321
esi: 00000001   edi: 00e54018   ebp: 0033de0c   esp: 0033ddbc
ds: 0018   es: 0018   fs: 002b   gs: 002b   ss: 0018
Process uucico (pid: 704, process nr: 28, stackpage=0033d000)
Stack: 00000000 00000202 001e7642 001e7de0 000d0000 00000246 000d0000 00000036 
       00000036 00000036 00000000 00000000 00000003 00000006 0182205f 000005d4 
       00000001 00000287 00000001 0033de28 0033de28 01822e4b 00000001 000005c4 
Call Trace: 0182205f 01822e4b 0181e55d 0181e855 001377a9 0013e2fe 00140817 
       00141317 00148125 00148163 00133ca0 00125358 001106c9 0011002b 
Code: 01 58 08 8b 84 b7 b4 28 00 00 66 8b 50 04 66 29 da 66 89 50 

1. If a kernel-panic occured, substitute the command "modprobe icn"
   in the ISDN-startup-script by the equivalent insmod command 
   with option "-m" and sort the output into a file:

     insmod -m isdn.o | sort > isdn.map
     insmod -m icn.o  | sort > icn.map

   These Files look like:

     01822000 b _mod_use_count_
     01822004 t ___gnu_compiled_c
     01822004 t gcc2_compiled.
     01822024 t _new_buf
     018220a4 t _free_queue
     018220e4 t _shiftout
     01822124 t _map_channel
     01822184 t _lock_channel
     018221b4 t _release_channel
     018221d4 t _trymaplock_channel
     01822214 t _maprelease_channel
     01822274 t _pollbchan_receive
     01822404 t _pollbchan_send
     01822624 t _pollbchan
     01822704 t _pollcard
     01822d74 t _sendbuf
     01822eb4 t _loadboot
     01823064 t _loadproto
     ... and so on.

2. Now it is possible to determine if, and which of the modules has caused
   the error. Therefore you look, if the address which is listed after
   "EIP:" in the panic-message (the part after the 2. colon, in our example
    "01822532") lies in the range of one of the map files.
   In our example, "EIP" lies between "_pollbchan_send" and "pollbchan".
   The line with the smaller number names the function that caused the 
   error (here _pollbchan_send). If you have a hex-calculator, you can
   calculate the offset inside the function: "EIP"-address of the function.   

3. Now edit the toplevel makefile and uncomment the 2. definition of
   MCFLAGS, comment the first definition. Then recompile the corresponding
   module. Afterwards cd into the directory containig the module and run the
   assembler by hand:

    as -o icn.o -ag icn.s > icn.l

4. The file icn.l now contains the listing, where you can look for the 
   operation that caused the panic. Search for the function name, followed
   by a colon. (In the example above: "_pollbchan_send:"). You will see
   something like this:

 1221                   _pollbchan_send:
 271:icn.c         **** 
GAS LISTING icn.s                     page 37


 272:icn.c         **** /* Send data-packet to B-Channel, split it up into fragm
ents of
 273:icn.c         ****  * ICN_FRAGSIZE length. If last fragment is sent out, si
gnal
 274:icn.c         ****  * success to upper layers via statcallb with ISDN_STAT_
BSENT argument.
 275:icn.c         ****  * This routine is called via timer-callback from pollbc
han() or
 276:icn.c         ****  * directly from sendbuf().
 277:icn.c         ****  */
 278:icn.c         **** 
 279:icn.c         **** static void
 280:icn.c         **** pollbchan_send(int channel) {
 1222                           .stabd 68,0,280
 1223 0400 55                   pushl %ebp
 1224 0401 89E5                 movl %esp,%ebp
 1225 0403 83EC4C               subl $76,%esp


Look at the adress of the first machine-instruction (in the example, this is
pushl %ebp at adress 0400) Now add the previously calculated offset to this
adress and you have the adress of the error within the listing). Find the line
containing this adress and go back some lines until you find the corresponding
c-code-line (They are shown with preceding ***)

Of course this only makes sense, if you are a real hacker.
Otherwise simply send a bugreport to me containing a copy of the
kernel-message, the .map files and your version of isdn4linux.
(If the error is reproducable, a short description would be nice)

 -Fritz (fritz@wuemaus.franken.de)

