Newsgroup: it.comp.os.linux.sys
Titolo: SB16, isapnp...

Salve,
ho qualche strano problema con una SB16 ed il PNP.
Tre kernel su quattro (non dentisti) assegnano l'irq 5
alla SB16 (come da PNP preferred configuration).
Un altro kernel (quello che uso normalmente, ovvio),
assegna l'irq 7.
La cosa non sarebbe di per se un problema, se non
fosse che:
1) la parallela non funziona piu` con gli irq (e vabbe`...)
2) Cambiando configurazioni da BIOS il modulo "sb.o" si
blocca in partenza (freeze completo) e nei log dice che
non riesce a configurare la SB16.
Ora, giocando con il BIOS o con isapnp, non si riesce ad
ottenere niente di meglio.
Se escludo l'irq 7 dai possibili (in modules.conf, un
parametro di isapnp), mi dice che non vi sono risorse
disponibili per la SB16 e non la configura.
Se forzo l'irq 5 (da BIOS) per ISA... Non succede nulla,
non riesce ad usarlo... (e si blocca).
Da notare che una scheda PCI, quando il modulo corrispondente
viene caricato, usa l'irq 5 (il che mi puzza sia assegnato a
priori a quello slot).
Tutto fuzionava OK prima che rimuovessi un modem, sempre
su ISA, che pero` usava l'irq 3 (o 4, quelli delle seriali).
Il kernel e` un 2.4.22 con qualche patch (ACPI il piu` notevole).
Su google vi sono note sparse riguardo ACPI per 2.5.xx e gli
irq della SB16, pero` non ho trovato niente di realmente concreto.
Idee? Suggerimenti? Link?
Thanks,
bye,
-- 
   Piergiorgio Sartor

Il giorno Tue, 18 Nov 2003, Piergiorgio Sartor così ha scritto:
|Salve,
|
|ho qualche strano problema con una SB16 ed il PNP.
|
|Tre kernel su quattro (non dentisti) assegnano l'irq 5
|alla SB16 (come da PNP preferred configuration).
|
|Un altro kernel (quello che uso normalmente, ovvio),
|assegna l'irq 7.
  Qualcosa usa la linea IRQ 5?
Può essere che un kernel condivida la linea di IRQ tra più dispositivi e
l'altro no.
  Sandro
-- 
Bellum se ipsum alet
       La guerra nutre se stessa
Livio, Ab urbe condita, XXXIV,9

 l'altro no.
Cioe`?
bye,
-- 
   Piergiorgio Sartor

Il giorno Tue, 18 Nov 2003, Piergiorgio Sartor così ha scritto:
|Alessandro Selli wrote:
|
|>   Qualcosa usa la linea IRQ 5?
|
|Puo` essere... Anzi pare certo che sia "allocata"
  Da cosa?
|(non usata, finche` non carico il modulo corrispondente)
  Quale dispositivo la usa?  Il problema ce l'hai sia che il modulo che
gestisce questo dispositivo sia caricato che quando non è caricato? (sarebbe
strano).
|> Può essere che un kernel condivida la linea di IRQ tra più dispositivi e
|> l'altro no.
|
|Cioe`?
  In linea di principio, più driver possono gestire periferiche che usano
la stessa linea di IRQ, ad es. una scheda audio potrebbe usare la stessa linea
di IRQ di una scheda ethernet.  In pratica, con le schede ISA, la cosa spesso
non riesce.  Per alcune schede seriali, il kernel va compilato appositamente
perché questo si possa fare:
make menuconfig
 Character devices  --->
 	   	    	[*] Extended dumb serial driver options
			[*]   Support for sharing serial interrupts (NEW)


 strano).
Prima di caricare il driver 1394, "sb.o" viene caricato e si
prende l'irq 7.
"procinfo" non mi dice nulla riguardo l'irq 5, che sembra
essere libero.
Quando carico i moduli 1394 (on demand) allora l'irq 5 viene
assegnato ad "ohci1394.o".
La cosa piu` disturbante e` che in certe condizioni il modulo
"sb.o" semplicemente si blocca e nulla funziona piu`, neanche
il "magic sysrq"...
Provero` con pci="noacpi" o simile...
bye,
-- 
   Piergiorgio Sartor

Il giorno Tue, 18 Nov 2003, Piergiorgio Sartor così ha scritto:
|Alessandro Selli wrote:
|
|> |Puo` essere... Anzi pare certo che sia "allocata"
|>
|>   Da cosa?
|
|Non saprei esattamente, il mio sospetto (verifichero`)
|e` che il driver ACPI allochi l'irq all'inizio.
  NOn ho esperienza con l'ACPI, le mie macchine sono tutte desktop di
"vecchia" data.  Ma leggo dia ogni sorta di problemi.
  Però, per "allocato" intendi che il BIOS lo assegna al controller ACPI?  In
teoria, se non erro, con i nuovi kernel, le impostazioni di IRQ del BIOS non
dovrebbero più fare testo, come pure la sua impostazione "PnP OS [Yes/No]".
In pratica ho visto come pure il supporto nativo PnP del kernel spesso non
permetta di fare a meno delle utility userland isapnp, come dovrebbe essere.
|> |(non usata, finche` non carico il modulo corrispondente)
|>
|>   Quale dispositivo la usa?  Il problema ce l'hai sia che il modulo che
|
|Scheda 1394.
  Sembrerebbe quindi che la firewire voglia usare lo stesso IRQ della scheda
