---

Forhistorie:
Jeg leger lidt med at måle cpu-belastning fra forskellige
netkort, og er nu nået til et 3Com 905C-TX-M. Disse kort
skulle kunne køre med 3c59x-modulet, men jeg har før oplevet
problemer med den kombination, incl. denne gang, hvor kortet
bliver fundet og konfigureret helt uden fejlmeldinger, men
ikke er i stand til at kommunikere med andre computere. Jeg
kan se på google, at det samme er sket for mange andre, og
at især de netkort, der hedder noget efter "905C" (som mit),
volder problemer.

Jeg forsøger derfor at kompilere 3Coms eget kernemodul
til 900-serien, kaldet 3c90x.o. Det går ikke godt. Jeg får
fejlmeldingen :

In file included from 3c90x.c:1:
3c90x.h:22: linux/modversions.h: No such file or directory

Fint nok. Jeg mangler linux/modversions.h - men hvor skal
den mon ligge? Jeg kigger derfor i 3c90x.h og ser, hvad
den ellers bruger af *.h-filer. Her er et lille uddrag:

#include <linux/config.h>

#ifdef MODULE
#ifdef MODVERSIONS
#include <linux/modversions.h>

Jeg leder så efter linux/config.h, som jo tydeligvis _er_
fundet, siden jeg ikke fik fejl, og finder den her:

/usr/include/linux/config.h
/usr/src/kernel-headers-2.2.18/include/linux/config.h
/usr/src/kernel-headers-2.2.19/include/linux/config.h
/usr/src/kernel-headers-2.4.18-586tsc/include/linux/config.h
/usr/src/kernel-headers-2.4.2/include/linux/config.h
/usr/src/kernel-source-2.4.18/include/linux/config.h

Hvorimod linux/modversions.h kun findes her.

/usr/src/kernel-headers-2.2.18/include/linux/modversions.h
/usr/src/kernel-headers-2.2.19/include/linux/modversions.h
/usr/src/kernel-headers-2.4.18-586tsc/include/linux/modversions.h
/usr/src/kernel-headers-2.4.2/include/linux/modversions.h
/usr/src/kernel-source-2.4.18/include/linux/modversions.h

(Jeg kører en binært installeret kerne 2.4.18-586tsc under Debian
Woody, men har for at være sikker installeret sourcen og kørt en
'make mrproper ; make config ; make dep')

I ovenstående listning er der kun biblioteket /usr/include/linux/
til forskel. Jeg tager derfor en dyb indånding og flytter
/usr/src/kernel-source-2.4.18/include/linux/modversions.h hertil.
Men når jeg så kompilerer modulet igen, få jeg bare at vide, at
alle de filer, som er nævnt i modversions.h, ikke kan findes,
selv om de _er_ i source-træet.

Nu kan jeg så efterhånden regne ud, at jeg er ude i noget med
et forkert angivet path et eller andet sted, men hvor?


--
Allan Olesen, Lunderskov

"UNIX er overflødigt." - Lars P. Fischer

---

Allan Olesen <aolesen@post3.tele.dk> writes:

> In file included from 3c90x.c:1:
> 3c90x.h:22: linux/modversions.h: No such file or directory

Normalt er /usr/include/linux er symlink til /usr/src/linux/include/linux,
hvor /usr/src/linux igen er et symlink til /usr/src/linux-2.x.x - det
er det i alt fald på min rødhætte. Jeg tror bare du skal sikre dig, at
/usr/include/linux linker ned i din kerne-sovs som beskrevet ovenfor.

Med venlig hilsen
- Jacob Atzen

---

Den 28 Mar 2002 09:31:10 +0100 skrev Jacob Atzen:
>Allan Olesen <aolesen@post3.tele.dk> writes:
>
>> In file included from 3c90x.c:1:
>> 3c90x.h:22: linux/modversions.h: No such file or directory
>
>Normalt er /usr/include/linux er symlink til /usr/src/linux/include/linux,
>hvor /usr/src/linux igen er et symlink til /usr/src/linux-2.x.x - det
>er det i alt fald på min rødhætte. Jeg tror bare du skal sikre dig, at
>/usr/include/linux linker ned i din kerne-sovs som beskrevet ovenfor.

En længere forklaring (prefixed med "Linus>", resten handler mere om
LVM) på hvorfor man ikke skal lave /usr/include/linux til et symlink:

http://linux.msede.com/lvm_mlist/archive/1999/08/0042.html

