Re: still loosing connections
On Sun, Nov 02, 2014 at 08:41:44PM +0100, Stefan Wollny wrote: I think so. Your message is a million lines long, but I have no idea what the problem is. Hi Ted, thank you for taking your time to reply. Long story short: Sometimes (=not deliberately repeatable) when fetching a fresh snapshot and/or the sources afterwards and/or running 'pkg_add -ui' connections to the internet are lost, entirely. This happens with i386-current as well with amd64-current and with different providers. I have to bring down all interfaces and flush routes prior to 'sudo sh /etc/netstart' to get a connection - but even this does not always work - a restart is then required. My problem is: I have no clue where to look or how to investigate further into this issue. That is why I have described en d??tail what I am doing and added as much information as possible. Can you (or s.o. else) give me hint where to look? I feel kind of lost... Thank's a lot! Cheers, STEFAN BTW: By now I use OpenBSD 5.6-current (GENERIC.MP) #515: Sat Nov 1 20:55:07 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Hi Stefan, Did you say you used different providers? Did you try my udptunnel that I told you about in private mail? I can update the sources for you on my vps in amsterdam for you. If you've followed my problem it was with the FritzBox, still is because I couldn't restore my config on the FritzBox after downgrading, so I upgraded to 6.20 again. The udptunnel I wrote circumvents the bad networking associated with the fritzbox. Generally I think watching a netstat -s output for tcp is a good start. Look for retransmissions and hangups in the tcp section of that. A dmesg to the list would be helpful, as always add a description of what interfaces you use for default route. Also take a look at netstat -ni and look for hardware errors on the interface itself. There is input/output errors and collisions noted. So, netstat -s netstat-s.`date +%s` before your downloads and the same during and after, see if anything changes using diff helps too. Good luck! -peter
Re: still loosing connections
Hi Peter, thanks for your help. I was too busy with some private requirements over the weekend to test your tunnel. During the week I am not at home, living in a hotel. I guess you'll understand that I will not use my main laptop which needed daily (and has some confidential stuff...) but would like to use a spare machine running i386-current (instead amd64-current) to test your udptunnel first. I noticed the broken connections with 'KabelDeutschland' at home via em0 and with wpi0 via T-Mobile and via the hotel-WLAN (I guess DTAG). Only at home and at the hotel a Fritz!Box (different models) is involved, not if I use my mobile phone. I will take a look at 'man netstat' and proceed as you suggested. Best,STEFAN Gesendet: Montag, 03. November 2014 um 12:17 Uhr Von: Peter J. Philipp p...@centroid.eu An: Stefan Wollny stefan.wol...@web.de Cc: openbsd-misc misc@openbsd.org Betreff: Re: still loosing connectionsOn Sun, Nov 02, 2014 at 08:41:44PM +0100, Stefan Wollny wrote: I think so. Your message is a million lines long, but I have no idea what the problem is. Hi Ted, thank you for taking your time to reply. Long story short: Sometimes (=not deliberately repeatable) when fetching a fresh snapshot and/or the sources afterwards and/or running 'pkg_add -ui' connections to the internet are lost, entirely. This happens with i386-current as well with amd64-current and with different providers. I have to bring down all interfaces and flush routes prior to 'sudo sh /etc/netstart' to get a connection - but even this does not always work - a restart is then required. My problem is: I have no clue where to look or how to investigate further into this issue. That is why I have described en d??tail what I am doing and added as much information as possible. Can you (or s.o. else) give me hint where to look? I feel kind of lost... Thank's a lot! Cheers, STEFAN BTW: By now I use OpenBSD 5.6-current (GENERIC.MP) #515: Sat Nov 1 20:55:07 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Hi Stefan, Did you say you used different providers? Did you try my udptunnel that I told you about in private mail? I can update the sources for you on my vps in amsterdam for you. If you've followed my problem it was with the FritzBox, still is because I couldn't restore my config on the FritzBox after downgrading, so I upgraded to 6.20 again. The udptunnel I wrote circumvents the bad networking associated with the fritzbox. Generally I think watching a netstat -s output for tcp is a good start. Look for retransmissions and hangups in the tcp section of that. A dmesg to the list would be helpful, as always add a description of what interfaces you use for default route. Also take a look at netstat -ni and look for hardware errors on the interface itself. There is input/output errors and collisions noted. So, netstat -s netstat-s.`date +%s` before your downloads and the same during and after, see if anything changes using diff helps too. Good luck! -peter
Re: still loosing connections
On Sat, Nov 01, 2014 at 20:26, Stefan Wollny wrote: An other case of TL:DR??? Please help me with a 'clue-stick' on how to investigate further. I think so. Your message is a million lines long, but I have no idea what the problem is.
Re: still loosing connections
Am 11/02/14 um 07:04 schrieb Ted Unangst: On Sat, Nov 01, 2014 at 20:26, Stefan Wollny wrote: An other case of TL:DR??? Please help me with a 'clue-stick' on how to investigate further. I think so. Your message is a million lines long, but I have no idea what the problem is. Hi Ted, thank you for taking your time to reply. Long story short: Sometimes (=not deliberately repeatable) when fetching a fresh snapshot and/or the sources afterwards and/or running 'pkg_add -ui' connections to the internet are lost, entirely. This happens with i386-current as well with amd64-current and with different providers. I have to bring down all interfaces and flush routes prior to 'sudo sh /etc/netstart' to get a connection - but even this does not always work - a restart is then required. My problem is: I have no clue where to look or how to investigate further into this issue. That is why I have described en détail what I am doing and added as much information as possible. Can you (or s.o. else) give me hint where to look? I feel kind of lost... Thank's a lot! Cheers, STEFAN BTW: By now I use OpenBSD 5.6-current (GENERIC.MP) #515: Sat Nov 1 20:55:07 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
Re: still loosing connections
An other case of TL:DR??? Please help me with a 'clue-stick' on how to investigate further. By now I use the very latest version as of Novemnber 1st: OpenBSD 5.6-current (GENERIC.MP) #509: Sat Nov 1 00:18:49 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP The settings are the same yet the issue is still unsolved - and I have no idea what I am doing wrong... BTW: Received my two copies of 5.6 yesterday in Germany: One for my shelf, one to give away. Again: Please help me as I am lost. Thanks, STEFAN New DMESG: OpenBSD 5.6-current (GENERIC.MP) #509: Sat Nov 1 00:18:49 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3203203072 (3054MB) avail mem = 3109294080 (2965MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (68 entries) bios0: vendor LENOVO version 79ETC9WW (2.09 ) date 12/22/2006 bios0: LENOVO 2007VG2 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET SLIC BOOT SSDT SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) LURT(S3) DURT(S3) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) PCI1(S4) USB0(S3) USB1(S3) USB2(S3) USB7(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz, 1994.61 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF cpu0: 4MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 166MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz, 1994.34 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF cpu1: 4MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 2, remapped to apid 1 acpimcfg0 at acpi0 addr 0xf000, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (AGP_) acpiprt2 at acpi0: bus 2 (EXP0) acpiprt3 at acpi0: bus 3 (EXP1) acpiprt4 at acpi0: bus 4 (EXP2) acpiprt5 at acpi0: bus 12 (EXP3) acpiprt6 at acpi0: bus 21 (PCI1) acpicpu0 at acpi0: C3, C2, C1, PSS acpicpu1 at acpi0: C3, C2, C1, PSS acpipwrres0 at acpi0: PUBS, resource for USB0, USB2, USB7 acpitz0 at acpi0: critical temperature is 127 degC acpitz1 at acpi0: critical temperature is 99 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 model 92P1139 serial 2887 type LION oem Panasonic acpibat1 at acpi0: BAT1 not present acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0 acpidock0 at acpi0: GDCK not docked (0) cpu0: Enhanced SpeedStep 1994 MHz: speeds: 2000, 1667, 1333, 1000 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 Intel 82945GM Host rev 0x03 ppb0 at pci0 dev 1 function 0 Intel 82945GM PCIE rev 0x03: msi pci1 at ppb0 bus 1 radeondrm0 at pci1 dev 0 function 0 ATI Radeon Mobility X1300 M52-64 rev 0x00 drm0 at radeondrm0 radeondrm0: apic 1 int 16 azalia0 at pci0 dev 27 function 0 Intel 82801GB HD Audio rev 0x02: msi azalia0: codecs: Analog Devices AD1981HD, Conexant/0x2bfa, using Analog Devices AD1981HD audio0 at azalia0 ppb1 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x02: msi pci2 at ppb1 bus 2 em0 at pci2 dev 0 function 0 Intel 82573L rev 0x00: msi, address 00:15:58:81:15:fb ppb2 at pci0 dev 28 function 1 Intel 82801GB PCIE rev 0x02: msi pci3 at ppb2 bus 3 wpi0 at pci3 dev 0 function 0 Intel PRO/Wireless 3945ABG rev 0x02: msi, MoW2, address 00:19:d2:85:6f:4d ppb3 at pci0 dev 28 function 2 Intel 82801GB PCIE rev 0x02: msi pci4 at ppb3 bus 4 ppb4 at pci0 dev 28 function 3 Intel 82801GB PCIE rev 0x02: msi pci5 at ppb4 bus 12 uhci0 at pci0 dev 29 function 0 Intel 82801GB USB rev 0x02: apic 1 int 16 uhci1 at pci0 dev 29 function 1 Intel 82801GB USB rev 0x02: apic 1 int 17 uhci2 at pci0 dev 29 function 2 Intel 82801GB USB rev 0x02: apic 1 int 18 uhci3 at pci0 dev 29 function 3 Intel 82801GB USB rev 0x02: apic 1 int 19 ehci0 at pci0 dev 29 function 7 Intel 82801GB USB rev 0x02: apic 1 int 19 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 ppb5 at pci0 dev 30 function 0 Intel 82801BAM Hub-to-PCI rev 0xe2 pci6 at ppb5 bus 21 cbb0 at pci6 dev 0 function 0 TI PCI1510 CardBus rev 0x00: apic 1 int 16 cardslot0 at cbb0 slot 0 flags 0 cardbus0 at cardslot0: bus 22 device 0 cacheline 0x8, lattimer 0xb0 pcmcia0 at cardslot0 pcib0 at pci0 dev 31
Re: still loosing connections
An other case of TL:DR???
Please help me with a 'clue-stick' on how to investigate further.
By now I use the very latest version as of Novemnber 1st:
OpenBSD 5.6-current (GENERIC.MP) #509: Sat Nov 1 00:18:49 MDT 2014
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
The settings are the same yet the issue is still unsolved - and I have
no idea what I am doing wrong...
BTW: Received my two copies of 5.6 yesterday in Germany: One for my
shelf, one to give away.
Again: Please help me as I am lost.
Thanks,
STEFAN
Am 10/26/14 um 09:59 schrieb Stefan Wollny:
Hi misc@!
I run OpenBSD-{amd64,i386}-current for several years now on 3
machines, having reinstalled everything late this summer because
s.th. related to either adsuck, ftp, cvs, pf or the netstack in
general feels broken.
I have complained before in the last weeks but unfortunatelly the
usually reliable strategy shut up - the devs know already - use
the next shnapshot seems to be not really successfull this
time...
Let me describe what I am doing and what happens (the laptop being
idefix @ 192.168.178.31): Running -current I try to use the
latest snapshot, being ~amd64 #477 from yesterday (dmesg below).
This is how I do it:
#!/bin/sh # print Laufwerk wechseln cd
/home/user/Downloads/amd64/ print Dateien loeschen rm * print
Dateien neu holen #wget
ftp://openbsd.cs.fau.de/pub/OpenBSD/snapshots/amd64/{IN*,SHA*,bsd*,*tgz}
#wget
ftp://ftp.hostserver.de/pub/OpenBSD/snapshots/amd64/{IN*,SHA*,bsd*,*tgz}
#wget ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/amd64/{IN*,SHA*,bsd*,*tgz}
wget
http://ftp.hostserver.de/pub/OpenBSD/snapshots/amd64/INSTALL.amd64
wget
http://ftp.hostserver.de/pub/OpenBSD/snapshots/amd64/SHA256{,.sig}
wget
http://ftp.hostserver.de/pub/OpenBSD/snapshots/amd64/bsd{,.rd,.mp}
wget
http://ftp.hostserver.de/pub/OpenBSD/snapshots/amd64/{base,comp,game,man}56.tgz
wget
http://ftp.hostserver.de/pub/OpenBSD/snapshots/amd64/x{base,font,serv,share}56.tgz
print Altes /bsd.rd sichern
sudo cp /bsd.rd /bsd.rd.1 print Neues /bsd.rd kopieren sudo cp -p
bsd.rd / print Neues bsd.mp als /bsd kopieren sudo cp -p bsd.mp
/bsd print /usr RW mounten sudo mount -uw /usr print untar
xfonts sudo tar -C / -xzphf xfont*.tgz print untar xserv sudo
tar -C / -xzphf xserv*.tgz print untar xshare sudo tar -C /
-xzphf xshare*.tgz print untar man sudo tar -C / -xzphf man*.tgz
print untar comp sudo tar -C / -xzphf comp*.tgz print untar
xbase sudo tar -C / -xzphf xbase*.tgz print untar base sudo tar
-C / -xzphf base*.tgz print run sysmerge sudo sysmerge print
mount /usr RO sudo mount -ur /usr cd
I switched to the http-protocol because of the issue desribed
below though it didn't help.
After updating the snapshot I _always_ update the apps and sources
like so:
#!/bin/sh # cd /tmp sudo mount -uw /usr print /usr/src updaten cd
/usr/src sudo cvs -q up -Pd print /usr/xenocara updaten cd
/usr/xenocara sudo cvs -q up -Pd print /usr/ports updaten cd
/usr/ports sudo cvs -q up -Pd cd print packages updaten sudo
pkg_add -ui print locate-db updaten sudo
/usr/libexec/locate.updatedb sudo mount -ur /usr
So my guess is that my system is up2date. Except that since
several weeks now both scripts suffer from the same shortcomming:
After some (non repeatable) time the network looses it's
connection. Not always, but way too often. And it doesn't matter if
I am at home wired or travelling using the mobile or the
hotel-wlan. It doesn't matter which mirror I use.
Simplyfying the observation it seems that the very moment the load
increases the connection decreases to zero.
I have gkrellm running at the side showing the network performance.
So please be patient with me as I have no scientifically valid test
data - only visual observation: The system is getting the fresh
data, at first at an acceptabel pace (e.g. 800 KB/s) but then
quickly gets slower and slower until connection to the net is
entirely lost. Not only ftp but http as well. Please do not get
mislead by the fact that /var/log/messages mentions adsuck -
without the behaviour is the same:
~ $ tail -f /var/log/messages Oct 25 23:28:28 idefix /bsd: drm:
PCIE GART of 512M enabled (table at 0x0004). Oct 25
23:28:28 idefix /bsd: radeondrm0: 1400x1050 Oct 25 23:28:28 idefix
/bsd: wsdisplay0 at radeondrm0 mux 1: console (std, vt100
emulation), using wskbd0 Oct 25 23:28:28 idefix /bsd: wskbd1:
connecting to wsdisplay0 Oct 25 23:28:28 idefix /bsd: wsdisplay0:
screen 1-5 added (std, vt100 emulation) Oct 25 23:28:44 idefix
savecore: no core dump Oct 25 23:29:09 idefix apmd: battery status:
high. external power status: connected. estimated battery life
100% Oct 25 23:30:09 idefix sensorsd[12040]: acpithinkpad0.temp5:
marked invalid Oct 25 23:30:09 idefix sensorsd[12040]:
acpithinkpad0.temp7: marked invalid Oct 25 23:30:09 idefix
sensorsd[12040]: acpidock0.indicator0: Off, UNKNOWN Oct 25
23:35:50
still loosing connections
Hi misc@!
I run OpenBSD-{amd64,i386}-current for several years now on 3 machines,
having reinstalled everything late this summer because s.th. related to
either adsuck, ftp, cvs, pf or the netstack in general feels broken.
I have complained before in the last weeks but unfortunatelly the
usually reliable strategy shut up - the devs know already -
use the next shnapshot seems to be not really successfull this time...
Let me describe what I am doing and what happens (the laptop being
idefix @ 192.168.178.31):
Running -current I try to use the latest snapshot, being ~amd64 #477
from yesterday (dmesg below). This is how I do it:
#!/bin/sh
#
print Laufwerk wechseln
cd /home/user/Downloads/amd64/
print Dateien loeschen
rm *
print Dateien neu holen
#wget
ftp://openbsd.cs.fau.de/pub/OpenBSD/snapshots/amd64/{IN*,SHA*,bsd*,*tgz}
#wget
ftp://ftp.hostserver.de/pub/OpenBSD/snapshots/amd64/{IN*,SHA*,bsd*,*tgz}
#wget ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/amd64/{IN*,SHA*,bsd*,*tgz}
wget http://ftp.hostserver.de/pub/OpenBSD/snapshots/amd64/INSTALL.amd64
wget http://ftp.hostserver.de/pub/OpenBSD/snapshots/amd64/SHA256{,.sig}
wget http://ftp.hostserver.de/pub/OpenBSD/snapshots/amd64/bsd{,.rd,.mp}
wget
http://ftp.hostserver.de/pub/OpenBSD/snapshots/amd64/{base,comp,game,man}56.tgz
wget
http://ftp.hostserver.de/pub/OpenBSD/snapshots/amd64/x{base,font,serv,share}56.tgz
print Altes /bsd.rd sichern
sudo cp /bsd.rd /bsd.rd.1
print Neues /bsd.rd kopieren
sudo cp -p bsd.rd /
print Neues bsd.mp als /bsd kopieren
sudo cp -p bsd.mp /bsd
print /usr RW mounten
sudo mount -uw /usr
print untar xfonts
sudo tar -C / -xzphf xfont*.tgz
print untar xserv
sudo tar -C / -xzphf xserv*.tgz
print untar xshare
sudo tar -C / -xzphf xshare*.tgz
print untar man
sudo tar -C / -xzphf man*.tgz
print untar comp
sudo tar -C / -xzphf comp*.tgz
print untar xbase
sudo tar -C / -xzphf xbase*.tgz
print untar base
sudo tar -C / -xzphf base*.tgz
print run sysmerge
sudo sysmerge
print mount /usr RO
sudo mount -ur /usr
cd
I switched to the http-protocol because of the issue desribed below
though it didn't help.
After updating the snapshot I _always_ update the apps and sources like so:
#!/bin/sh
#
cd /tmp
sudo mount -uw /usr
print /usr/src updaten
cd /usr/src
sudo cvs -q up -Pd
print /usr/xenocara updaten
cd /usr/xenocara
sudo cvs -q up -Pd
print /usr/ports updaten
cd /usr/ports
sudo cvs -q up -Pd
cd
print packages updaten
sudo pkg_add -ui
print locate-db updaten
sudo /usr/libexec/locate.updatedb
sudo mount -ur /usr
So my guess is that my system is up2date. Except that since several
weeks now both scripts suffer from the same shortcomming:
After some (non repeatable) time the network looses it's connection. Not
always, but way too often. And it doesn't matter if I
am at home wired or travelling using the mobile or the hotel-wlan. It
doesn't matter which mirror I use.
Simplyfying the observation it seems that the very moment the load
increases the connection decreases to zero.
I have gkrellm running at the side showing the network performance. So
please be patient with me as I have no scientifically
valid test data - only visual observation: The system is getting the
fresh data, at first at an acceptabel pace (e.g. 800 KB/s)
but then quickly gets slower and slower until connection to the net is
entirely lost. Not only ftp but http as well. Please do not get mislead
by the fact that
/var/log/messages mentions adsuck - without the behaviour is the same:
~ $ tail -f /var/log/messages
Oct 25 23:28:28 idefix /bsd: drm: PCIE GART of 512M enabled (table at
0x0004).
Oct 25 23:28:28 idefix /bsd: radeondrm0: 1400x1050
Oct 25 23:28:28 idefix /bsd: wsdisplay0 at radeondrm0 mux 1: console
(std, vt100 emulation), using wskbd0
Oct 25 23:28:28 idefix /bsd: wskbd1: connecting to wsdisplay0
Oct 25 23:28:28 idefix /bsd: wsdisplay0: screen 1-5 added (std, vt100
emulation)
Oct 25 23:28:44 idefix savecore: no core dump
Oct 25 23:29:09 idefix apmd: battery status: high. external power
status: connected. estimated battery life 100%
Oct 25 23:30:09 idefix sensorsd[12040]: acpithinkpad0.temp5: marked invalid
Oct 25 23:30:09 idefix sensorsd[12040]: acpithinkpad0.temp7: marked invalid
Oct 25 23:30:09 idefix sensorsd[12040]: acpidock0.indicator0: Off, UNKNOWN
Oct 25 23:35:50 idefix sensorsd[12040]: cpu0.temp0: exceeds limits:
75.00 degC is above 70.00 degC
Oct 25 23:35:50 idefix sensorsd[12040]: cpu1.temp0: exceeds limits:
75.00 degC is above 70.00 degC
Oct 25 23:35:50 idefix sensorsd[12040]: acpitz0.temp0: exceeds limits:
85.00 degC is above 70.00 degC
Oct 25 23:35:50 idefix sensorsd[12040]: acpitz1.temp0: exceeds limits:
86.00 degC is above 70.00 degC
Oct 25 23:35:50 idefix sensorsd[12040]: acpithinkpad0.temp0: exceeds
limits: 85.00 degC is above 70.00 degC
Oct 25 23:38:06 idefix ntpd[22421]: 2 out of 4 peers valid
Oct 25 23:38:06 idefix ntpd[22421]: bad peer from pool pool.ntp.org
(213.95.21.43)
Oct 25 23:38:06 idefix ntpd[22421]: bad peer from pool pool.ntp.org
