My Own Made Little World

HPET : faire de sa bête de course une machine à freeze

Fabien — Fri, 27 May 2011 14:40:00 +0200

Symptôme : vous êtes sur votre bête de course (sous GNU Linux bien entendu) et vous copiez, chargez des gros fichiers. Puis, plus rien, l'écran se fige. Plus aucun périphérique ne réponds (clavier, souris, etc). Super, vous êtes tombé sur le Freeze machine comme on les aime. Par voie de conséquence, je fais un premier hard reboot explosif.

Cela faisait une éternité (genre + de 3 ans) que je n'ai pas réussi à geler une machine personnelle (hors celles de développement -_-). Je recommence la copie et BAM refreeze au bout d'1 à 2 minutes. (2ème Hard Reboot mode explosif)

Les lockups sont difficiles à cerner car généralement nous ne savons par où commencer. Comme tout à chacun, j'ai commencé par blâmer les disques et les systèmes de fichier. Du coup, je passe en mode secours "MacGyver" avec le Live CD et la commande e2fsck pour traquer l'anomalie sur les systèmes de fichiers mais rien. Fausse piste.

Du côté du journal d'événement, rien de miraculeux (attention c'est un peu verbeux) :

Les 5 premières secondes particulièrement pompeuses ont été retirées

May 27 11:42:35 home01 kernel: [    5.447313] usb usb10: No SuperSpeed endpoint companion for config 1 interface 0 altsetting 0 ep 129: using minimum values
May 27 11:42:35 home01 kernel: [    5.447404] xHCI xhci_add_endpoint called for root hub
May 27 11:42:35 home01 kernel: [    5.447409] xHCI xhci_check_bandwidth called for root hub
May 27 11:42:35 home01 kernel: [    5.447436] hub 10-0:1.0: USB hub found
May 27 11:42:35 home01 kernel: [    5.447440] hub 10-0:1.0: 4 ports detected
May 27 11:42:35 home01 kernel: [    5.500394] hda_codec: ALC889: BIOS auto-probing.
May 27 11:42:35 home01 kernel: [    5.509177] input: HDA Intel Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input5
May 27 11:42:35 home01 kernel: [    5.509276] HDA Intel 0000:01:00.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
May 27 11:42:35 home01 kernel: [    5.509278] hda_intel: Disable MSI for Nvidia chipset
May 27 11:42:35 home01 kernel: [    5.509313] HDA Intel 0000:01:00.1: setting latency timer to 64
May 27 11:42:35 home01 kernel: [    5.544666] EXT4-fs (sda1): warning: maximal mount count reached, running e2fsck is recommended
May 27 11:42:35 home01 kernel: [    5.557815] EXT4-fs (sda1): recovery complete
May 27 11:42:35 home01 kernel: [    5.567065] EXT4-fs (sda1): mounted filesystem with writeback data mode. Opts: data=writeback
May 27 11:42:35 home01 kernel: [    5.702843] type=1400 audit(1306489355.878:5): apparmor="STATUS" operation="profile_load" name="/usr/share/gdm/guest-session/Xsession" pid=948 comm="apparmor_parser"
May 27 11:42:35 home01 kernel: [    5.703854] type=1400 audit(1306489355.888:6): apparmor="STATUS" operation="profile_load" name="/usr/lib/cups/backend/cups-pdf" pid=952 comm="apparmor_parser"
May 27 11:42:35 home01 kernel: [    5.706014] type=1400 audit(1306489355.888:7): apparmor="STATUS" operation="profile_load" name="/usr/sbin/cupsd" pid=952 comm="apparmor_parser"
May 27 11:42:35 home01 kernel: [    5.706052] type=1400 audit(1306489355.888:8): apparmor="STATUS" operation="profile_replace" name="/sbin/dhclient" pid=949 comm="apparmor_parser"
May 27 11:42:35 home01 kernel: [    5.706585] type=1400 audit(1306489355.888:9): apparmor="STATUS" operation="profile_replace" name="/usr/lib/NetworkManager/nm-dhcp-client.action" pid=949 comm="apparmor_parser"
May 27 11:42:35 home01 kernel: [    5.706934] type=1400 audit(1306489355.888:10): apparmor="STATUS" operation="profile_replace" name="/usr/lib/connman/scripts/dhclient-script" pid=949 comm="apparmor_parser"
May 27 11:42:35 home01 kernel: [    5.764488] r8169 0000:06:00.0: eth0: link down
May 27 11:42:35 home01 kernel: [    5.764498] r8169 0000:06:00.0: eth0: link down
May 27 11:42:35 home01 kernel: [    5.764999] ADDRCONF(NETDEV_UP): eth0: link is not ready
May 27 11:42:36 home01 kernel: [    5.856723] vboxdrv: Found 8 processor cores.
May 27 11:42:36 home01 kernel: [    5.856919] vboxdrv: fAsync=0 offMin=0x1de offMax=0x427e
May 27 11:42:36 home01 kernel: [    5.856962] vboxdrv: TSC mode is 'synchronous', kernel timer mode is 'normal'.
May 27 11:42:36 home01 kernel: [    5.856964] vboxdrv: Successfully loaded version 4.0.4_OSE (interface 0x00160000).
May 27 11:42:36 home01 kernel: [    6.033727] EXT4-fs (sdb3): Ignoring deprecated nobh option
May 27 11:42:36 home01 kernel: [    6.033741] EXT4-fs (sdb3): re-mounted. Opts: data=writeback,barrier=0,nobh,errors=remount-ro,commit=0
May 27 11:42:36 home01 kernel: [    6.035912] EXT4-fs (sda1): re-mounted. Opts: data=writeback,commit=0
May 27 11:42:38 home01 kernel: [    7.941778] nvidia 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
May 27 11:42:38 home01 kernel: [    7.941789] nvidia 0000:01:00.0: setting latency timer to 64
May 27 11:42:38 home01 kernel: [    7.941793] vgaarb: device changed decodes: PCI:0000:01:00.0,olddecodes=io+mem,decodes=none:owns=io+mem
May 27 11:42:38 home01 kernel: [    7.941925] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 270.41.06 Mon Apr 18 14:53:56 PDT 2011
May 27 11:42:38 home01 kernel: [    7.975030] vesafb: framebuffer at 0xed000000, mapped to 0xffffc90008580000, using 1216k, total 1216k
May 27 11:42:38 home01 kernel: [    7.975034] vesafb: mode is 640x480x32, linelength=2560, pages=0
May 27 11:42:38 home01 kernel: [    7.975035] vesafb: scrolling: redraw
May 27 11:42:38 home01 kernel: [    7.975037] vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0
May 27 11:42:38 home01 kernel: [    7.975155] Console: switching to colour frame buffer device 80x30
May 27 11:42:38 home01 kernel: [    7.979522] audit_printk_skb: 12 callbacks suppressed
May 27 11:42:38 home01 kernel: [    7.979523] type=1400 audit(1306489358.158:15): apparmor="STATUS" operation="profile_replace" name="/usr/lib/cups/backend/cups-pdf" pid=1318 comm="apparmor_parser"
May 27 11:42:38 home01 kernel: [    7.980104] type=1400 audit(1306489358.158:16): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/cupsd" pid=1318 comm="apparmor_parser"
May 27 11:42:38 home01 kernel: [    8.013739] fb0: VESA VGA frame buffer device
May 27 11:42:38 home01 kernel: [    8.134566] ioremap error for 0xdf7d1000-0xdf7d2000, requested 0x10, got 0x0
May 27 11:42:39 home01 kernel: [    9.301019] EXT4-fs (sdb3): Ignoring deprecated nobh option
May 27 11:42:39 home01 kernel: [    9.301027] EXT4-fs (sdb3): re-mounted. Opts: data=writeback,barrier=0,nobh,errors=remount-ro,commit=0
May 27 11:42:39 home01 kernel: [    9.302877] EXT4-fs (sda1): re-mounted. Opts: data=writeback,commit=0
May 27 11:42:39 home01 kernel: [    9.559678] r8169 0000:06:00.0: eth0: link up
May 27 11:42:39 home01 kernel: [    9.560134] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
May 27 11:42:40 home01 kernel: [   10.795361] RPC: Registered udp transport module.
May 27 11:42:40 home01 kernel: [   10.795364] RPC: Registered tcp transport module.
May 27 11:42:40 home01 kernel: [   10.795365] RPC: Registered tcp NFSv4.1 backchannel transport module.
May 27 11:42:41 home01 kernel: [   10.802957] FS-Cache: Loaded
May 27 11:42:41 home01 kernel: [   10.814580] FS-Cache: Netfs 'nfs' registered for caching
May 27 11:42:41 home01 kernel: [   11.086066] svc: failed to register lockdv1 RPC service (errno 97).
May 27 11:42:41 home01 kernel: [   11.442578] hda-intel: IRQ timing workaround is activated for card #1. Suggest a bigger bdl_pos_adj.
May 27 11:42:50 home01 kernel: [   20.189693] eth0: no IPv6 routers present
May 27 11:42:52 home01 kernel: [   22.218461] CE: hpet2 increased min_delta_ns to 7500 nsec
May 27 11:42:52 home01 kernel: [   22.218469] CE: hpet2 increased min_delta_ns to 11250 nsec
May 27 11:42:52 home01 kernel: [   22.218472] hrtimer: interrupt took 4564 ns
May 27 11:42:54 home01 kernel: [   24.137550] CE: hpet6 increased min_delta_ns to 7500 nsec
May 27 11:42:54 home01 kernel: [   24.137556] CE: hpet6 increased min_delta_ns to 11250 nsec
May 27 11:42:56 home01 kernel: [   25.926711] CE: hpet3 increased min_delta_ns to 7500 nsec
May 27 11:42:56 home01 kernel: [   25.926721] CE: hpet3 increased min_delta_ns to 11250 nsec
May 27 11:42:57 home01 kernel: [   27.483274] CE: hpet5 increased min_delta_ns to 7500 nsec
May 27 11:42:57 home01 kernel: [   27.483282] CE: hpet5 increased min_delta_ns to 11250 nsec
May 27 11:43:02 home01 kernel: [   32.243730] CE: hpet4 increased min_delta_ns to 7500 nsec
May 27 11:43:02 home01 kernel: [   32.243738] CE: hpet4 increased min_delta_ns to 11250 nsec
May 27 11:44:25 home01 kernel: [ 114.754945] r8169 0000:06:00.0: eth0: link up
May 27 11:44:25 home01 kernel: [ 114.754961] NOHZ: local_softirq_pending 08
May 27 11:45:06 home01 kernel: [ 156.135457] r8169 0000:06:00.0: eth0: link up
May 27 11:45:06 home01 kernel: [ 156.135469] NOHZ: local_softirq_pending 08
May 27 11:45:06 home01 kernel: [ 156.265357] r8169 0000:06:00.0: eth0: link up
May 27 11:45:06 home01 kernel: [ 156.265373] NOHZ: local_softirq_pending 08
May 27 11:45:06 home01 kernel: [ 156.271621] NOHZ: local_softirq_pending 08
May 27 11:45:07 home01 kernel: [ 156.755147] r8169 0000:06:00.0: eth0: link up
May 27 11:45:08 home01 kernel: [ 158.224469] r8169 0000:06:00.0: eth0: link up
May 27 11:45:08 home01 kernel: [ 158.224485] NOHZ: local_softirq_pending 08
May 27 11:45:08 home01 kernel: [ 158.294458] r8169 0000:06:00.0: eth0: link up
May 27 11:45:08 home01 kernel: [ 158.294473] NOHZ: local_softirq_pending 08
May 27 11:45:09 home01 kernel: [ 158.994106] r8169 0000:06:00.0: eth0: link up
May 27 11:45:09 home01 kernel: [ 158.994121] NOHZ: local_softirq_pending 08
May 27 11:45:09 home01 kernel: [ 159.263954] r8169 0000:06:00.0: eth0: link up
May 27 11:45:10 home01 kernel: [ 160.163562] r8169 0000:06:00.0: eth0: link up
May 27 11:45:10 home01 kernel: [ 160.163574] NOHZ: local_softirq_pending 08
May 27 11:45:10 home01 kernel: [ 160.313501] r8169 0000:06:00.0: eth0: link up
May 27 11:45:10 home01 kernel: [ 160.313517] NOHZ: local_softirq_pending 08
May 27 11:45:11 home01 kernel: [ 160.763395] NOHZ: local_softirq_pending 08
May 27 11:45:12 home01 kernel: [ 162.132681] net_ratelimit: 1 callbacks suppressed
May 27 11:45:12 home01 kernel: [ 162.132687] r8169 0000:06:00.0: eth0: link up
May 27 11:45:12 home01 kernel: [ 162.402502] r8169 0000:06:00.0: eth0: link up
May 27 11:45:12 home01 kernel: [ 162.472410] r8169 0000:06:00.0: eth0: link up
May 27 11:45:13 home01 kernel: [ 162.962189] r8169 0000:06:00.0: eth0: link up
May 27 11:45:13 home01 kernel: [ 163.242066] r8169 0000:06:00.0: eth0: link up
May 27 11:45:13 home01 kernel: [ 163.382005] r8169 0000:06:00.0: eth0: link up
May 27 11:45:13 home01 kernel: [ 163.521966] r8169 0000:06:00.0: eth0: link up
May 27 11:45:14 home01 kernel: [ 163.801795] r8169 0000:06:00.0: eth0: link up
May 27 11:45:14 home01 kernel: [ 164.161684] r8169 0000:06:00.0: eth0: link up
May 27 11:45:14 home01 kernel: [ 164.571430] r8169 0000:06:00.0: eth0: link up
May 27 11:45:19 home01 kernel: [ 169.169269] net_ratelimit: 6 callbacks suppressed
May 27 11:45:19 home01 kernel: [ 169.169276] r8169 0000:06:00.0: eth0: link up
May 27 11:45:19 home01 kernel: [ 169.669074] r8169 0000:06:00.0: eth0: link up
May 27 11:45:20 home01 kernel: [ 170.638657] r8169 0000:06:00.0: eth0: link up
May 27 11:45:21 home01 kernel: [ 170.768551] r8169 0000:06:00.0: eth0: link up
May 27 11:45:21 home01 kernel: [ 171.058362] r8169 0000:06:00.0: eth0: link up
May 27 11:45:21 home01 kernel: [ 171.538208] r8169 0000:06:00.0: eth0: link up
May 27 11:45:22 home01 kernel: [ 172.377840] r8169 0000:06:00.0: eth0: link up
May 27 11:45:22 home01 kernel: [ 172.517662] r8169 0000:06:00.0: eth0: link up
May 27 11:45:23 home01 kernel: [ 173.077423] r8169 0000:06:00.0: eth0: link up
May 27 11:45:24 home01 kernel: [ 174.596723] r8169 0000:06:00.0: eth0: link up
May 27 11:45:26 home01 kernel: [ 175.736249] r8169 0000:06:00.0: eth0: link up
May 27 11:45:27 home01 kernel: [ 177.405393] r8169 0000:06:00.0: eth0: link up
May 27 11:45:27 home01 kernel: [ 177.685257] r8169 0000:06:00.0: eth0: link up
May 27 11:45:28 home01 kernel: [ 177.975117] r8169 0000:06:00.0: eth0: link up
May 27 11:45:28 home01 kernel: [ 178.105151] r8169 0000:06:00.0: eth0: link up
May 27 11:45:28 home01 kernel: [ 178.384988] r8169 0000:06:00.0: eth0: link up
May 27 11:45:28 home01 kernel: [ 178.704755] r8169 0000:06:00.0: eth0: link up
May 27 11:45:29 home01 kernel: [ 179.014860] r8169 0000:06:00.0: eth0: link up
May 27 11:45:29 home01 kernel: [ 179.434455] r8169 0000:06:00.0: eth0: link up
May 27 11:45:29 home01 kernel: [ 179.654480] r8169 0000:06:00.0: eth0: link up
May 27 11:45:32 home01 kernel: [ 182.413126] net_ratelimit: 7 callbacks suppressed
May 27 11:45:32 home01 kernel: [ 182.413133] r8169 0000:06:00.0: eth0: link up
May 27 11:45:33 home01 kernel: [ 183.542481] r8169 0000:06:00.0: eth0: link up
May 27 11:45:34 home01 kernel: [ 184.242176] r8169 0000:06:00.0: eth0: link up
May 27 11:45:35 home01 kernel: [ 185.581600] r8169 0000:06:00.0: eth0: link up
May 27 11:45:36 home01 kernel: [ 185.971446] r8169 0000:06:00.0: eth0: link up
May 27 11:45:36 home01 kernel: [ 186.041435] r8169 0000:06:00.0: eth0: link up
May 27 11:45:36 home01 kernel: [ 186.291355] r8169 0000:06:00.0: eth0: link up
May 27 11:45:36 home01 kernel: [ 186.541117] r8169 0000:06:00.0: eth0: link up
May 27 11:45:37 home01 kernel: [ 187.170877] r8169 0000:06:00.0: eth0: link up
May 27 11:45:37 home01 kernel: [ 187.390805] r8169 0000:06:00.0: eth0: link up
May 27 11:45:39 home01 kernel: [ 189.359872] net_ratelimit: 6 callbacks suppressed
May 27 11:45:39 home01 kernel: [ 189.359879] r8169 0000:06:00.0: eth0: link up
May 27 11:45:40 home01 kernel: [ 190.029434] r8169 0000:06:00.0: eth0: link up
May 27 11:45:40 home01 kernel: [ 190.519276] r8169 0000:06:00.0: eth0: link up
May 27 11:45:40 home01 kernel: [ 190.649129] r8169 0000:06:00.0: eth0: link up
May 27 11:45:41 home01 kernel: [ 191.428869] r8169 0000:06:00.0: eth0: link up
May 27 11:45:42 home01 kernel: [ 191.848575] r8169 0000:06:00.0: eth0: link up
May 27 11:45:42 home01 kernel: [ 192.298432] r8169 0000:06:00.0: eth0: link up
May 27 11:45:43 home01 kernel: [ 193.587759] r8169 0000:06:00.0: eth0: link up
May 27 11:45:43 home01 kernel: [ 193.657813] r8169 0000:06:00.0: eth0: link up
May 27 11:45:44 home01 kernel: [ 193.837937] r8169 0000:06:00.0: eth0: link up
May 27 11:45:45 home01 kernel: [ 195.307164] net_ratelimit: 3 callbacks suppressed
May 27 11:45:45 home01 kernel: [ 195.307171] r8169 0000:06:00.0: eth0: link up
May 27 11:45:45 home01 kernel: [ 195.466971] r8169 0000:06:00.0: eth0: link up
May 27 11:45:46 home01 kernel: [ 196.096693] r8169 0000:06:00.0: eth0: link up
May 27 11:45:47 home01 kernel: [ 197.286001] r8169 0000:06:00.0: eth0: link up
May 27 11:45:47 home01 kernel: [ 197.395946] r8169 0000:06:00.0: eth0: link up
May 27 11:45:49 home01 kernel: [ 198.745369] r8169 0000:06:00.0: eth0: link up
May 27 11:45:49 home01 kernel: [ 199.435125] r8169 0000:06:00.0: eth0: link up
May 27 11:45:49 home01 kernel: [ 199.544995] r8169 0000:06:00.0: eth0: link up
May 27 11:45:49 home01 kernel: [ 199.644936] r8169 0000:06:00.0: eth0: link up
May 27 11:45:50 home01 kernel: [ 199.784821] r8169 0000:06:00.0: eth0: link up
May 27 11:45:51 home01 kernel: [ 200.994345] net_ratelimit: 1 callbacks suppressed
May 27 11:45:51 home01 kernel: [ 200.994351] r8169 0000:06:00.0: eth0: link up
May 27 11:45:51 home01 kernel: [ 201.214195] r8169 0000:06:00.0: eth0: link up
May 27 11:45:51 home01 kernel: [ 201.434195] r8169 0000:06:00.0: eth0: link up
May 27 11:45:53 home01 kernel: [ 203.373323] r8169 0000:06:00.0: eth0: link up
May 27 11:45:53 home01 kernel: [ 203.483165] r8169 0000:06:00.0: eth0: link up
May 27 11:45:53 home01 kernel: [ 203.603131] r8169 0000:06:00.0: eth0: link up
May 27 11:45:54 home01 kernel: [ 204.472628] r8169 0000:06:00.0: eth0: link up
May 27 11:45:54 home01 kernel: [ 204.612646] r8169 0000:06:00.0: eth0: link up
May 27 11:45:55 home01 kernel: [ 205.272309] r8169 0000:06:00.0: eth0: link up
May 27 11:45:55 home01 kernel: [ 205.342344] r8169 0000:06:00.0: eth0: link up
May 27 11:45:56 home01 kernel: [ 206.501724] net_ratelimit: 1 callbacks suppressed
May 27 11:45:56 home01 kernel: [ 206.501731] r8169 0000:06:00.0: eth0: link up
May 27 11:45:57 home01 kernel: [ 207.061401] r8169 0000:06:00.0: eth0: link up
May 27 11:45:57 home01 kernel: [ 207.201335] r8169 0000:06:00.0: eth0: link up
May 27 11:45:57 home01 kernel: [ 207.681118] r8169 0000:06:00.0: eth0: link up
May 27 11:45:59 home01 kernel: [ 208.940520] r8169 0000:06:00.0: eth0: link up
May 27 11:45:59 home01 kernel: [ 209.060504] r8169 0000:06:00.0: eth0: link up
May 27 11:45:59 home01 kernel: [ 209.160533] r8169 0000:06:00.0: eth0: link up
May 27 11:45:59 home01 kernel: [ 209.390487] r8169 0000:06:00.0: eth0: link up
May 27 11:46:00 home01 kernel: [ 210.059983] r8169 0000:06:00.0: eth0: link up
May 27 11:46:01 home01 kernel: [ 210.749668] r8169 0000:06:00.0: eth0: link up
May 27 11:46:02 home01 kernel: [ 212.639067] net_ratelimit: 1 callbacks suppressed
May 27 11:46:02 home01 kernel: [ 212.639071] r8169 0000:06:00.0: eth0: link up
May 27 11:46:04 home01 kernel: [ 214.408054] r8169 0000:06:00.0: eth0: link up
May 27 11:46:05 home01 kernel: [ 214.937765] r8169 0000:06:00.0: eth0: link up
May 27 11:46:06 home01 kernel: [ 216.137189] r8169 0000:06:00.0: eth0: link up
May 27 11:46:06 home01 kernel: [ 216.437041] r8169 0000:06:00.0: eth0: link up
May 27 11:46:06 home01 kernel: [ 216.546989] r8169 0000:06:00.0: eth0: link up
May 27 11:46:07 home01 kernel: [ 217.336717] r8169 0000:06:00.0: eth0: link up
May 27 11:46:09 home01 kernel: [ 218.995889] r8169 0000:06:00.0: eth0: link up
May 27 11:46:09 home01 kernel: [ 219.605539] r8169 0000:06:00.0: eth0: link up
May 27 11:46:10 home01 kernel: [ 220.585029] r8169 0000:06:00.0: eth0: link up
May 27 11:46:14 home01 kernel: [ 223.753670] r8169 0000:06:00.0: eth0: link up
------------------------------ CRASH -----------------------------

