Forum Linux.debian/ubuntu [sarge] DMA activé sur un graveur DVD mais K3B n'en tient pas compte !!?!

Posté par .
Tags : aucun
0
19
oct.
2006
Bonsoir à tous,

[caveat : ce post est une reprise de mon post sur linux-général, cette partie là du forum semblant tout à fait inactive (sic) !!]

Je suis sous Debian Sarge avec un noyau 2.4.x. Bien que je pense que mon problème n'est pas spécifique à Debian, la masse de outstanding bugs du paquet dvd+rw-utils m'a un peu affolé et donc me voici.

Mon nouveau graveur de DVD Pioneer DVR-111D (IDE) me fait souci : il a bien été détecté dès le premier redémarrage mais les diffétrentes opérations (sur CD ou DVD) sont incroyablement lentes !!

Pour illustration, il grave en 0.30X un DVD-RW de test au lieu de 6X/8X. J'ai très vite pensé un problème de DMA d'autant que k3b m'indique ceci dans sa sortie de déboguage (écriture CD-RW) :


PIONEER DVD-RW DVR-111D 1.23 (/dev/hdb, ) at /media/cdrom0 [CD-R; CD-RW; CD-ROM; DVD-ROM; DVD-R; DVD-RW; DVD-R DL; DVD+R; DVD+RW; DVD+R DL] [DVD-ROM; DVD-R séquentiel; DVD-R double couche séquentiel; DVD+R double couche à saut; DVD RW à réinscription limitée; DVD-RW séquentiel; DVD+RW; DVD+R; DVD+R double couche; CD-ROM; CD-R; CD-RW] [SAO; TAO; RAW; SAO/R96P; SAO/R96R; RAW/R16; RAW/R96P; RAW/R96R; Réinscription restreinte; Saut de couche]
Used versions
-----------------------
cdrecord: 2.1.1a01

cdrecord
-----------------------
scsidev: 'ATAPI:/dev/hdb'
devname: 'ATAPI:/dev/hdb'
scsibus: -2 target: -2 lun: -2
Warning: Using ATA Packet interface.
Warning: The related Linux kernel interface code seems to be unmaintained.
Warning: There is absolutely NO DMA, operations thus are slow.
SCSI buffer size: 64512
/usr/bin/cdrecord: This version of cdrecord does not include DVD-R/DVD-RW support code.
/usr/bin/cdrecord: See /usr/share/doc/cdrecord/README.DVD.Debian for details on DVD support.
Cdrecord-Clone 2.01.01a01 (i686-pc-linux-gnu) Copyright (C) 1995-2004 Jörg Schilling
NOTE: this version of cdrecord is an inofficial (modified) release of cdrecord
and thus may have bugs that are not present in the original version.
Please send bug reports and support requests to <cdrtools@packages.debian.org>.
The original author should not be bothered with problems of this version.
TOC Type: 1 = CD-ROM
Using libscg version 'schily-0.8'.
Driveropts: 'burnfree'
atapi: 1
Device type : Removable CD-ROM
Version : 0
Response Format: 2
Capabilities :
Vendor_info : 'PIONEER '
Identifikation : 'DVD-RW DVR-111D'
Revision : '1.23'



Mais en réalité, soit en utilisant directement hdparm, soi en forçant en dur dans le BIOS le mode DMA et en éditant /etc/hdparm.conf, le résultat est le même : le système est persuadé que mon DMA est activé mais k3b / growisofs me soutient le contraire !


C'est assez original : sur les forums, le gros souci c'est d'activer le DMA, or mon problème va au-delà !!

Ainsi, voilà ce que me renvoie hdparm -v [devices] pour /dev/hdb et /dev/dvd


/dev/hdb:
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 1 (on)
readahead = 8 (on)
HDIO_GETGEO failed: Invalid argument

/dev/dvd:
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 1 (on)
readahead = 8 (on)
HDIO_GETGEO failed: Invalid argume



La curiosité, c'est la dernière ligne : HDIO_GETGEO failed: Invalid argument mais on explique ici que c'est normal pour des lecteurs optiques : hdparm ne trouve pas de géométrie !!
http://lists.debian.org/debian-user-french/2006/06/msg01006.(...)

J'ai jeté aussi un coup d'oeil ici sans amélioration notable :

http://k3b.plainblack.com/faq

(nota : je pense que les conseils prodigués ici sont valables pour un noyau 2.6.x car la syntaxe des options d'hdparm telle que décrite en commentaire de ma version de hdparm.conf me semble légérement différente !).


Au cas où, les lignes pertinentes (?!) de la configuration de mon noyau :


yojik@chéouam:~$ uname -r
2.4.27-3-k7
yojik@chéouam:~$ cat /boot/config-2.4.27-3-k7 | grep DMA
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_PCI_WIP is not set
CONFIG_BLK_DEV_ADMA100=m
# CONFIG_HPT34X_AUTODMA is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_IDEDMA_IVB is not set
# CONFIG_DMA_NONPCI is not set
# CONFIG_SCSI_EATA_DMA is not set
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1
# CONFIG_IEEE1394_SBP2_PHYS_DMA is not set
CONFIG_DMASCC=m
CONFIG_SOUND_ALI5455_CODECSPDIFOUT_CODECINDEPENDENTDMA=y
CONFIG_SOUND_ALI5455_CONTROLLERSPDIFOUT_CONTROLLERINDEPENDENTDMA=y
# CONFIG_SOUND_DMAP is not set



Bref, je cale bien là, mes options sont les suivantes :

1°) j'ai raté quelque chose dans ma configuration noyau !?
2°) il y a un problème lié au matériel (firmware à mettre à jour, problème méca, etc.)
3°) c'est un bug logiciel de la version Sarge de growisofs (malchance : pas de version plus fraîche sur backports pour vérifier ça !).
* growisofs by <appro@fy.chalmers.se>, version 5.21,
front-ending to mkisofs: mkisofs 2.01-unofficial-iconv (i686-pc-linux-gnu)
4°) ????

Merci par avance de tous vos conseils !!


Bonne soirée à tous,

Yojik
  • # Packet writing ?

    Posté par . Évalué à 5.

    Il y a un détail qui me chifonne (comme dirait Columbo), c'est ça :
    Warning: Using ATA Packet interface.
    Warning: The related Linux kernel interface code seems to be unmaintained.

    Le packet writing est la méthode de gravure qui permet de graver un CD comme une disquette (formatage la première fois puis ajout de fichier possible à la volée). Comme l'indique le warning, ce fonctionnement n'est plus vraiment maintenu dans le noyau et n'est peut être pas compatible avec le DMA. Il y a surement une option à la con cochée dans ton K3B qui force ce mode de gravure.

    J'ai exactement le même graveur, je n'ai rien touché et il tourne très bien sous Debian Sid (2.6.18). Regarde si dans les options de gravure il n'y aurait pas une case du genre "packet writing" cochée.

    Bon courage.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.