Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Galère avec le noyau

8 réponses
Avatar
maderios
Bonjour
Ceci concerne Jessie ainsi que les noyaux 3.16/jessie et 4.2/sid.
Sur un portable r=E9cent qui fonctionnait bien avec Jessie, j'ai install=E9=
un dual-boot avec une fedora beta (mise =E0 jour) puis une Sid. J'ai du su=
pprimer ces 2 distro invit=E9es vu les gal=E8res que cela entra=EEnait: plu=
s de r=E9seau et le message ci-dessous en prime. Ensuite, j'ai pens=E9 que =
c'=E9tait un truc d'UUID. Donc j'ai vir=E9 l'option UUID dans grub que j'ai=
remplac=E9e par le classique /dev/xxx. Aucun changement, je suis donc reve=
nu =E0 l'option UUID en les v=E9rifiant avec blkid.=20
Pour r=E9sumer, tout fonctionne sauf le r=E9seau. Ce qui n'emp=EAche pas le=
syst=E8me d'afficher un superbe eth0: link up :(

Oct 27 22:02:41 debconchita kernel: r8169 0000:02:00.1: firmware: direct-lo=
ading firmware rtl_nic/rtl8411-2.fw
Oct 27 22:02:41 debconchita kernel: r8169 0000:02:00.1 eth0: link down
Oct 27 22:02:43 debconchita kernel: r8169 0000:02:00.1 eth0: link up
Oct 27 22:02:56 debconchita kernel: ------------[ cut here ]------------
Oct 27 22:02:56 debconchita kernel: WARNING: CPU: 2 PID: 0 at /build/linux-=
9oV2VH/linux-4.2.3/net/sched/sch_generic.c:303 dev_watchdog+0x231/0x240()
Oct 27 22:02:56 debconchita kernel: NETDEV WATCHDOG: eth0 (r8169): transmit=
queue 0 timed out
Oct 27 22:02:56 debconchita kernel: Modules linked in: cpufreq_stats cpufre=
q_userspace cpufreq_powersave cpufreq_conservative nfsd auth_rpcgss oid_reg=
istry nfs_acl nfs lockd grace fscache sunrpc nls_utf8 nls_cp437 vfat fat x8=
6_pkg_temp_thermal intel_powerclamp intel_rapl coretemp kvm_intel kvm joyde=
v crct10dif_pclmul crc32_pclmul ghash_clmulni_intel sha256_ssse3 sha256_gen=
eric hmac drbg ansi_cprng aesni_intel aes_x86_64 lrw arc4 psmouse gf128mul =
asus_nb_wmi asus_wmi sparse_keymap ath3k mxm_wmi btusb iTCO_wdt btrtl iTCO_=
vendor_support btbcm ath9k btintel ath9k_common bluetooth ath9k_hw evdev at=
h mac80211 pcspkr crc16 glue_helper snd_hda_codec_hdmi serio_raw rtsx_pci_m=
s ablk_helper cryptd cfg80211 rfkill snd_soc_rt5640 snd_soc_rl6231 snd_soc_=
core snd_compress efi_pstore memstick efivars regmap_i2c i915 wmi dw_dmac d=
w_dmac_core
Oct 27 22:02:56 debconchita kernel: snd_soc_sst_acpi drm_kms_helper drm sn=
d_hda_codec_realtek snd_hda_codec_generic i2c_algo_bit battery video proces=
sor_thermal_device int3402_thermal snd_hda_intel intel_soc_dts_iosf snd_hda=
_codec int340x_thermal_zone snd_hda_core snd_hwdep processor i2c_designware=
_platform i2c_designware_core acpi_pad button ac snd_pcm snd_timer iosf_mbi=
snd int3400_thermal acpi_thermal_rel soundcore shpchp i2c_i801 lpc_ich mei=
_me mei fuse parport_pc ppdev lp parport autofs4 xfs libcrc32c hid_generic =
usbhid sg sr_mod cdrom sd_mod rtsx_pci_sdmmc crc32c_intel ahci libahci xhci=
_pci libata xhci_hcd r8169 scsi_mod mii rtsx_pci mfd_core usbcore usb_commo=
n fan thermal thermal_sys i2c_hid sdhci_acpi sdhci hid mmc_core
Oct 27 22:02:56 debconchita kernel: CPU: 2 PID: 0 Comm: swapper/2 Not taint=
ed 4.2.0-1-amd64 #1 Debian 4.2.3-2
Oct 27 22:02:56 debconchita kernel: Hardware name: ASUSTeK COMPUTER INC. X7=
51LB/X751LB, BIOS X751LB.201 01/13/2015
Oct 27 22:02:56 debconchita kernel: 0000000000000000 ffffffff81852d98 ffff=
ffff81548ea6 ffff8801aed03df8
Oct 27 22:02:56 debconchita kernel: ffffffff8106e5a1 0000000000000000 ffff=
8801a492c3e0 ffff8801a492c000
Oct 27 22:02:56 debconchita kernel: 0000000000000002 0000000000000001 ffff=
ffff8106e61a ffffffff81852d58
Oct 27 22:02:56 debconchita kernel: Call Trace:
Oct 27 22:02:56 debconchita kernel: <IRQ> [<ffffffff81548ea6>] ? dump_sta=
ck+0x40/0x50
Oct 27 22:02:56 debconchita kernel: [<ffffffff8106e5a1>] ? warn_slowpath_c=
ommon+0x81/0xb0
Oct 27 22:02:56 debconchita kernel: [<ffffffff8106e61a>] ? warn_slowpath_f=
mt+0x4a/0x50
Oct 27 22:02:56 debconchita kernel: [<ffffffff8101c835>] ? sched_clock+0x5=
/0x10
Oct 27 22:02:56 debconchita kernel: [<ffffffff8147cd81>] ? dev_watchdog+0x=
231/0x240
Oct 27 22:02:56 debconchita kernel: [<ffffffff8147cb50>] ? dev_deactivate_=
queue.constprop.34+0x60/0x60
Oct 27 22:02:56 debconchita kernel: [<ffffffff810ccdb0>] ? call_timer_fn+0=
x30/0xe0
Oct 27 22:02:56 debconchita kernel: [<ffffffff8147cb50>] ? dev_deactivate_=
queue.constprop.34+0x60/0x60
Oct 27 22:02:56 debconchita kernel: [<ffffffff810ce24e>] ? run_timer_softi=
rq+0x16e/0x290
Oct 27 22:02:56 debconchita kernel: [<ffffffff8101c2e5>] ? read_tsc+0x5/0x=
10
Oct 27 22:02:56 debconchita kernel: [<ffffffff8107257e>] ? __do_softirq+0x=
fe/0x250
Oct 27 22:02:56 debconchita kernel: [<ffffffff81072842>] ? irq_exit+0x92/0=
xa0
Oct 27 22:02:56 debconchita kernel: [<ffffffff8155127e>] ? smp_apic_timer_=
interrupt+0x3e/0x50
Oct 27 22:02:56 debconchita kernel: [<ffffffff8154f45b>] ? apic_timer_inte=
rrupt+0x6b/0x70
Oct 27 22:02:56 debconchita kernel: <EOI> [<ffffffff81425bd8>] ? cpuidle_=
enter_state+0xe8/0x220
Oct 27 22:02:56 debconchita kernel: [<ffffffff81425bb3>] ? cpuidle_enter_s=
tate+0xc3/0x220
Oct 27 22:02:56 debconchita kernel: [<ffffffff810aa136>] ? cpu_startup_ent=
ry+0x256/0x310
Oct 27 22:02:56 debconchita kernel: [<ffffffff81047d38>] ? start_secondary=
+0x178/0x1a0
Oct 27 22:02:56 debconchita kernel: ---[ end trace 8890f9b83b76aa5b ]---
Oct 27 22:02:56 debconchita kernel: r8169 0000:02:00.1 eth0: link up
Oct 27 22:09:07 debconchita kernel: r8169 0000:02:00.1 eth0: link up
--=20
maderios