Mvh
Kent
--
Advarsel: ny e-mail adresse - med risiko for at mails går tabt.
Den gamle adresse virker stadig, men bliver primært checket i
arbejdstiden.

---

leeloo@phreaker.net (Kent Friis) writes:

> En længere forklaring (prefixed med "Linus>", resten handler mere om
> LVM) på hvorfor man ikke skal lave /usr/include/linux til et symlink:

Så blev jeg også lidt klogere idag :)

Hvad bør man så gøre, når man skal bruge headers på en RedHat?

- Jacob

---

Den 28 Mar 2002 10:50:02 +0100 skrev Jacob Atzen:
>leeloo@phreaker.net (Kent Friis) writes:
>
>> En længere forklaring (prefixed med "Linus>", resten handler mere om
>> LVM) på hvorfor man ikke skal lave /usr/include/linux til et symlink:
>
>Så blev jeg også lidt klogere idag :)
>
>Hvad bør man så gøre, når man skal bruge headers på en RedHat?

Nøjes med at installere kernel-headers (er der ikke en rpm der hedder
sådan? under SuSE hedder den: linclude) under /usr/src/linux, og så
lægge kernen under /usr/src/linux-2.4.18, eller under /home eller...
Moderne kerner er ligeglade med hvor de ligger.

Mvh
Kent
--
Advarsel: ny e-mail adresse - med risiko for at mails går tabt.
Den gamle adresse virker stadig, men bliver primært checket i
arbejdstiden.

---

Den Thu, 28 Mar 2002 10:00:37 +0000 (UTC) skrev Kent Friis:
>Den 28 Mar 2002 10:50:02 +0100 skrev Jacob Atzen:
>>leeloo@phreaker.net (Kent Friis) writes:
>>
>>> En længere forklaring (prefixed med "Linus>", resten handler mere om
>>> LVM) på hvorfor man ikke skal lave /usr/include/linux til et symlink:
>>
>>Så blev jeg også lidt klogere idag :)
>>
>>Hvad bør man så gøre, når man skal bruge headers på en RedHat?
>
>Nøjes med at installere kernel-headers (er der ikke en rpm der hedder
>sådan? under SuSE hedder den: linclude) under /usr/src/linux,

Lige en tilføjelse: Det skal naturligvis være de kernel-headers der
passer til distributionen, altså dem fra CD'en. Ikke de nyeste fra FTP.

>og så
>lægge kernen under /usr/src/linux-2.4.18, eller under /home eller...
>Moderne kerner er ligeglade med hvor de ligger.

Mvh
Kent
--
Advarsel: ny e-mail adresse - med risiko for at mails går tabt.
Den gamle adresse virker stadig, men bliver primært checket i
arbejdstiden.

---

>>>>> "Kent" == Kent Friis <leeloo@phreaker.net> writes:

Kent> Lige en tilføjelse: Det skal naturligvis være de kernel-headers
Kent> der passer til distributionen, altså dem fra CD'en. Ikke de
Kent> nyeste fra FTP.

Bør det ikke være dem der passer til den kerne man køre med? Jeg kunne
da forestille mig at hvis man ville til at kompilere en 2.4.xx kerne
med kernel-headers fra 2.2 så ville det meste springe i luften...

/Thomas
--
/"\ | Human Knowledge Belongs To The World
\ / | -- Milo Hoffman in "AntiTrust"
x |
/ \ <-- (ASCII Ribbon Campain against html emails and postings!)

---

Den 28 Mar 2002 11:10:42 +0100 skrev Thomas Rasmussen:
>>>>>> "Kent" == Kent Friis <leeloo@phreaker.net> writes:
>
> Kent> Lige en tilføjelse: Det skal naturligvis være de kernel-headers
> Kent> der passer til distributionen, altså dem fra CD'en. Ikke de
> Kent> nyeste fra FTP.
>
>Bør det ikke være dem der passer til den kerne man køre med? Jeg kunne
>da forestille mig at hvis man ville til at kompilere en 2.4.xx kerne
>med kernel-headers fra 2.2 så ville det meste springe i luften...

Når du compilerer kernen, så ved den godt at den skal kigge i sine egne
headers.

Problemet (som beskrevet i den link jeg sendte i et andet indlæg) er at
libc-headerne #incude'r header-filerne under /usr/src/linux, så når et
userspace program bliver compileret imod nyere headers, så kan en struct
fx. have ændret udseende, og programmet og libc er ikke enige om hvordan
struct'en ser ud. SIGSEGV, core dumpet.

