Problème de Sata - Installation sur Dell PowerEdge R300

[nmaupu]

Bonjour,

je me permet de vous solliciter afin d'essayer de résoudre un problème que je rencontre lors de l'installation d'ipcop 1.4.21 sur un serveur Dell PowerEdge R300.

Dès la première tentative, aucune carte réseaux n'était détectée, le module (tg3) était présent mais trop ancien pour fonctionner. J'ai donc recompiler le bousin pour que l'install detecte enfin mes cartes. Joie de courte durée car à l'écran d'après, j'ai le message "No hard disk found, press OK to reboot".

La faute au controleur SATA (sur lequel le lecteur CDROM est aussi branché et n'est pas détecté non plus) dont le module ne supporte pas le matériel ...


lspci m'informe de la nature des controleurs SATA du système :
00:1f.2 IDE interface [0101]: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 4 port SATA IDE Controller [8086:2920] (rev 02) (prog-if 8f [Master SecP SecO PriP PriO])
00:1f.5 IDE interface [0101]: Intel Corporation 82801I (ICH9 Family) 2 port SATA IDE Controller [8086:2926] (rev 02) (prog-if 85 [Master SecO PriO])


Je pense qu'une fois ce contrôleur correctement configuré, je pense que tout devrait fonctionner.
Si je parviens à faire fonctionner ce controleur sous un kernel 2.4.36 (celui d'ipcop une fois installé), y'a t'il un moyen d'installer sans passer par l'installeur fourni par ipcop ? En effet, je sais recompiler le kernel d'ipcop pour éventuellement prendre en charge le matériel mais je ne sais pas le "déployer" sur la machine en question et booter dessus.

Y'a-t-il un autre moyen plus propre de parvenir à faire détecter le disque par l'installeur (utilisation de modules sur une clé usb par exemple ?)

Merci pour vos éclairages.

[Gesp]

A priori, il faut patcher le driver ata-piix pour que le controleur soit reconnu.

Pour tg3, j'ai vu qu'il y a un driver 3.85l chez Broadcom mais c'est vraiment pas pratique de pas pouvoir charger librement un driver gpl.
Je vais voir si je peux trouver une autre source pour cette version 3.85l (on utilise 3.66d actuellement).

[nmaupu]

D'abord, merci pour ta réponse.

Effectivement la version 1.66d ne supportait pas mes cartes dans mon cas précis.
Par ailleurs j'ai compilé également le driver igb pour le support de la carte PCIe quad port d'intel (Intel Corporation 82575GB Gigabit Network Connection - VendorID=8086, PCI_ID=10d6) présente aussi dans ce serveur. Je n'ai réussi qu'à inclure ce driver dans le kernel final (celui installé sur le système par l'installeur), je suppose donc que cette carte sera reconnue au premier boot si j'arrive à l'installer sur disque (je devrais d'ailleurs modprobe ce module depuis un support usb sur l'install pour voir si j'ai raison).

Pour l'histoire de l'ata_piix, c'est ce que je me suis dit, mais je ne vois pas ce que je dois faire pour obtenir des sources plus récentes ou un patch permettant le support de mon matériel ...

Peux-tu m'en dire un peu plus ?

EDIT : Je viens de vérifier via l'installeur pour les modules des cartes réseaux. Si on monte la clé usb via l'installeur dans /cdrom par exemple et que je spécifie en module réseau /cdrom/igb.o.gz (récupéré sur le site de Intel et compilé manuellement dans un environement ipcop 1.4.21), le module se charge et je suis en mesure d'utiliser la carte réseau intel quad port.
Il me reste donc que le controlleur SATA à faire fonctionner pour enfin réussir à installer cet ipcop

[Gesp]

Pour l'histoire de l'ata_piix, c'est ce que je me suis dit, mais je ne vois pas ce que je dois faire pour obtenir des sources plus récentes ou un patch permettant le support de mon matériel ...

Ce que je fais est de comparer le driver ata_piix en 2.4.36 et 2.6.27.
Le problème est qu'il y a tellement de changements que l'on est à peu près complètement perdu (en fin c'était le cas pour moi avec le driver ahci, pour d'autre c'est plus simple).

Pour mettre à jour uniquement la table des PCI ID, la différence doit être simple à repérer. Ayant le matériel, tu peux au moins tester tes changements.

Pour le driver igb, je me demandais si je devais l'inclure. S'il y a un besoin, je peux le faire.
Si tu as un fichier lfs/igb qui fonctionne, je veux bien une copie.
Normalement tous les modules réseau sont inclus dans l'installeur (et tous les modules sont inclus par défaut à l'installation). Si une carte réseau est built-in, cela va perturber le fonctionnement de l'autodétection des cartes d'interface et éventuellement le comptages des interfaces disponibles pour attribuer eth0, eth1, eth2,...

[nmaupu]

Pour l'histoire de l'ata_piix, c'est ce que je me suis dit, mais je ne vois pas ce que je dois faire pour obtenir des sources plus récentes ou un patch permettant le support de mon matériel ...

Ce que je fais est de comparer le driver ata_piix en 2.4.36 et 2.6.27.
Le problème est qu'il y a tellement de changements que l'on est à peu près complètement perdu (en fin c'était le cas pour moi avec le driver ahci, pour d'autre c'est plus simple).

Pour mettre à jour uniquement la table des PCI ID, la différence doit être simple à repérer. Ayant le matériel, tu peux au moins tester tes changements.

Je vais tester de recompiler le module en ajouter le PCI ID qui va bien pour voir ce qui se passe. Je ne me suis jamais intéressé d'assez près aux modules / drivers d'un kernel et j'imagine que la table des PCI ID présente dans les sources permet au système de dire si un matériel est supporté ou non. Donc si le PCI ID n'est pas spécifié mais que le driver supporte le matériel, le système n'arrivera pas à le detecter, j'ai bon ?

Ensuite, que se passerait-il si je prenais le drivers 2.6.x et que je le compilais dans un 2.4.36 ? Aurait-il une chance que ça fonctionne ?

Pour le driver igb, je me demandais si je devais l'inclure. S'il y a un besoin, je peux le faire.
Si tu as un fichier lfs/igb qui fonctionne, je veux bien une copie.

Je te l'ai mis à la fin du post.

Normalement tous les modules réseau sont inclus dans l'installeur (et tous les modules sont inclus par défaut à l'installation). Si une carte réseau est built-in, cela va perturber le fonctionnement de l'autodétection des cartes d'interface et éventuellement le comptages des interfaces disponibles pour attribuer eth0, eth1, eth2,...

Pourtant, j'ai ajouté le driver igb, j'ai compilé et lors de l'installation, le driver igb n'était pas présent ... Peut-être que j'ai merdé au niveau du déploiement du kernel+miniroot (je boot en pxe). A voir. Ou alors, il y a un autre fichier à éditer avant la compile pour indiquer qu'un module a été ajouté ?


Voici le fichier igb (copier/coller à partir d'un autre).

Code: Tout sélectionner

###############################################################################
# Definitions
###############################################################################

include Config

VER        = 1.2.44.3

THISAPP    = igb-$(VER)
DL_FILE    = $(THISAPP).tar.gz
DL_FROM    = $(URL_SFNET)/igb
DIR_APP    = $(DIR_SRC)/$(THISAPP)
ifeq "$(SMP)" ""
  TARGET     = $(DIR_INFO)/$(THISAPP)
else
  TARGET     = $(DIR_INFO)/$(THISAPP)-smp
endif

###############################################################################
# Top-level Rules
###############################################################################

objects = $(DL_FILE)

$(DL_FILE)                      = $(DL_FROM)/$(DL_FILE)
$(DL_FILE)_MD5                  = a10b591fc616ee560d7c7ce7d454c49e


install : $(TARGET)

check : $(patsubst %,$(DIR_CHK)/%,$(objects))

download :$(patsubst %,$(DIR_DL)/%,$(objects))

md5 : $(subst %,%_MD5,$(objects))

###############################################################################
# Downloading, checking, md5sum
###############################################################################

$(patsubst %,$(DIR_CHK)/%,$(objects)) :
        @$(CHECK)

$(patsubst %,$(DIR_DL)/%,$(objects)) :
        @$(LOAD)

$(subst %,%_MD5,$(objects)) :
        @$(MD5)

###############################################################################
# Installation Details
###############################################################################

$(TARGET) : $(patsubst %,$(DIR_DL)/%,$(objects))
        @$(PREBUILD)
        @rm -rf $(DIR_APP) && cd $(DIR_SRC) && tar zxf $(DIR_DL)/$(DL_FILE)
ifeq "$(SMP)" ""
        # force 2.4 kernel rules, UP/SMP, just build as we don't want time consuming depmod
        cd $(DIR_APP)/src && CFLAGS="$(CFLAGS) -fno-strict-aliasing" make K_VERSION=$(KVER) SMP=0 igb.o
        cd $(DIR_APP)/src && gzip -nf9 igb.o
        install -D -m 644 $(DIR_APP)/src/igb.o.gz /lib/modules/$(KVER)/kernel/drivers/net/igb/igb.o.gz
else
        # force 2.4 kernel rules, UP/SMP, just build as we don't want time consuming depmod
        cd $(DIR_APP)/src && CFLAGS="$(CFLAGS) -fno-strict-aliasing" make K_VERSION=$(KVER) SMP=1 igb.o
        cd $(DIR_APP)/src && gzip -nf9 igb.o
        install -D -m 644 $(DIR_APP)/src/igb.o.gz /lib/modules/$(KVER)-smp/kernel/drivers/net/igb/igb.o.gz
endif
        @rm -rf $(DIR_APP)
        @$(POSTBUILD)

[Gesp]

Je vais tester de recompiler le module en ajouter le PCI ID qui va bien pour voir ce qui se passe. Je ne me suis jamais intéressé d'assez près aux modules / drivers d'un kernel et j'imagine que la table des PCI ID présente dans les sources permet au système de dire si un matériel est supporté ou non. Donc si le PCI ID n'est pas spécifié mais que le driver supporte le matériel, le système n'arrivera pas à le detecter, j'ai bon ?

Pour savoir si un driver supporte un certain matériel, il liste la table des PCI ID du système et compare à une table interne qui comporte ce qu'il connait. C'est cette table interne qu'il n'est souvent pas compliqué d'enrichir.
Dans 90% des cas, ce que le driver connait est une liste de VID/PID (Vendor ID, Product ID) mais dans un petit nombre de cas, un driver supporte toute une classe d'ID, comme par exemple usb-uhci ou usb-ohci.

Il arrive qu'il ne suffise pas de rajouter l'ID pour que cela fonctionne, si par exemple un controleur particulier a besoin d'un traitement spécifique à son démarrage. Dans ce cas, il faut rajouter la partie de code qui a été rajouté en même temps que les ID dans le driver. C'est le cas pas toujours simple.

Relire comment les changements ont été apporté en 2.6 peut être très utile.
A partir de git du noyau 2.6, un git log -p chemin/driver >../monlog permet de suivre l'évolution du driver avec à chaque fois le patch et le commentaire.

Ensuite, que se passerait-il si je prenais le drivers 2.6.x et que je le compilais dans un 2.4.36 ? Aurait-il une chance que ça fonctionne ?

Tu auras juste un tas d'erreur à la compilation dans 99% des cas, surtout pour ce qui concerne les drivers ata. Aucune chance d'arriver à la fin de la compilation sans changement.
Le fait d'avoir le matériel disponible pour tester est un gros plus une fois que la modification compile correctement.

Peut-être que j'ai merdé au niveau du déploiement du kernel+miniroot (je boot en pxe). A voir. Ou alors, il y a un autre fichier à éditer avant la compile pour indiquer qu'un module a été ajouté ?

Je pense que tu as oublié de recompiler la cible drivers.img (celle qui crée l'image incluant les cartes réseau pour l'installeur) ou de mettre à jour l'iso montée sur le serveur http.

[nmaupu]

Je vais tester de recompiler le module en ajouter le PCI ID qui va bien pour voir ce qui se passe. Je ne me suis jamais intéressé d'assez près aux modules / drivers d'un kernel et j'imagine que la table des PCI ID présente dans les sources permet au système de dire si un matériel est supporté ou non. Donc si le PCI ID n'est pas spécifié mais que le driver supporte le matériel, le système n'arrivera pas à le detecter, j'ai bon ?

Pour savoir si un driver supporte un certain matériel, il liste la table des PCI ID du système et compare à une table interne qui comporte ce qu'il connait. C'est cette table interne qu'il n'est souvent pas compliqué d'enrichir.
Dans 90% des cas, ce que le driver connait est une liste de VID/PID (Vendor ID, Product ID) mais dans un petit nombre de cas, un driver supporte toute une classe d'ID, comme par exemple usb-uhci ou usb-ohci.

Il arrive qu'il ne suffise pas de rajouter l'ID pour que cela fonctionne, si par exemple un controleur particulier a besoin d'un traitement spécifique à son démarrage. Dans ce cas, il faut rajouter la partie de code qui a été rajouté en même temps que les ID dans le driver. C'est le cas pas toujours simple.

j'ai naivement ajouté les bons PCI ID dans les sources du 2.4 d'ipcop avec les paramètres d'un autre controller, je m'apprête à recompiler (aaaargl encore cette erreur :

Code: Tout sélectionner

/tools/bin/env: error while loading shared libraries: /lib/libsafe.so.2: file too short

)
Je n'ai trouvé que ./make.sh clean et rebuild pour que ça compile correctement ...

Peut-être que j'ai merdé au niveau du déploiement du kernel+miniroot (je boot en pxe). A voir. Ou alors, il y a un autre fichier à éditer avant la compile pour indiquer qu'un module a été ajouté ?

Je pense que tu as oublié de recompiler la cible drivers.img (celle qui crée l'image incluant les cartes réseau pour l'installeur) ou de mettre à jour l'iso montée sur le serveur http.[/quote]

Ha, je pensais qu'un ./make build aurait suffit

[Gesp]

/tools/bin/env: error while loading shared libraries: /lib/libsafe.so.2: file too short

Je ne sais pas ce que tu as fait. Je n'ai jamais vu cela. Je suppose que tu as voulu recompiler linux-headers ou une autre partie avant stage2.

Si tu ne l'a pas déjà fait, je te conseille d'utiliser la toolchain précompilée, cela permet de gagner un tiers du temps. Soit la compiler soi-même avec ./make.sh clean ./make.sh toolchain, soit la charger depuis sourceforge avec ./make.sh gettoolchain

Je pense que tu as oublié de recompiler la cible drivers.img (celle qui crée l'image incluant les cartes réseau pour l'installeur) ou de mettre à jour l'iso montée sur le serveur http.

Ha, je pensais qu'un ./make build aurait suffit

Les dépendances ne sont pratiquement pas gérées, donc quand quelquechose a changé en amont, il vaut mieux recréer tous les points de compilation de la fin (les *.img, l'installeur,...)

[nmaupu]

/tools/bin/env: error while loading shared libraries: /lib/libsafe.so.2: file too short

Je ne sais pas ce que tu as fait. Je n'ai jamais vu cela. Je suppose que tu as voulu recompiler linux-headers ou une autre partie avant stage2.

Si tu ne l'a pas déjà fait, je te conseille d'utiliser la toolchain précompilée, cela permet de gagner un tiers du temps. Soit la compiler soi-même avec ./make.sh clean ./make.sh toolchain, soit la charger depuis sourceforge avec ./make.sh gettoolchain

J'avais en effet récuperé le toolchain. J'ai tout recompilé malheuresement, mes modifs n'ont pas été prise en compte dans la version finale (je n'ai pas du les faire au bon endroit). J'avais modifié les sources directement dans ./build/usr/src/linux-2.4.36.
Je vais donc tenter de modifier les sources directement depuis l'environement chrooté, de compiler ata_piix en dur et de booter l'install sur ce kernel pour voir ce qui se passe.

Je pense que tu as oublié de recompiler la cible drivers.img (celle qui crée l'image incluant les cartes réseau pour l'installeur) ou de mettre à jour l'iso montée sur le serveur http.

Ha, je pensais qu'un ./make build aurait suffit

Les dépendances ne sont pratiquement pas gérées, donc quand quelquechose a changé en amont, il vaut mieux recréer tous les points de compilation de la fin (les *.img, l'installeur,...)

Ok, c'est bon à savoir.

[nmaupu]

Désolé de double poster mais je pense que la lisibilité en sera améliorée.

J'ai donc tenté dans l'environement chrooté (./make.sh shell) de modifier les sources d'ata_piix.c afin d'ajouter les PCI ID des controllers (2926 et 2920), de recompiler le kernel en mettant en dur l'option scsi > low level drivers > PIIX. J'ai ensuite copié le bzImage obtenu en lieu et place du vmlinuz sur le serveur pxe afin de booter l'install avec ce kernel.
Le problème est toujours le même : pas de disque détecté ...
Demain, je tenterai de modprobe le module ata_piix fraichement compilé séparément sur une clé usb juste au cas où, pour une raison que j'ignore, les modifications n'aient pas été prises en compte ...


Pourrais-tu m'indiquer les chemins des fichiers des sources d'ipcop contenant les sources du kernel utilisées dans l'installeur afin que j'essaie d'ajouter les PCI ID de manière plus propre ?
En effet, je n'ai pas la certitude que le code exécuté contienne bien mes modif ... Par ailleurs est-il possible à partir d'un module compilé d'obtenir une liste de PCI ID compatibles (commande?, astuce?) afin d'être sûr que c'est bien le bon code que j'ai modifié et que je ne passe pas à coté de la solution ?

Le kernel utilisé au boot de l'installeur est-il le même que celui installé sur disque à la fin de l'installation d'ipcop ?

Si tout ça échoue, j'avais aussi pensé à faire une installation sur une autre machine (qui ne pose pas de problème ), de cloner les partitions, de les copier sur le Dell à l'identique et de remplacer le kernel et ses modules par un 2.6.x maison qui supporte mon controller.
Ai-je un quelconque espoir que cela puisse fonctionner ?

Quid d'utiliser la version 2 en dev d'ipcop ?

Merci en tout cas pour l'aide apportée.

[Gesp]

Si tu modifie les sources manuellement, c'est difficile de savoir ce qui est inclu dans l'installeur et l'iso entre une ancienne compilation et la nouvelle.
Il y a 3 compilations du noyau (l'installeur, le noyau UP, le noyau smp) donc il vaut vraiment mieux avoir un patch modifiant les sources à chaque fois plutôt que de faire des modif manuelles.

Toujours faire un patch et insérer son appel dans lfs/linux (pour ce qui concerne le noyau)

Par ailleurs est-il possible à partir d'un module compilé d'obtenir une liste de PCI ID compatibles (commande?, astuce?) afin d'être sûr que c'est bien le bon code que j'ai modifié et que je ne passe pas à coté de la solution ?

Oui une fois que la compilation d'IPCop est finie, un appel à depmod a été fait et il doit y avoir un fichier build/lib/modules/2.4.36/modules.pcimap qui liste les ID supportés des différents modules (pas pour tous les modules mais la pluspart)

Le kernel utilisé au boot de l'installeur est-il le même que celui installé sur disque à la fin de l'installation d'ipcop ?

Non, le noyau de l'installeur a des options différentes pour le rendre plus petit à cause de la contrainte de boot depuis floppy. Mais les même modules sont utilisés, (ceux du noyau non-smp), la compilation du noyau de l'installeur ne compilant pas les modules, que le noyau.

Quid d'utiliser la version 2 en dev d'ipcop ?

Je déconseille sauf s'il s'agit de participer au developpement de cette version tant qu'elle n'est pas passé au moins en version beta.

[nmaupu]

J'ai donc créé un patch de mes modifs pour le fichier drivers/scsi/ata_piix.c que voici :

Code: Tout sélectionner

--- linux/drivers/scsi/ata_piix.c.orig   2008-08-22 16:24:51.000000000 +0200
+++ linux/drivers/scsi/ata_piix.c   2008-08-22 16:32:06.000000000 +0200
@@ -81,6 +81,10 @@
   ich6_sata_rm      = 4,
   ich7_sata      = 5,
   esb2_sata      = 6,
+   
+   /* nmaupu */
+        ich9_sata               = 7,
+        /* end nmaupu */

   PIIX_AHCI_DEVICE   = 6,
};
@@ -119,6 +123,11 @@
   { 0x8086, 0x2825, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich7_sata },
   { 0x8086, 0x2680, PCI_ANY_ID, PCI_ANY_ID, 0, 0, esb2_sata },

+   /* nmaupu */
+        { 0x8086, 0x2920, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich9_sata },
+        { 0x8086, 0x2926, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich9_sata },
+        /* end nmaupu */
+
   { }   /* terminate list */
};

@@ -295,6 +304,21 @@
      .udma_mask   = 0x7f,   /* udma0-6 */
      .port_ops   = &piix_sata_ops,
   },
+
+   /* nmaupu
+           Adding support for ich9_sata controller
+        */
+        /* ich9_sata */
+        {
+                .sht            = &piix_sht,
+                .host_flags     = ATA_FLAG_SATA | ATA_FLAG_SRST |
+                                  PIIX_FLAG_COMBINED | PIIX_FLAG_CHECKINTR |
+                                  ATA_FLAG_SLAVE_POSS | PIIX_FLAG_AHCI,
+                .pio_mask       = 0x1f, /* pio0-4 */
+                .mwdma_mask     = 0x07, /* mwdma0-2 */
+                .udma_mask      = 0x7f, /* udma0-6 */
+                .port_ops       = &piix_sata_ops,
+        },
};

static struct pci_bits piix_enable_bits[] = {


J'ai relancé la compilation des différents kernels (en supprimant au préalable les fichiers de logs ./log/linux-2.4.36*), j'ai gravé le CD et j'ai tenté l'installation. Le CDROM n'était toujours pas reconnu (il est en SATA sur le controller en question

J'ai tout de même tenté de faire un modprobe ata_piix pour être sûr et j'ai toujours l'erreur "No such device"

PS : Le fichier modules.pcimap possède bien mes 2 PCI ID au niveau du module ata_piix ...


EDIT :
J'ai peut-être une ultime piste. Après avoir relu le changelog ipcop 1.4.19 - 1.4.20 qui spécifie que des améliorations ont été faites sur certains chipset ahci sata intel de la famille des ICH9/ICH9R (famille du controller du R300), j'ai été jeter un coup d'oeil aux sources du patch et parmi les PCI ID présents, on trouve des controllers dont les specs sont très voisines. Cependant pas de trace du PCI ID 2920 et 2926 ...
Il serait peut-être bon de les ajouter pour voir si ça passe où pas. Je teste ça lundi

Note : On trouve notamment :
PCI ID 2922 = 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA AHCI Controller
Celui du R300 étant :
PCI ID 2920 = 82801IR/IO/IH (ICH9R/DO/DH) 4 port SATA IDE Controller

Je ne sais pas bien si un controller SATA IDE peut-être utilisé avec un driver AHCI mais bon, on peut toujours tester.