[RISOLTO] Compilando 2.6.17 e 2.6.20 (vecchia mobo ABIT)

kens · Messaggio da **kens** » dom 25 mar 2007, 21:56

Dopo avere installato la Slack 11 su un hard disk separato (lavoro ancora con una 10.0 messa a punto in mesi di affinamenti successivi), mi sto divertendo a giocare un po' con la "11", ad esempio installando il 2.6.17 e provando a compilare ed installare il 2.6.20.
Ho dei problemi -credo sia naturale per un non espertissimo

- e vorrei, se possibile, qualche parere/consiglio:

1) in fase di boot -ed anche rileggendo sia "syslog" sia "dmesg"- noto questa strana serie di stringhe che, ad occhio, non mi pare del tutto rassicurante:
<c0133982> __report_bad_irq+0x22/0x90 <c0133a98> note_interrupt+0x78/0xc0
<c01334a9> __do_IRQ+0x99/0xb0 <c01048da> do_IRQ+0x1a/0x30
<c010305a> common_interrupt+0x1a/0x20 <c011d250> __do_softirq+0x30/0xb0
<c011d305> do_softirq+0x35/0x40 <c01048df> do_IRQ+0x1f/0x30
<c010305a> common_interrupt+0x1a/0x20 <c013355c> enable_irq+0x2c/0x80
<c02323d5> ide_config_drive_speed+0x215/0x370 <c0221e01> hpt370_tune_chipset+0x131/0x140
<c02221e0> hpt366_config_drive_xfer_rate+0x0/0x80 <c022220f> hpt366_config_drive_xfer_rate+0x2f/0x80
<c02348de> probe_hwif+0x36e/0x4c0 <c0234a40> probe_hwif_init_with_fixup+0x10/0x80
<c0237a17> ide_setup_pci_device+0x57/0xa0 <c0223784> init_setup_hpt366+0x134/0x180
<c02237f0> hpt366_init_one+0x20/0x30 <c0401725> ide_scan_pcidev+0x45/0x70
<c0401776> ide_scan_pcibus+0x26/0xb0 <c040166b> probe_for_hwifs+0xb/0x20
<c04016c4> ide_init+0x44/0x60 <c03e87d9> do_initcalls+0x79/0x120
<c0133e1d> register_irq_proc+0x6d/0x80 <c01002b0> init+0x0/0x1a0
<c01002dd> init+0x2d/0x1a0 <c0101355> kernel_thread_helper+0x5/0x10

qualcuno sa dirmi di che si tratta e, eventualmente, come rimediare?

2) Come interfaccia grafica uso KDE 3.5 -che ho provveduto ad italianizzare- ma il sistema mi sembra assai lento e poco "reattivo" (ad esempio, in fase di avvio del'interfaccia grafica, il file sonoro associato allo start-up viene riprodotto dopo una decina di secondi, le finestre si aprono e chiudono con ritardo, come se il sistema fosse molto occupato a far altro).
Ho sentito dire che il 3.5 non è il miglior parto di KDE, può essere questa una delle ragioni?

3) Non disponendo di un "config-file" di guida -che invece esiste per il 2.6.17- configurare il menu di compilazione del 2.6.20 -make menuconfig- non è delle cose più semplici -ed infatti il 2.6.20 compilato da me non parte...

- qualcuno sa dove potrei trovare una traccia per non partire da zero?

Grazie della pazienza

lunga vita a slackware!

:):)

Messaggio da **michele.p** » dom 25 mar 2007, 23:35

...nell'ordine;

1) Le stringhe che hai riportato hanno a che vedere con la gestione degli interrupt probabilmente (ma non ne sono certo) dovuto a qualche "discrepanza" con il BIOS. Ad esempio il tuo BIOS supporta l'APIC?....su questo per un uso "normale" del PC non mi preoccuperei più di tanto, diverso il caso se dovessi usarlo per ambienti industriali e/o (hard) Real Time. Potrebbe anche darsi che questa cosa si rifletti sul secondo quesito che hai posto. Che PC hai?...l'hardware intendo....