audio.  Strano, le schede PCI (anche i controller integrati) normalmente usano
linee IRQ alte, non quelle solitamente usate dai dispositivi ISA vecchio stile.
|Prima di caricare il driver 1394, "sb.o" viene caricato e si
|prende l'irq 7.
|"procinfo" non mi dice nulla riguardo l'irq 5, che sembra
|essere libero.
|Quando carico i moduli 1394 (on demand) allora l'irq 5 viene
|assegnato ad "ohci1394.o".
  Fin qui, nulla di anomalo.  Dovrebbe essere possibile specificare un IRQ
preciso al modulo da caricare, invece di lasciarlo libero di scegliersene uno
dinamicamente.  Spesso è un parametro "irq=x" da dare sulla linea di comando a
insmod, oppure da mettere in una voce "options" in /etc/modules.conf.
Se ci provi, succede nulla di diverso/ incoraggiante?  Provassi, ad es., a dare:
# insmod ohci1394 irq=11
o qualche altro IRQ che non 11 che risulti libero in /proc/interrupts, funziona?
|La cosa piu` disturbante e` che in certe condizioni il modulo
|"sb.o" semplicemente si blocca e nulla funziona piu`, neanche
|il "magic sysrq"...
  Molto anomalo.  Di soundblaster ne ho usate parecchie, non ho mai avuto di
simili problemi.  Temo veramente che l'ACPI ci stia mettendo il suo malefico
zampino.  Che il kernel non sia stato configurato per usare il "SysReq" è
normale, quello non si dovrebbe usare in condizioni normali, è pensato per
situazioni di estrema sperimentazione da parte dei "kernel hackers" più
avanzati/ temerari.  Negli altri casi, magari il modulo non viene caricato o
non funziona, ma il kernel non dovrebbe bloccarsi così brutalmente.
Lo so, in pratica invece succede, a me un controller Adaptec AVA 1904 ha dato
parecchie rogne.
|Provero` con pci="noacpi" o simile...
  Buona idea.
  Auguri!  :-)


 non funziona, ma il kernel non dovrebbe bloccarsi cosě brutalmente.
Infatti, sembra come se aspetti un irq per sempre,
ignorando tutto il resto, inclusa la tastiera.


 "vecchia" data.  Ma leggo dia ogni sorta di problemi.
E diffatti...
Dopo un'occhiata meno superficiale ai log, risulta
che ACPI si piglia, all'inizio, l'irq 10, 11 e 5 (!!!!)
per il bus PCI.
Usando "pci=noacpi", l'irq 5 finisce sulla SB ed il
bus PCI si prende quelli alti...
Strano che sia solo un kernel a fare lo scherzo...
bye,
-- 
   Piergiorgio Sartor