Newsgroup: it.comp.os.linux.sys
Titolo: attivare dma su masterizzatore ide

salve,
qualche tempo fa avevo problemi a usare sotto linux un masterizzatore ide.
il "trucco" sta nell'usare l'emulazione scsi, e ok. il problema e' che il
dma non e' attivato sul masterizzatore, e non e' possibile attivarlo usando
hdparam perche' quest'ultimo vede solo /dev/hdX e non /dev/scd0
inoltre mettendo "append = ide0=dma" non succede niente. magari non e' ide0,
ma allora non so che numero mettere: la configurazione hw e' questa:
/dev/hda dvdrom (primario master)
/dev/hdc cdrv (secondario master)
/dev/hde hd
qualcuno mi puo' aiutare?
bye
Touch

 attivarlo usando hdparam perche' quest'ultimo vede solo /dev/hdX e non
Funziona, funziona.
Ciao.
-- 
***  Per E-mail rimuovi ModE dall'indirizzo  ***
  *** Linux user # 198661 --- ICQ 33500725 ***
*** homepage 
http://web.tiscalinet.it/kailed
 ***
            *** Powered by Linux ***

 Funziona, funziona.
che vuoi dire? se nei parametri del kernel metto "hdc=ide-scsi"
poi invoco "hdparm /dev/hdc" mi dice un qualcosa tipo che non esiste
e "hdparm /dev/scd0" mi dice un qualcosa tipo che non puo'
(ops, mi viene in mente: forse e' una questione di permessi? faro' sapere
nel pomeriggio)
bye
Touch

 nel pomeriggio)
Oooooh, questo e` un trucco davvero sporco...
modprobe ide-scsi
hdparm /dev/hdc
modprobe -r ide-scsi (-r == remove, non sono sicuro)
Notato la contraddizione?
Su RH6.2 con kernel 2.2.19 funziona cosi`...
bye,
-- 
  Piergiorgio Sartor

Simone Pierazzini wrote:

hda,hdb -> ide0
hdc,hdd -> ide1
hde,hdf -> ide2
.....

 che vuoi dire? se nei parametri del kernel metto "hdc=ide-scsi"
Io ho l'emulazione scsi direttamente nel kernel e hdparm funziona 
correttamente.
Se faccio $ hdparm -v /dev/hdd, da si un errore ma se gli do qualche 
impostazione la prende senza problemi:
kailed:~ # hdparm -v /dev/hdd
/dev/hdd:
 HDIO_GET_MULTCOUNT failed: Input/output error
 I/O support  =  1 (32-bit)
 unmaskirq    =  1 (on)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 HDIO_GET_NOWERR failed: Input/output error
 readonly     =  0 (off)
 BLKRAGET failed: Input/output error
 HDIO_GETGEO failed: Invalid argument
kailed:~ # hdparm -c /dev/hdd
/dev/hdd:
 I/O support  =  1 (32-bit)
Con i moduli hai però un problema, ogni volta che il modulo viene 
scaricato, le impostazioni di haparm vanno perse, devi smanettare in 
/etc/modules.conf con qualcosa tipo: postinstall ide-scsi /sbin/hdparm 
....
Adesso non ricordo la sintassi esatta, non l'ho mai usato in questo 
modo.


 modo.
Uhm, non saprei, c'e` l'opzione, mi pare, -k di hdparm che
mantiene i settaggi tra i reset del device, il che include
il caricamento dei moduli (il reset, intendo).
Infatti hdparm va a toccare il driver ide di basso livello,
il quale, a meno che non sia un modulo lui stesso (?), non
dovrebbe perdere la configurazione con -k.
bye,
-- 
piergiorgio

 Uhm, non saprei, c'e` l'opzione, mi pare, -k di hdparm che
Se non ricordo male, mi sembra che l'opzione -k sia sconsigliata ma 
proprio non mi ricordo dove l'ho letto.
Comunque, io tutte 'ste menate per un modulo proprio non le capisco, 
inserite l'emulazione scsi direttamente nel kernel e buonanotte.


 inserite l'emulazione scsi direttamente nel kernel e buonanotte.
Perche` avendo i moduli puoi avere il CDROM visto
come SCSI ed anche come IDE (in tempi diversi, ovviamente).
Se hai CDROM e CDRW (2 drive), puoi vedere uno IDE
e l'altro SCSI, a seconda delle necessita`.
Alle volte torna utile, dato in alcuni casi il device
IDE si comporta meglio dello SCSI emulato.
Se non usi il CDROM, puoi avere un po' piu` di memoria
libera nell'area del kernel.
Insomma vi possono essere tutta una serie di ragioni
per avere il sottosistema CDROM in moduli, invece
che integrato nel kernel.
bye,
-- 
  Piergiorgio Sartor

 che integrato nel kernel.
Ognuno fa come gli pare, ovviamente, ma io rimango dell'idea che sia 
una menata inutile.


 una menata inutile.