8 réponses

Avatar
Alexandre Hoïde
On Wed, Oct 28, 2015 at 12:05:55AM +0100, maderios wrote:
Bonjour
Ceci concerne Jessie ainsi que les noyaux 3.16/jessie et 4.2/sid. Sur
un portable récent qui fonctionnait bien avec Jessie, j'ai installé un
dual-boot avec une fedora beta (mise à jour) puis une Sid. J'ai du
supprimer ces 2 distro invitées vu les galères que cela entraînait:
plus de réseau et le message ci-dessous en prime. Ensuite, j'ai pensé
que c'était un truc d'UUID. Donc j'ai viré l'option UUID dans grub que
j'ai remplacée par le classique /dev/xxx. Aucun changement, je suis
donc revenu à l'option UUID en les vérifiant avec blkid. Pour
résumer, tout fonctionne sauf le réseau. Ce qui n'empêche pas le
système d'afficher un superbe eth0: link up :(




Salut Madeiros,

C'est peut-être parce que je ne suis pas cap de décoder tes logs du
noyau, mais il me semble que les résultats de :
# ifconfig -a
$ ip r
$ lspci | egrep -i "network|ethernet"

… ainsi qu'un lsmod « | greppé » sur le pilote sensé piloter ta carte
ethernet et/ou wifi, permettraient peut-être de mieux cerner ton
problème ? Et accessoirement de savoir comment tu gères ton réseau
(ifupdown, wicd, network-manager,…) et comment tu l'as
configuré (/etc/network/interfaces, dhcp, resolv.conf, resolvconf, …),
firewall ? Pas obligé de tout balancer, juste qu'on comprenne mieux ce
que ça veut dire « ne fonctionne pas ».