Deuxième fausse piste : faisant une copie depuis un répertoire NFS sur un NAS, je pense que le message "NOHZ: local_softirq_pending 08" est important. Après épluchage d'une bonne centaine de forums, il s'agit plus d'un vieux spam indésirable dans la log que d'une erreur "sérieuse".

La piste est venue du post suivant : http://kubuntuforums.net/forums/index.php?topic=3114285.0

Dans le post, la fonctionnalité HPET est mise en cause. Pour rappel, voici dans la log du kernel ci-dessus les entrées HPET ci référant :

May 27 11:42:54 home01 kernel: [   24.137550] CE: hpet6 increased min_delta_ns to 7500 nsec
May 27 11:42:54 home01 kernel: [   24.137556] CE: hpet6 increased min_delta_ns to 11250 nsec
May 27 11:42:56 home01 kernel: [   25.926711] CE: hpet3 increased min_delta_ns to 7500 nsec
May 27 11:42:56 home01 kernel: [   25.926721] CE: hpet3 increased min_delta_ns to 11250 nsec
May 27 11:42:57 home01 kernel: [   27.483274] CE: hpet5 increased min_delta_ns to 7500 nsec
May 27 11:42:57 home01 kernel: [   27.483282] CE: hpet5 increased min_delta_ns to 11250 nsec
May 27 11:43:02 home01 kernel: [   32.243730] CE: hpet4 increased min_delta_ns to 7500 nsec
May 27 11:43:02 home01 kernel: [   32.243738] CE: hpet4 increased min_delta_ns to 11250 nsec