Mvh
Kent
--
Advarsel: ny e-mail adresse - med risiko for at mails går tabt.
Den gamle adresse virker stadig, men bliver primært checket i
arbejdstiden.

---

>>>>> "Allan" == Allan Olesen <aolesen@post3.tele.dk> writes:

Allan> Nu kan jeg så efterhånden regne ud, at jeg er ude i noget med
Allan> et forkert angivet path et eller andet sted, men hvor?

Well, du er lidt på rette kurs... dit problem ser ud til at være, at
du ikke har installeret kernel-headers sammen med din binære kerne
installation... Kernel-headers mener jeg indeholder alle de header
filer du skal have for at kompilere kernemoduler. Det er ikke nok blot
at flytte modversions.h.

Du kan også prøve at kigge på -I option til gcc, der kan du tilføje en
sti til hvor gcc skal kigge efter include filer. Pr. default ved den
ikke at den skal kigge i /usr/src/kernel-headers-2.2.18 (eller hvad
det nu lige hedder) da det er specifikt for din maskine. Eksempelvis
ligger min modversions.h i /usr/include/linux sammen med en masse
andre filer (som ikke er symlinked ind i mit source dir). Jeg køre en
debian 2.2 med lidt hacked moduler, kerne og stuff fra woody...

Et hurtigt hack kan måske være blot at flytte *alt* fra
/usr/src/kernel-headers-blah-blah/linux til /usr/include/linux (på
eget ansvar)

/Thomas

--
/"\ | Human Knowledge Belongs To The World
\ / | -- Milo Hoffman in "AntiTrust"
x |
/ \ <-- (ASCII Ribbon Campain against html emails and postings!)

---

Den 28 Mar 2002 10:04:58 +0100 skrev Thomas Rasmussen:
>>>>>> "Allan" == Allan Olesen <aolesen@post3.tele.dk> writes:
>
> Allan> Nu kan jeg så efterhånden regne ud, at jeg er ude i noget med
> Allan> et forkert angivet path et eller andet sted, men hvor?
>
>Well, du er lidt på rette kurs... dit problem ser ud til at være, at
>du ikke har installeret kernel-headers sammen med din binære kerne
>installation... Kernel-headers mener jeg indeholder alle de header
>filer du skal have for at kompilere kernemoduler. Det er ikke nok blot
>at flytte modversions.h.
>
>Du kan også prøve at kigge på -I option til gcc, der kan du tilføje en
>sti til hvor gcc skal kigge efter include filer. Pr. default ved den
>ikke at den skal kigge i /usr/src/kernel-headers-2.2.18 (eller hvad
>det nu lige hedder) da det er specifikt for din maskine. Eksempelvis
>ligger min modversions.h i /usr/include/linux sammen med en masse
>andre filer (som ikke er symlinked ind i mit source dir). Jeg køre en
>debian 2.2 med lidt hacked moduler, kerne og stuff fra woody...

Så har du nok en nyere libc.

>Et hurtigt hack kan måske være blot at flytte *alt* fra
>/usr/src/kernel-headers-blah-blah/linux til /usr/include/linux (på
>eget ansvar)

Det giver nøjagtig samme problem som symlink'et: libc og include-filer
passer ikke sammen, med segfaults og lignende til følge.

Mvh
Kent
--
Advarsel: ny e-mail adresse - med risiko for at mails går tabt.
Den gamle adresse virker stadig, men bliver primært checket i
arbejdstiden.

---

>>>>> "Kent" == Kent Friis <leeloo@phreaker.net> writes:

Kent> Så har du nok en nyere libc.

Hmm... libc6 - 2.2.4-5 og libc5 - 5.4.48-8, sa det ved jeg ikke om jeg
gør

>> Et hurtigt hack kan måske være blot at flytte *alt* fra
>> /usr/src/kernel-headers-blah-blah/linux til /usr/include/linux (på
>> eget ansvar)

Kent> Det giver nøjagtig samme problem som symlink'et: libc og
Kent> include-filer passer ikke sammen, med segfaults og lignende til
Kent> følge.

Well, jeg vil til enhver tid anbefale at man installere kernel-headers
istedet... det burde være nok og er den "rigtigste" måde at løse
problemet på.

/Thomas

--
/"\ | Human Knowledge Belongs To The World
\ / | -- Milo Hoffman in "AntiTrust"
x |
/ \ <-- (ASCII Ribbon Campain against html emails and postings!)

