modules: 2.2.10 init.c patch

[Giorgio T. <de...@ip...>]

Hi all,
during my tests of CLgen driver i have found problems
with modularization and consequent panics when i tried
to load CLgen driver with insmod command.

This is the panic's log:

Dec 20 21:25:03 amy kernel: clgen: init_module: enter
Dec 20 21:25:03 amy kernel: clgen: clgenfb_init: enter
Dec 20 21:25:03 amy kernel: clgen: clgenfb_init: REG at $40600000
Dec 20 21:25:03 amy kernel: clgen: clgenfb_init: Registers virtual
address for board set to: $ccd0b000
Dec 20 21:25:03 amy kernel: clgen: clgenfb_init: RAM virtual start set
to: $ccd1c000
Dec 20 21:25:03 amy kernel: clgen: init_vgachip: enter

Dec 20 21:25:03 amy kernel: NIP: CC8F3454 XER: 00000000 LR: CC8F332C
REGS: c2139cc0 TRAP: 0300
Dec 20 21:25:03 amy kernel: MSR: 00009072 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR:
11
Dec 20 21:25:03 amy kernel: TASK = c2138000[1146] 'insmod' mm->pgd
c28f8000 Last syscall: 128
Dec 20 21:25:03 amy kernel: last math c2138000
Dec 20 21:25:03 amy kernel: GPR00: 00000051 C2139D70 C2138000 00000028
00000001 C0168970 C0170000 00000000
Dec 20 21:25:03 amy kernel: GPR08: C03EFBA0 CCD0B000 CC8F3444 CC8F64C0
22242442 1002B1A8 00000000 100B4AD0
Dec 20 21:25:03 amy kernel: GPR16: 7FFFFAB8 10020000 00000000 00000000
00009072 0A139E80 00000000 C2139DF8
Dec 20 21:25:03 amy kernel: GPR24: CC8F0000 C5DEB400 00000000 00000000
00000000 CC8F0000 C5DEB4C4 C5DEB400
Dec 20 21:25:03 amy kernel: Call backtrace:
Dec 20 21:25:03 amy kernel: CC8F332C CC8F4BF0 CC8F4F08 C0018948 C0003A20
10020000 1000341C
Dec 20 21:25:03 amy kernel: 10003F1C 100041D8 0FF0C75C 00000000
Dec 20 21:25:03 amy kernel: Kernel panic: kernel access of bad area pc
cc8f3454
lr cc8f332c address CCD0B3D4 tsk insmod/1146

As you will see the problem succeded when the function init_vgachip
tried to access the address $CCD0B3D4 that is the remapped address of 
the CRTC index ( CRTX-> $3D4 ).

The initialising code in the driver was so:
----------------------------------------------------
if (btype == BT_PICASSO4) {
    printk(" REG at $%lx\n", board_addr + 0x600000);

         /* To be precise, for the P4 this is not the */
         /* begin of the board, but the begin of RAM. */
         /* for P4, map in its address space in 2 chunks (### TEST! ) */
         /* (note the ugly hardcoded 16M number) */

 fb_info->regs = ioremap(board_addr, 16777216);
 DEBUG printk(KERN_INFO "clgen: Virtual address for board set to:
$%p\n",
fb_info->regs);
 fb_info->regs += 0x600000;
 fb_info->fbregs_phys = board_addr + 0x600000;

 fb_info->fbmem_phys = board_addr + 16777216;
 fb_info->fbmem = ioremap(fb_info->fbmem_phys, 16777216);
 DEBUG printk(KERN_INFO "clgen: (RAM start set to: $%lx)\n",
fb_info->fbmem);
}
----------------------------------------------------------
that for me is a lot ugly so i have sobstituted the code within braces
as follows to use less paging resources:
----------------------------------------------------------
fb_info->fbregs_phys = board_addr + 0x00600000;
fb_info->fbmem_phys = board_addr + 0x01000000;
fb_info->regs = ioremap( fb_info->fbregs_phys,0x10000);
fb_info->fbmem = ioremap(fb_info->fbmem_phys,0x01000000);
-----------------------------------------------------------
After this, insmod loaded the module correctly the first time but not
the second time after a rmmod: the result was another panic as above 
but with different addresses.
I had the suspect that some resources were not delocated by the driver
and the complement function of ioremap(), iounmap() that is needed to 
module cleanup don't work as expected.
That was true because in PPC 2.2.10 kernel iounmap() is an empty
function as you can see in arch/ppc/mm/init.c
This was fixed in the 2.3 kernel so i have sobstituted the 2.2.10
iounmap() with the 2.3 function and now seems that all works correctly 
(i have not yet finished the work on CLgen and the tests )

The following is the fix of init.c:
-----------------------------------------------------------
--- /usr/src/orig2.2/init.c Sat Dec 23 10:44:55 2000
+++ /usr/src/linux-apus-2.2/arch/ppc/mm/init.c Sat Dec 23 10:11:10 2000
@@ -426,7 +426,8 @@

 void iounmap(void *addr)
 {
- /* XXX todo */
+ if (addr > high_memory && (unsigned long) addr < ioremap_bot)
+  vfree((void *) (PAGE_MASK & (unsigned long) addr));
 }

 unsigned long iopa(unsigned long addr)
-----------------------------------------------------------

There are also some function symbols that must be exported in
drivers/video/fbgen.c for the video framebuffer drivers 
modularisation:

EXPORT_SYMBOL(fbgen_switch);
EXPORT_SYMBOL(fbgen_get_var);
EXPORT_SYMBOL(fbgen_get_cmap);
EXPORT_SYMBOL(fbgen_set_disp);
EXPORT_SYMBOL(fbgen_pan_display);
EXPORT_SYMBOL(fbgen_get_fix);
EXPORT_SYMBOL(fbgen_install_cmap);
EXPORT_SYMBOL(fbgen_update_var);
EXPORT_SYMBOL(fbgen_do_set_var);
EXPORT_SYMBOL(fbgen_blank);
EXPORT_SYMBOL(fbgen_set_cmap);
EXPORT_SYMBOL(fbgen_set_var);

After these modifications in 2.2.10 kernel now CLgen module works so i
will speed up my tests without rebooting all the times.

What do you think about ? Do you have other suggestions?

Regards and Merry Christmas

                                   Giorgio Terzi