Mais qu'est ce que le HPET ???

L'article de wikipedia (http://en.wikipedia.org/wiki/High_Precision_Event_Timer) est assez complet et bien écrit. Donc, comme le café Maxwel, pas la peine d'en rajouter.

Il s'agit d'une technologie développée par Intel pour améliorer la précision de requêtes d'interruption et du coup "en passant" alléger celles gérées par le CPU... enfin pas de quoi tricoter une nouille. Normalement le Kernel Linux le gère depuis le 2.6

Ca tombe bien, j'utilise un Ubuntu 11.04 (tout le monde a des défauts) avec un kernel 2.6.38-8-generic. J'essaie donc de désactiver cette fonctionnalité dans le BIOS de la carte mère. Et je m'aperçois que le HPET est mode 32bits (j'utilise un kernel 64bits)..... Pour m'épargner des galères, je décide de désactiver depuis le BIOS le HPET.

Enregistrement du BIOS. Redémarrage. Test de la copie de fichier. Réussi. Plus de freeze.

Mission accomplie.

Quand 2 font 4 et parfois même plus : jeux de caractères et varchar2

Fabien — Mon, 01 Mar 2010 20:28:00 +0100

Je bloque toujours sur l'utilisation abusive faite du varchar2 et de manière générale du stockage de données de type caractères. Tout est stocké n'importe comment et après le public (utilisateurs) se retrouve avec des données pas très jolies à regarder.