---

Thomas Rasmussen <simpsons@kom.auc.dk> wrote:

>Well, du er lidt på rette kurs... dit problem ser ud til at være, at
>du ikke har installeret kernel-headers

Hm, bemærkede du stien til de fundne filer?

Jo, jeg har skam kernel-headers til alle mine kerner.

Tak til jer alle for forslagene. Jeg fik løst mit problem
med kompileringen.

Som Kent og Jacob var inde på, lå problemet i, at 3Coms
kompileringsscript (der er ikke en egentlig makefile) er
baseret på denne (sandsynligvis defekte RedHat-)sti til
filerne:

gcc -c 3c90x.c -O2 -Wall -Wstrict-prototypes -fomit-frame-pointer \
-I/lib/modules/$(uname -r)/build/include \
-fno-strength-reduce -pipe -m486 -malign-loops=2 \
-malign-jumps=2 -malign-functions=2 -DCPU=486 \
-DMODULE -D__KERNEL__ -DMODVERSIONS

Jeg prøvede først med Jacobs symlink, men det gav mig masser
af unresolved symbols, når jeg forsøgte at bruge modulet.

I stedet rettede jeg linie 2 i scriptet til:

-I/usr/src/kernel-headers-2.4.18-586tsc/include \

Derefter gik kompileringen og indsættelsen af modulet fint.

Det hele viste sig dog at være omsonst. Netkortet fungerede
heller ikke med det nye modul. Tilsyneladende har det
været en eller anden hardwareinkompatibilitet, der havde
skylden for, at netkortet ikke fungerede. I to andre
maskiner kunne jeg fint bruge det selvsamme netkort med
det originale kernemodul 3c59x.o.


I øvrigt har min lille test af netkort indtil videre vist sig
at være lidt kedelig, hvis nogen ellers har interesse i at
høre resultaterne:

Under kerne 2.2.19 er der pæne forskelle på CPU-belastningen
fra 3Com 509C TX-M og Intel Pro 100, men forskellene går til
hver sin side, så der var ingen vinder.

Under kerne 2.4.18 ligger 3Com 509C TX-M, Intel Pro 100 og
en billig Tulip-klon nøjagtigt ens i CPU-belastning - i øvrigt
en noget højere belastning end under kerne 2.2.19.

Der er ingen større forskelle på hastigheden.

Desværre er mit RTL 8139-kort udlånt for tiden, så jeg har
ingen tal for dette forkætrede kort. Indtil videre er mine
konklusioner:

- Et 100 Mbit kort for fuld skrue æder sagtens op mod
halvdelen af processortiden på en 350 MHz K6-2.

- Mærkevare-kort er ingen garanti for lav CPU-belastning

- En billig Tulip-klon kan til gengæld være rigtig træls
at finde en kerne til, og det er ikke spor rart, når
man godt kan lide at lave netværksinstallation.

--
Allan Olesen, Lunderskov

"UNIX er overflødigt." - Lars P. Fischer

---

Den Sat, 30 Mar 2002 13:42:41 +0100 skrev Allan Olesen:
>Thomas Rasmussen <simpsons@kom.auc.dk> wrote:
>
>>Well, du er lidt på rette kurs... dit problem ser ud til at være, at
>>du ikke har installeret kernel-headers
>
>Hm, bemærkede du stien til de fundne filer?
>
>Jo, jeg har skam kernel-headers til alle mine kerner.
>
>Tak til jer alle for forslagene. Jeg fik løst mit problem
>med kompileringen.
>
>Som Kent og Jacob var inde på, lå problemet i, at 3Coms
>kompileringsscript (der er ikke en egentlig makefile) er
>baseret på denne (sandsynligvis defekte RedHat-)sti til
>filerne:
>
> gcc -c 3c90x.c -O2 -Wall -Wstrict-prototypes -fomit-frame-pointer \
> -I/lib/modules/$(uname -r)/build/include \

Denne skulle faktisk være rigtig. Make modules_install laver .../build
som et symlink til det directory hvor kernen blev compileret, dvs. det
burde være et link til din source.

Det link blev SVJV indført netop for at udefrakommende moduler skulle
kunne finde de rigtige filer automatisk.

Du burde måske lige lave en:
file /lib/modules/$(uname -r)/build
og checke at linket peger det rigtige sted hen.