2) Apri una shell e impartisci il comando

top

attraverso questo vedi (dinamicamente) chi/cosa/quale processo consuma risorse; in genere in un uso desktop al primo posto ci sono sempre Firefox e X e in termini di memoria e in termini di CPU (eventualmente un client Torrent e/o P2P). Potrebbe anche darsi che durante la fase d installazione hai attivato, involontariamente, tutti i processi.

3) Per una prima parziale configurazione del nuovo kernel, puoi usare sempre il config del kernel "vecchio" anche perché ad eccezione di nuove feature i cambiamenti da una versione a quelle immediatamente successive non sono così radicali tali da non far partire nulla. Le differenze (se presenti) ti vengono comunque mostrate in consolle attraverso dei warning quando il parser va a leggere il file config e non trova le voci corrispondenti oppure trova voci inesistenti per le nuove versioni.

Bye

kens · Messaggio da **kens** » lun 26 mar 2007, 0:08

Beh, l'hardware è un po' datato -ma a prova di bomba:

-Mobo ABIT KT7A Raid (controller RAID disabilitato da BIOS e visto come normale ATA)
-CPU AMD Duron 1300 MHz
-RAM 512 MB
-Scheda video nVidia GEForce 2MX
-Scheda Audio Terratec SixPack 5.1+
-Scheda di rete PCI Realtek RTL-8139/8139C/8139
-Scheda di rete ISA 3Com 3C509b
-HDD Drive IBM 60GB e Maxtor 40GB (entrambi IDE ATA 100)
-CD RW IDE Samsung
-DVD RW IDE Pioneer
-Alimentatore 400W Enermax

Ad ogni modo la stessa Slack11 non da il messaggio incriminato quando l'avvio col 2.4.33.

D'accordo che sto "giocando", ma...
viste le differenze "architetturali" di non poco conto, intercorrenti tra i kernel 2.4 e quelli 2.6, non potrebbe darsi -la mia impressione inizia ad essere proprio questa...- che impostare un multi-boot che avvii 2.4 o 2.6 sullo stesso sistema sia sempre un'operazione non priva di effetti collaterali?
Quasi quasi ricomincio da capo scegliendo il 2.6 direttamente in fase di installazione (per poi magari upgradare a 2.6.20).

Grazie 1000 comunque, Michele!

Messaggio da **michele.p** » lun 26 mar 2007, 0:28

....eheheheh....questo, invece, è il mio PC

Mb Asus A7V
CPU AMD Athlon Thunderbird 1400
RAM 512MB PC 133
Scheda nVidia GeForce 2MX 100/200
Scheda Audio Creative Audigy SE
Scheda di rete PCI Realtek 8139
HDD Drive 80GB Maxtor e 40GB Seagate (entrambi IDE ATA 100)
CD RW IDE Samsung
DVD RW IDE Nec
Alimentatore 400w Enermax (correzione attiva del cos fi)

...a questi aggiungo;

Stampante HP LaserJet 1100
Modem Ethernet/USB dLink DSL-302T (in collegamento Ethernet)
Scheda di acquisizione dati su bus PCI Measurement Computing DAS-1200 (per motivi di tesi

)
Kernel 2.6.20 con patch RTAI-Adeos (hard Real Time)

...naturalmente il tutto su una Slackware 11

Riguardo ai messaggi; prova a disabilitare nel 2.6 la gestione APM e a far rimanere attiva solo l'ACPI oppure il contrario
Se ora provi con;

dmesg|grep acpi

cosa ti viene restituito?...e con un;

dmesg|grep irq

cosa ti da?

Quando scegli il 2.6 direttamente in fase di installazione ricordati di installare anche i moduli altrimenti non ti funziona nulla.

P.S.:Quando fai le prove, mantieni sempre un kernel "vecchio" si tale da poter sempre ripartire in caso di problemi.

Bye

kens · Messaggio da **kens** » lun 26 mar 2007, 7:56