Dipende dalle necessita`, come sempre...
bye,
-- 
piergiorgio

 una menata inutile.
C'e` un sicuramente un altro buon motivo per avere
il sottosistema CDROM _nel_ kernel e _non_ in moduli.
E` possibile, sistematicamente o casualmente, provocare
un kernel panic avendo la roba in moduli.
Il che non e` affatto bello...
bye,
-- 
  Piergiorgio Sartor

Piergiorgio Sartor wrote:

Questo mi sembra un motivo pių valido rispetto a quelli per la 
soluzione "modulare" che hai esposto nell'altro msg.


 soluzione "modulare" che hai esposto nell'altro msg.
Oh, beh, si spera sempre che qualcuno sistemi
il problema ;-)
bye,
-- 
piergiorgio

 un kernel panic avendo la roba in moduli.
MAggiori info ?

 MAggiori info ?
Sapevo di trovare qualche curiosone :-)
Dunque il problema, riscontrato su RH5.2 e RH6.2,
con kernel 2.0.39 e 2.2.19, e` legato all'intervallo
temporale tra il riconoscimento del CD da parte del
CDROM e la rimozione dei moduli.
Quello che mi capita e` questo:
inserisco un CD nel drive e faccio "mount /mnt/cdrom",
il drive ci mette un paio di secondi per riconoscere il
CD, nel frattempo, a causa di "mount" i moduli vengono
caricati, ma durante l'attesa (i due secondi), non sono
"locked", perche` risultano inutilizzati, cosi` se uno da
"rmmod -as" oppure (come nel mio caso) il cron job lancia
"rmmod -as" giusto in quel momento, i moduli vengono rimossi.
Il problema e` che, quando il CDROM ha riconosciuto il CD,
mount continua da dove si era fermato, solo che le funzioni
che deve usare in seguito non sono piu` disponibili (?!) in
memoria e si ha un bel kernel panic, con tanto di macchina
inchiodata (non ho provato SysRq).
Almeno questa e` la mia interpretazione...
bye,
-- 
piergiorgio

 Almeno questa e` la mia interpretazione...
Dando per scontato che la tua interpretazione sia giusta, mi si 
rafforza la convinzione che l'utilizzo di moduli nell'emulazione scsi, 
porti più "problemi" che vantaggi.
Certo, il tuo esempio è forse un caso un "limite" però perché rischiare?
Per risparmiare 30K? Va bene ottimizzare tutto, non sprecare risorse, 
ma 30K....
Poi se non sbaglio, alcuni rippers vogliono un device scsi...


 Poi se non sbaglio, alcuni rippers vogliono un device scsi...
Infatti, qui nasce l'inghippo
Un ripper voleva SCSI, ma non funzionava a dovere ed era
lentissimo (sempre 2.0.x). Un altro andava benissimo
usando IDE, ma non altrettanto SCSI (come il primo).
Per masterizzare, pero`, serve SCSI.
La mia esperienza con il CDROM ed il CDRW e` stata che,
a parte masterizzare, e` meglio avere tutto IDE.
Attualmente sto provando ad usare, con il 2.2.19, il
sistema in modalita` SCSI emulata. Vedremo...
Giusto per darti ancora ragione :-), vi e` un'altra
controindicazione per l'uso dei moduli, questa volta
per il sottosistema SCSI...
Se hai diverse periferiche SCSI-emulate (ZIP su parallela,
CDROM, CDRW, USB-storage), i device associati dipendono
dall'ordine in cui i moduli vengono caricati...
L'effetto non e` visibile immediatamente, a meno di
non usare "cdrecord" e tentare di masterizzare
sullo ZIP... :-)
Comunque vi e` un vantaggio nell'usare i moduli:
si imparano un sacco di cose!!!
In generale, moduli a parte, ho trovato che l'emulazione
SCSI e` ancora un po' poverella in Linux, spesso le
cose non funzionano proprio a dovere...
Mi riferisco a ZIP, CD, USB.
bye,
-- 
piergiorgio

 Almeno questa e` la mia interpretazione...
Interessante. Non mi torna la tua spiegazione con quello che conosco; ma 
non mi sento di affermare che sia sbagliata. Comunque quello che tu dici é 
un problema dei driver cd, non dei moduli in generale.

 un problema dei driver cd, non dei moduli in generale.
Uhm, ci sono riuscito anche con altri moduli.
E` difficile, dato che la finestra temporale e` di
solito breve, tranne nel caso del CD.
Pero` l'USB ha comportamenti simili, dato che ci mette
quasi un secondo buono ad assestarsi. Solo che questi
driver sono talmente alfa che non si puo`
dire con certezza...
Con lo ZIP (su parallela) e` anche possibile ed
anche in questo caso bisogna essere veloci.
Inserendo il CD, dando "mount..." e, in un altro
terminale, dando "lsmod", trovo che alcuni moduli
relativi al CD (sr_mod, sd_mod, mi pare), sono
caricati, ma "(autoclean) unused" e hanno count zero.
In seguito risulteranno solo "(autoclean)" e con
count uno.
Ora, io mi chiedo, perche` se la mount e` in corso,
anche se aspetta  il CDROM, il count e` zero?
Ci sara` un motivo?
Secondo, perche` i moduli, se rimossi, non vengono
ricaricati al proseguire della mount?
Forse non e` la mount che e` bloccata, ma una chiamata
piu` bassa, a livello di kernel...
Non so, se mi gira mi metto ad investigare piu`
a fondo... Vedro`...
bye,
-- 
piergiorgio

 dall'ordine in cui i moduli vengono caricati...
