very frequent crashes (about every other hour)

[Steffen Hartmann]

Hello,

after installation and some weeks of using cubes 3.2 I'm still facing troubles with the system hanging comletly.
It starts with very delayed mouse and keyboard input - finally everything stops.
When looking with top in dom0 no obvious memory hungry tasks.

However I have to reboot or even stop the computer the hard way pulling the mains.

With my other OS's on the same computer no such troubles.

Where can I look into to trace down this problem?

I have a dell precision 5500 with 16 GB Ram an 3 VM running (sys-firewall, sys-net, fed23) and dom0 of course.

Everything is pretty much standard installation.

thank you

[Jean-Philippe Ouellet]

No guarantees about this fixing your specific problem, but you might
want to try a newer kernel.

https://www.qubes-os.org/doc/software-update-dom0/#how-is-software-updated-securely-in-dom0

See section "Testing repositories"

[Chris Laprise]

Hi,

A little more info could be helpful: CPU model, bios revision, GPU and
current driver

Did this not work after all... ?
https://groups.google.com/d/msg/qubes-users/avqu_g6PeTM/xOrw75TWAgAJ

Have you run a hardware diagnostic (including RAM and disk)?

Do you see anything in 'xl dmesg` or 'dmesg' that look like serious errors?

Does upgrading to ('unstable') kernel 4.8 help?

Does upgrading to fedora-24 template help?


--

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett

[Steffen Hartmann]

Am Montag, 13. März 2017 06:28:52 UTC+1 schrieb Chris Laprise:
> On 03/12/2017 04:47 PM, Steffen Hartmann wrote:
> > Hello,
> >
> > after installation and some weeks of using cubes 3.2 I'm still facing troubles with the system hanging comletly.
> > It starts with very delayed mouse and keyboard input - finally everything stops.
> > When looking with top in dom0 no obvious memory hungry tasks.
> >
> > However I have to reboot or even stop the computer the hard way pulling the mains.
> >
> > With my other OS's on the same computer no such troubles.
> >
> > Where can I look into to trace down this problem?
> >
> > I have a dell precision 5500 with 16 GB Ram an 3 VM running (sys-firewall, sys-net, fed23) and dom0 of course.
> >
> > Everything is pretty much standard installation.
> >
> > thank you
> >


Hi,

I put all my results between the lines:

>
> Hi,
>
> A little more info could be helpful: CPU model, bios revision, GPU and
> current driver

lscpu shows Intel Xeon E5606 @ 2.13GHz
Bios A13
Driver: /sys/bus/pcidrivers/nouveau/0000:03:00.0
GPU: GF108

>
> Did this not work after all... ?
> https://groups.google.com/d/msg/qubes-users/avqu_g6PeTM/xOrw75TWAgAJ

No it does not work. However I thought it would since it did not happen for 1 day or so.

>
> Have you run a hardware diagnostic (including RAM and disk)?
>

Yes, I run memtest and this time I installed on a completely differnet (externel) USB HD

> Do you see anything in 'xl dmesg` or 'dmesg' that look like serious errors?
>

I don't recognize any error

> Does upgrading to ('unstable') kernel 4.8 help?
>

I did not try 4.8 but I tried from testing repositories 4.4.38-11

> Does upgrading to fedora-24 template help?
>

Not tried yet, but would it stop the complete system when changing templates?


Thank you

[Chris Laprise]

I have a feeling its NVIDIA/nuveau that's causing it; notice your
graphics card is different than Drew White's.

A few suggestions:

* Run a full hw diagnostic. This program is usually found in the BIOS

* Try upgrading to the 4.8 kernel; this will update the graphics support
and bring other improvements (I've been using 4.8.9-12 for a long time
now without problems). Use a command like:

sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable kernel

* Try a different graphics card such as AMD Radeon

* Upgrading to fedora-24 (or debian-8) template is less critical for
stability (but recommended anyway). You would have to stop all VMs using
fedora-23 to make the switch.

[Steffen Hartmann]

Hello,

I installed the 4.8 kernel yesterday and now test over the next days how everything works. Keep you informed...

[Steffen Hartmann]

Hello,

no luck here. The first crash happens today:-(

[Frank Schäckermann]

On 16 Mar 2017, at 20:49, Steffen Hartmann hast0011-at-gmail.com |qubes-mailing-list/Example Allow| <p8dlw...@sneakemail.com> wrote:

Hello,

no luck here. The first crash happens today:-(

Have you tried switching off VT-d in the BIOS? I can use my ThinkPad W530 with it's discreet NVIDIA GPU only with VT-d switched off. Otherwise it will lock up very reliably within an hour. Using the internal Intel GPU everything is fine - even with VT-d enabled.

Regards, Frank

--
You received this message because you are subscribed to the Google Groups "qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CADkZmRzxz5i-RGAWM3gwbwtqhYc-8q66cBVY-L0z1Y9ZvNfzKQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Drew White]

Hi Steffen,

You are using the almost EXACT SAME machine that I am. I have 24 GB RAM.
I used to have the exact same problem before I reconfigured things to work properly so that this did not happen.

FIRSTLY, upgrade to A16, there are bugs in A13 that should not be there.
This fixes the frequent overloads and thus the lockups.

SECOND, disable screensaver, put it to blank screen.
THIRD, whenever you are going away overnight, pause every guest that runs web browsers, OR shut them down.

FOURTH, make sure you update the Qubes Manager to get rid of the Memory Leak it has.

Currently I have been using most of my own things to replace the Qubes Manager, thus utilising less RAM in Dom0, which also resolved numerous locking issues.

I run Fedora 23 Templates, along with Debian 8, and numerous versions of Windows along with other operating systems including Android.
At times I have anywhere up to 20 Guests running at a time.

RARELY less than 8.

[cooloutac]

also might want to test power settings in bios and desktop settings. or shut them off. wake and remote wake settings, cpu frequency settings, suspend power off settings especially for gpu monitor hdd or anything.

[cooloutac]

Drew when you gonna join Qubes team?

[Steffen Hartmann]

Hi,

I upgraded BIOS to A16 as suggested by Drew and now uptime is > 8 h without crash.

Thank you to all and I will keep you informed.

Steffen

[Steffen Hartmann]

Just to further document the problem and what helped me in this situation:

First it turned out that there was always a readonly filesystem when the system became unusable. Because of that I installed the system on an external usb drive but still the same behaviour. From then I new it has nothing to do with my internal flash drive.

To solve I switched off vt-d in the BIOS. And that stopped the problem for sure. Turning it on and the crashes came back.

I'm wondering if that has to do with the special procedure needed to make my network card working is related to this. I need to set permissive mode for it in order to make it work.

[Tim W]

That is one of the reasons I returned the first thinkpad 440p w nvida discreet and got one with only intel as they got rid of the bios switch to disable one or the other.

I also saw a issue related to one point Drew mentions. that it would build over time with symptoms sucb as yours. Vms with web browsers left open for long periods. Manily firefox but after a few days the whole system would get sluggish even though ram reported was fine. Closing web browsers more freq took care of issues.

To me if you do not have active iommu (intel vt-d) you are castrating qubes secuirty. Still way too many power drain perf issues with discreet nvida imo. Not that its not workable just nvida makes it harder imo deliberately when it comes to linux just in general as do a majority of hardware manf.