root@k6_400:~# dmesg |grep ACPI
BIOS-e820: 000000001fff0000 - 000000001fff3000 (ACPI NVS)
BIOS-e820: 000000001fff3000 - 0000000020000000 (ACPI data)
ACPI: RSDP (v000 VT8371 ) @ 0x000f7900
ACPI: RSDT (v001 VT8371 AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff3000
ACPI: FADT (v001 VT8371 AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff3040
ACPI: DSDT (v001 VT8371 AWRDACPI 0x00001000 MSFT 0x0100000c) @ 0x00000000
ACPI: PM-Timer IO Port: 0x4008
ACPI: setting ELCR to 0800 (from 0e00)
ACPI: bus type pci registered
ACPI: Subsystem revision 20060127
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 10 11 12 14 15) *9
ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 5 6 7 10 *11 12 14 15)
PCI: Using ACPI for IRQ routing
apm: overridden by ACPI.
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:13.0[A] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11
ACPI wakeup devices:
ACPI: (supports S0 S1 S4 S5)
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:07.2[D] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
ACPI: PCI Interrupt 0000:00:07.3[D] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10
ACPI: PCI Interrupt 0000:00:0d.0[A] -> Link [LNKB] -> GSI 10 (level, low) -> IRQ 10
ACPI: PCI Interrupt 0000:00:0f.0[A] -> Link [LNKB] -> GSI 10 (level, low) -> IRQ 10

root@k6_400:~# dmesg |grep irq
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
VP_IDE: not 100% native mode: will probe irqs later
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
HPT370: 100% native mode on irq 11
ide2 at 0xd000-0xd007,0xd402 on irq 11
ide3 at 0xd800-0xd807,0xdc02 on irq 11
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
uhci_hcd 0000:00:07.2: irq 11, io base 0x0000c400
uhci_hcd 0000:00:07.3: irq 11, io base 0x0000c800
parport0: PC-style at 0x378, irq 7 [PCSPP,EPP]
parport_pc: VIA parallel port: io=0x378, irq=7

Michele innanzitutto grazie ancora della pazienza, poi...
ne vuoi sapere una "bella"?
Se faccio lo shutdown e spengo il sistema, alla riaccensione i messaggi "incriminati" spariscono; se invece riavvio semplicemente senza spegnere ricompaiono (mistero...).

Messaggio da **michele.p** » lun 26 mar 2007, 22:25

...ma i messaggi ti vengono dati avviando il kernel 2.6 una seconda volta?...in sostanza; fai un primo avvio del 2.6 poi riavvii nuovamente con il 2.6: i messaggi ti sono gli stessi o cambiano?...e con il kernel 2.4?

Prova a disabilitare nel ricompilare il kernel 2.6, il gestore APM.

Un'altra cosa; per caso hai un controller DMA su bus PCI?...ad esempio un "hpt366"...

Bye

kens · Messaggio da **kens** » lun 26 mar 2007, 22:45

Ciao Michele! Ti angoscio ancora un po'...

Sì, dovrei avere un controller del genere integrato nel chipset; rispondo con un "lspci":

root@k6_400:/home/nicola# lspci
00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03)
00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40)
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C/VT8235 PIPC Bus Master IDE (rev 06)
00:07.2 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 16)
00:07.3 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 16)
00:07.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
00:0d.0 Multimedia audio controller: Cirrus Logic CS 4614/22/24 [CrystalClear SoundFusion Audio Accelerator] (rev 01)
00:0f.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
00:13.0 Unknown mass storage controller: Triones Technologies, Inc. HPT366/368/370/370A/372 (rev 03)
01:00.0 VGA compatible controller: nVidia Corporation NV11DDR [GeForce2 MX 100 DDR/200 DDR] (rev b2)

Per quanto riguarda la misteriosa "sparizione" dei messaggi incriminati ho condotto ulteriori indagini che non hanno fatto altro che rendere meno chiaro il quadro

Premesso che parlo sempre di riaccensione/riavvio con 2.6.17, ho notato che il problema si presenta in modo casuale, diciamo nell'80% delle occasioni (stregoneria?). Riavviando col 2.4.33 tutto si svolge invece regolarmente, sempre.