Ne blamons pas d'entrée le développeur, celui développe parfois des bons bugs dans les règles de l'art. L'administrateur de base de données est potentiellement un meilleur coupable.

L'utilisation illustrée ci-dessous a été réalisée sous une Oracle 10g R2. Oracle a assoupli depuis quelques temps, version 9, l'utilisation des types de données varchar2 (le type varchar devenant obsolète). il est possible de le déclarer non plus comme un tableau de n octets mais comme un tableau contenant n caractères.

Un exemple permet de dresser un portait du coupable :

Create table Toto (mytext Varchar2(200))

Tout va bien, vous venez de déclarer un attribut de la table comme varchar2 de 200.... octets ou char ? Vous allez dire peu importe : je vous invite à lire la suite et notamment le cas "tordu" ci-dessous. Pour le savoir, l'unité (char ou octet) employée par défaut va dépendre des paramètres NLS. Si vous avez un peu de chances, votre DBA a été bienveillant est à paramètrer le NLS_LENGTH_SEMANTICS en char et non en octets.

Le truc tordu arrive: imaginons que vous êtes amenés à stocker pour une très bonne raison des données caractères de langues exotico-européennes : bulgare, grecque, finnois. La liste est loin d'être exhaustive ! Vous vous retrouvez à gérer des données au format planétaire et universel : l'UTF8. J'entends déjà les experts critiqués le côté planétaire et universel de l'UTF8. Qu'il se rassure, il m'est arrivé de stocker du Klingon en UTF16.