À moins que le bout de log ne soit suffisant pour diagnostiquer ton
problème… là, je ne dirais plus rien.

[Je ne comprends pas le lien que tu fais entre les UUID's et ton
problème réseau ?! pas grave, remarque ]

Et est-ce que l'un des utilitaires utilisés sur les distros supprimées
n'aurait pas bêtement désactivé l'interface (à réactiver avec une touche
de fonction de ton portable) ? Pardon si c'est trop évident… parfois,
quand on a la tête dans le guidon… ^^

--
 ___________________
| $ post_tenebras ↲ |       waouh !
| GNU         /    |      /
|          -- * --  |     o
| $ who ↲    /     |_-- ~_|
| Alexandre Hoïde   |  _/| |
 -------------------
Avatar
maderios
On 10/28/2015 01:21 AM, Alexandre Hoïde wrote:
On Wed, Oct 28, 2015 at 12:05:55AM +0100, maderios wrote:
Bonjour
Ceci concerne Jessie ainsi que les noyaux 3.16/jessie et 4.2/sid. Sur
un portable récent qui fonctionnait bien avec Jessie, j'ai installé un
dual-boot avec une fedora beta (mise à jour) puis une Sid. J'ai du
supprimer ces 2 distro invitées vu les galères que cela entraînait:
plus de réseau et le message ci-dessous en prime. Ensuite, j'ai pensé
que c'était un truc d'UUID. Donc j'ai viré l'option UUID dans grub que
j'ai remplacée par le classique /dev/xxx. Aucun changement, je suis
donc revenu à l'option UUID en les vérifiant avec blkid. Pour
résumer, tout fonctionne sauf le réseau. Ce qui n'empêche pas le
système d'afficher un superbe eth0: link up :(




Salut Madeiros,

C'est peut-être parce que je ne suis pas cap de décoder tes logs du
noyau, mais il me semble que les résultats de :
# ifconfig -a
$ ip r
$ lspci | egrep -i "network|ethernet"


J'ai vérifié hier la conf réseau, aucune anomalie.
J'ai omis de préciser que le réseau était inopérant sur cette machine
aussi bien avec Debian, F23 que W$ (je le conserve pour la garantie). Ce
n'est donc pas un pb de conf logicielle mais plutôt un pb de driver ou
de bios. En redémarrant ce matin, pas de message d'erreur et le réseau
est opérationnel. Il est vrai que j'ai supprimé hier le dualboot avec
Sid/F23. C'était exactement la même configuration hier soir après avoir
réinstallé kernels, grub et rebooté et pourtant le bug persistait.
Il faut croire que l'extinction totale de la machine a provisoirement
réglé le pb. Le mystère reste entier mais je soupçonne le bios qui ne
semble pas très à jour.

--
Maderios
Avatar
Pascal Hambourg
maderios a écrit :
Il faut croire que l'extinction totale de la machine a provisoirement
réglé le pb. Le mystère reste entier mais je soupçonne le bios qui ne
semble pas très à jour.



Grand classique déjà vu. Le BIOS et les drivers ne réinitialisent pas
complètement le contrôleur réseau.
Avatar
maderios
On 10/28/2015 10:00 AM, Pascal Hambourg wrote:
maderios a écrit :
Il faut croire que l'extinction totale de la machine a provisoirement
réglé le pb. Le mystère reste entier mais je soupçonne le bios qui ne
semble pas très à jour.



Grand classique déjà vu. Le BIOS et les drivers ne réinitialisent pas
complètement le contrôleur réseau.



Oui mais quel est le rapport avec le dualboot? C'est bien ce dernier qui
a semé le bazar. Plus précisément, c'est depuis la période où j'ai testé
une fedora 23 beta que le bug est apparu. J'ai ensuite formaté la
partition, copié dessus une Jessie et le bug est réapparu. J'ai supprimé
cette Jessie, reformaté la partition, éteint le PC, redémarré et le bug
a disparu.

--
Maderios
Avatar
maderios
On 10/28/2015 10:17 AM, maderios wrote:
On 10/28/2015 10:00 AM, Pascal Hambourg wrote:
maderios a écrit :
Il faut croire que l'extinction totale de la machine a provisoirement
réglé le pb. Le mystère reste entier mais je soupçonne le bios qui ne
semble pas très à jour.



Grand classique déjà vu. Le BIOS et les drivers ne réinitialisent pas
complètement le contrôleur réseau.