Un sincero saluto e grazie ancora!

:):)

Messaggio da **michele.p** » lun 26 mar 2007, 23:01

...questa è la tua scheda madre;

http://www.hothardware.com/reviews/imag ... /board.jpg

giusto?

...torno a riperterti; quando ricompilerai di nuovo il kernel (MANTIENI SEMPRE QUELLO "vecchio" in caso di problemi) disabilita l'APM e rimani solo con l'ACPI

Riguardo al controller UDMA integrato prova a dare una letta qui;

http://web.cecs.pdx.edu/~cklin/hpt366/

è un po vecchio, ma rende l'idea.

Bye

kens · Messaggio da **kens** » ven 20 apr 2007, 19:17

Sto ottenendo qualche risultato disabilitando ACPI (mantenendo il solo APM) ed aggiungendo a lilo "irqpoll".
Ora il sistema parte regolarmente sia col kernel 2.6.17 sia col 2.6.20.
Il problema degli strani messaggi al boot sembrerebbe dunque legato a conflitti e/o contese di "irq" (la mia mobo "KT7A RAID" ne è più assetata avendo quattro controller IDE), più che ad un'incompatibilità del controler "HPT370".

Rimangono però due problemi:
1) col solo APM (impostato direttamente nel kernel, non come modulo) il pc non si spegne (perché fa così, visto che con APM e col kernel 2.4 usato sinora lo spegnimento è sempre stato regolare? Avrò dimenticato qualcosa?).
2) il sistema continua ad apparire poco "reattivo" anche se dando un "top" nessun processo pare consumare risorse ingenti (i suoni arrivano con ritardo e le finestrea volte si chiudono qualche secondo dopo il comando).

Qualcuno ha in mente una spiegazione?

Come al solito grazie...

in anticipo

Messaggio da **michele.p** » sab 21 apr 2007, 14:25

1) Probabilmente avrai dimenticato qualcosa nella configurazione. Io, per motivi legato alle latenze, ho disabilitato completamente l'APM e abilitato solo l'ACPI.

2) Probabilmente non avrai il DMA attivato. Prova a fare così; apri una shell, diventa root e impartisci il seguente comando;

hdparm -v /dev/hdx | grep dma

...dove al posto della x dovrai inserire la periferica che vuoi controllare. Se ti "risponde" con;

using_dma = 1 (on)

allora il problema è da ricercarsi altrove. Se invece sta a 0 alias in "off" allora devi attivare il DMA sull'hard disk.

Bye

Messaggio da **submax82** » sab 21 apr 2007, 14:53

Non disponendo di un "config-file" di guida -che invece esiste per il 2.6.17- configurare il menu di compilazione del 2.6.20 -make menuconfig- non è delle cose più semplici -ed infatti il 2.6.20 compilato da me non parte... Confused- qualcuno sa dove potrei trovare una traccia per non partire da zero?

usa make oldconfig

il titolo è un pò ambiguo con il tema trattato... meglio "giocando con la ricompilazione del 2.6.20" o qualcosa di quel tipo

kens · Messaggio da **kens** » lun 7 mag 2007, 11:30

Pant pant puff puff... Risolto (almeno così pare)

Il mio, come dicevo, non è un PC giovincello...

Dunque ho abilitato sia ACPI sia APM nel kernel e poi ho "stoppato" ACPI "appendendo" l'apposita stringa in lilo (quindi ora "governa" APM).
Evidentemente il BIOS della mia "Abit K7A Raid" e l'APM, essendo quasi coevi

s'intendono meglio!
Ora il PC si spegne, non ci sono più conflitti di "irq" ed il "dmesg" è di una pulizia esemplare.
Lavorando da terminale le prestazioni sono ottime; lavorando sotto KDE permane invece una percettibile lentezza solo se si opera da root. Visto però che operare in X da root non è né consigliabile né utilissimo credo che lo lascerò fare...

Un sincero grazie a tutti voi.

Nicola