L'UTF8 se comporte comme un jeux de caractères multi-octets sur les langues comme le grec, le bulgare etc. La grosse boulette vient du stockage en mode octet du varchar2. Vous vous attendez à stocker 200 caractères bulgares et vous vous retrouvez avec 200 octets en bulgare. Un caractère bulgare est représenté sur 2 octets... patatra, vous avez 100 caractères bulgares au lieu des 200 attendus.

Le cas peut encore être plus tordu si vous avez un attribut varchar2 taillé sur un nombre impair d'octets. Le dernier caractère est tronqué et par défaut remplacé par un caractère Blank d'un octet. Ca peut donner des situations folkloriques où le dernier mot spécifié sur le résumé d'un contrat est une insulte en bulgare.... Succès garanti à la clé en clientèle (situation purement hypothétique ne pouvant jamais arrivé ^^)

Pour parer à toute éventualité, quelques préconisations de bonne usage :

Préférer le stockage en mode Char plutôt que l'octet, vous serez sur et certains du nombre de caractères que vous affichez (surtout en cas de mixe de jeux caractères anglais + bulgare)
Oublier la mollesse : des déclarations fortes n'ont jamais tué personne : mytext Varchar2(200 CHAR)

Dans la suite du billet, je vais un peu blâmer le moteur de base Ora*** . Âme sensible s'abstenir.

