# [kernel] freeze au démarrage

## Adrien

Salut à tous!

J'ai posté depuis bien une semaine sur le forum AMD64 sans obtenir la moindre réponse.   :Crying or Very sad: 

J'éspère avoir plus de chance ici....  :Rolling Eyes: 

De temps en temps (je dirai 2 fois sur 3) sur mon portable, le système freeze au démarrage au moment du dmesg et je suis obligé de faire un hard reboot.

Voici les deux dernières lignes qui apparaissent avant le freeze:

```
ACPI: PCI Interrupt 0000:00:03.3[D] -> GSI 23 (level, low) -> IRQ 19

ehci_hcd 0000:00:03.3: EHCI Host Controller
```

Juste histoire de, j'ai tenté d'enlever le support ehci_hcd du kernel pour voir ce qui se passe et la séquence de boot va un peu plus loin, mais j'ai quand même un freeze à ce moment là:

```
Colplugging PCI devices                      [ok]
```

Enfin, une dernière précision, ce problème apparaît dès que j'utilise un kernel gentoo-sources > 2.6.12-r10. J'utilise en ce moment un 2.6.15-r1 (Enfin, seulement quand ça veut bien booter   :Evil or Very Mad:  )

Quelqu'un verrait-il d'où ça peut venir? C'est très agaçant.

----------

## Trevoke

Bah, Euh. Visiblement, un probleme USB?

Dans ton BIOS, y a pas de problemes d'IRQ?

T'as fait un memtest.. ?

----------

## Adrien

 *Trevoke wrote:*   

> Bah, Euh. Visiblement, un probleme USB?
> 
> Dans ton BIOS, y a pas de problemes d'IRQ?
> 
> T'as fait un memtest.. ?

 

 :Very Happy:   Bah sûrement ! Je vais voir pour le memtest...  :Wink: 

----------

## Adrien

Sachant que j'ai 512Mo de RAM, je dois laisser tourner e memtest combien de temps environ??

Pour l'instant j'en suis à 4 passes et ça fait 1h20 que ça tourne...  :Rolling Eyes:   (aucune erreur BTW)

----------

## Trevoke

Bah, arrete-le alors. Je suis d'avis qu'une passe avec tous les tests suffit amplement.

Tu es en reiser4?

----------

## Adrien

 *Trevoke wrote:*   

> Bah, arrete-le alors. Je suis d'avis qu'une passe avec tous les tests suffit amplement.

 

Merci!   :Smile: 

 *Trevoke wrote:*   

> Tu es en reiser4?

 

resierfs   :Rolling Eyes: 

----------

## Trevoke

Hmmmm.

Tu peux me faire un lspci ?