Questi sono casi un po' troppo specifici, e anche se molto 
interessanti, stiamo forse andando un po' troppo oltre il topic del 
thread.


 caso di problemi si può sempre cambiare soluzione.
Esatto. E questa e` la cosa migliore che possa
capitare: se vuoi cambiare, puoi farlo.
bye,
-- 
piergiorgio

 Ci sara` un motivo?
La count é inzializzata a "mano" nel codice attraverso la macro 
MOD_INC_USE_COUNT;
Ho fatto l'esperimento con il kernel 2.4.14 é non ho verificato quello che 
hai detto; da un lato ho lanciato il comando mount e dall'altro un qualcosa 
del tipo 'while true; do rmmod -as; done'. Il mount é andato a buon fine.


 del tipo 'while true; do rmmod -as; done'. Il mount é andato a buon fine.
Dunque, il 2.4.x io non lo ho provato, secondo il loop...
...non funziona neanche con il 2.2.19 :-)
Due possibilita`: avviene troppo presto, non avviene affatto.
Prova "rmmod", senza "-as".
Quello che ho fatto io e` usare due console virtuali e
verificare con lsmod lo stato, prima di dare "rmmod",
senza "-as".
Il fatto strano, pero`, e` che il crontab ha il "-as"...
Sempre piu` boh...?
bye,
-- 
piergiorgio

 senza "-as".
Funziona anche con "-as", ma non troppo presto.
Ho inchiodato talmente bene il kernel, che neanche
SysRq mi ha salvato...
Piuttosto, continuando sul discorso di "unused",
se io do "cat /dev/scd0 >/dev/null" (tanto per
fare un esempio), il modulo viene caricato, usato,
alla fine del comando il count sara` 0, ma non
"unused".
Se do qualcosa come "cat /dev/cpu/0/msr >/dev/null"
(ma anche solo usando "rdmsr/wrmsr"), il modulo "msr",
alla fine, risulta con count 0, ma anche "unused".
Perche`?
La cosa noiosa e` che devo rimuoverlo a mano, non
posso affidarmi al crontab, perche` "rmmod -as" non
funziona....
Any hints?
bye,
-- 
  Piergiorgio Sartor

 >> > che integrato nel kernel.
e una di quelle citate nel thread era la possibilita' di scegliere se usare
un device (eg. /dev/hdc) come ide o come scsi a seconda della "voglia"
il fatto e' che per abilitare l'emulazione scsi occorre dare parametri al
kernel (quindi a boot-time. ci sono altri sistemi?) del tipo "hdc=ide-scsi"
e una volta fatto questo ad esempio cdparanoia si rifiuta di aprire hdc (ma
anche scd0)
il mount non funge su hdc ma su scd0 etc.
in pratica hdc "scompare" (per tutti tranne che per hdparam)
quindi che ide-scsi.o sia un modulo o no non cambia niente: la questione
viene decisa a boottime, o no?
bye
Touch

 viene decisa a boottime, o no?
No.
Con il 2.2.x e` possibile scegliere run-time cosa
avere, se IDE od SCSI emulato.
Se interessa posso riportare il mio /etc/modules.conf
per dettagli ulteriori.
bye,
-- 
  Piergiorgio Sartor

 per dettagli ulteriori.
Anche se non interessa, riporto lo stesso le
righe "incriminate" di /etc/modules.conf, che
rilascio sotto GPL.
below sr_mod ide-scsi
below sg ide-scsi
options ide-cd ignore=/dev/hdc
La prima riga dice di caricare "ide-scsi" prima di caricare
"sr_mod", questo secondo e` il driver che gestisce /dev/scdX
(cioe` il CDROM come disco).
La seconda riga dice di caricare "ide-scsi" prima di
caricare "sg", questo secondo e` il driver di /dev/sgX
(cioe` il CDRW, in modo "generic", per masterizzare".
La terza riga dice a "ide-cd" (caricato quando si
accede a /dev/hdX, con X l'unita` del CDROM) di ignorare
/dev/hdc (nel mio caso considera solo /dev/hdd).
Questa terza riga consente (e` un caso, si puo` fare
anche altro) di avere un'unita` come IDE e l'altra
come SCSI (attenzione che i riferimenti potrebbero
cambiare...).
Credo sia tutto,
bye,
-- 
piergiorgio