La bonne blague arrive quand vous essayez de créer un attribut du style : {{ Create table Toto (mytext Varchar2(4000 CHAR))}}

Aucun problème, même avec une base en UTF8 !

La blague consiste à utiliser un outil d'alimentation UTF8-aware capable de balancer 4000 caractères bulgares dans cet attribut. Oracle explose avec une erreur grossière et abscon :

ORA-01461: cannot bind a LONG value for insert into a long column

Déjà d'entrée de jeu le message ne veut RIEN dire : qui parle de Long ? Pourquoi ne peut-on pas lier une valeur long avec un attribut long ? N'est-ce pas Oracle qui insiste pour que le monde arrête l'implémentation dans sa base de données du type long et le considère comme déprécié ? Les cores développeurs Oracle fument-ils du crack ou de l'herbe ?

Questions sans réponses pour le commun des mortels.

La faiblesse de l'engin, en l'occurence le moteur de base de données, vient d'une limite type "deus ex machina" ou "10 commandements" : le varchar2 ne peut faire plus de 4000 octets. Mais pourtant l'outil autorise la création d'un varchar2(4000 CHAR) et non 4000 BYTE sur une base avec jeu de caractères UTF8.

Incroyable mais vrai, plutôt que d'implémenter un principe du type qui peut le plus peut le moins, ils ont préféré choisir un principe du type le lièvre est aussi rapide que la tortue.

Grosso modo, ce qui prévaut c'est toujours la limité des 4000 octets. Point.

En bref, vous essayez de faire passer 4000 caractères bulgares : poids 8000 octets dans 4000. C'est le drame. D'autant plus avec le message déprimant parlant de Long.

A ce moment là, la ruse est de mise et il faut calculer à priori le poids de chaînes de caractères avant chargement (LengthB et consort). Un beau numéro de claquettes en perspective.

Le plus drôle c'est que la précédente "limite" (sur Oracle 8) était de 2000 octets (2 puissance 11) et maintenant 4000 (2 puissance 12). Ca m'impressionne vraiment la taille de leurs blocs au niveau de leur système interne de fichier. J'ai vaguement l'impression que des fois l'informatique progresse à pas de géant lilipucien.

Pas de panique : donnez moi un live CD, une clé USB et je vous sauvegarderai le monde !!!

Fabien — Sat, 03 Jan 2009 18:58:00 +0100

Une amie a récemment crashé son OS XP home edition de chez GrosSoft. La panique l'a saisi. Récupérer à tout prix les photos sur son PC portable hors d'état de boot.

Bien sur les outils de restauration proposés par l'OS de GrosSoft ne fonctionne desespérement pas, mode sans échec (en échec), mode sans échec avec prise en charge réseau (mort de rire, en échec lui aussi), chargement de la dernière bonne configuration connue (bien sur sans aucune information sur la date du cliché). L'outil de réparation intégré à l'OS est complètement inutilisable ("insérez la disquette de restauration"). Qui utilise encore un lecteur disquette ?

Bon d'accord, je suis médisant. Je suis un vil trolleur. L'OS XP, venant des années 2001, a mal survécu au fil des ans.

Pour se faire, j'ai décidé de sauvegarder ce qui pouvait encore l'être à l'aide d'un CD Live Ubuntu 8.10 et d'une clé USB (peu importe sa capacité).

Je vous invite bien évidemment à télécharger la dernière version du CD d'intallation pour desktop d'Ubuntu (http://www.ubuntu.com/getubuntu). Pourquoi Ubuntu ? Et bien pourquoi pas ! Le live CD est stable et les outils fournis en standard sont largement suffisants pour ce que nous comptons en faire. De plus, ce live tient sur une seule galette. Parfait, je n'aime pas brûler plus de 700 Mo de données. Cela suffira.

Insérer le live CD, configurer la langue en français (pas nécessaire et pas utile), puis utiliser lancer Ubuntu sans rien installer sur le disque dur.

Au bout d'un certains temps, vous devriez voir apparaître le bureau Gnome (bureau par défaut). Nous allons inspecter l'état du disque et des partitions sur le portable pour commencer à analyser la situation.

Allez dans une console et taper la commande suivante : gparted

L'interface graphique suivante se lance et analyse les diques.

Les partitions ont l'air correct, une partition système (sda1) et une partition de données (sda2). Gparted indique le système de fichier est un NTFS (typique de l'OS de GrosSoft).

La suite va consister à monter les deux disques afin d'effectuer les sauvegardes pour cela nous allons d'abord créer deux points de montage.Dans un terminal, taper les commandes suivantes

mkdir /tmp/win

mkdir /tmp/data

La première commande nous permet juste de créer un répertoire qui sera notre support pour le point de montage. La seconde effectue la même chose mais sera le support pour notre partition secondaire contenant les données. Il convient ensuite de créer les points de montage juste après. Toujours dans un terminal, taper :

mount -t ntfs /dev/sda1 /tmp/win

mount -t ntfs /dev/sda2 /tmp/data