(d'ailleurs, lspci -v serait mieux)

----------

## Adrien

Monseigneur:

```

00:03.0 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f) (prog-if 10 [OHCI])

        Subsystem: ASUSTeK Computer Inc. Unknown device 1107

        Flags: bus master, medium devsel, latency 64, IRQ 20

        Memory at febff000 (32-bit, non-prefetchable) [size=4K]

```

  :Very Happy: Last edited by Adrien on Mon Jan 23, 2006 7:17 pm; edited 1 time in total

----------

## Trevoke

```
00:03.3 USB Controller: Silicon Integrated Systems [SiS] USB 2.0 Controller (prog-if 20 [EHCI])

        Subsystem: ASUSTeK Computer Inc. Unknown device 1107

        Flags: bus master, medium devsel, latency 64, IRQ 19

        Memory at febfc000 (32-bit, non-prefetchable) [size=4K]

        Capabilities: [50] Power Management version 2 
```

Okay. Hmm. Juste pour voir.. On vit dans une epoque ou l'USB devient necessaire, mais t'as essaye de desactiver le support USB dans le kernel? Il est possible que le port USB aie un probleme...

----------

## Adrien

 *Trevoke wrote:*   

> 
> 
> ```
> 00:03.3 USB Controller: Silicon Integrated Systems [SiS] USB 2.0 Controller (prog-if 20 [EHCI])
> 
> ...

 

Qu'entends tu par USB? ehci_hcd? Si oui, regarde mon premier message. 

Je te pose juste la question parce qu'il y a ohci_hcd ehci_hcd et uhci_hcd etje me souviens jamais lequel sert à quoi...  :Rolling Eyes: 

Edit: A moins que tu ne veuilles que je désactive tout ce qui a rapport avec l'USB

----------

## marvin rouge

Tu as dit que tu avais aussi le problème (parfois) avec coldplug. Si je me souviens bien, coldplug sert à charger les modules au boot en fonction du matos branché. T'as essayé de tout compiler en dur dans le kernel et virer coldplug des runlevels ? (hormis le module nvidia, masi tu le charge via /etc/modules.autoload.d/kernel-2.6)

----------

## Adrien

 *marvin rouge wrote:*   

> Tu as dit que tu avais aussi le problème (parfois) avec coldplug. Si je me souviens bien, coldplug sert à charger les modules au boot en fonction du matos branché. T'as essayé de tout compiler en dur dans le kernel et virer coldplug des runlevels ? (hormis le module nvidia, masi tu le charge via /etc/modules.autoload.d/kernel-2.6)

 

En fait, ce qui se passe, c'est que si je vire l'ehci_hcd du kernel, ça freeze au moment de coldplug. En revanche mon ehci_hcd n'est pas en module. Mon kernel est complètement monolithique, à part les modules qui sont pas inclus dedans (nvidia, madwifi...).

----------

## marvin rouge

Et en supprimant coldplug ?

(dans le cas de figure que tu décris, tu n'en n'as pas besoin, non ?)

----------

## Adrien

 *marvin rouge wrote:*   

> Et en supprimant coldplug ?
> 
> (dans le cas de figure que tu décris, tu n'en n'as pas besoin, non ?)

 

Ben on peut essayer, mais j'ai quand même besoin du support USB 2 quoi...   :Confused: 

----------

## Adrien

 *marvin rouge wrote:*   

> Et en supprimant coldplug ?
> 
> (dans le cas de figure que tu décris, tu n'en n'as pas besoin, non ?)

 

Mais tu parlais de virer ehci_hcd ET hotplug? ou j'ai mal compris?   :Rolling Eyes: 

----------

## marvin rouge

 *Adrien wrote:*   

> Mais tu parlais de virer ehci_hcd ET hotplug? ou j'ai mal compris?  

 Oui, pour séparer les problèmes, et essayer d'y voir plus clair. Mais c'est pas forcément la bonne solution, hein.

----------

## Adrien

 *marvin rouge wrote:*   

>  *Adrien wrote:*   Mais tu parlais de virer ehci_hcd ET hotplug? ou j'ai mal compris?   Oui, pour séparer les problèmes, et essayer d'y voir plus clair. Mais c'est pas forcément la bonne solution, hein.

 

Bon je tenterais le coup de main voir si ça apporte quelque infos supplémentaires.

Merci pour toutes vos suggestions!   :Smile: 

----------

## Adrien

Bon j'ai tenté de mettre ehci-hcd en module et je le charge au démarrage avec /etc/modules.autoload.d/kernel-2.6.

Devinez quoi! Ca freeze au moment du chargement du module!   :Confused: 

Ca en inspire quelques-uns ou pas?

----------

## boozo

'alute

tu as bien les bonnes options dans le kernel ? çà me semble bien venir de là qd m^...   :Confused: 

un exemple chez moi... (après faut que tu vois avec ta config à toi bien entendu)

```
confcat /usr/src/linux/.config | grep USB

CONFIG_SND_USB_AUDIO=y

CONFIG_USB_ARCH_HAS_HCD=y

CONFIG_USB_ARCH_HAS_OHCI=y

CONFIG_USB=y

CONFIG_USB_DEVICEFS=y

CONFIG_USB_EHCI_HCD=y

CONFIG_USB_UHCI_HCD=y

CONFIG_USB_PRINTER=y

CONFIG_USB_STORAGE=y

CONFIG_USB_STORAGE_SDDR09=y

CONFIG_USB_STORAGE_SDDR55=y

CONFIG_USB_HID=y

CONFIG_USB_HIDINPUT=y

CONFIG_USB_MON=y

```

```
confcat /usr/src/linux/.config | grep HCI

CONFIG_IEEE1394_OHCI1394=y

CONFIG_USB_ARCH_HAS_OHCI=y

CONFIG_USB_EHCI_HCD=y

CONFIG_USB_UHCI_HCD=y

```

----------

## Adrien

@ boozo: Ben oui, bien sûr j'ai tout ça (je viens de vérifier). De toute façon, l'USB a toujours bien fonctionné c'est juste quand j'utilise un kernel > 2.6.12-r10.

Vous pensez que ça serait un bug? Ou un problème hardware? Parce qu'avant, jamais aucun problème, mais là ça devint relou...   :Evil or Very Mad: 

----------

## boozo

 *Adrien wrote:*   

> @ boozo: Ben oui, bien sûr j'ai tout ça (je viens de vérifier). De toute façon, l'USB a toujours bien fonctionné c'est juste quand j'utilise un kernel > 2.6.12-r10.
> 
> Vous pensez que ça serait un bug? Ou un problème hardware? Parce qu'avant, jamais aucun problème, mais là ça devint relou...  

 

bô voulais pas te froisser moi   :Sad:   c'est juste que souvent on rate des trucs évidents m^ qd on connait bien...

bon alors soit un bug qui se traine bien... et dans ce cas c'est très probablement déjà rapporté ; soit un pb hardware... qui ne se manifeste pas sur ton vieux noyau... et dans ce cas c'est proche d'un bug kernel donc ce n'est pas un pb de matos   :Rolling Eyes: 

sinon... t'as pas une chèvre qui traine dans le salon ?   :Laughing: 

 :Idea:   z'ont quoi comme noyau les LiveCD BSD de nos jours ? c'est peut-être un moyen de se fixer nan ?

----------

## Adrien

 *boozo wrote:*   

> bô voulais pas te froisser moi  

 

C'est pô toi qui me froisse, c'est cette histoire de kernel à la noix   :Wink: 

 *boozo wrote:*   

> souvent on rate des trucs évidents m^ qd on connait bien...

 

+1 

 *boozo wrote:*   

> sinon... t'as pas une chèvre qui traine dans le salon ?   

 

 :Shocked:   Et pourquoi pas un bouquetin?   :Laughing: 

 *boozo wrote:*   

>    z'ont quoi comme noyau les LiveCD BSD de nos jours ? c'est peut-être un moyen de se fixer nan ?

 

Je te suis pas là...T'as quoi comme idée en tête? Tu crois que le pilote ehci-hcd est le même sur *BSD et nunux?

----------

## marvin rouge

Le seul bug (que j'ai trouvé) sur gentoo-bugzilla qui pourrait ressembler est le 98100. La résolution du problème (dans ce cas) c'est l'upgrade du bios.

Qu'en est il de ton bios ? y'en a de nouvelles versions ? t'as moyen d'upgrader ?

Est-ce le même comportement si tu utilises un kernel à la vanille ?

J'ai trouvé aussi ce bug en cherchant ALL ehci_hcd sur http://bugzilla.kernel.org/ : bug #5788

Si tu reproduis le problème avec un kernel à la vanille, tu peux poser un rapport de bug sur bugzilla.kernel.org, je crois.

+

edit : en gros la question est la suivante: c'est quoi ta carte mère ? est-ce que t'as essayé de passer acpi=off en paramètre du kernel ?

----------

## Adrien

 *marvin rouge wrote:*   

> J'ai trouvé aussi ce bug en cherchant ALL ehci_hcd sur http://bugzilla.kernel.org/ : bug #5788

 

Génial, bon ben c'est exactement mon portable. Je vais voir si je peux faire quelque chose, j'ai pas regardé dernièrement s'il y a des upgrade du BIOS. Je vais aussi tester avec un vanilla. Faut que je voie le acpi=off aussi.

Merci beaucoup marvin!   :Smile:  Je vous tiens au courant.

-- 

NDM : la suite du thread étant sans intérêt, elle est donc partie vers /dev/null.

Enjoy !

----------

## Adrien

Me revoilà!

Bon ben j'ai installé un vanilla-sources-2.6.14.2 avec support ehci-hcd en dur, et le problème s'est reproduit. Je vais donc m'en aller faire un rapport de bug dès que possible...  :Rolling Eyes: 

Sinon, j'ai aussi testé avec acpi=off au démarrage, mais ça ne change rien du tout.

Merci de vos conseils, j'éspère que ça va s'arranger rapidement.

----------

## Adrien

 *marvin rouge wrote:*   

> J'ai trouvé aussi ce bug en cherchant ALL ehci_hcd sur http://bugzilla.kernel.org/ : bug #5788 

 

J'avais pas vu mais dans les commentaires après le bug, un mec dit qu'on peut résoudre le problème en mettant à jour un truc qui s'appelle DSDT.

Quelqu'un peut m'expliquer ce que c'est?   :Rolling Eyes: 

----------

## boozo

 *Adrien wrote:*   

>  *marvin rouge wrote:*   J'ai trouvé aussi ce bug en cherchant ALL ehci_hcd sur http://bugzilla.kernel.org/ : bug #5788  
> 
> J'avais pas vu mais dans les commentaires après le bug, un mec dit qu'on peut résoudre le problème en mettant à jour un truc qui s'appelle DSDT.
> 
> Quelqu'un peut m'expliquer ce que c'est?  

 

tiens t'étais dans l'affaire pourtant   :Razz:   gentoo wiki est en carafe pour l'instant mais le howto y est (google : dsdt + gentoo + wiki)  :Wink: 

----------

## Adrien

 *boozo wrote:*   

> tiens t'étais dans l'affaire pourtant    gentoo wiki est en carafe pour l'instant mais le howto y est (google : dsdt + gentoo + wiki) 

 

Ah bah c'est malin!   :Embarassed: 

Merci boozo!   :Smile: 

----------

## apocryphe

jsuis a mon ecole la mais sur ma gentoo pour les truc irq de ehci jai mi handdle-usb(jsuis pas sur de la commande) je crois dans le truc de grub... si sa peut aider... sinon ba bon couragee

----------

## Adrien

Bon ça y est j'ai décidé de résoudre ce problème une bonne fois pour toutes.

J'ai trouvé une DSDT débuggée pour mon portable (un ASUS A6K) ici.

Et j'ai suivi les HOWTO ici et là (merci boozo):

http://fr.gentoo-wiki.com/HOWTO_Corriger_les_probl%C3%A8mes_courants_li%C3%A9s_%C3%A0_l'ACPI

Donc j'ai compilé la DSDT fixée comme il se doit et le problème se situe quand j'essaie de patcher:

```
razorback linux-2.6.15-gentoo-r4 # patch -p1 < /home/atreyu/ACPI_fix/dsdt_kernel_patch.cgi 

patching file drivers/acpi/osl.c

Hunk #1 succeeded at 25 with fuzz 2.

Hunk #2 FAILED at 209.

1 out of 2 hunks FAILED -- saving rejects to file drivers/acpi/osl.c.rej
```

D'ailleurs, voici le fichier drivers/acpi/osl.c.rej:

```
razorback linux # cat drivers/acpi/osl.c.rej 

***************

*** 208,214 ****

        if (!existing_table || !new_table)

                return AE_BAD_PARAMETER;

  

-       *new_table = NULL;

        return AE_OK;

  }

  

--- 209,216 ----

        if (!existing_table || !new_table)

                return AE_BAD_PARAMETER;

  

+       *new_table = (strncmp(existing_table->signature, DSDT_SIG, 4)) ? NULL \

+                       : (struct acpi_table_header *) AmlCode;

        return AE_OK;

  }
```

Et le contenu du fameux patch:

```
razorback linux # cat /home/atreyu/ACPI_fix/dsdt_kernel_patch.cgi 

--- linux-2.4/drivers/acpi/osl.c        2003/01/14 16:22:32     1.1

+++ linux-2.4/drivers/acpi/osl.c        2003/01/14 16:25:43

@@ -25,6 +25,7 @@

  *

  */

 

+#include <acpi/dsdt_table.h>

 #include <linux/config.h>

 #include <linux/kernel.h>

 #include <linux/slab.h>

@@ -208,7 +209,8 @@

        if (!existing_table || !new_table)

                return AE_BAD_PARAMETER;

 

-       *new_table = NULL;

+       *new_table = (strncmp(existing_table->signature, DSDT_SIG, 4)) ? NULL \

+                       : (struct acpi_table_header *) AmlCode;

        return AE_OK;

 }
```

Le patch en question c'est pour installer la nouvelle DSDT en statique, je préfère ça à l'initrd. A la base il est d'ailleurs prévu pour les kernels 2.4 et supérieurs, mais bon comme on est maintenant loin des 2.4 je me demande si ça convient.

En gros les questions que je me pose c'est:

1- Apparemment le patch échoue. Y-a-t-il un possibilité que la nouvelle DSDT fonctionne quand même?

2- Si cette erreur est un mauvais présage, quelq'un sait-il comment corriger le patch, ou alors, à quel endroit je pourrais en trouver un autre?   :Rolling Eyes: 

----------

## boozo

 *Adrien wrote:*   

> J'ai trouvé une DSDT débuggée pour mon portable (un ASUS A6K) ici. 

 

je ne voudrais pas dire une grosse co******* mais il me semble qu'une dsdt est liée à ta config harware donc si celle-ci est différente de la tienne je ne sais en quoi celà peu jouer exactement   :Confused: 

mais as-tu plutôt essayé de corriger manuellement la tienne avec iasl ? je ne suis pas sur que tu arriveras à régler tous les warning mais les erreurs (s'il y en a) c'est fort probable... kwenspc l'a fait sans dommage sur le sien si je me souviens bien donc tu pourrais peut-être lui demander conseil le cas échéant ?!   :Wink:   ...personnellement je l'ai fait sans soucis particulier mais juste sur des warnning donc c'était pas trop génant pour moi... c'était juste pour le savoir-faire en fait   :Rolling Eyes: 

sinon, pour ce qui est du patch buggé... au pire tu peux toujours modifier le fichier idoine à la main non ?

----------

## Adrien

 *boozo wrote:*   

> il me semble qu'une dsdt est liée à ta config harware donc si celle-ci est différente de la tienne je ne sais en quoi celà peu jouer exactement  

 

Ben si tu veux des précisions sur quoi ça peut jouer, je te conseille le HOWTO de gentoo-wiki, c'est très clair. Par contre, je serais incapable de t'expliquer de mémoire...  :Razz: 

Maintenant, j'ai du mal à te suivre, la DSDT est bien liée à la config hardware, mais c'est pour le même portable donc la même config. Ou bien j'ai pas compris ce que tu veux dire.

 *boozo wrote:*   

> mais as-tu plutôt essayé de corriger manuellement la tienne avec iasl ?

 

Ben non, vu que j'en ai trouvé une déjà corrigée. Je l'ai juste compilée avec iasl en vérifiant qu'il n'y avait pas de mesage d'erreur, et il n'y en avait pas. 

 *boozo wrote:*   

> sinon, pour ce qui est du patch buggé... au pire tu peux toujours modifier le fichier idoine à la main non ?

 

Ca veut dire quoi "idoine"?   :Embarassed: 

----------

## boozo

 *Adrien wrote:*   

> Maintenant, j'ai du mal à te suivre, la DSDT est bien liée à la config hardware, mais c'est pour le même portable donc la même config. Ou bien j'ai pas compris ce que tu veux dire.
> 
>  *boozo wrote:*   mais as-tu plutôt essayé de corriger manuellement la tienne avec iasl ? 
> 
> Ben non, vu que j'en ai trouvé une déjà corrigée. Je l'ai juste compilée avec iasl en vérifiant qu'il n'y avait pas de mesage d'erreur, et il n'y en avait pas. 
> ...

 

possible qu'il s'agisse du même portable mais il n'est évident qu'il contiennent les mêmes composants non ? (tq : ram ; carte graph || son ; ... enfin le cas de Dell par exemple) maintenant moi non plus je n'ai plus le hwto en tête pour te dire si celà pourrait jouer   :Wink: 

en fait tu as recompilé une DSDT qui était déjà corrigée et donc valide de fait mais as-tu tenté de corriger/recompiler la tienne ?   :Wink: 

BTW: idoine <--> adapté ; qui va bien, etc. exple: "une solution idoine"

----------

## Adrien

 *boozo wrote:*   

> en fait tu as recompilé une DSDT qui était déjà corrigée et donc valide de fait mais as-tu tenté de corriger/recompiler la tienne ?   

 

Nan! J'ai tenté d'abord le plus simple, mais si tu insistes et vu que je suis en week-end ce soir!   :Smile: 

 *boozo wrote:*   

> BTW: idoine <--> adapté ; qui va bien, etc. exple: "une solution idoine"

 

Merci!   :Wink: 

Modifier le fichier idoine à la main, je veux bien mais le genre de prose qu'il y a dans le fichier idoine, ça m'est aussi familier que le chinois ancien...  :Rolling Eyes: 

----------

## boozo

j'insiste, j'insiste... bon je dis çà je dis rien ! c'est à toi de voir   :Razz: 

pour le patch kernel si'il cherche le fichier linux-2.4/drivers/acpi/osl.c alors que tu es en 2.6 çà ne m'étonne qu'a 1/2 qu'il ve vautre   :Wink:   regarde sur la version que tu as cad /usr/src/linux/drivers/acpi/osl.c si tu veux faire un patch qui soit générique pour tes futures corrections de noyau ou plus spécifique de cette version avec /usr/src/linux-2.6.15-gentoo-r1/drivers/acpi/osl.c (enfin non je dis une co******* puisque tu patches depuis le repertoire des sources bon enfin tu regardes pour le chemin d'adressage genre linux-2.6.15-gentoo-r1/drivers/acpi/osl.c à mettre en haut du nouveau patch etc...)

bon je m'étale... ensuite tu cherches les lignes à modifier cf @@ si elles existent toujours ou si elles sont toujours au même endroit et tout et tout et puis tu refait ton patch et tu testes   :Wink: 

là j'ai plus le temps mais j'essaye ce soir pour voir...

A+

----------

## Adrien

 *boozo wrote:*   

> j'insiste, j'insiste... bon je dis çà je dis rien ! c'est à toi de voir  
> 
> pour le patch kernel si'il cherche le fichier linux-2.4/drivers/acpi/osl.c alors que tu es en 2.6 çà ne m'étonne qu'a 1/2 qu'il ve vautre    regarde sur la version que tu as cad /usr/src/linux/drivers/acpi/osl.c si tu veux faire un patch qui soit générique pour tes futures corrections de noyau ou plus spécifique de cette version avec /usr/src/linux-2.6.15-gentoo-r1/drivers/acpi/osl.c (enfin non je dis une co******* puisque tu patches depuis le repertoire des sources bon enfin tu regardes pour le chemin d'adressage genre linux-2.6.15-gentoo-r1/drivers/acpi/osl.c à mettre en haut du nouveau patch etc...)
> 
> bon je m'étale... ensuite tu cherches les lignes à modifier cf @@ si elles existent toujours ou si elles sont toujours au même endroit et tout et tout et puis tu refait ton patch et tu testes  
> ...

 

Oki intéressant, ben j'essaie ce soir aussi! Merci à toi!   :Smile: 

----------

## boozo

bon en fait c'est un pb du patch comme mentionné dans ton erreur du reste il fait bien la première modif mais pas la seconde

```
more osl.c.rej

***************

*** 208,214 ****

         if (!existing_table || !new_table)

                 return AE_BAD_PARAMETER;

-        *new_table = NULL;

         return AE_OK;

  }

--- 209,216 ----

         if (!existing_table || !new_table)

                 return AE_BAD_PARAMETER;

+        *new_table = (strncmp(existing_table->signature, DSDT_SIG, 4)) ? NULL \

+                        : (struct acpi_table_header *) AmlCode;

         return AE_OK;

  }

```

bref il ne match pas la 2ème section au bon endroit (les lignes 208-214 et 209-216) donc c'est plus bas maintenant   :Razz: 

Dans le code de osl.c tu as la boucle qu'il cherche (je parle de celle du patch cette fois) qui est shuntée en commentaire (lignes 255-263) donc tu regardes les n° de lignes qui conviennent et tu modifies le patch en fonction en virant kernel-2.4/ ou si tu ne veux pas t'embeter a refaire le patch en bonne et due forme, tu modifies manuellement les lignes et tu ajoutes le include en haut et après ruleeeeeez   :Wink: 

----------

## Adrien

 *boozo wrote:*   

> bref il ne match pas la 2ème section au bon endroit (les lignes 208-214 et 209-216) donc c'est plus bas maintenant  
> 
> Dans le code de osl.c tu as la boucle qu'il cherche (je parle de celle du patch cette fois) qui est shuntée en commentaire (lignes 255-263) donc tu regardes les n° de lignes qui conviennent et tu modifies le patch en fonction en virant kernel-2.4/ ou si tu ne veux pas t'embeter a refaire le patch en bonne et due forme, tu modifies manuellement les lignes et tu ajoutes le include en haut et après ruleeeeeez  

 

J'ai toujours du mal à te suivre. 

De mon côté, j'ai remplacé linux-2.4.x par linux-2.6.15-gentoo-r4 au début du patch mais ça ne marche pas. La première modif passe toujours, mais pas la 2°.

J'éspère que je t'en demandes pas trop, mais tu pourrais m'expliquer un peu plus clairement les deux possibilités que j'ai?

En gros, tu me proposes d'éditer le patch ou alors d'éditer directement le code de osl.c, c'est ça?

Sinon, j'utilises nano comme éditeur de texte, mais ce qui me gêne c'est que je ne sais pas trop comment on peut afficher les n° de lignes ou bien quelle est la commande qu'il faut pour se rendre à une ligne que l'on spécifie par son n°. C'est possible de faire ça avec nano?

----------

## boozo

 *Adrien wrote:*   

> 
> 
> En gros, tu me proposes d'éditer le patch ou alors d'éditer directement le code de osl.c, c'est ça?
> 
> Sinon, j'utilises nano comme éditeur de texte, mais ce qui me gêne c'est que je ne sais pas trop comment on peut afficher les n° de lignes ou bien quelle est la commande qu'il faut pour se rendre à une ligne que l'on spécifie par son n°. C'est possible de faire ça avec nano?

 

oui .  en gros si tu patch directement depuis l'intérieur du repertoire linux-2.6.15-gentoo-r1/ alors tu dois mettre drivers/acpi/osl.c si tu es un cran au dessus alors c'est linux-2.6.15-gentoo-r1/drivers/acpi/osl.c qu'il faut mettre

bon avec nano (-w) c'est pas le plus simple mais tu as la command "Ctrl-unerscore" pour te rendre à la ligne que tu souhaites directement (l'aide commande générale est avec "Ctrl-G") ou plus simple tu prends nedit et tu affiches les n° de lignes   :Wink: 

----------

## Adrien

 *boozo wrote:*   

> oui .  en gros si tu patch directement depuis l'intérieur du repertoire linux-2.6.15-gentoo-r1/ alors tu dois mettre drivers/acpi/osl.c si tu es un cran au dessus alors c'est linux-2.6.15-gentoo-r1/drivers/acpi/osl.c qu'il faut mettre

 

Où avais-je la tête...  :Embarassed:   J'ai même pas fait attention à si j'avais mis le bon path.

 *boozo wrote:*   

> ou plus simple tu prends nedit et tu affiches les n° de lignes  

 

Ouaip, bonne idée, c'est vrai que j'ai jamais utilisé d'éditeur de texte en graphique.   :Rolling Eyes: 

Je vais regarder tout ça.

----------

## boozo

cette attente me tue les nerfs...   :Laughing: 

----------

## Adrien

 *boozo wrote:*   

> cette attente me tue les nerfs...  

 

Attends, déjà je crois avoir capté, c'est pas mal!   :Laughing: 

J'ai édité le code à la main, ça compile...

Edit:  Et merde, ça plante toujours!   :Evil or Very Mad: 

Par contre le noyau a compilé correctement...

Bon ça vaut le coup que j'essaie de corriger ma dsdt buguée moi-même tu crois?

----------

## Adrien

Bon, histoire de faire les choses bien et d'être sûr:

Dans le fichier original, j'ai trouvé ça:

```
[...]

#include <linux/config.h>

#include <linux/module.h>

#include <linux/kernel.h>

[...]

{

   if (!existing_table || !new_table)

      return AE_BAD_PARAMETER;

#ifdef CONFIG_ACPI_CUSTOM_DSDT

   if (strncmp(existing_table->signature, "DSDT", 4) == 0)

      *new_table = (struct acpi_table_header *)AmlCode;

   else

      *new_table = NULL;

#else

   *new_table = NULL;

#endif

   return AE_OK;

}

[...]
```

Que j'ai édité à la main, pour le remplacer par ça:

```
[...]

#include <acpi/dsdt_table.h>

#include <linux/config.h>

#include <linux/module.h>

#include <linux/kernel.h>

[...]

{

   if (!existing_table || !new_table)

      return AE_BAD_PARAMETER;

#ifdef CONFIG_ACPI_CUSTOM_DSDT

   if (strncmp(existing_table->signature, "DSDT", 4) == 0)

      *new_table = (struct acpi_table_header *)AmlCode;

   else

      *new_table = NULL;

#else

           *new_table = (strncmp(existing_table->signature, DSDT_SIG, 4)) ? NULL \

                      : (struct acpi_table_header *) AmlCode;

#endif

   return AE_OK;

}

[...]
```

Puis, j'ai bien sûr mis le fichier dsdt_table.h au bon endroit avant de recompiler le kernel.

C'est correct non?   :Rolling Eyes: 

----------

## boozo

oui çà m'a l'air correct...

 *Adrien wrote:*   

> Bon ça vaut le coup que j'essaie de corriger ma dsdt buguée moi-même tu crois?

 

je crois que c'est ce qu'il y a de mieux à faire en effet surtout que ce n'est pas plus compliqué à faire ; mais demande conseil à des pro de la chose pour arranger tout çà car : quelques erreurs et warning sont documentés dans le how-to mais si tu en as des plus exotiques...   :Confused: 

----------

