system freezes

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
26 messages Options
12
Xen
Reply | Threaded
Open this post in threaded view
|

system freezes

Xen
So I have a number of unknowns:



  - nvidia RAID (works fine in Windows)




  - LVM dm-cache of the root device

What happens is at least the following:

  - keyboard repetition regularly stops

  - the entire KDE environment sometimes freezes, sometimes it recovers,
sometimes it doesn't.

  - it will freeze upon writes (saves)
  - last time the application successfully exited while saving but the
KDE screen was frozen


  - but sometimes it also freezes while I'm not doing anything in
particular.

Sometimes /etc/init.d/sddm restart works, sometimes it doesn't.

Sometimes ctrl-alt-f1 responds instantly, sometimes it takes a minute.

It seems more a KDE issue than anything else honestly.


Since this is a 4.10 kernel, the GTX 950 that is running inside, is
supported by Nouveau.

Currently don't have broadband internet so I can't go and download big
things.

I haven't checked top yet (for cpu consumption)

but

vmstat -d shows nothing unusual (as in queues)

Also there appear to be no messages in the console but I guess those
only appear when you are in it?

Fairly annoying.

I mean the nVidia raid appears to be not entirely stable (in Linux)

But that thing only crashed once thus far while heavy writing :p.

I have no clue what could be causing it this time, I guess this is more
a Kubuntu question than anything else,

but quite a bit annoying, let's just say debilitating.

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: system freezes

compdoc
On 11/08/2017 04:21 AM, Xen wrote:

> I have no clue what could be causing it this time

What you describe is often what happens when a power supply or hard
drive begins to fail.

Cheap power supplies often fail after a year of continuous use, when the
tops of small capacitors inside begin to bulge. But there can also be
components that burn up from power surges, because cheaper PSUs have
little to no surge protection built in. I had to replace several a year
for customers. but after switching to 80+ certified power supplies, that
problem went away and they last for years.

Of course, thats not to say that expensive PSUs dont fail, because they
do. And drives fail as well, but those are easier to check - you just
have to read the SMART info stored within the drives. But if SMART
errors were happening, your raid controller would be dropping them from
the array.



--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Xen
Reply | Threaded
Open this post in threaded view
|

Re: system freezes

Xen
compdoc schreef op 08-11-2017 15:06:
> On 11/08/2017 04:21 AM, Xen wrote:
>
>> I have no clue what could be causing it this time
>
> What you describe is often what happens when a power supply or hard
> drive begins to fail.
>
> Cheap power supplies often fail after a year of continuous use, when
> the tops of small capacitors inside begin to bulge.

My system runs fine in Windows.

PSU is older but A-brand.

> And drives fail as well, but those are easier to check - you
> just have to read the SMART info stored within the drives. But if
> SMART errors were happening, your raid controller would be dropping
> them from the array.

I can't completely discount the raid but when plasma stops responding
this can be indicative of write problems.

To files I mean.

So there can be some IO lock.

The only thing I can do to verify is run a script in the background that
does vmstat -d on the root and cache device and logs it to a file.

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: system freezes

compdoc
On 11/08/2017 07:27 AM, Xen wrote:

> My system runs fine in Windows.

I hear that a lot. Try live booting from a dvd or usb stick, to rule out
your OS.

IRQ conflicts used to cause problems, but I dont see a lot of that these
days. You can try removing all but the most necessary cards, and moving
cards to different slots.



--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Xen
Reply | Threaded
Open this post in threaded view
|

Re: system freezes

Xen
compdoc schreef op 08-11-2017 15:34:

> On 11/08/2017 07:27 AM, Xen wrote:
>
>> My system runs fine in Windows.
>
> I hear that a lot. Try live booting from a dvd or usb stick, to rule
> out your OS.
>
> IRQ conflicts used to cause problems, but I dont see a lot of that
> these days. You can try removing all but the most necessary cards, and
> moving cards to different slots.

I know I can do a shitload of troubleshooting but I don't have time for
that now.

Busy week.

I was running live Ubuntu 14.04 for a while but no issues, but also not
running from raid or dm-cache.

I have also been a bit in live Kubuntu 16.04 with this system and/or
15.10 but no issues then.

So I still think it could be either the raid or the dm-cache, but I
suspect dm-cache more.

I conconted this script for now:




#!/bin/bash

devs="msata-root msata-root_cache_cdata"

declare -A dms