Les deux points de montage sont créés. Prenez soin de vérifier les types de partitions à créer dans mon cas, il s'agissait de systèmes de fichiers NTFS. Pour ceux qui ne voient pas, retourner voir la description fournie par Gparted plus haut.

Il ne reste plus qu'à lancer une copie sur notre clé USB de ses fichiers préférés. Vous pouvez très bien pour ceux qui ont plus de moyens de les recopier par réseau sur un poste distant ou même un nas.

Mise à jour du BIOS de sa carte mère, l'enfer a un nom : MS-DOS

Fabien — Fri, 02 Jan 2009 15:36:00 +0100

Etant possesseur d'une carte mère ASUS A7N8X Deluxe, je souhaitais faire la mise à jour de son BIOS. Histoire de posséder les dernières "kikoos" fonctionnalités. Le bios actuellement sur la carte mère est en version 1007.

En me rendant sur le site d'ASUS, je decouvris les nombreuses mises à jours de ce BIOS, la version 1008 et même la 1009 en béta !

Première difficulté mais pas des moindres avant de faire la moindre mise à jour : connaître la version correcte de sa carte mère. Petite subtilité; l'ASUS A7N8X posséde un numéro de version majeure (A7N8X) mais aussi un numéro de version mineure (1.04, 1.06, 2.0 et supérieure). Le site ASUS vous indique comme maigre consolation de vous reporter au numéro indiquer dans le boot du BIOS : la bonne blague, le numéro est A7N8X et ne comporte pas le numéro de version mineure. Pour ceux qui disposent d'un cerveau, d'un bon tournevis, et d'une loupe grossissante, vous pouvez lire directement le numéro de révision sur la carte mère entre deux ports PCI.

Après avoir mis 20 bonnes minutes pour trouver ma loupe et à peu près autant pour lire le numéro de révision, je commencais à télécharger le BIOS 1009 pour l'A7N8X v1.04 ainsi que son outil d'installation Awdflash BIOS update tool V8.24B.

Je dézippe les deux archives et j'obtiens deux fichiers : AN8D1009.BIN pour le bios et AWDFLASH.EXE pour l'utilitaire. Aïe ! Mon linux favori m'indique que l'exe est un exécutable DOS/Windows (application/x-ms-dos-executable). Je me reporte sur le site d'ASUS pour connaître leur façon d'installer ce bouzin. A la lecture de la page au doux nom "Comment mettre à jour votre BIOS?", je m'aperçois qu'ils sont un peu à la ramasse chez ASUS. Je vois passer des phrases grossières comme "Veuillez insérer une disquette non formatée dans le lecteur A:\ et démarrer le système en mode DOS". Pour ceux qui n'auraient pas compris, redémarrez de suite votre windows 98 en mode dos !! C'est du pur bonheur cette page, je sais pas depuis quand elle a été écrite mais elle survit toujours !

Bon, je me creuse la tête 5 secondes. A la sixième seconde, je decidais de faire la mise à jour à l'aide d'un freeDOS (http://www.freedos.org/).

D'abord, commencer par télécharger l'image iso du projet. Mon choix s'est porté sur le CD complet (fdfullcd.iso). La seconde opération va consister à intégrer le fichier de mise à jour ainsi que le précieux utilitaire fournis par ASUS dans l'image iso fraîchement téléchargée. Pour se faire, j'utilise une superbe application isoMaster (package sous debian/ubuntu), permettant d'éditer ou d'extraire des fichiers dans une image iso.

J'intégre les fichiers dans l'image ISO à l'endroit suivant : /freedos/bios/

Enregistrement de la nouvelle ISO et passage au four. 5 minutes plus tard, j'ai une super galette prête à être utilisée.

Superbe, je lance le CD de boot obtenu précédemment. "Enter" et je lance freedos.

Je choisis le mode "lancer freedos à l'aide du CDROM". Me voilà désormais avec un prompt au nom évocateur :

X:\

Pas de soucis, je me sens en terrain connu...

X:\cd freedos\bios

X:\dir

Une commande Dir pour m'assurer que les fichiers sont là, tout est ok.

Je lance l'utilitaire : X:\awdflash

Je me retrouve en mode graphique, je tape le nom du fichier de mise à jour AN8D1009.BIN et je me laisse guider par l'interface. Surtout zapper l'étape "taper un nom de fichier de sauvegarde", celui-ci serait sauvegardé sur le CDROM.... qui est en lecture seule, le drame.

La mise à jour se termine et me demande de redémarrer en appuyant sur F1. La touche ne répond pas. Mon clavier ne répond plus ... étrange. Qu'à cela ne tienne, je fais un hard reboot sur le boitier du PC. Au démarrage, je vois que le numéro du BIOS à changer... en 1008 au lieu de 1007. Je m'attendais à voir 1009. Je pense que cela doit venir du mode béta du BIOS. Le numéro n'a pas été mis en jour par les équipes ASUS.

Encore un plan qui s'est déroulé sans accroc !

Pétage de plomb sur un switch KVM trend.net

Fabien — Fri, 02 Jan 2009 13:17:00 +0100

Très pratique le switch KVM (KeyBoard, Video and Mouse), j'ai opté depuis quelques temps pour le KVM full usb de trendnet, le TK207. A vrai, je ne l'ai plus utilisé depuis quelques temps. Je switch de mon PC fixe sous ubuntu sur mon PC de démo sous l'OS 2003 de GrosSoft.

Le soucis est que mon clavier et ma souris partent en vrac dès le moindre redémarrage de l'OS de GrosSoft. Bizarre ? Après avoir claqué une bonne douzaine de fois le switch contre le mur et que celui-ci ne répondait toujours pas, j'ai accusé la carte mère du PC de démo.

Qui n'a jamais eu un controleur USB mort sur une carte mère ? Mon accusation ne tient pas la route. Le controleur envoie toujours du courant de façon constante au switch. La solution est venu du site de support de GrosSoft (et oui, il paraît qu'ils font du support) avec le point suivant :

