sarge installation, unresolved symbols loading marvell yukon module

hi,
i'm trying to install debian sarge on my toshiba portege R200,
equipped with a marvell yukon gigabit ethernet controller. By default
the NIC is not recognized from the setup program. Now I compiled on a
previous installed sarge (throw full CDs) on the same laptop the
correct sk98lin.o module, for kernel 2.4.27, which is working
perfectly. To be able to use in the future the netinst I'm trying to
load manually the module from the shell (alt+F2) when installation
claims it can't find any NIC. doing insmod or modprobe sk98lin (with
or without full path /lib/modu.../drivers/net/sk98lin/) I get about 40
unresolved symbol (pci_set_master, mem_map, printk, add_timer,
irq_stat, pci_save_state ...etc).
how is it possible to solve this? other modules missing?
trying the same procedure with kernel 2.6 (after compiling the .ko
version of the module on another machine with 2.6) makes the driver
load perfectly and the installation complete via net.
I would like to be able to do the same with 2.4

david

On Wed, 06 Sep 2006 22:47:56 GMT, dave <(E-Mail Removed)> wrote:

> i'm trying to install debian sarge on my toshiba portege R200,
> equipped with a marvell yukon gigabit ethernet controller.

[compiled on another machine, won't work]

> trying the same procedure with kernel 2.6 (after compiling the .ko
> version of the module on another machine with 2.6) makes the driver
> load perfectly and the installation complete via net.

The running kernel on the machine you use the module on has to be
configured exactly the same as the kernel sources on the machine where
you compiled the module.

It might be easier to burn the driver to a CD and compile it on the
machine where it is needed.


--
-| Bob Hauck
-| A proud member of the unhinged moonbat horde.
-| http://www.haucks.org/

On Wed, 6 Sep 2006 19:24:28 -0400, Bob Hauck
<(E-Mail Removed)> wrote:

>On Wed, 06 Sep 2006 22:47:56 GMT, dave <(E-Mail Removed)> wrote:
>
>> i'm trying to install debian sarge on my toshiba portege R200,
>> equipped with a marvell yukon gigabit ethernet controller.
>
>[compiled on another machine, won't work]
>
>> trying the same procedure with kernel 2.6 (after compiling the .ko
>> version of the module on another machine with 2.6) makes the driver
>> load perfectly and the installation complete via net.

Is it so just a case that with 2.6 is working, or it acts differently?

>
>The running kernel on the machine you use the module on has to be
>configured exactly the same as the kernel sources on the machine where
>you compiled the module.

the driver is compiled and installed by a shell script, which requires
the kernel headers only, which where installed (correct version, same
as kernel). the kernel compiled for (and working with) is the same
used in the installation (checked by uname -r on the shell, during
install process. 2.4.27-32-386).

>
>It might be easier to burn the driver to a CD and compile it on the
>machine where it is needed.

unfortunately during initial install of debian-sarge there is no
compiler available, so I cannot build the driver at that time; I can
only load a precompiled driver.
After finishing the installation, loading the same driver it works;
but not with the kernel which boots with the installation.

could it be that instead of the 2.6 version, the 2.4 requires manual
installation of other modules before it? (modules which are missing,
since modprobe gives same result as insmod)

On Thu, 07 Sep 2006 09:35:44 GMT, dave <(E-Mail Removed)> wrote:
> On Wed, 6 Sep 2006 19:24:28 -0400, Bob Hauck
><(E-Mail Removed)> wrote:
>
>>On Wed, 06 Sep 2006 22:47:56 GMT, dave <(E-Mail Removed)> wrote:

[trying to compile network driver on another machine]

>> It might be easier to burn the driver to a CD and compile it on the
>> machine where it is needed.
>
> unfortunately during initial install of debian-sarge there is no
> compiler available, so I cannot build the driver at that time; I can
> only load a precompiled driver.

Since the compile-on-another-machine procedure works for 2.6, you could
install a 2.6 kernel and then install the 2.4 kernel, kernel headers,
and driver.


> After finishing the installation, loading the same driver it works;
> but not with the kernel which boots with the installation.

So...how did you finish the install? With 2.6? Now I'm confused.

Anyway, that probably means the kernel that boots with the installation
is not configured exactly the same as the final one. It could well be
that the 2.6 one is and the 2.4 isn't.


> could it be that instead of the 2.6 version, the 2.4 requires manual
> installation of other modules before it? (modules which are missing,
> since modprobe gives same result as insmod)

I suppose it is possible. I'm not familiar with the Yukon driver.


--
-| Bob Hauck
-| A proud member of the unhinged moonbat horde.
-| http://www.haucks.org/

On Thu, 7 Sep 2006 07:54:02 -0400, Bob Hauck
<(E-Mail Removed)> wrote:

>On Thu, 07 Sep 2006 09:35:44 GMT, dave <(E-Mail Removed)> wrote:
>> On Wed, 6 Sep 2006 19:24:28 -0400, Bob Hauck
>><(E-Mail Removed)> wrote:
>>
>>>On Wed, 06 Sep 2006 22:47:56 GMT, dave <(E-Mail Removed)> wrote:
>
>[trying to compile network driver on another machine]
>
>>> It might be easier to burn the driver to a CD and compile it on the
>>> machine where it is needed.
>>
>> unfortunately during initial install of debian-sarge there is no
>> compiler available, so I cannot build the driver at that time; I can
>> only load a precompiled driver.
>
>Since the compile-on-another-machine procedure works for 2.6, you could
>install a 2.6 kernel and then install the 2.4 kernel, kernel headers,
>and driver.\

technically yes, but I can even download the full installation
cd-image... was also to understand what was going on
>
>
>> After finishing the installation, loading the same driver it works;
>> but not with the kernel which boots with the installation.
>
>So...how did you finish the install? With 2.6? Now I'm confused.

I finished the installation with the 2.4 without network support, so
only kernel 2.4 and very few basic things where installed. after the
first boot of the just-installed basic system I copied and loaded the
2.4 driver compiled on another machine (from a usb-key) and it works.
non if I do the same from a shell suring the install, as told before.
But in this way lot of things done during install don't complete
properly, so this is not a solution.

>
>Anyway, that probably means the kernel that boots with the installation
>is not configured exactly the same as the final one. It could well be
>that the 2.6 one is and the 2.4 isn't.

I'm not a kernel-expert to understan in deep what are the requirements
for a module to load, but I thought that when module support is on and
the version of the module is correct, the module should load (except
for other modules needed).

>
>
>> could it be that instead of the 2.6 version, the 2.4 requires manual
>> installation of other modules before it? (modules which are missing,
>> since modprobe gives same result as insmod)
>
>I suppose it is possible. I'm not familiar with the Yukon driver.

On Sun, 10 Sep 2006 15:45:28 GMT, dave <(E-Mail Removed)> wrote:
> On Thu, 7 Sep 2006 07:54:02 -0400, Bob Hauck
><(E-Mail Removed)> wrote:
>
>>On Thu, 07 Sep 2006 09:35:44 GMT, dave <(E-Mail Removed)> wrote:
>>> On Wed, 6 Sep 2006 19:24:28 -0400, Bob Hauck
>>><(E-Mail Removed)> wrote:
>>>
>>>>On Wed, 06 Sep 2006 22:47:56 GMT, dave <(E-Mail Removed)> wrote:

>>> After finishing the installation, loading the same driver it works;
>>> but not with the kernel which boots with the installation.
>>
>>So...how did you finish the install? With 2.6? Now I'm confused.
>
> I finished the installation with the 2.4 without network support, so
> only kernel 2.4 and very few basic things where installed.

Ok, I understand now.


> But in this way lot of things done during install don't complete
> properly, so this is not a solution.

You could make note of those things and then use "dpkg-reconfigure" to
perform the missing setups by hand. It is tedious I know.

The "official" way of doing this kind of install is to boot from
floppies or a CD that supports your hardware, then use "debootstrap" and
"chroot" to install on the target disk after manually partitioning, etc.


>> Anyway, that probably means the kernel that boots with the
>> installation is not configured exactly the same as the final one. It
>> could well be that the 2.6 one is and the 2.4 isn't.
>
> I'm not a kernel-expert to understan in deep what are the requirements
> for a module to load, but I thought that when module support is on and
> the version of the module is correct, the module should load (except
> for other modules needed).

In general the module needs to be compiled against kernel sources that
are configured the same as the kernel the module will be loaded into.
The reason is that some internal kernel symbols may change depending on
the kernel configuration.

It also seems to be required to use the same compiler, or at least the
same major version (i.e. a module compiled with gcc3 probably won't load
into a kernel compiled with gcc4).

In short, there is no defined kernel binary interface, only a source
interface, even at a particular kernel release level. This is why, if
you want to ship binary drivers, you need to supply a "wrapper" to be
compiled for the particular kernel.

The "modversions" thing was supposed to allow for some flexibility in
this but I never had much luck with it. The kernel configurations seem
to have to match pretty closely, although I haven't done a scientific
study of what that means.


--
-| Bob Hauck
-| A proud member of the unhinged moonbat horde.
-| http://www.haucks.org/

On Sun, 10 Sep 2006 12:27:50 -0400, Bob Hauck
<(E-Mail Removed)> wrote:

>On Sun, 10 Sep 2006 15:45:28 GMT, dave <(E-Mail Removed)> wrote:
>> On Thu, 7 Sep 2006 07:54:02 -0400, Bob Hauck
>><(E-Mail Removed)> wrote:
>>
>>>On Thu, 07 Sep 2006 09:35:44 GMT, dave <(E-Mail Removed)> wrote:
>>>> On Wed, 6 Sep 2006 19:24:28 -0400, Bob Hauck
>>>><(E-Mail Removed)> wrote:
>>>>
>>>>>On Wed, 06 Sep 2006 22:47:56 GMT, dave <(E-Mail Removed)> wrote:
>
>>>> After finishing the installation, loading the same driver it works;
>>>> but not with the kernel which boots with the installation.
>>>
>>>So...how did you finish the install? With 2.6? Now I'm confused.
>>
>> I finished the installation with the 2.4 without network support, so
>> only kernel 2.4 and very few basic things where installed.
>
>Ok, I understand now.
>
>
>> But in this way lot of things done during install don't complete
>> properly, so this is not a solution.
>
>You could make note of those things and then use "dpkg-reconfigure" to
>perform the missing setups by hand. It is tedious I know.
>
>The "official" way of doing this kind of install is to boot from
>floppies or a CD that supports your hardware, then use "debootstrap" and
>"chroot" to install on the target disk after manually partitioning, etc.
>
>
>>> Anyway, that probably means the kernel that boots with the
>>> installation is not configured exactly the same as the final one. It
>>> could well be that the 2.6 one is and the 2.4 isn't.

I've done a test. copied the 2.4 kernel from the installation cd to
the system and configured grub to boot that kernel (even renamed the
original kernel to be shure it was not booting that one). it boots and
automatically loads the module and the ethernet card is working
properly.
crazy.
probably it means that is not a kernel problem but of something else
which is present on the final system and not during installation,
otherwise I cannot explain this


>>
>> I'm not a kernel-expert to understan in deep what are the requirements
>> for a module to load, but I thought that when module support is on and
>> the version of the module is correct, the module should load (except
>> for other modules needed).
>
>In general the module needs to be compiled against kernel sources that
>are configured the same as the kernel the module will be loaded into.
>The reason is that some internal kernel symbols may change depending on
>the kernel configuration.
>
>It also seems to be required to use the same compiler, or at least the
>same major version (i.e. a module compiled with gcc3 probably won't load
>into a kernel compiled with gcc4).
>
>In short, there is no defined kernel binary interface, only a source
>interface, even at a particular kernel release level. This is why, if
>you want to ship binary drivers, you need to supply a "wrapper" to be
>compiled for the particular kernel.
>
>The "modversions" thing was supposed to allow for some flexibility in
>this but I never had much luck with it. The kernel configurations seem
>to have to match pretty closely, although I haven't done a scientific
>study of what that means.