- This topic has 11 replies, 7 voices, and was last updated Nov 17-5:53 am by akathaddeus.
-
AuthorPosts
-
November 9, 2020 at 9:29 pm #44715Member
akathaddeus
A brief note about AntiX 19.2 on Core 2 Duo.
I recently updated a working 24/7 Linux box running on a T7200 processor (2006) with AntiX 19.2. Both the 32 bit and 64 bit versions of Antix caused random freezing to occur, typically within 24 hours. Tried a few different distributions then found a post on the Internet which attributed Linux freezes on Core 2 Duos to kernels 4.18+.
Tried upgrading to kernel 5.5.16 for 64 bit and 32 bit but these failed. Then tried downgrading to kernel 4.14.14 for 64 bit and that also failed. But kernel 4.14.14 for 32 bit stayed up. And that is good.
- This topic was modified 2 years, 6 months ago by akathaddeus.
November 9, 2020 at 9:39 pm #44718Forum Admin
anticapitalista
::Thanks for the info.
Just to clarify – are you saying that the default 4.9 antiX series kernels freeze?
Have you tried the 4.4 antiX series kernels?
Can you post the output of inxi -v8 – thanks.I have several Core 2 Duo laptops that work ok with the default antiX kernels.
- This reply was modified 2 years, 6 months ago by anticapitalista.
Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - leaner and meaner.
November 9, 2020 at 10:54 pm #44724Memberakathaddeus
::Hope you guys can find the cause. It was up for two days on 4.14 32 bit before the last reboot and it has been up two days since. Should have confidence in a week or so.
Both the default 4.9 kernels freeze. Until I came across the 4.18+ post I had tried 64 bit Debian Buster Stable, 64 bit OpenSUSE Leap and 32 bit Opensuse Tumbleweed using lightweight desktops also without success. Did not try 4.4 because after the 5.5 test as the 4.18+ post observation by then was given more weight. The T7200 before the upgrade had ran for 14 years on kernel 2.6 with no unresolved downtime so very confident about the hardware.
All the tested OSes installed and operated great during the upgrade (AntiX was the fastest) but all would on average freeze sometime during the next 24 hours.
System: Host: xxxxxx Kernel: 4.14.14-antix.1-486-smp i686 bits: 32 compiler: gcc v: 7.2.0 parameters: BOOT_IMAGE=/boot/vmlinuz-4.14.14-antix.1-486-smp root=UUID=24c84370-a852-458a-ac26-c80966c5bbde ro vga=791 quiet Console: tty 0 dm: SLiM 1.3.6 Distro: antiX-19.2_386-full Hannie Schaft 27 March 2020 base: Debian GNU/Linux 10 (buster) Machine: Type: Desktop Mobo: Gigabyte model: 8I945GMMFY-RH v: x.x serial: N/A BIOS: Award v: F1 date: 04/26/2006 Memory: RAM: total: 2.95 GiB used: 350.3 MiB (11.6%) Array-1: capacity: 2 GiB slots: 2 EC: None max module size: 1 GiB Device-1: A0 size: 1 GiB info: double-bank speed: 66 MT/s type: Unknown detail: none bus width: 64 bits total: 64 bits manufacturer: N/A part-no: None serial: None Device-2: A1 size: No Module Installed PCI Slots: Slot: 0 type: 32-bit PCI PCI status: Available length: Long Slot: 1 type: 32-bit PCI PCI status: Available length: Long CPU: Topology: Dual Core model: Intel Core2 T7200 bits: 64 type: MCP arch: Core Merom family: 6 model-id: F (15) stepping: 6 microcode: D1 L1 cache: 20 KiB L2 cache: 4096 KiB bogomips: 7980 Speed: 1207 MHz min/max: 600/1200 MHz Core speeds (MHz): 1: 1025 2: 1024 Flags: acpi aperfmperf apic arch_perfmon bts clflush cmov constant_tsc cpuid cx16 cx8 de ds_cpl dtes64 dtherm dts est fpu fxsr ht lahf_lm lm mca mce mmx monitor msr mtrr nx pae pat pbe pdcm pebs pge pni pse pse36 retpoline sep ss sse sse2 ssse3 tm tm2 tpr_shadow tsc vme vmx xtpr Vulnerabilities: Type: meltdown status: Vulnerable Type: spectre_v1 status: Vulnerable Type: spectre_v2 status: Vulnerable: Minimal generic ASM retpoline Graphics: Device-1: Intel Mobile 945GM/GMS 943/940GML Express Integrated Graphics vendor: Gigabyte driver: i915 v: kernel bus ID: 00:02.0 chip ID: 8086:27a2 Display: server: X.org 1.20.4 driver: intel unloaded: fbdev,modesetting,vesa tty: 147x121 Message: Advanced graphics data unavailable in console for root. Audio: Device-1: Intel NM10/ICH7 Family High Definition Audio vendor: Gigabyte GA-8I945PG-RH Mainboard driver: snd_hda_intel v: kernel bus ID: 00:1b.0 chip ID: 8086:27d8 Sound Server: ALSA v: k4.14.14-antix.1-486-smp Network: Device-1: Intel 82573L Gigabit Ethernet vendor: Gigabyte driver: e1000e v: 3.2.6-k port: a000 bus ID: 02:00.0 chip ID: 8086:109a IF: eth0 state: up speed: 1000 Mbps duplex: full mac: xxxxxx IP v4: xxxxxx scope: global broadcast: xxxxxx IP v6: fe80::216:e6ff:fe5c:58e4/64 scope: link WAN IP: xxxxxx Drives: Local Storage: total: 111.79 GiB used: 3.65 GiB (3.3%) ID-1: /dev/sda vendor: Samsung model: SSD 840 EVO 120GB size: 111.79 GiB block size: physical: 512 B logical: 512 B speed: <unknown> serial: S1D5NSBF198826M rev: BB6Q scheme: MBR Floppy-1: /dev/fd0 Optical-1: /dev/sr0 vendor: LITE-ON model: DVDRW LH-20A1P rev: KL0N dev-links: cdrom,cdrw,dvd,dvdrw Features: speed: 48 multisession: yes audio: yes dvd: yes rw: cd-r,cd-rw,dvd-r,dvd-ram state: running RAID: Hardware-1: Silicon Image SiI 3132 Serial ATA Raid II Controller driver: sata_sil24 v: kernel port: 9000 bus ID: 01:00.0 chip ID: 1095.3132 rev: 01 Partition: ID-1: / raw size: 109.76 GiB size: 107.53 GiB (97.97%) used: 3.65 GiB (3.4%) fs: ext4 block size: 4096 B dev: /dev/sda1 label: rootantiX19 uuid: 24c84370-a852-458a-ac26-c80966c5bbde ID-2: swap-1 size: 2.00 GiB used: 0 KiB (0.0%) fs: swap swappiness: 10 (default 60) cache pressure: 50 (default 100) dev: /dev/sda2 label: swapantiX uuid: 1a8fb0af-afb7-411d-a619-ea7b059673b5 Unmounted: Message: No unmounted partitions found. USB: Hub: 1-0:1 info: Full speed (or root) Hub ports: 8 rev: 2.0 speed: 480 Mb/s chip ID: 1d6b:0002 Device-1: 1-1:2 info: Realtek USB 2.0 Card Reader type: Mass Storage driver: usb-storage interfaces: 1 rev: 2.0 speed: 480 Mb/s chip ID: 0bda:0103 serial: 050304014271000121 Hub: 2-0:1 info: Full speed (or root) Hub ports: 2 rev: 1.1 speed: 12 Mb/s chip ID: 1d6b:0001 Hub: 3-0:1 info: Full speed (or root) Hub ports: 2 rev: 1.1 speed: 12 Mb/s chip ID: 1d6b:0001 Hub: 4-0:1 info: Full speed (or root) Hub ports: 2 rev: 1.1 speed: 12 Mb/s chip ID: 1d6b:0001 Hub: 5-0:1 info: Full speed (or root) Hub ports: 2 rev: 1.1 speed: 12 Mb/s chip ID: 1d6b:0001 Sensors: System Temperatures: cpu: 30.0 C mobo: N/A Fan Speeds (RPM): N/A Repos: Active apt repos in: /etc/apt/sources.list 1: deb http://mirror.datamossa.io/mxlinux/antix/buster/ buster main nosystemd nonfree No active apt repos in: /etc/apt/sources.list.d/antix.list Active apt repos in: /etc/apt/sources.list.d/buster-backports.list 1: deb http://deb.debian.org/debian/ buster-backports main contrib non-free Active apt repos in: /etc/apt/sources.list.d/debian-stable-updates.list 1: deb http://ftp.au.debian.org/debian/ buster-updates main contrib non-free Active apt repos in: /etc/apt/sources.list.d/debian.list 1: deb http://ftp.au.debian.org/debian/ buster main contrib non-free 2: deb http://security.debian.org/ buster/updates main contrib non-free No active apt repos in: /etc/apt/sources.list.d/onion.list No active apt repos in: /etc/apt/sources.list.d/various.list Processes: CPU top: 5 1: cpu: 0.4% command: su pid: 31046 mem: 3.14 MiB (0.1%) 2: cpu: 0.4% command: bash pid: 31047 mem: 3.96 MiB (0.1%) 3: cpu: 0.1% command: [kworker/0:1] pid: 20 mem: 0.00 MiB (0.0%) 4: cpu: 0.1% command: nxserver.bin pid: 2138 mem: 58.5 MiB (1.9%) 5: cpu: 0.1% command: nxnode.bin pid: 2694 mem: 55.7 MiB (1.8%) Memory top: 5 1: mem: 58.5 MiB (1.9%) command: nxserver.bin pid: 2138 cpu: 0.1% 2: mem: 56.3 MiB (1.8%) command: apt-notifier.py started by: python pid: 2593 cpu: 0.0% 3: mem: 55.7 MiB (1.8%) command: nxnode.bin pid: 2694 cpu: 0.1% 4: mem: 32.9 MiB (1.0%) command: xorg pid: 2091 cpu: 0.0% 5: mem: 30.7 MiB (1.0%) command: nxclient.bin pid: 2711 cpu: 0.0% Info: Processes: 122 Uptime: 2d 1h 50m Init: SysVinit v: 2.93 runlevel: 5 default: 5 Compilers: gcc: 8.3.0 alt: 8 Shell: bash v: 5.0.3 running in: tty 0 (SSH) inxi: 3.0.36`
November 10, 2020 at 8:48 am #44733Member
Xecure
::If 4.14 works for you, keep it like that.
It would be good to see if a 4.4 kernel also works for you, as anticapitalista has patched many security updates for this kernel version.
See the latest patched kernel versions:
https://antixlinux.com/fixed-bluez-security-vulnerabilities-kernels-available/antiX Live system enthusiast.
General Live Boot Parameters for antiX.November 10, 2020 at 9:12 am #44735MemberModdIt
::Did you do or have any maintenance done, 14 years is a very long time.
No experience of problems with core 2 duo systems.you wrote: All the tested OSes installed and operated great during the upgrade but all
would on average freeze sometime during the next 24 hours.I would be looking at hardware as common factor.
Experienced on older devices:
Random crashes experienced due to dried up cooling paste between processor and heatsink,
this includes any other chips with a cooler, pads dry and fail too not just paste.Lately I have also had swollen/failed PSU Capacitors. Failed smoothing/buffer capacitors
near PSU connector on board. Fans stopping due dry bearings. Poor contact memory module.I did not see that your board is called ultra durable so maybe still has older wet electrolyte
capacitors. Even hardly visible swelling is a sign of failing.November 10, 2020 at 8:57 pm #44770MemberMinux1
::Have an old Panasonic CF-19 laptop with a Core 2 DUO core … with MX Linux 19.2 64 bit (antiX’s big brother) installed on it now it’s blazing fast. It was sluggish with Windows 10 Pro but with Linux no resource sucking AV suite in tow it’s very fast. It’s fully booted up almost before my finger is completely off the ENTER key.
- This reply was modified 2 years, 6 months ago by Minux1.
November 10, 2020 at 9:19 pm #44773Memberakathaddeus
::It’s been up for three days now.
Yep pleased that the thing ran non stop for 14 years and agree it’s getting on a bit. But pretty sure its not the hardware. The OS switchover from 2.6 was on a running system. It’s headless with a 35w TPD mobile processor that idles at ambient +10c with an undemanding workload.
I’ll report back in a couple of weeks to confirm 4.14 stability. I might give the 4.4 a go after that.
November 11, 2020 at 8:57 am #44784MemberModdIt
::This is not a jab at akathaddeus !.
Maybe this should be in the WIKI in capital letters.
One misconception I keep on meeting is that a computer should run forever without loss of performance.
Performance is not just software dependant. I get asked a lot of times to reinstall an OS due performance
issues. The OS is rarely to blame with exception of the bloat from a fanious us company.Performance depends on Power supply, clean power = capacitors in good condition, cooling sufficient. Fan clean.
CPU and GPU performance and service life depend on efficient cooling, those without heat spreader caps,
which were a and are a form of corporate desperation to mitigate local hotspots are more demanding on the
interface cooler chip.
That applies no matter whether heatpipe or the in desktop devices more common chunk of aluminium or
the more expensive and better conductive copper.A system with a low load will still have high CPU transient temperatures, usualy localised, chips break down
internaly with time a big factor is the internal layer connectors failing due to expansion and contraction,
the hotter they get the more they expand until plasticity point. After that connectors vapourise and the chip
goes bang. More often it just quietly fails.This is general:
Many devices I open are filthy, laptops full of cat or dog hairs dust dirt and bugs which cause
allergy inducing poop to be blown in to rooms by the struggling cooling fans. Floorstanding towers come along with
something looking like a rats nest inside.Laptop maintenance is more involved but on desktop and floorstanding systems an about hour of maintence every couple
of years will keep your device running with maximum performance and safety.Safety Yes PSU fires happenv occasionaly when the heap of combustible crud inside ignites.
life of capacitors is in part temperature dependant, if they are covered in crud they fail more quickly, some
spewing out aluminium foil and electrolyte which may well kill a device due short circuit or at least make a repair way
more expensive than neccesary.November 11, 2020 at 8:42 pm #44812Member
fungalnet
::I have 2 c2d machines running and I’ve used kernels from 3.16 to 5.8 in antix, void, and arch-based/obarun and none have ever had any issue. I have used a third which I haven’t personally touched for a year, I think it had 5.3 or 5.4 last I’d seen it. No problems. But all three are very different machines, a huge family of cpu and other hw related to c2d. Have you had the RAM tested, maybe there is bad sector/module in it that is failing when used.
anti-X - Adélie - obarun - systemd Free Space
November 11, 2020 at 10:39 pm #44814Memberakathaddeus
::Thanks for the suggestions. Good to hear that Core 2 Duos are running fine for others.
The system has failed after 4.5 days of idle. So back to square 1. Memory tests OK. Maybe board specific.
In looking at it further there seems to be a bit of chit chat about i915 GPU problems which may cause random lock ups . I’m gonna take a look into that. Maybe also turning ACPI off. Both areas had warnings in the syslog.
November 15, 2020 at 3:41 pm #45074ModeratorBobC
::Are you overclocked now, or has the system been overclocked or overheated in the past?
I had this problem many years ago when I would try to push them harder than they could handle. If it was the CPU, temps usually would go too high. I would also see if you can get it to run a memory test for a week or two using an OS that it has been completely stable with to see if the problem is hardware or software.
November 17, 2020 at 5:53 am #45204Memberakathaddeus
::Nothing as exciting as overclocking. Just a boring back-end system 🙂
Anyway, to close this off…
After having a snoop around my conclusion was that as the i915 depends on ACPI the freezes likely arose from the ACPI/i915 memory conflicts recorded in syslog. Root cause was probably the very old ACPI tables in the firmware for which there is no update.
I ended up restoring the kernel to default 4.9.212 for 19.2, leaving ACPI on and setting INIT to level 3 so that it boots into console to avoid using i915. Rather than setting ACPI off or nobbling i915 this seemed to have achieved stability for the headless installation needed. In this way X can be started on the physical display for short periods at minor risk if needed or remotely accessed on a virtual display risk free.
It’s been up for 6 days now with intermittent remote desktop workload, so should be OK. Reverted to 64 bit for the longer term. This was not a Core 2 Duo problem after all. I’ll post an update if the thing should unexpectedly fall over again. Thanks for the help guys.
-
AuthorPosts
- You must be logged in to reply to this topic.