Microsoft KB817900 USB fail to enter S3 patch file for Windows XP

En y regardant de plus près à ce patch, nous retrouvons un vieux hack dans la base de registre :

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\usb]
"USBBIOSHACKS"=dword:00000000
"USBBIOSx"=dword:00000000

Il s'agit plutôt de la désactivation du dit hack... Un redémarrage complet m'assure que tout est en ordre. Je pense que ceci doit aussi s'appliquer à d'autres périphériques USB qui ont un comportement étrange à la sortie du mode Suspend-To-Ram.

Le père noël est un informaticien barbu jouant les terreurs dans le village

Fabien — Fri, 26 Dec 2008 12:10:00 +0100

Pas de répis même durant les fêtes. Je me réveille tardivement, j'allume mon pc portable. J'essaie de me replonger dans un sale bug sur mon interface X.
Mon interface "eye candy" m'attire l'oeil sur l'état de ma connexion wifi. Elle n'est pas très bonne et je constate de gros lags lors de téléchargement de vidéo sur youtube. Cela fait quelques jours que le problème perdure.
Ma première piste est que le problème est normal. Revenu pour les fêtes de Noël dans la famille, perdu dans un village profond du Nord, il est normal que l'opérateur historique ne parvient pas à assurer une qualité de ligne suffisante (erf... je m'y suis résigné).
Etrangement, mon cerveau primaire d'informaticien me fait taper dans un terminal un ifconfig. Vous connaissez déjà la suite : et là c'est le drame.
J'avais pris grand soin de configurer un réseau wifi sécurisé à grand renfort de routeur wrt54g de chez Linksys et d'adresses IP privées.
Je sors l'artillerie lourde, airodump-ng me donne les points d'accès suivants :

BSSID              PWR Beacons    #Data, #/s CH MB ENC CIPHER AUTH ESSID

00:14:BF:A5:BA:56 208      198       58    0 13 54 WPA TKIP PSK linksys
00:14:BF:64:61:5E 177      232        8    0   6 54 OPN              linksys
00:18:E7:59:1D:42 170      102        0    0   6 54. WPA TKIP   PSK Livebox-016D
00:17:33:34:22:5C 170       70        0    0 11 54 OPN              Neuf WiFi

Le point d'accès que je dois normalement utilisé est en premier dans la liste ci-dessus. Mais pourquoi n'est-il pas dans la liste des connexions dans le "connexion manager" de mon ubuntu 8.10 favori ? Je suppose que la faute en revient au nom du ESSID identique dans les deux cas (linksys). Pour éviter d'afficher des doublons dans la liste des connexions wifi disponibles, le choix par défaut s'est fait sur celui étant ouvert (OPN). De toute évidence, il s'agit d'un manque fonctionnel dans l'interface proposée par le paquet network-manager d'ubuntu.
J'ai du par erreur activer la connexion ouverte en ne me fiant qu'au nom du réseau. Erreur grossière, le réseau est ouvert et pourvu d'un DHCP. Mea Culpa.
Cette erreur m'ayant mis un peu hors de moi, j'ai décidé de revoir mon point d'accès. Vous le trouverez en premier dans la liste suivante :

BSSID              PWR Beacons    #Data, #/s CH MB ENC CIPHER AUTH ESSID

00:14:BF:A5:BA:56 212      198       56    0 10 54 WPA2 CCMP   PSK molw
00:14:BF:64:61:5E 171      232        6    0   6 54 OPN              linksys
00:18:E7:59:1D:42 170      104        0    0   6 54. WPA TKIP   PSK Livebox-016D
00:17:33:34:22:5C 170       73        0    0 11 54 OPN              Neuf WiFi
00:17:33:34:22:55 169       77      285    4 11 54 WEP WEP         NEUF_2254
00:16:41:C0:7E:07 164       15        0    0 10 54 WEP WEP         Livebox-ff40

Tout ça, pour en venir au point suivant : même les personnes qui connaissent se font abuser. Le wifi est par définition pervasif. J'irai même jusqu'à dire envahissant. Si vous ne savez pas ce que vous faîtes, préférer les installations filaires (du bon câble FTP catégorie 5). Elles se faufilent partout : gaines électiques, sous des baguettes. Elles assureront dans la plupart des cas un meilleur débit que ce pauvre wifi, digne descendant des talki walkies de notre enfance.

PS : père noël si tu existes, arrête de suite l'envoi de routeur wrt54g.

Premier billet : il faut bien un début à tout !!

Fabien — Thu, 25 Dec 2008 11:05:00 +0000

Pourquoi écrire un blog ? L'effet de mode "Blog" passé, cet outil reste très puissant pour publier des petits posts et autres points de vue.

La deuxième question qui trotte dans l'esprit du blogueur (désolé pour l'anglicisme) est quel sujet traité sur son blog. Pour ceux qui s'attendent à voir des photos, ou des extraits de ma vie quotidienne, vous allez être déçus. Je compte y mettre mes quelques réflexions sur la façon dont je gagne ma vie : la consultance informatique. Au programme : des coups de coeur et des coups de gueule, des tutoriels, des @-'~^^^, des contributions tribales de collègues informaticiens, grosso modo des tas de choses intéressantes !!

La dernière question, comment écrire.... Question triviale : avec un clavier. Le comment ne se limite pas au simple outil permettant l'écriture, il implique aussi la façon de la produire. Une écriture régulière évite les sujets longs et pompeux : le blog s'y prête bien. Je compte écrire de manière libre et simple tout en essayant d'être un peu moqueur pour ne pas trop se prendre au sérieux.

BONNE LECTURE !