Hello!
> I've just committed a whole bunch of bugfixes to CVS. Everyone who was
> experiencing crashes recently, could you please try again with this
> version?
I still have crashes. with 2.3 kernels.
I have not tried with 2.2 as I do not have headers to compile against, but I'll
try eventually.
BTW, all mappings seems to be fine:
freemware: vm c281b000..c281bfff -> page 000012df
freemware: vm c281c000..c281cfff -> page 0000129f
freemware: vm c281d000..c281dfff -> page 00001293
freemware: vm c281e000..c281efff -> page 000012bf
freemware: vm c281f000..c281ffff -> page 00001320
Sections: Size Address Align
.this 0000004c c281b000 2**2
.text 00003b09 c281b04c 2**2
.fixup 00000018 c281eb55 2**0
.rodata 000007ed c281eb6d 2**0
__ex_table 00000010 c281f35c 2**2
.data 00000000 c281f36c 2**2
.kstrtab 0000000a c281f36c 2**0
.bss 000004c8 c281f378 2**2
> - The trick of defining special symbols via a linker script to retrieve
> the module virtual address range broke badly under certain combinations
> of kernel / insmod versions, causing all kinds of strange effects.
>
> I've now completely removed this hack, and instead get the module
> address range by querying the corresponding kernel structure (the
> __this_module structure) in kernels >= 2.1.18, and using a hack in
> earlier kernels (the symbol mod_use_count_ is guaranteed to point
> to the start of the module, and the end of the module is guaranteed
> to be the first virtual address greater than the start where there
> is no physical page mapped ...).
It seems there is still some problems left.
Bye,
Oleg