Oui mais quel est le rapport avec le dualboot? C'est bien ce dernier qui
a semé le bazar. Plus précisément, c'est depuis la période où j'ai testé
une fedora 23 beta que le bug est apparu. J'ai ensuite formaté la
partition, copié dessus une Jessie et le bug est réapparu. J'ai supprimé
cette Jessie, reformaté la partition, éteint le PC, redémarré et le bug
a disparu.



La mise à jour du bios de la CM a supprimé le bug. Le dual/trial/etc
boot fonctionne normalement. Merci pour vos suggestions et diagnostics.

--
Maderios
Avatar
Alexandre Hoïde
On Wed, Oct 28, 2015 at 04:52:37PM +0100, maderios wrote:
On 10/28/2015 10:17 AM, maderios wrote:
>On 10/28/2015 10:00 AM, Pascal Hambourg wrote:
>>maderios a écrit :
>>>Il faut croire que l'extinction totale de la machine a provisoirement
>>>réglé le pb. Le mystère reste entier mais je soupçonne le bios qui ne
>>>semble pas très à jour.
>>
>>Grand classique déjà vu. Le BIOS et les drivers ne réinitialisent pas
>>complètement le contrôleur réseau.
>>
>Oui mais quel est le rapport avec le dualboot? C'est bien ce dernier qui
>a semé le bazar. Plus précisément, c'est depuis la période où j'ai testé
>une fedora 23 beta que le bug est apparu. J'ai ensuite formaté la
>partition, copié dessus une Jessie et le bug est réapparu. J'ai supprimé
>cette Jessie, reformaté la partition, éteint le PC, redémarré et le bug
>a disparu.
>
La mise à jour du bios de la CM a supprimé le bug. Le dual/trial/etc boot
fonctionne normalement. Merci pour vos suggestions et diagnostics.



Bon à savoir, je ne connaissais pas ce grand classique là. Pas
l'impression d'avoir été excessivement utile, mais puisque les
remerciements sont adressés à tous : je t'en prie.

--
 ___________________
| $ post_tenebras ↲ |       waouh !
| GNU         /    |      /
|          -- * --  |     o
| $ who ↲    /     |_-- ~_|
| Alexandre Hoïde   |  _/| |
 -------------------
Avatar
maderios
On 10/28/2015 05:41 PM, Alexandre Hoïde wrote:
On Wed, Oct 28, 2015 at 04:52:37PM +0100, maderios wrote:
On 10/28/2015 10:17 AM, maderios wrote:
On 10/28/2015 10:00 AM, Pascal Hambourg wrote:
maderios a écrit :
Il faut croire que l'extinction totale de la machine a provisoirement
réglé le pb. Le mystère reste entier mais je soupçonne le bios qui ne
semble pas très à jour.



Grand classique déjà vu. Le BIOS et les drivers ne réinitialisent pas
complètement le contrôleur réseau.



Oui mais quel est le rapport avec le dualboot? C'est bien ce dernier qui
a semé le bazar. Plus précisément, c'est depuis la période où j'ai testé
une fedora 23 beta que le bug est apparu. J'ai ensuite formaté la
partition, copié dessus une Jessie et le bug est réapparu. J'ai supprimé
cette Jessie, reformaté la partition, éteint le PC, redémarré et le bug
a disparu.



La mise à jour du bios de la CM a supprimé le bug. Le dual/trial/etc boot
fonctionne normalement. Merci pour vos suggestions et diagnostics.



Bon à savoir, je ne connaissais pas ce grand classique là. Pas
l'impression d'avoir été excessivement utile, mais puisque les
remerciements sont adressés à tous : je t'en prie.



Comme il a été écrit plusieurs fois sur cette liste, le principal est de
participer. Par ailleurs, je soupçonne la F23 (fedora bêta de chez bêta
mais intéressante) d'être la principale responsable de la résolution de
ce bug de bios. Juste après son install en dualboot, j'ai eu le droit,
lors du boot, à des messages en cascade concernant des pb d'inodes, une
partition qui n'existerait pas, un freeze, etc... A partir de cet
instant, les multiboots sont devenus plus ou moins foireux.

--
Maderios
Avatar
Pascal Hambourg
maderios a écrit :
On 10/28/2015 10:00 AM, Pascal Hambourg wrote:
maderios a écrit :
Il faut croire que l'extinction totale de la machine a provisoirement
réglé le pb. Le mystère reste entier mais je soupçonne le bios qui ne
semble pas très à jour.


Grand classique déjà vu. Le BIOS et les drivers ne réinitialisent pas
complètement le contrôleur réseau.



Oui mais quel est le rapport avec le dualboot? C'est bien ce dernier qui
a semé le bazar.



Mon interprétation est qu'un des OS a laissé le contrôleur ethernet dans
un état que ni le BIOS ni l'autre OS n'ont été capables de réinitialiser
complètement, et incompatible avec le fonctionnement de l'autre OS.