Dotaz: kompilace linux-2.6.13.4

[Antonín Kolísek]

Dnes jsem zkusil sestavit nový linux-2.6.13.4. Postup:

- make mrproper

- nakopírování .config z 2.6.13.1

- make oldconfig

- make menuconfig (prohlédnutí je-li vše OK)

- make

první error:

...
 LD      drivers/scsi/qla2xxx/built-in.o
 CC      drivers/serial/serial_core.o
*** glibc detected *** double free or corruption (!prev): 0x084dd188 ***
drivers/serial/serial_core.c: In function `uart_set_info':
drivers/serial/serial_core.c:799: internal compiler error: Neúspěšně ukončen 
(SIGABRT)
Please submit a full bug report,
with preprocessed source if appropriate.
See URL: gcc.gnu.org/bugs.html for instructions.
make[2]: *** [drivers/serial/serial_core.o] Error 1
make[1]: *** [drivers/serial] Error 2
make: *** [drivers] Error 2

make clean

make

vše OK

zkouším ještě jednou (pro jistotu)

make clean

make

druhý error:

--
 LD      drivers/char/agp/built-in.o
 CC [M]  drivers/char/agp/backend.o
{standard input}: Assembler messages:
{standard input}:0: Warning: end of file not at end of a line; newline inserted
gcc: Internal error: Neoprávněný přístup do paměti (SIGSEGV) (program cc1)
Please submit a full bug report.
See URL:http://gcc.gnu.org/bugs.html for instructions.
make[3]: *** [drivers/char/agp/backend.o] Error 1
make[2]: *** [drivers/char/agp] Error 2
make[1]: *** [drivers/char] Error 2
make: *** [drivers] Error 2

zkouším po třetí :)

make clean

make

vše OK

Má někdo podobné postřehy? Zajímalo by mne čím je takové chování dáno.

Slackware-current, linux-2.6.13.1, gcc-3.3.6

Díky

Odpovědi

[Tom K]

Máte to rozbité .
vděčnými kandidáty bývají paměť, přehřátý procesor, disk a nevylučoval bych ani sluneční skvrny, nebo negativní energii hlasujících marťanů.

[Antonín Kolísek]

No,to asi dost těžko. CPU je AMD teplota v klidu 39 při max vytížení 45 stupňů, což je dle mne v pohodě. Paměti nedávno testované asi 6hodin memtestem a taky OK. Zdroj je taky OK :) Zajímavé, že 2.6.13.1 jde zkompilovat v pohodě i několikrát ihned po sobě :)

[Luboš Doležel (Doli)]

A jak to jde s GCC 3.4?

[Antonín Kolísek]

GCC 3.4 nemám. Slackware jej oficiálně nemá, možná v testing ano. Právě jsem zkusil spustit kompilaci 2.6.13.1 a 2.6.13.4 souběžně a hodilo to error nyní u 2.6.13.1...takže to vypadá špatně. Ale nevím kde.

Spustil jsem nyní na 2 hodiny memtest86, sada testů se zopakovala 3x a žadná chyba v RAM není. Možná jsem to testoval krátkou dobu,ale i tak. CPU jako vadné nevidím, bez problémů komprimuje audio i video. Hmm, ještě to zkusím nějak testnout.

[David Watzke]

No a neupdatoval's něco systémovýho v poslední době ? Nebo nešťoural ses do něčeho ?

[Antonín Kolísek]

Ani jedno ani druhé.

[David Watzke]

A použil si při kompilaci ifconfig ?

[Antonín Kolísek]

Ne, ifconfig nepoužívám, vše nastavuji přes wine + win_tweak_util :))

[David Watzke]

ifconfig nepoužívám

Tak se modli, ať se sem nepřijde kouknout Yetiho bot, ten by ti dal.

vše nastavuji přes wine + win_tweak_util :))

Já nastavuju pomocí wine /mnt/win/WINDOWS/regedit.exe, ale zkusím i tvůj způsob.

[Antonín Kolísek]

Tak jsem dal kompilovat znovu kernel a do toho pustil v gimpu animaci tak aby se zapráskala co nejvíce RAM a swap. Výsledek dle dmesg teno:

Bad page state at prep_new_page (in process 'cc1', page c13de000)
flags:0x40000004 mapping:00000000 mapcount:0 count:-9
Backtrace:
[<c060c013671f>] bad_page+0x6f/0xb0
[<c0136a3d>] prep_new_page+0x2d/0x60
 [<c0136efc>] buffered_rmqueue+0xdc/0x190
 [<c0137426>] __alloc_pages+0x3c6/0x410
 [<c0140afb>] do_anonymous_page+0x4b/0x110
 [<c0140c1f>] do_no_page+0x5f/0x2b0
 [<c014101e>] __handle_mm_fault+0xbe/0x120
 [<c0110aa7>] do_page_fault+0x187/0x594
 [<c01268e0>] autoremove_wake_function+0x0/0x50
 [<c015678b>] sys_fstat64+0x2b/0x30
 [<c0162a19>] dput+0x179/0x180
 [<c014e89e>] __fput+0xfe/0x170
 [<c014d053>] filp_close+0x43/0x70
 [<c0110920>] do_page_fault+0x0/0x594
 [<c0102d3f>] error_code+0x4f/0x54
Trying to fix it up, but a reboot is needed

Systém jede dál nic nespadlo. Má někdo nějaký návrh? :) Že by vadný swap?

[David Watzke]

Píše tam, že je nutnej restart, tak to zkus. To je hnusný řešení.

[Tom K]

To by klidně mohla být ta paměť. Memtest rozhodně neodhalí všechno. Kdysi se mi stalo, že jednu specifickou chybu, která se občas projevovala odhalilo jen permanentní pouštění jednoho konkrétního subtestu v memtestu. A taky se mi stalo, že u kolegy se chyba projevila asi po osmi hodinách a jen jedna (ale v reálném životě to poznal daleko častěji).

[Antonín Kolísek]

Díky ta odpověď. Ale mohla by to být nebo je to ta paměť to je dost rozdíl. On to také může být CPU, chyba v kernelu, chyba v GCC a jsem zase tam kde jsem. Začal bych u toho jestli někdo neumí přeluštit ten výpis z dmesg. Určitě to nepíše jen tak,ale v konkrétním případě, při konkrétním konfliktu. Osobně tomu moc nerozumím.

[petr_p]

Kdyz prohledas usenet, tak nejdes napr. pesimistickou statistiku techto pripadu, vysvetleni, co to znamena a jeden reseny pripad.

Obecne jde o to, ze alokator stranek obdrzi dva krat stranku s ruznym flagem PG_swapcache, coz by se stat nemelo. Vetsinou se prokaze HW chyba.