Mvh
Kent
--
Advarsel: ny e-mail adresse - med risiko for at mails går tabt.
Den gamle adresse virker stadig, men bliver primært checket i
arbejdstiden.

---

leeloo@phreaker.net (Kent Friis) wrote:

>Denne skulle faktisk være rigtig. Make modules_install laver .../build
>som et symlink til det directory hvor kernen blev compileret, dvs. det
>burde være et link til din source.

Sjovt. Det symlink har jeg i den kerne, jeg selv har kompileret:

/lib/modules/2.4.18/build -> /usr/src/kernel-source-2.4.18

I de binært installerede kerner fra dengang, jeg kørte Progeny Debian,
findes der også et symlink, men det ser meget personligt og ikke
særligt gennemtænkt ud:

/lib/modules/2.2.18/build -> /scratch/jgoerzen/kern/kernel-source-2.2.18-1.64
/lib/modules/2.2.19/build -> /scratch/jgoerzen/kern/kernel-source-2.2.19-1.81
/lib/modules/2.4.2/build -> /scratch/laz/kernel/linux-2.4.2

Men i min binært installerede "ægte" Debian-kerne 2.4.18 findes
det ikke. Debian går jo ellers for at være så god til at overholde
diverse Linux-standarder.


--
Allan Olesen, Lunderskov

"UNIX er overflødigt." - Lars P. Fischer

---

Den Sat, 30 Mar 2002 17:32:12 +0100 skrev Allan Olesen:
>leeloo@phreaker.net (Kent Friis) wrote:
>
>>Denne skulle faktisk være rigtig. Make modules_install laver .../build
>>som et symlink til det directory hvor kernen blev compileret, dvs. det
>>burde være et link til din source.
>
>Sjovt. Det symlink har jeg i den kerne, jeg selv har kompileret:
>
>/lib/modules/2.4.18/build -> /usr/src/kernel-source-2.4.18

Den ser rigtig nok ud.

>I de binært installerede kerner fra dengang, jeg kørte Progeny Debian,
>findes der også et symlink, men det ser meget personligt og ikke
>særligt gennemtænkt ud:
>
>/lib/modules/2.2.18/build -> /scratch/jgoerzen/kern/kernel-source-2.2.18-1.64
>/lib/modules/2.2.19/build -> /scratch/jgoerzen/kern/kernel-source-2.2.19-1.81
>/lib/modules/2.4.2/build -> /scratch/laz/kernel/linux-2.4.2

Yikes.

>Men i min binært installerede "ægte" Debian-kerne 2.4.18 findes
>det ikke. Debian går jo ellers for at være så god til at overholde
>diverse Linux-standarder.

Ja det lyder da godt nok lidt underligt.

Mvh
Kent
--
Advarsel: ny e-mail adresse - med risiko for at mails går tabt.
Den gamle adresse virker stadig, men bliver primært checket i
arbejdstiden.

---

Den Thu, 28 Mar 2002 09:26:00 +0100 skrev Allan Olesen:
>Jeg forsøger derfor at kompilere 3Coms eget kernemodul
>til 900-serien, kaldet 3c90x.o. Det går ikke godt. Jeg får
>fejlmeldingen :
>
>In file included from 3c90x.c:1:
>3c90x.h:22: linux/modversions.h: No such file or directory
>
>Fint nok. Jeg mangler linux/modversions.h - men hvor skal
>den mon ligge? Jeg kigger derfor i 3c90x.h og ser, hvad
>den ellers bruger af *.h-filer. Her er et lille uddrag:
>
>#include <linux/config.h>

Du skal nok rette i 3com's Makefile, og sikre at at CFLAGS indeholder
-I /usr/src/kernel-headers-2.4.18-586tsc/include

I hvert fald ud fra hvad jeg umiddelbart kan se i
/home/src/linux-2.4.18/Makefile.

>/usr/src/kernel-headers-2.4.18-586tsc/include/linux/config.h
>
>(Jeg kører en binært installeret kerne 2.4.18-586tsc under Debian
>Woody, men har for at være sikker installeret sourcen og kørt en
>'make mrproper ; make config ; make dep')

Problemet er AFAICS at 3com går ud fra an broken-by-design RedHat
installation, som linker /usr/include/linux direkte til kernel-sourcen.

Mvh
Kent
--
Advarsel: ny e-mail adresse - med risiko for at mails går tabt.
Den gamle adresse virker stadig, men bliver primært checket i
arbejdstiden.