for f in $devs; do
         dms[$f]="dm-$(dmsetup info $f -c -o major,minor --noheadings |
cut -d: -f2)"
done

grepar=$(echo ${dms[@]} | sed "s/\s/\\\\|/g")

i=0
while true; do
         { [ $(( i % 7)) -eq 0 ] && { date; echo; }
         vmstat -d | grep "$grepar"
         echo; } | tee -a /var/log/vmstat.log
         i=$(( i++ ))
         sleep 8s
done


With a bit of luck I will at least have queue stats when next my system
freezes.

Regards.

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Xen
Reply | Threaded
Open this post in threaded view
|

Re: system freezes

Xen
Xen schreef op 08-11-2017 15:54:

> With a bit of luck I will at least have queue stats when next my system
> freezes.

Script now also lists all processes in uninterruptable sleep when there
is any queue item in vmstat :p.

#!/bin/bash

devs="msata-root msata-root_cache_cdata"

declare -A dms

for f in $devs; do
         dms[$f]="dm-$(dmsetup info $f -c -o major,minor --noheadings |
cut -d: -f2)"
done

grepar=$(echo ${dms[@]} | sed "s/\s/\\\\|/g")

i=0
while true; do
         {
                 [ $(( i % 7)) -eq 0 ] && { date; echo; }
                 a=$(vmstat -d | grep "$grepar")

                 echo "$a"

                 [ "$(echo "$a" | tr -s ' '  | cut -d' ' -f10)" != 0 ] &&
{
                         ps aux | grep " D" | grep -v grep
                         echo
                 }

         } | tee -a /var/log/vmstat.log
         i=$(( i++ ))
         sleep 8s
done






But enough for now.

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: system freezes

Ralf Mardorf-2
In reply to this post by compdoc
On Wed, 8 Nov 2017 07:06:24 -0700, compdoc wrote:
>What you describe is often what happens when a power supply or hard
>drive begins to fail.

Hi,

when I experienced issues as described by the OP, it often was either
CMOS related or a HDD at the end of it's life cycle.

Sometimes just clearing the CMOS (BIOS) thingy solved issues, sometimes
it was required to replace the battery. It's similar for HDDs,
sometimes disconnecting and then connecting the SATA cables again solved
issues, sometimes a new HDD was needed.

An important note, SMART and Co not necessarily report any HDD issue,
neither claims the BIOS that something is fishy or that the battery is
empty.

Regards,
Ralf


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Xen
Reply | Threaded
Open this post in threaded view
|

Re: system freezes

Xen
Ralf Mardorf schreef op 08-11-2017 16:42:

> On Wed, 8 Nov 2017 07:06:24 -0700, compdoc wrote:
>> What you describe is often what happens when a power supply or hard
>> drive begins to fail.
>
> Hi,
>
> when I experienced issues as described by the OP, it often was either
> CMOS related or a HDD at the end of it's life cycle.
>
> Sometimes just clearing the CMOS (BIOS) thingy solved issues, sometimes
> it was required to replace the battery. It's similar for HDDs,
> sometimes disconnecting and then connecting the SATA cables again
> solved
> issues, sometimes a new HDD was needed.
>
> An important note, SMART and Co not necessarily report any HDD issue,
> neither claims the BIOS that something is fishy or that the battery is
> empty.

Well there is another rather weird thing.

The time runs slower in Linux.

However the CMOS battery is quite new.

Windows generally doesn't regularly update the time from the internet so
since Windows does not or did not seem to suffer this problem, I wonder
what could be going on.

KDE just froze, I checked my logfile, there was nothing fishy in it.

By accident the script always checked all "D" state processes.

There weren't any from plasma.

Only from time to time jbd2 and kworker.

So now I know the time runs behind.

It didn't do that before to my recollection but this system is very new.

As in the linux installation is very new and I hadn't really used it
yet.

So thank you for the hint for CMOS, but how can that cause harddisk or
KDE failure?

The background system still runs fine.

Ehm...

There is this CUPS in dmesg:

[   18.934182] audit: type=1400 audit(1510139614.277:21):
apparmor="DENIED" operation="capable" profile="/usr/sbin/cupsd" pid=1928
comm="serial" capability=21  capname="sys_admin"

But printing works fine.

Then there is weirdness about the clock:

[ 3639.891181] clocksource: timekeeping watchdog on CPU2: Marking
clocksource 'tsc' as unstable because the skew is too large:
[ 3639.891202] clocksource:                       'hpet' wd_now:
301bc391 wd_last: 90a8ad86 mask: ffffffff
[ 3639.891206] clocksource:                       'tsc' cs_now:
9cb4474a36c cs_last: 98264db91aa mask: ffffffffffffffff
[ 3639.896980] clocksource: Switched to clocksource hpet



Then there are multi-core issues in dmesg:

[10193.796843] INFO: rcu_sched self-detected stall on CPU
[10193.796850] INFO: rcu_sched self-detected stall on CPU
[10193.796870]  3-...: (3 GPs behind) idle=61f/1/0 softirq=304876/304876
fqs=0
[10193.796874] INFO: rcu_sched self-detected stall on CPU
[10193.796879]
[10193.796887]  (t=15260 jiffies g=199741 c=199740 q=6)
[10193.796895]  2-...: (1 GPs behind) idle=a75/1/0 softirq=308395/308395
fqs=0
[10193.796903] rcu_sched kthread starved for 15260 jiffies! g199741
c199740 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x1
[10193.796904]
[10193.796909] rcu_sched       S
[10193.796913]  (t=15260 jiffies g=199741 c=199740 q=6)
[10193.796918]     0     7      2 0x00000000
[10193.796924] rcu_sched kthread starved for 15260 jiffies! g199741
c199740 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x1

Follows is a calltrace.

[18816.691512] INFO: rcu_sched self-detected stall on CPU
[18816.691530]  0-...: (1 GPs behind) idle=853/1/0 softirq=415479/415480
fqs=0
[18816.691533]   (t=18086 jiffies g=292162 c=292161 q=103)
[18816.691545] rcu_sched kthread starved for 18086 jiffies! g292162
c292161 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x1
[18816.691549] rcu_sched       S    0     7      2 0x00000000
[18816.691554] Call Trace:
[18816.691566]  __schedule+0x232/0x700
[18816.691571]  schedule+0x36/0x80
[18816.691575]  schedule_timeout+0x1ea/0x3f0
[18816.691580]  ? del_timer_sync+0x50/0x50
[18816.691586]  rcu_gp_kthread+0x551/0x910
[18816.691592]  kthread+0x109/0x140
[18816.691596]  ? rcu_note_context_switch+0x100/0x100
[18816.691601]  ? kthread_create_on_node+0x60/0x60
[18816.691606]  ret_from_fork+0x2c/0x40
[18816.691624] Task dump for CPU 0:
[18816.691626] swapper/0       R  running task        0     0      0
0x00000008
[18816.691630] Call Trace:
[18816.691632]  <IRQ>
[18816.691637]  sched_show_task+0xcd/0x130
[18816.691641]  dump_cpu_task+0x37/0x40
[18816.691646]  rcu_dump_cpu_stacks+0x94/0xba
[18816.691651]  rcu_check_callbacks+0x747/0x890
[18816.691656]  ? update_wall_time+0x483/0x7a0
[18816.691661]  ? tick_sched_handle.isra.15+0x60/0x60
[18816.691665]  update_process_times+0x2f/0x60
[18816.691670]  tick_sched_handle.isra.15+0x25/0x60
[18816.691674]  tick_sched_timer+0x3d/0x70
[18816.691678]  __hrtimer_run_queues+0xf3/0x280
[18816.691683]  hrtimer_interrupt+0xb1/0x200
[18816.691689]  local_apic_timer_interrupt+0x38/0x60
[18816.691693]  smp_apic_timer_interrupt+0x38/0x50
[18816.691698]  apic_timer_interrupt+0x89/0x90
[18816.691702] RIP: 0010:native_safe_halt+0x6/0x10
[18816.691705] RSP: 0018:ffffffffbd403de8 EFLAGS: 00000246 ORIG_RAX:
ffffffffffffff10
[18816.691709] RAX: 0000000000000000 RBX: ffffffffbd410500 RCX:
0000000000000003
[18816.691711] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
ffffffffbd89b79c
[18816.691713] RBP: ffffffffbd403de8 R08: 0100000000000000 R09:
00000000ffffffe0
[18816.691715] R10: 0000000000000000 R11: 000000000001d1c8 R12:
0000000000000000
[18816.691717] R13: ffffffffbd410500 R14: 0000000000000000 R15:
0000000000000000
[18816.691719]  </IRQ>
[18816.691725]  default_idle+0x1e/0xd0
[18816.691730]  amd_e400_idle+0x23/0x50
[18816.691733]  arch_cpu_idle+0xf/0x20
[18816.691737]  default_idle_call+0x23/0x30
[18816.691742]  do_idle+0x165/0x1f0
[18816.691746]  cpu_startup_entry+0x71/0x80
[18816.691751]  rest_init+0x77/0x80
[18816.691756]  start_kernel+0x482/0x4a3
[18816.691761]  ? early_idt_handler_array+0x120/0x120
[18816.691765]  x86_64_start_reservations+0x24/0x26
[18816.691769]  x86_64_start_kernel+0x143/0x166
[18816.691774]  start_cpu+0x14/0x14

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Xen
Reply | Threaded
Open this post in threaded view
|

Re: system freezes

Xen
Xen schreef op 08-11-2017 18:28:

> Then there is weirdness about the clock:
>
> [ 3639.891181] clocksource: timekeeping watchdog on CPU2: Marking
> clocksource 'tsc' as unstable because the skew is too large:
> [ 3639.891202] clocksource:                       'hpet' wd_now:
> 301bc391 wd_last: 90a8ad86 mask: ffffffff
> [ 3639.891206] clocksource:                       'tsc' cs_now:
> 9cb4474a36c cs_last: 98264db91aa mask: ffffffffffffffff
> [ 3639.896980] clocksource: Switched to clocksource hpet

JournalD also contains:

nov 08 16:46:47 xen-linux rtkit-daemon[2574]: The canary thread is
apparently starving. Taking action.
nov 08 16:46:47 xen-linux rtkit-daemon[2574]: Demoting known real-time
threads.
nov 08 16:46:47 xen-linux rtkit-daemon[2574]: Successfully demoted
thread 6778 of process 2573 (n/a).
nov 08 16:46:47 xen-linux rtkit-daemon[2574]: Demoted 1 threads.
nov 08 16:48:42 xen-linux dbus[1301]: [system] Activating via systemd:
service name='org.freedesktop.timedate1'
nov 08 16:48:42 xen-linux systemd[1]: Starting Time & Date Service...
nov 08 16:48:42 xen-linux dbus[1301]: [system] Successfully activated
service 'org.freedesktop.timedate1'
nov 08 16:48:42 xen-linux systemd[1]: Started Time & Date Service.
nov 08 16:48:51 xen-linux systemd[1]: Reloading.
nov 08 16:48:51 xen-linux systemd[1]: Started ACPI event daemon.
nov 08 16:48:51 xen-linux systemd[1]: Started CUPS Scheduler.
nov 08 16:48:51 xen-linux systemd-timedated[22410]: Set NTP to enabled
nov 08 16:48:51 xen-linux systemd[1]: Starting Network Time
Synchronization...
nov 08 16:48:51 xen-linux colord[1824]: (colord:1824): Cd-WARNING **:
failed to get session [pid 22445]: No suc
nov 08 16:48:51 xen-linux systemd-timesyncd[22446]: The system is
configured to read the RTC time in the local
nov 08 16:48:51 xen-linux systemd[1]: Started Network Time
Synchronization.
nov 08 16:48:51 xen-linux systemd[1]: Reached target System Time
Synchronized.
nov 08 17:27:16 xen-linux systemd[2383]: Time has been changed
nov 08 17:27:16 xen-linux systemd-timesyncd[22446]: Synchronized to time
server 91.189.89.199:123 (ntp.ubuntu.c
nov 08 17:27:16 xen-linux systemd[1]: Time has been changed
nov 08 17:27:16 xen-linux systemd[1912]: Time has been changed

This was the moment I turned on automatic sync.

But I actually set the clock like yesterday.

So I guess it is CMOS battery time after all.

:-/.

The battery is not older than a few months.

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: system freezes

compdoc
On 11/08/2017 10:32 AM, Xen wrote:

> Xen schreef op 08-11-2017 18:28:
>
>
>
> But I actually set the clock like yesterday.
>
> So I guess it is CMOS battery time after all.
>
> :-/.
>
> The battery is not older than a few months.
>

Does it look like the bios settings have changed? is ahci, acpi, etc
enabled?

I would even check to see that ram is being detected properly and
running at their rated speed.


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: system freezes

Ralf Mardorf-2
In reply to this post by Xen
On Wed, 08 Nov 2017 18:28:02 +0100, Xen wrote:
>So thank you for the hint for CMOS, but how can that cause harddisk or
>KDE failure?

I don't know, I only could take a wild guess. I guess that all IO
operations are done by Linux, OTOH it's possible to set some PCI
latency settings, RAM settings and other critical settings as well.
Important parts of the hardware are seemingly controlled by the BIOS,
even if the operating system shouldn't make usage of BIOS routines.

Another good question is, why should clearing the CMOS thingy make any
difference, if the battery isn't empty? One explanation would be that
something is fishy, but I would expect that clearing a fishy CMOS would
solve issues just for a short time and then it would fail again.

Actually after clearing CMOS and restoring all settings from a backup I
got rid of issues, not just for a short time.

Btw. the selected settings shown by the BIOS were always ok, there must
be something under the hood that required clearing the BIOS. I also had
a mobo with a completely empty battery, that only required to set date
and time each time the power was turned off, apart from this there were
no issues at all.


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: system freezes

Colin Law
In reply to this post by Xen
On 8 November 2017 at 17:32, Xen <[hidden email]> wrote:

> Xen schreef op 08-11-2017 18:28:
>
>> Then there is weirdness about the clock:
>>
>> [ 3639.891181] clocksource: timekeeping watchdog on CPU2: Marking
>> clocksource 'tsc' as unstable because the skew is too large:
>> [ 3639.891202] clocksource:                       'hpet' wd_now:
>> 301bc391 wd_last: 90a8ad86 mask: ffffffff
>> [ 3639.891206] clocksource:                       'tsc' cs_now:
>> 9cb4474a36c cs_last: 98264db91aa mask: ffffffffffffffff
>> [ 3639.896980] clocksource: Switched to clocksource hpet
>
>
> JournalD also contains:
>
> nov 08 16:46:47 xen-linux rtkit-daemon[2574]: The canary thread is
> apparently starving. Taking action.
> nov 08 16:46:47 xen-linux rtkit-daemon[2574]: Demoting known real-time
> threads.
> nov 08 16:46:47 xen-linux rtkit-daemon[2574]: Successfully demoted thread
> 6778 of process 2573 (n/a).
> nov 08 16:46:47 xen-linux rtkit-daemon[2574]: Demoted 1 threads.
> nov 08 16:48:42 xen-linux dbus[1301]: [system] Activating via systemd:
> service name='org.freedesktop.timedate1'
> nov 08 16:48:42 xen-linux systemd[1]: Starting Time & Date Service...
> nov 08 16:48:42 xen-linux dbus[1301]: [system] Successfully activated
> service 'org.freedesktop.timedate1'
> nov 08 16:48:42 xen-linux systemd[1]: Started Time & Date Service.
> nov 08 16:48:51 xen-linux systemd[1]: Reloading.
> nov 08 16:48:51 xen-linux systemd[1]: Started ACPI event daemon.
> nov 08 16:48:51 xen-linux systemd[1]: Started CUPS Scheduler.
> nov 08 16:48:51 xen-linux systemd-timedated[22410]: Set NTP to enabled
> nov 08 16:48:51 xen-linux systemd[1]: Starting Network Time
> Synchronization...
> nov 08 16:48:51 xen-linux colord[1824]: (colord:1824): Cd-WARNING **: failed
> to get session [pid 22445]: No suc
> nov 08 16:48:51 xen-linux systemd-timesyncd[22446]: The system is configured
> to read the RTC time in the local
> nov 08 16:48:51 xen-linux systemd[1]: Started Network Time Synchronization.
> nov 08 16:48:51 xen-linux systemd[1]: Reached target System Time
> Synchronized.
> nov 08 17:27:16 xen-linux systemd[2383]: Time has been changed
> nov 08 17:27:16 xen-linux systemd-timesyncd[22446]: Synchronized to time
> server 91.189.89.199:123 (ntp.ubuntu.c
> nov 08 17:27:16 xen-linux systemd[1]: Time has been changed
> nov 08 17:27:16 xen-linux systemd[1912]: Time has been changed
>
> This was the moment I turned on automatic sync.
>
> But I actually set the clock like yesterday.
>
> So I guess it is CMOS battery time after all.

I *think* but not certain that the time is read from the real time
clock only on boot (and from suspend I supose) and from then on it is
irrelevant. If so then if the time is drifting when the power is on it
is not a cmos issue. I think it is a different issue you are seeing.

Colin

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Xen
Reply | Threaded
Open this post in threaded view
|

Re: system freezes

Xen
In reply to this post by Ralf Mardorf-2
Ralf Mardorf schreef op 08-11-2017 21:58:
> On Wed, 08 Nov 2017 18:28:02 +0100, Xen wrote:
>> So thank you for the hint for CMOS, but how can that cause harddisk or
>> KDE failure?
>
> I don't know, I only could take a wild guess.

I still think you are on to something.

My BIOS does weird stuff (shit) all the time, probably also because I
use a mains disconnector to switch off the power now and then.

For example, if I turn it on and it automatically comes on (bios
setting) if I turn it off again quickly after that because I change my
mind,

it won't come on after that.

I have to walk to the computer (which is hard for me)

because the BIOS fails to turn the PC on again.

My USB also got corrupted after I booted Linux for the first time.

On this mainboard.

After reboot in Windows lots of stuff doesn't work.

The score is now like this:



- after reboot from Windows, the SD card I use to boot Linux, is not
recognised by the BIOS

- after reboot from Linux, the 3G stick I use to access the internet is
not recognised by Windows, or doesn't work until I reset it

- after I reboot from Linux, many devices in Windows can keep
malfunctioning (USB)

- many times after a cold boot the BIOS screen won't show the "Press F8
for boot menu" line until I boot into Windows for 1 second and then
press ctrl-alt-del.

There is so much fishy behaviour that I think you are entirely right.

- even after a completely cold boot, after I was in Linux for the first
time,

many cheap USB2 hubs do not function any more, I cannot use a DVD player
(in Windows) on them, in BIOS it works fine and I can boot from it, but
Windows driver functioning is destroyed.

In Linux it often also doesn't work I think. The only reliable way to
use the dvd burner is to use a USB 3 card,

which is annoying because of the distance.

This is an Asus M2N motherboard, M2N-E, it's a horror.

Well, since I booted Linux.

> Btw. the selected settings shown by the BIOS were always ok, there must
> be something under the hood that required clearing the BIOS. I also had
> a mobo with a completely empty battery, that only required to set date
> and time each time the power was turned off, apart from this there were
> no issues at all.

No I think you are correct.

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: system freezes

Ralf Mardorf-2
On Thu, 09 Nov 2017 08:29:20 +0100, Xen wrote:
>This is an Asus M2N motherboard, M2N-E, it's a horror.

My experiences were clearing CMOS solved issues (usually with replacing
the battery, too) was with my previous mobo an ASUS M2A-VM HDMI without
the HDMI thingy mounted. The BIOS technology is called "ASUS EZ Flash
2"/"ASUS CrashFree BIOS 3", IOW the same as provided by your mobo, let
alone that my old mobo also was for DDR2 RAM, provided SATA 3Gb/s, USB2
and the socket was AM2.

I can't comment on the timer issue, since my AMD CPU used with the ASAU
mobo didn't provide TSC, it only had HPET (HRTIMER).

The wiki claims...

"AMD processors up to the K8 core always incremented the time-stamp
counter every clock cycle.[6] Thus, power management features were able
to change the number of increments per second, and the values could get
out of sync between different cores or processors in the same system.
For Windows, AMD provides a utility[7] to periodically synchronize the
counters on multiple core CPUs. Since the family 10h
(Barcelona/Phenom), AMD chips feature a constant TSC, which can be
driven either by the HyperTransport speed or the highest P state. A
CPUID bit (Fn8000_0007:EDX_8) advertises this." -
https://en.wikipedia.org/wiki/Time_Stamp_Counter

...and it provides a link: https://lkml.org/lkml/2005/11/4/173



--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Xen
Reply | Threaded
Open this post in threaded view
|

Re: system freezes

Xen
Ralf Mardorf schreef op 09-11-2017 9:52:

> On Thu, 09 Nov 2017 08:29:20 +0100, Xen wrote:
>> This is an Asus M2N motherboard, M2N-E, it's a horror.
>
> My experiences were clearing CMOS solved issues (usually with replacing
> the battery, too) was with my previous mobo an ASUS M2A-VM HDMI without
> the HDMI thingy mounted. The BIOS technology is called "ASUS EZ Flash
> 2"/"ASUS CrashFree BIOS 3", IOW the same as provided by your mobo, let
> alone that my old mobo also was for DDR2 RAM, provided SATA 3Gb/s, USB2
> and the socket was AM2.
>
> I can't comment on the timer issue, since my AMD CPU used with the ASAU
> mobo didn't provide TSC, it only had HPET (HRTIMER).

I reset the CMOS but no difference.

[ 4276.865023] clocksource: timekeeping watchdog on CPU3: Marking
clocksource 'tsc' as unstable because the skew is too large:
[ 4276.865027] clocksource:                       'hpet' wd_now:
e559648a wd_last: 30656759 mask: ffffffff
[ 4276.865037] clocksource:                       'tsc' cs_now:
a42bfbbea74 cs_last: 9f8e57ce8e2 mask: ffffffffffffffff
[ 4276.870912] clocksource: Switched to clocksource hpet

It took a while I guess, more than an hour?

All I can do is replace the battery, otherwise this mobo is not fit for
Linux.

It's incredible.

I shall not say how many mobos I have recently tried and there was an
issue with every one of them.

This Mobo does not stably support my 2.1V 1066 memory even though it
should. I mean, oops, it only does 1.95V.

The other one that I threw away...

Anyway.

The only good mobo was the original one I had that got... wasted for
some reason.

I have had a:

Abit AX78
Asus M2N-E SLI
Asus M2N-E
Asus M3N-something
Asrock something.

I wish I still had the M3N.

I agreed to trade it with someone and what I got in return was shit.

I wanted to humour the guy and in return he basically treated me like
shit.

Never do stuff for another person.

Everyone will betray you.

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: system freezes

Nils Kassube-2
Xen wrote:

> I reset the CMOS but no difference.
>
> [ 4276.865023] clocksource: timekeeping watchdog on CPU3: Marking
> clocksource 'tsc' as unstable because the skew is too large:
> [ 4276.865027] clocksource:                       'hpet' wd_now:
> e559648a wd_last: 30656759 mask: ffffffff
> [ 4276.865037] clocksource:                       'tsc' cs_now:
> a42bfbbea74 cs_last: 9f8e57ce8e2 mask: ffffffffffffffff
> [ 4276.870912] clocksource: Switched to clocksource hpet
>
> It took a while I guess, more than an hour?
>
> All I can do is replace the battery, otherwise this mobo is not fit
> for Linux.

Colin already mentioned that the battery shouldn't be a problem because
the RTC is read at startup only. Maybe you should rather replace the
CPU: <https://forums.lime-technology.com/topic/45190-marking-clocksource-tsc-as-unstable-because-the-skew-is-too-large/>


Nils


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Xen
Reply | Threaded
Open this post in threaded view
|

Re: system freezes

Xen
Nils Kassube schreef op 09-11-2017 11:25:

> Xen wrote:
>> I reset the CMOS but no difference.
>>
>> [ 4276.865023] clocksource: timekeeping watchdog on CPU3: Marking
>> clocksource 'tsc' as unstable because the skew is too large:
>> [ 4276.865027] clocksource:                       'hpet' wd_now:
>> e559648a wd_last: 30656759 mask: ffffffff
>> [ 4276.865037] clocksource:                       'tsc' cs_now:
>> a42bfbbea74 cs_last: 9f8e57ce8e2 mask: ffffffffffffffff
>> [ 4276.870912] clocksource: Switched to clocksource hpet
>>
>> It took a while I guess, more than an hour?
>>
>> All I can do is replace the battery, otherwise this mobo is not fit
>> for Linux.
>
> Colin already mentioned that the battery shouldn't be a problem because
> the RTC is read at startup only. Maybe you should rather replace the
> CPU:
> <https://forums.lime-technology.com/topic/45190-marking-clocksource-tsc-as-unstable-because-the-skew-is-too-large/>

Thanks for the pointer. That was informative.

However.

I have ran Ubuntu 14.04 Live for days without any issue.

I mean, I can also just say: Yeah, spend another $40 on a DDR2 system...

The guy also doesn't mention what he replaced it with, and the 955 was
what I wanted to replace mine _with_ rather than get away from ;-).

I can't go randomly test $40 CPUs and the only one I have left I
think...

Well whatever.

I could check if the hang occurs during such a message but the above
thing you quoted happened without a hang.

Other than that my symptom appears to be the same as the thread you
linked.

I'm just a bit annoyed at the thought of throwing random hardware at
what is basically a kernel problem... :(.

I have not had a hang thus far though after the CMOS reset.

Of course I am grateful for the hints and pointers and feedback.

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: system freezes

Nils Kassube-2
Xen wrote:

> Nils Kassube schreef op 09-11-2017 11:25:
> > Xen wrote:
> >> I reset the CMOS but no difference.
> >>
> >> [ 4276.865023] clocksource: timekeeping watchdog on CPU3: Marking
> >> clocksource 'tsc' as unstable because the skew is too large:
> >> [ 4276.865027] clocksource:                       'hpet' wd_now:
> >> e559648a wd_last: 30656759 mask: ffffffff
> >> [ 4276.865037] clocksource:                       'tsc' cs_now:
> >> a42bfbbea74 cs_last: 9f8e57ce8e2 mask: ffffffffffffffff
> >> [ 4276.870912] clocksource: Switched to clocksource hpet
> >>
> >> It took a while I guess, more than an hour?
> >>
> >> All I can do is replace the battery, otherwise this mobo is not fit
> >> for Linux.
> >
> > Colin already mentioned that the battery shouldn't be a problem
> > because the RTC is read at startup only. Maybe you should rather
> > replace the CPU:
> > <https://forums.lime-technology.com/topic/45190-marking-clocksource-> > tsc-as-unstable-because-the-skew-is-too-large/>
> Thanks for the pointer. That was informative.
>
> However.
>
> I have ran Ubuntu 14.04 Live for days without any issue.

That is indeed an indication, that it isn't related to the CPU. OTOH it
is also an indication that it isn't related to the battery.

> I mean, I can also just say: Yeah, spend another $40 on a DDR2
> system...
>
> The guy also doesn't mention what he replaced it with, and the 955 was
> what I wanted to replace mine _with_ rather than get away from ;-).
>
> I can't go randomly test $40 CPUs and the only one I have left I
> think...
>
> Well whatever.
>
> I could check if the hang occurs during such a message but the above
> thing you quoted happened without a hang.

I can't imagine that switching the clock source from tsc to hpet could
cause a hang - probably those issues aren't related.

> Other than that my symptom appears to be the same as the thread you
> linked.
>
> I'm just a bit annoyed at the thought of throwing random hardware at
> what is basically a kernel problem... :(.

Sure, thet makes sense and I don't know if the CPU really causes the
trouble. It was just an interesting thread I found when I tried to
understand what the kernel message means.

Of course a new battery would be less expensive than the CPU, but
replacing the battery is also what you call "throwing random hardware at
what is basically a kernel problem", IMHO.

> I have not had a hang thus far though after the CMOS reset.

Let's hope that it really was the cure.


Nils


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Xen
Reply | Threaded
Open this post in threaded view
|

Re: system freezes

Xen
Nils Kassube schreef op 09-11-2017 13:52:

> That is indeed an indication, that it isn't related to the CPU. OTOH it
> is also an indication that it isn't related to the battery.

The other guy only had it while running a certain application.

> I can't imagine that switching the clock source from tsc to hpet could
> cause a hang - probably those issues aren't related.

In that case that person also didn't know what actually solved the
problem.


> Sure, thet makes sense and I don't know if the CPU really causes the
> trouble. It was just an interesting thread I found when I tried to
> understand what the kernel message means.
>
> Of course a new battery would be less expensive than the CPU, but
> replacing the battery is also what you call "throwing random hardware
> at
> what is basically a kernel problem", IMHO.

Even so it is about 20 times less expensive.

In Linux people often give the most expensive advice.

I think they do so because problems are usually software related so if
you can pretend it's hardware that means the software is then "not at
fault" ie. linux is then not at fault.

Like Mr. Zen would have his DisplayPort issue and people would say "get
a new laptop".

Which then can also have problems, there is just no solace in starting
with the most expensive solutions.

Also in terms of time.

Yes I can disconnect all USB devices, test without the cache, test
without the RAID, etc., but if you took every hour as $30, those would
be very expensive solutions.

Not that I'm happy with this mobo's USB behaviour.

But sometimes it's just better to follow along the path you are already
on and maybe in time you will find that some change makes a difference.

If I can keep using this system long enough of course.

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: system freezes

compdoc
On 11/09/2017 06:18 AM, Xen wrote:

> In Linux people often give the most expensive advice.

People give advice on common computer problems. I don't see that it has
anything to do with the OS.

With desktop computers, things like failing power supplies,
motherboards, and hard drives are easy to find by simply looking at the
components, or through SMART.

Doesnt cost anything to look.

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
12