[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Problema con configuración de disco IDE (con hdparm)



Pues simplemente decirte que te agradezco la ayuda, ya que estaba un poco bloqueado y ahora ya sé con qué seguir probando. Sí que he de decirte que el cable que tiene 40 hilos y que aparece en "Cable Type" es el que corresponde al otro canal ide, en el que sólo hay conectado una grabadora de DVD.

Por cierto, hoy mismo me habían hablado de ese tipo de cable, voy a comprarlo y probarlo, ya os contaré.

Un saludo y gracias!!!


Santiago José López Borrazás escribió:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

El 30/12/07 01:18, Javier Rey escribió:
(...)
  
Cable Type:                   80w              40w
    
¿Tas seguro que ese cable tiene 80 conexiones, tanto para el primario como
para el secundario? Porque, por lo que, estás conectando del 2º con un
conector de 40 pines en vez de 80.

Mi consejo, es que, te compres un cable de esos, que tiene la faja circular
(envuelto en plástico o vulcanizado), y te dejarás de rollos, porque esos
cables tienen 80 hilos por los dos conectores.

Lo digo, porque, el cable de 80 hilos en faja (normalmente, tiene 40 hilos,
ya que, en el principal, te vienen enmarcados como 80 hilos, porque están
entrelazados entre sí), no te garantizan que tengas 80 hilos, tanto como
uno, como otro.

  
Lo que ocurre es que, si intento aplicar a hda un modo de trasferencia
UDMA4 O UDMA5, los errores antes mencionados de BadCRC me salen también
durante la ejecución de INIT (imagino que cuando se lee la configuración
de /etc/hdparm.conf), pero esta vez el error aparece tanto en los dos
discos, y el resultado es que, hda ahora queda funcionando en modo DMA,
pero hdb queda en modo PIO.
    
Me temo que, aunque lo tienes bien, esa faja para hda y hdb, tienes en un
tramo los 80 hilos, y el otro, de 40. Lo mejor, es que, te compres un cable
nuevo, que te viene los 80 hilos ya puestos y entrelazados, que pueden
servir perfectamente para los dos discos duros.

  
*No comprendo por qué aparecen errores en lectura de sectores si se
cambia el modo de transferencia a uno más rápido*, sobretodo cuando son
modos soportados según las características del disco duro y estoy usando
un cable IDE de 80 hilos (ya comprobé que no es fallo del cable, con
otro cable me ocurre lo mismo).
    
Ya, sí. Pero el cable siendo de 80, el otro extremo (que normalmente, es del
medio), pues no tiene los 80 hilitos entrelazados. Sólo que el terminador
del cable, si te fijas, tiene unos remaches que hacen que se sientan que son
de 80 hilos. El otro, no lo tiene, los tiene como 40.

Ya digo, que hay unos cables nuevos ya (y son redondos, y son mejores, que
tienen los 80 hilos, tanto como uno, como otro conector sin ningún tipo de
problemas. Y pueden servir para ello. ;-)

¿Tiene tu placa madre otro conector IDE? Pruébalo con el otro canal y con el
otro cable de 80 hilos,...¡verás que no te falla! Te lo hará a la primera, y
a la de cambio, no te va a dar errores.

  
*Si alguien me supiera decir a qué podría deberse, se lo agradecería*
    
Se debe a lo que he dicho arriba. Que la faja de cable IDE, _sólo_ tiene en
el último extremo como 80 hilos, en vez de 40, pero si pones el conector al
disco principal dicho conector del medio, ¡_claro_ que te va a dar como IDE
normal y te dé errores!

  
Por último, a ver si alguien pudiera saber si habría alguna forma de que
se pudieran salvar los errores de BadCRC durante la carga del kernel, lo
he intentado poniendo como parámetro del kernel ide=nodma y persiste el
problema.
    
Eso no es problema. Aunque, te puedo decir, que puedes indicar al inicio que
no se ejecute como UDMA (que se puede). Pero no es recomendable, ya que,
perderás mucha velocidad.

  
Un saludo, y gracias de antemano!
    
De nadas.

- --
Slds de Santiago José López Borrazás
Conocimientos avanzados en seguridad informática.
Conocimientos avanzados en redes.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJHdud7AAoJELuF9/q6J55We74P/Rn2onEuVsVZvM6zAhud9s+X
34PFcxJPD1h1peXdUW76VzcRghNuDF13qLUQAqZDu1opSlOwE4h7fUsGF4hIsFhr
GoSLWwVI6BQC7FJo7P1BxLM6kvsose048nMR2+LkUS0ei9B6JgmVohaRtSZBE5UF
0XhRq8sv58h11+AATEHJwNNpHU2PfKOi8CeW5kvcx+2Tiz8cnJft1WB4aY3YVyhx
ExPoDXD2+YINC2ioDtpc2s0RpLapq6KoP9oehQ0lWltYzz9XcuF7qAtX2VaRC7IM
w8sfA64jRQFSWQ4g/LdjT57097Clw0xziApoZW1Zbyz4839xYc96/LIpMB72xhYA
G9CLWYlRWVtc7ViYNR/KvtzvOJ5vRONmoXp3fFRPhb74O2LRMU4AeW+O8RhDJ+de
YxsIaGw9Wx+5D0cjnnZbPKkHBmclpQtdxQ8Nf5GbvWfTtBPZXvchBNXHDTHrPyEm
ryj2Acyn9Ws2PZ4n8ZzJTo3tWrwCCGHdLMW4Fsxus3Ab5hcC5inJwGO5hElVm/Z3
ENuJUPuBt8wU2CvG4ZfSuRRzgR0Wgap/oWzF41bTsWMQkC1SjIwUws6CfQAYCgUh
ivItOyLTQNig9jrQ0ohJn5U5OjtMD97lpTarlUc5aRqbytUjkg5J/Ce2G2EP36t3
ZwvrWrmOKSlj3VmB1XGG
=tJpC
-----END PGP SIGNATURE-----


  


Reply to: