Forum général.hors-sujets carte mère HS ?

Posté par  .
Étiquettes : aucune
1
26
nov.
2011

Bonjour les moules,

J'ai depuis quelques jours de petits soucis avec mon pc que je me propose de vous exposer ici:
mercredi de cette semaine, depuis mon boulot (et comme quasiment chaque jour), je me connecte en ssh à ma machine perso pour lancer un yaourt -Syu mais obtiens une erreur d'écriture dans /tmp. Je tente un touch dans /tmp, ~/, faut me rendre à l'évidence, tout est passé en lecture seul.
Ne prenant pas le temps de réfléchir, je reboot à distance ma machine: je n'y aurais plus accès.

De retour chez moi, je constate qu'au reboot la partition /dev/sda3 (mon /) n'a put être monté dans /new_root. Me voilà donc dans un busybox minimal.
Un reboot sur un ctkarch (live cd basé sur arch) plus tard, le fsck.ext4 me parle d'une feature "FEATURE_I15".
e2fsck me dit qu'il y trop vieux pour certaines feature du fs, blablabla...
Un coup de debugfs pour retirer cette feature et fsck est enfin d'accord pour faire un check du FS.
Évidemment, c'est la cata, le bordel, la misère. Bref, pleins d'erreurs (mais corrigé).
Reboot du pc et là, ça démarre normalement et me retrouve sur mon bureau.

Sauf que... pas de réseau.
je passe rapidement sur le contrôleur realtek rtl8168b de ma carte mère et les histoires de module r8169 et r8168. J'utilisais (par défaut) le r8169 pour ce contrôleur sans aucun problème. Mais à présent, mon réseau ne fonctionne qu'avec le r8168 et en forçant le lien à 10Mbit (je suis relié en 100Mbit autonegocié avec une freebox v5 normalement).

si je reste en négociation automatique, voilà l'état du lien:

[peshane@pesharch3 ~]$ while true; do sudo mii-tool eth0; sleep 0.1; done | awk     '{if(/ok$/){ok=ok+1; nok=0; print "ok="ok,"\tnok="nok}else{nok=nok+1; ok=0; print "ok="ok,"\tnok="nok}}'
ok=1    nok=0
ok=2    nok=0
ok=3    nok=0
ok=4    nok=0
ok=0    nok=1
ok=0    nok=2
ok=0    nok=3
ok=0    nok=4
ok=0    nok=5
ok=0    nok=6
ok=0    nok=7
ok=0    nok=8
ok=0    nok=9
ok=0    nok=10
ok=0    nok=11
ok=0    nok=12
ok=0    nok=13
ok=0    nok=14
ok=0    nok=15
ok=0    nok=16
ok=1    nok=0
ok=2    nok=0
ok=3    nok=0
ok=4    nok=0
ok=5    nok=0
ok=6    nok=0
ok=7    nok=0
ok=8    nok=0
ok=0    nok=1
ok=0    nok=2
ok=0    nok=3
ok=0    nok=4
ok=0    nok=5
ok=0    nok=6
ok=0    nok=7
ok=0    nok=8
ok=0    nok=9
ok=0    nok=10
ok=0    nok=11
ok=0    nok=12
ok=0    nok=13
ok=0    nok=14
ok=0    nok=15
ok=0    nok=16
ok=0    nok=17
ok=1    nok=0
ok=2    nok=0
ok=3    nok=0
ok=4    nok=0
ok=5    nok=0
ok=6    nok=0
ok=7    nok=0
ok=0    nok=1
ok=0    nok=2
ok=0    nok=3
ok=0    nok=4
ok=0    nok=5
ok=0    nok=6
ok=0    nok=7
ok=0    nok=8
ok=0    nok=9
ok=0    nok=10
ok=0    nok=11
^C
[peshane@pesharch3 ~]$

Ce problème de lien réseau est également présent durant la POST, donc l'OS ne semble pas en cause.
Vu que le pc tournait et que j'étais un peu interloqué par ce problème réseau, je me penche même pas sur le problème disque précédent.

Donc ok, j'achète une carte ethernet en pci.
Lien ok dès la POST, cool.
De retour sur mon bureau, toujours pas d'internet et de réseau. Ping de la passerelle ko.
Je reforce en 10Mbit, ça fonctionne.

On ne peut donc pas dire que j'ai beaucoup avancé avec cette carte pci.
Je remarque, enfin, que parfois le pc freeze durant un instant plus ou moins long.
En zieutant les logs du kernel, je vois des choses comme ceci:

Nov 25 20:22:38 localhost kernel: [  258.595995] ata1.00: exception Emask 0x10 SAct 0x1 SErr 0x280100 action 0x6 frozen
Nov 25 20:22:38 localhost kernel: [  258.596114] ata1.00: irq_stat 0x08000000, interface fatal error
Nov 25 20:22:38 localhost kernel: [  258.596194] ata1: SError: { UnrecovData 10B8B BadCRC }
Nov 25 20:22:38 localhost kernel: [  258.596271] ata1.00: failed command: READ FPDMA QUEUED
Nov 25 20:22:38 localhost kernel: [  258.596350] ata1.00: cmd 60/00:00:e0:1d:9d/02:00:2f:00:00/40 tag 0 ncq 262144 in
Nov 25 20:22:38 localhost kernel: [  258.596351]          res 40/00:04:e0:1d:9d/00:00:2f:00:00/40 Emask 0x10 (ATA bus error)
Nov 25 20:22:38 localhost kernel: [  258.596565] ata1.00: status: { DRDY }
Nov 25 20:22:38 localhost kernel: [  258.596639] ata1: hard resetting link
Nov 25 20:22:48 localhost kernel: [  268.577425] ata1: softreset failed (1st FIS failed)
Nov 25 20:22:48 localhost kernel: [  268.577512] ata1: hard resetting link
Nov 25 20:22:48 localhost kernel: [  269.063360] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Nov 25 20:22:48 localhost kernel: [  269.075011] ata1.00: configured for UDMA/133
Nov 25 20:22:48 localhost kernel: [  269.086663] ata1: EH complete
Nov 25 20:22:54 localhost kernel: [  274.493172] ata1.00: exception Emask 0x10 SAct 0x1 SErr 0x280100 action 0x6 frozen
Nov 25 20:22:54 localhost kernel: [  274.493291] ata1.00: irq_stat 0x08000000, interface fatal error
Nov 25 20:22:54 localhost kernel: [  274.493370] ata1: SError: { UnrecovData 10B8B BadCRC }
Nov 25 20:22:54 localhost kernel: [  274.493447] ata1.00: failed command: READ FPDMA QUEUED
Nov 25 20:22:54 localhost kernel: [  274.493526] ata1.00: cmd 60/00:00:e0:63:de/02:00:2f:00:00/40 tag 0 ncq 262144 in
Nov 25 20:22:54 localhost kernel: [  274.493527]          res 40/00:04:e0:63:de/00:00:2f:00:00/40 Emask 0x10 (ATA bus error)
Nov 25 20:22:54 localhost kernel: [  274.493741] ata1.00: status: { DRDY }
Nov 25 20:22:57 localhost kernel: [  277.436492] ata1: SATA link down (SStatus 0 SControl 310)
Nov 25 20:23:02 localhost kernel: [  282.428543] ata1: hard resetting link
Nov 25 20:23:20 localhost kernel: [  282.914437] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
Nov 25 20:23:20 localhost kernel: [  282.926034] ata1.00: configured for UDMA/133
Nov 25 20:23:20 localhost kernel: [  282.937688] ata1: EH complete
Nov 25 20:23:20 localhost kernel: [  282.955902] ata1.00: exception Emask 0x50 SAct 0xf SErr 0x280900 action 0x6 frozen
Nov 25 20:23:20 localhost kernel: [  282.956019] ata1.00: irq_stat 0x08000000, interface fatal error
Nov 25 20:23:20 localhost kernel: [  282.956097] ata1: SError: { UnrecovData HostInt 10B8B BadCRC }
Nov 25 20:23:20 localhost kernel: [  282.956175] ata1.00: failed command: READ FPDMA QUEUED
Nov 25 20:23:20 localhost kernel: [  282.956252] ata1.00: cmd 60/00:00:e0:6f:e0/02:00:2f:00:00/40 tag 0 ncq 262144 in
Nov 25 20:23:20 localhost kernel: [  282.956253]          res 40/00:1c:02:23:ca/00:00:01:00:00/40 Emask 0x50 (ATA bus error)
Nov 25 20:23:20 localhost kernel: [  282.956465] ata1.00: status: { DRDY }
Nov 25 20:23:20 localhost kernel: [  282.956535] ata1.00: failed command: WRITE FPDMA QUEUED
Nov 25 20:23:20 localhost kernel: [  282.956612] ata1.00: cmd 61/08:08:9a:38:6a/00:00:03:00:00/40 tag 1 ncq 4096 out
Nov 25 20:23:20 localhost kernel: [  282.956613]          res 40/00:1c:02:23:ca/00:00:01:00:00/40 Emask 0x50 (ATA bus error)
Nov 25 20:23:20 localhost kernel: [  282.956824] ata1.00: status: { DRDY }
Nov 25 20:23:20 localhost kernel: [  282.956894] ata1.00: failed command: WRITE FPDMA QUEUED
Nov 25 20:23:20 localhost kernel: [  282.956971] ata1.00: cmd 61/20:10:b2:68:87/00:00:01:00:00/40 tag 2 ncq 16384 out
Nov 25 20:23:20 localhost kernel: [  282.956972]          res 40/00:1c:02:23:ca/00:00:01:00:00/40 Emask 0x50 (ATA bus error)
Nov 25 20:23:20 localhost kernel: [  282.957183] ata1.00: status: { DRDY }
Nov 25 20:23:20 localhost kernel: [  282.957254] ata1.00: failed command: WRITE FPDMA QUEUED
Nov 25 20:23:20 localhost kernel: [  282.957331] ata1.00: cmd 61/08:18:02:23:ca/00:00:01:00:00/40 tag 3 ncq 4096 out
Nov 25 20:23:20 localhost kernel: [  282.957332]          res 40/00:1c:02:23:ca/00:00:01:00:00/40 Emask 0x50 (ATA bus error)
Nov 25 20:23:20 localhost kernel: [  282.957543] ata1.00: status: { DRDY }
Nov 25 20:23:20 localhost kernel: [  282.957621] ata1: hard resetting link

smartctl, pour ce que ça vaut:

[peshane@pesharch3 ~]$ sudo smartctl -H /dev/sda
smartctl 5.42 2011-10-20 r3458 [x86_64-linux-3.1.2-1-ARCH] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

Là j'écris depuis ce même pc souffre-tant dont le log kernel ne m'indique pour l'instant aucun problème disque mais pendant combien de temps...
Qu'en pensez-vous ?

  • # facile

    Posté par  . Évalué à 1.

    C'est le câble réseau.
    a+

    • [^] # Re: facile

      Posté par  . Évalué à 2.

      C'est vrai que mon récit passe un peu vite sur le problème réseau.

      J'ai testé avec un autre câble, les autres ports de la freebox (et de la rebooter), j'ai également testé le lien avec un routeur linksys wrt54gc sans plus de succès.

      • [^] # de retour sur le souci réseau

        Posté par  . Évalué à -1.

        je ne sais pas si ça peut aider les plus perspicaces d'entre vous mais lorsque mon pc mourant est en 100 Mbit et que je lance un tcpdump arp sur un autre pc du lan, j'obtiens ça:

        21:46:45.790950 ARP, Request who-has 192.168.1.128 tell 192.168.1.254, length 48
21:46:46.790928 ARP, Request who-has 192.168.1.128 tell 192.168.1.254, length 48
21:46:47.790933 ARP, Request who-has 192.168.1.128 tell 192.168.1.254, length 48
21:46:48.840229 ARP, Request who-has 192.168.1.128 tell 192.168.1.254, length 48
21:46:49.838947 ARP, Request who-has 192.168.1.128 tell 192.168.1.254, length 48
21:46:50.838961 ARP, Request who-has 192.168.1.128 tell 192.168.1.254, length 48
21:46:53.395013 ARP, Request who-has 192.168.1.128 tell 192.168.1.254, length 48
21:46:53.726293 ARP, Request who-has 192.168.1.254 (ff:ff:ff:ff:ff:ff) tell 192.168.1.128, length 46
21:46:54.726444 ARP, Request who-has 192.168.1.254 (ff:ff:ff:ff:ff:ff) tell 192.168.1.128, length 46
21:46:55.726569 ARP, Request who-has 192.168.1.254 (ff:ff:ff:ff:ff:ff) tell 192.168.1.128, length 46

        ma freebox demande qui est 192.168.1.128 (mon pc mourant).
        les 3 derniers sont un arping depuis le pc mourant qui est bien reçu par l'autre pc.

        Si je fait un arping vers 192.168.1.123 (mon deuxième pc), alors vu du deuxième pc:

        21:54:14.859469 ARP, Request who-has 192.168.1.123 (ff:ff:ff:ff:ff:ff) tell 192.168.1.128, length 46
21:54:14.859484 ARP, Reply 192.168.1.123 is-at 00:19:66:fd:9e:6b, length 28
21:54:15.859580 ARP, Request who-has 192.168.1.123 (ff:ff:ff:ff:ff:ff) tell 192.168.1.128, length 46
21:54:15.859595 ARP, Reply 192.168.1.123 is-at 00:19:66:fd:9e:6b, length 28
21:54:16.859705 ARP, Request who-has 192.168.1.123 (ff:ff:ff:ff:ff:ff) tell 192.168.1.128, length 46
21:54:16.859722 ARP, Reply 192.168.1.123 is-at 00:19:66:fd:9e:6b, length 28

        alors que le pc en souffrance ne reçoit aucune réponse:

        21:54:14.700514 ARP, Request who-has 192.168.1.123 (ff:ff:ff:ff:ff:ff) tell 192.168.1.128, length 28
21:54:15.700619 ARP, Request who-has 192.168.1.123 (ff:ff:ff:ff:ff:ff) tell 192.168.1.128, length 28
21:54:16.700749 ARP, Request who-has 192.168.1.123 (ff:ff:ff:ff:ff:ff) tell 192.168.1.128, length 28

        évidement, dès que je passe à 10 Mbit, tout est ok.

  • # Negociation SATA

    Posté par  (site web personnel) . Évalué à 6.

    Il y a quelques temps, depuis le passage dans les derniers kernel 2.6 (je suis en Debian Testing, donc cela évolue régulièrement), j'ai moi aussi vu ce genre de messages lier au disque dur.

    Le problème ne vient pas du disque, mais de la manière dont le kernel négocie la vitesse du contrôleur SATA(/PATA). Cela se configure en passant des paramètres au kernel ( http://www.kernel.org/doc/Documentation/kernel-parameters.txt ).

    Ce n'est pas super évident à analyser, et il faut faire des tests "jusque cela marche". Avec évidement un reboot pour chaque tests... :=(

    Voici les différents combinaisons que j'ai utilisé:
    libata.force=noncq
    libata.force=noncq,1.5Gbps
    libata.force=noncq,3.0Gbps
    libata.noacpi
    acpi=noirq
    acpi=off

    La dernière option est un peu une "arme atomique" qui bride pas mal la machine (les modes hibernation/suspend ne marcherons par exemple plus). Mais elle a au moins eu le mérite de marcher dans les conditions les moins favorables.

    Plus d'informations ici : http://ubuntuforums.org/showthread.php?t=1014723

    Pour info, c'est bien un problème de kernel. En boutant la machine sur un kernel plus ancien, le problème n'apparaît plus. De plus, le problème apparaît sur différentes machines, plus ou moins anciennes, laptop ou desktop.

    • [^] # Re: Negociation SATA

      Posté par  . Évalué à 0. Dernière modification le 27 novembre 2011 à 16:32.

      étrangement, je n'ai plus de trace du disque dans les logs depuis que j'ai essayé de brancher mon disque sur un autre port SATA (mais le disque n'était alors plus vu lors de la POST donc je l'ai remis sur le port 1).

      Par contre, je viens de découvrir ça dans les logs:

      Nov 27 12:27:41 localhost kernel: [55608.577053] ------------[ cut here ]------------
Nov 27 12:27:41 localhost kernel: [55608.577063] WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0x257/0x260()
Nov 27 12:27:41 localhost kernel: [55608.577067] Hardware name: System Product Name
Nov 27 12:27:41 localhost kernel: [55608.577070] NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out
Nov 27 12:27:41 localhost kernel: [55608.577073] Modules linked in: r8169 mii fuse ipv6 ext2 snd_hda_codec_hdmi snd_hda_codec_via nvidia(P) snd_hda_intel snd_hda_codec snd_hwdep snd_pcm firewire_ohci snd_timer firewire_core snd soundcore evdev crc_itu_t iTCO_wdt pcspkr i7core_edac edac_core psmouse serio_raw iTCO_vendor_support i2c_i801 snd_page_alloc i2c_core asus_atk0110 processor button ext4 mbcache jbd2 crc16 pata_acpi sd_mod pata_jmicron ahci libahci libata ehci_hcd scsi_mod usbcore [last unloaded: mii]
Nov 27 12:27:41 localhost kernel: [55608.577126] Pid: 0, comm: swapper Tainted: P          I 3.1.2-1-ARCH #1
Nov 27 12:27:41 localhost kernel: [55608.577129] Call Trace:
Nov 27 12:27:41 localhost kernel: [55608.577132]  <IRQ>  [<ffffffff81061b9f>] warn_slowpath_common+0x7f/0xc0
Nov 27 12:27:41 localhost kernel: [55608.577147]  [<ffffffff8122c684>] ? timerqueue_add+0x74/0xc0
Nov 27 12:27:41 localhost kernel: [55608.577153]  [<ffffffff81061c96>] warn_slowpath_fmt+0x46/0x50
Nov 27 12:27:41 localhost kernel: [55608.577159]  [<ffffffff81094d92>] ? clockevents_program_event+0x62/0xa0
Nov 27 12:27:41 localhost kernel: [55608.577165]  [<ffffffff813642c7>] dev_watchdog+0x257/0x260
Nov 27 12:27:41 localhost kernel: [55608.577171]  [<ffffffff81071e61>] run_timer_softirq+0x131/0x440
Nov 27 12:27:41 localhost kernel: [55608.577176]  [<ffffffff81364070>] ? qdisc_reset+0x50/0x50
Nov 27 12:27:41 localhost kernel: [55608.577184]  [<ffffffff810691c0>] __do_softirq+0xb0/0x270
Nov 27 12:27:41 localhost kernel: [55608.577188]  [<ffffffff8140c6ac>] call_softirq+0x1c/0x30
Nov 27 12:27:41 localhost kernel: [55608.577191]  [<ffffffff81016a15>] do_softirq+0x65/0xa0
Nov 27 12:27:41 localhost kernel: [55608.577193]  [<ffffffff810696ce>] irq_exit+0x9e/0xc0
Nov 27 12:27:41 localhost kernel: [55608.577195]  [<ffffffff8140cf63>] do_IRQ+0x63/0xe0
Nov 27 12:27:41 localhost kernel: [55608.577198]  [<ffffffff81409bae>] common_interrupt+0x6e/0x6e
Nov 27 12:27:41 localhost kernel: [55608.577199]  <EOI>  [<ffffffff8108a71d>] ? notifier_call_chain+0x4d/0x70
Nov 27 12:27:41 localhost kernel: [55608.577205]  [<ffffffff81279eab>] ? intel_idle+0xcb/0x120
Nov 27 12:27:41 localhost kernel: [55608.577207]  [<ffffffff81279e8d>] ? intel_idle+0xad/0x120
Nov 27 12:27:41 localhost kernel: [55608.577210]  [<ffffffff8131d6a6>] cpuidle_idle_call+0xc6/0x350
Nov 27 12:27:41 localhost kernel: [55608.577212]  [<ffffffff81013229>] cpu_idle+0xc9/0x120
Nov 27 12:27:41 localhost kernel: [55608.577216]  [<ffffffff813e6862>] rest_init+0x96/0xa4
Nov 27 12:27:41 localhost kernel: [55608.577218]  [<ffffffff8194fc15>] start_kernel+0x3bf/0x3cc
Nov 27 12:27:41 localhost kernel: [55608.577221]  [<ffffffff8194f347>] x86_64_start_reservations+0x132/0x136
Nov 27 12:27:41 localhost kernel: [55608.577223]  [<ffffffff8194f140>] ? early_idt_handlers+0x140/0x140
Nov 27 12:27:41 localhost kernel: [55608.577225]  [<ffffffff8194f44d>] x86_64_start_kernel+0x102/0x111
Nov 27 12:27:41 localhost kernel: [55608.577227] ---[ end trace a7919e7f17c0a727 ]---

      A ce moment là, j'étais entrain de tester différentes combinaison de vitesse et de duplex. A noter qu'en retournant à 10Mbits full duplex, cette fois-ci cela ne fonctionnait plus et j'ai du rebooter la machine pour à nouveau récupérer le réseau en 10Mbits full.

      Pour en revenir au disque, finalement smartctl indique quand même quelques bricoles:

      SMART Error Log Version: 1
ATA Error Count: 185 (device log contains only the most recent five errors)
        CR = Command Register [HEX]
        FR = Features Register [HEX]
        SC = Sector Count Register [HEX]
        SN = Sector Number Register [HEX]
        CL = Cylinder Low Register [HEX]
        CH = Cylinder High Register [HEX]
        DH = Device/Head Register [HEX]
        DC = Device Command Register [HEX]
        ER = Error register [HEX]
        ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error 185 occurred at disk power-on lifetime: 7504 hours (312 days + 16 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  84 51 00 00 00 00 a0

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  ec 00 00 00 00 00 a0 08      00:00:00.958  IDENTIFY DEVICE
  ef 03 42 00 00 00 a0 08      00:00:00.958  SET FEATURES [Set transfer mode]
  ef 10 02 00 00 00 a0 08      00:00:00.958  SET FEATURES [Reserved for Serial ATA]
  27 00 00 00 00 00 e0 08      00:00:00.958  READ NATIVE MAX ADDRESS EXT
  ec 00 00 00 00 00 a0 08      00:00:00.958  IDENTIFY DEVICE

Error 184 occurred at disk power-on lifetime: 7504 hours (312 days + 16 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  84 51 00 00 00 00 a0

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  ec 00 00 00 00 00 a0 08      00:00:00.947  IDENTIFY DEVICE
  ef 03 42 00 00 00 a0 08      00:00:00.947  SET FEATURES [Set transfer mode]
  ef 10 02 00 00 00 a0 08      00:00:00.947  SET FEATURES [Reserved for Serial ATA]
  27 00 00 00 00 00 e0 08      00:00:00.947  READ NATIVE MAX ADDRESS EXT
  ec 00 00 00 00 00 a0 08      00:00:00.947  IDENTIFY DEVICE

Error 183 occurred at disk power-on lifetime: 7504 hours (312 days + 16 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  84 51 00 00 00 00 a0

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  ec 00 00 00 00 00 a0 08      00:00:00.925  IDENTIFY DEVICE
  00 10 00 00 00 00 00 08      00:00:00.925  NOP [Reserved subcommand]
  00 00 00 00 00 00 00 08      00:00:00.925  NOP [Abort queued commands]
  00 00 00 00 00 00 00 08      00:00:00.925  NOP [Abort queued commands]
  00 00 08 90 52 4c 40 08      00:00:00.915  NOP [Abort queued commands]

Error 182 occurred at disk power-on lifetime: 7504 hours (312 days + 16 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  84 51 00 00 00 00 a0

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  ec 00 00 00 00 00 a0 08      00:00:00.841  IDENTIFY DEVICE
  ef 03 42 00 00 00 a0 08      00:00:00.841  SET FEATURES [Set transfer mode]
  ef 10 02 00 00 00 a0 08      00:00:00.841  SET FEATURES [Reserved for Serial ATA]
  27 00 00 00 00 00 e0 08      00:00:00.841  READ NATIVE MAX ADDRESS EXT
  ec 00 00 00 00 00 a0 08      00:00:00.841  IDENTIFY DEVICE

Error 181 occurred at disk power-on lifetime: 7504 hours (312 days + 16 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  84 51 00 00 00 00 a0

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  ec 00 00 00 00 00 a0 08      00:00:00.812  IDENTIFY DEVICE
  00 00 e0 00 70 e0 40 08      00:00:00.812  NOP [Abort queued commands]
  00 00 08 f0 6f e0 40 08      00:00:00.812  NOP [Abort queued commands]
  60 00 08 f0 6f e0 40 08      00:00:00.807  READ FPDMA QUEUED
  60 90 08 f0 6f e0 40 08      00:00:00.812  READ FPDMA QUEUED

      ça donne l'impression d'un problème de lien SATA mais je n'en suis pas certain. En plus, depuis que j'ai tripoter un peu le cable SATA, j'ai plus plus rien dans les logs par rapport au disque.

      Mais je reste persuadé qu'il y a un lien avec mon problème réseau. Les points communs que je voit sont:
      - le southbridge
      * contrôleur réseau intégré qui ne fait plus de link en 100Mbits mais ok en 10Mbits
      * contrôleur réseau en pci qui link en 100Mbits mais qui ne peut rien pinger même dans le lan (unreachable) sauf en 10Mbits (et à condition manifestement de ne pas trop le faire switcher de vitesse)
      * problème d'accès disque
      - l'alimentation
      * une faiblesse de l'alimentation pourrait également être une explication à mes problèmes mais les tensions sont ok.

      • [^] # Re: Negociation SATA

        Posté par  . Évalué à 2.

        ton disque que tu ne vois plus dans le "POST" en changeant de port
        => verifie dans le BIOS que tes ports SATA sont reglés sur "auto" et pas sur "disabled"
        car sinon, il n'est pas vu au POST
        et parfois pas vu sous linux (mais là ca depend du driver)

      • [^] # Re: Negociation SATA

        Posté par  (site web personnel) . Évalué à 3.

        D'après les logs, c'est le module réseau qui a crashé.

        Outre un problème lié au code source du driver dans le kernel Linux, le problème est peut-être purement hardware.

        L'année dernière, je m'étais acheté une carte réseau gigabyte PCI-expresse pas chère du tout sur eBay. Je me suis rapidement rendu compte que cela rendait le kernel super instable (crash), et aussi que le chipset principale de la carte chauffait beaucoup. Il y n'y avait pas de dissipateur thermique dessus, ce qui explique peut-être les problèmes. En tout cas, j'ai rapidement retiré la carte de ma machine, et depuis, plus de problème.

        Par hasard, est-ce que les chipsets north/southbridge ne chauffent pas trop ? Ou alors, un composé commence a vieillir sur la machine (un condensateur par exemple, ce qui fait planter la partie réseau).

        Peux-tu désactiver cette carte réseau, et en utiliser une autre ?

        • [^] # Re: Negociation SATA

          Posté par  . Évalué à 0.

          c'est à dire qu'il s'agit déjà d'une carte réseau pci que j'ai acheter suite à mon problème précédent:
          - flapping du lien en négociation auto (quelques soit le câble, sur ma freebox v5 et un routeur linksys): en boucle, lien pendant 0.8s, pas de lien pendant 1,7s.
          - lien possible uniquement en forçant le lien à 10Mbit.

          J'ai donc tenté le coup de m'acheter une carte ethernet en pci et constate aujourd’hui ceci:
          - autonégo ok à 100Mbit mais "destination host unreachable"
          - réseau ok une fois forcé à 10Mbit

          L'ensemble des problèmes (disque et réseau) me fait en effet penser à un problème matériel.
          Du reste, sur ce même pc qui sent le sapin, j'ai joué plusieurs heures à Skyrim sans que la machine sourcille. Bon wine et/ou le jeu ont plantés plusieurs fois mais rien d’anormal dans les logs systèmes suite à ce mini stress test de la machine.

  • # Conclusion ... ?

    Posté par  . Évalué à 0.

    Alors finalement, j'ai racheté une carte mère (le même modèle d'ailleurs) et tout va bien à présent. Fin de l'histoire... j'espère!

Suivre le flux des commentaires

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