EasyOS version 2.3.2, June 22, 2020

[BarryK]

I've been running Quirky Xenial 8.5 with Intel uxa mode enabled. It is very solid. Unfortunately not so with EasyOS, Even with 0.8.1 updated driver it freezes with both uxa and sna.

Next I am going to compare differences (if any) in setups between the various puppies and Easy. I do know that Xenialpup uses an older version of the Intel driver and Fatdog64 uses a newer version (at least newer than 0.8.0 was). I don't yet know what options they set.

Is it possible there is a timing issue in startup? Maybe the system is looking for a file not available yet? I set a custom background by creating a symbolic link to a file in the /usr/share/backgrounds directory. The actual file is in the /home/media/images directory. On reboot the system did not use the linked image but reverted to default background. The link existed, just was not yet connected to file when background was set.

Edit: note the above was with Easy 0.8.0 I haven't successfully run 0.8.1 for longer than a few minutes yet. I also retried Quirky Pyro64 and it froze when I opened the. main menu. I seem to have better luck with them when I boot up and let sit doing nothing for about 10 minutes. It's like I have to ease slowly into using them.

So, it is still very much a mystery!

On the Arch Linux page, there is one interesting thing:

Code: Select all

i915.semaphores=1

...added to kernel boot parameters. Worth a try.

In the boot partition, insert it into these files:

syslinux.cfg (for legacy booting)

EFI/BOOT/refind.conf

In refind.conf, append to the "options rw" line.

EDIT:
Might be worth trying this one too:

Code: Select all

i915.enable_execlists=0

[BarryK]

OT (and the real reason for the post) your caravan is similar to one made in Vic. The main differance is the top half folds down in two giving a slightly humped top when down, and the middle bit of the roof-top is an inbuilt solar panel as it's basically for off-grid travel (12v everywhere). Not a pop-top either, everything's solid when up or down. I'll ask them when they get back from Darwin (after ANZAC day) for a report and details and put it up somewhere.

Found it!

This is made in Victoria, and has a hump:

http://www.ecotourer.com.au/

There is no mention of weight, so they probably aren't that light. So you would probably need a fairly beefy car to tow it, 1.8 litre at least.

[BarryK]

Right now I am running EasyOS Pyro64 0.8.1 on my sister's PC, an Asus Veriton. Don't know what model, it has 4GB RAM, i3-2130 @3.4GHz CPU, and Intel video.

Been using it for about 30 minutes, running perfectly, no video issues at all.

So far, that is five computers with Intel video that I have tested Easy on, and all run perfectly.

Which is beginning to make me wonder...

I am reminded of a couple of years ago, users reported that the popup message that appears the first time that SeaMonkey runs, did not go away after SM started.

I asked heaps of questions, asked the testers to try various things, all to no avail. It was defying logic.
Then, after this had gone on for six months or so, one of the testers who experienced this problem, mentioned that they ran SM as user 'spot'.

No one had mentioned this little detail! As soon as I knew that, I fixed the problem immediately.

It is not necessarily a similar situation now, with the video problems, but worth considering.

At first bootup, QuirkSetup appears. The only thing that I change is the timezone, I set it to "Australia/Perth". Oh, also tick the checkbox to recompress 'q.sfs' from xz to gzip.

On some of my computers I also change the video resolution, from the drop-down list.

So, those who are experiencing severe issues with intel video, such as hanging, do you change anything else?

[Billtoo]

I installed to a 32gb flash drive on an older Compaq desktop:

System: Host: EASYPC17115 Kernel: 4.14.23 x86_64 bits: 64 Desktop: JWM 2.4.0 Distro: Quirky 0.8.1 pyro64
Machine: Device: desktop System: Compaq-Presario product: AU194AA-A2L CQ5123F serial: MXX9300M0F
Mobo: MSI model: Boston v: 1.0 serial: N/A BIOS: Phoenix v: 5.24 date: 06/19/2009
CPU: Dual core Pentium E5200 (-MCP-) speed/max: 2211/2500 MHz
Graphics: Card: Intel 82G33/G31 Express Integrated Graphics Controller
Display Server: X.Org 1.19.1 driver: intel Resolution: 1920x1080@60.00hz
OpenGL: renderer: Mesa DRI Intel G33 version: 2.1 Mesa 17.0.2
Network: Card-1: Realtek RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller driver: r8169
Card-2: D-Link System AirPlus G DWL-G122 Wireless Adapter(rev.C1) [Ralink RT2571W] driver: rt73usb
Drives: HDD Total Size: 531.6GB (0.2% used)
Weather: Conditions: 25 F (-4 C) - Partly Cloudy Time: March 19, 12:37 AM EDT
Info: Processes: 94 Uptime: 41 min Memory: 155.4/3943.0MB Client: Shell (bash) inxi: 2.3.56

I added Palemoon web browser + the devx, downloaded a video with youtubedl.
No problems so far.

[lp-dolittle]

Hi Barry,

as for your question about not-mentioned minor issues, yes, I could imagine that the instability problem might (also) be due to additional factors.

On my Dell Latitude6500 Laptop, I never manage to really properly run the Quicksetup Manager. Choosing the Swiss German keyboard layout never worked 'directly', I spontaneously coped with that issue by additionally fine-tuning the settings via the XKB-Manger which also proved to be a potential source of problems. Before doing so, I always clicked away the spontaneously popping up option to download the German langpack.

I repeatedly reported on that problem in the quirky xerus blog after the release of Quirky Xerus64 8.3 final. Your then optimisations of the XKB-Manager did not really eliminate the problem, but your recent fixes relating to the Intel video driver settings at least made the XKB-settings become persistent (surviving restarts of X as well as reboots).

hopefully, this information can help find the real cause of the instability issue.

kind regards

.

[scsijon]

Ryzen 7 8 core coming next week to play with, pcie ssd, souped up with a NVIDIA® GeForce® GTX 1050 with 4G 64bit GDDR5, 4K Ultra HD (3840 x 2160) InfinityEdge touch display, and something called a 'Killer 1535 802.11ac 2x2 WiFi Module'. I will of course get the standard set of graphic related tests done first! Wish I could buy one but n/a at present, maybe christmas, but I bet not cheap even then when it comes out, as I think, if I read correctly, the ram is 64bit interlaced. would be a killer linux build ( ?) machine! Won't be in time for the next semester's course, but.....

Do I need extras from you to to test pyro64 out before deleting everything and returning?

That will leave three yet to arrive and return to their sources by mid April as agreed when I took on the project.

Found it!

This is made in Victoria, and has a hump:

http://www.ecotourer.com.au/

There is no mention of weight, so they probably aren't that light. So you would probably need a fairly beefy car to tow it, 1.8 litre at least.

Not quite but almost it, from memory.Both ends had a sweep like this one has at the back, not a bump at the front. Maybe it was an earlier version? But if you look at the 420 Off-road with the solar/12v extras, especially the platform step and door at the back, I could almost say that's it. And I know Caravan Court, as they are near where I was when I lived in Melbourne and at least then did good work as they did a lot of repairs for others and the insurance companies. I've asked questions as i'm curious too. I'll post when received.

scsijon

[don570]

EasyOS Pyro64 0.8.1
VGA compatible controller: Intel Corporation 82945G/GZ Integrated


Update after 3 days....

Everything is running great with uxa intel driver. No crashes or stalls.
Runs apps fast from a USB stick. Great work!!!

___________________________________________________

[BarryK]

Barry,
I have had problems booting Easy all along. It persists in easy 0.8.

If I boot to my USB3 drive and use either 'normal startup' or 'Commandline only' and enter 'xwin' before the resolution changes to 1920x1080, I get to the desktop at the wrong resolution then immediately see messed up graphics and, finally, loss of the VGA signal, requiring manual power-down and power-up.

The technique that works is to select 'Commandline only' and enter 'xwin' after the resolution changes. But this works only after manual power down/up; after a 'reboot' this results in the message: "ERROR: Boot drive not found", after listing sda 8 times (instead of sda 3 times then sdb).

Separate issue: the message "date:...invalid time always appears before the 'finding' line; it has the time zone appended.

I attach my log of boot attempts in the hope it provides a clue. The PC is my early 64-bit Presario, details also attached.

BTW, when I have a stable desktop, /mnt/q_ro has both the q.sfs file and mounted (green dot) q_sfs directory.

Richard

Interesting. I don't have any computers that use the 'nouveau' driver. It seems that the kernel nouveau driver is too slow.

Well, there is something that you can try. In /etc/rc.d/rc.sysinit, there is a commented-out line:

Code: Select all

#udevadm settle

Uncomment it, and reboot.

[rerwin]

Interesting. I don't have any computers that use the 'nouveau' driver. It seems that the kernel nouveau driver is too slow.

Well, there is something that you can try. In /etc/rc.d/rc.sysinit, there is a commented-out line:

Code: Select all

#udevadm settle

Uncomment it, and reboot.

Thanks for your recommendation. It does make it possible to boot up normally to the desktop, but only if I select the modesetting X driver. [However, I cannot reproduce that setup, so need to assess it further.] The nouveau X driver crashes and stops the boot-up, with either modeset=1 or modeset=0 in nouveau.conf. The boot messages:

• (EE) Fatal server error:
  (EE) No screens found (EE)

and in /var/log/Xorg.0.log (before the above):

• [...] (EE) [drm] Failed to open DRM device for pci:0000:00:0d.0: -19
  [...] (EE) [drm] Failed to open DRM device for pci:0000:00:0d.0: -19

BTW, the nv drivers work successfully, even without the "settle".
Richard

[BarryK]

rerwin, Cu Chulinux,
Your tests are indicating that X is starting too soon, the kernel video drivers not loaded.

So, I have modified /usr/bin/xwin to wait until they are loaded. Try the attached, instead of that other recommendation to uncomment "udevadm settle".

If you watch bootup, just before X starts you should see some output.

An alternative would be to put that wait loop in /etc/rc.d/rc.sysinit, just where the '#udevadm settle" line is.

[BarryK]

Thanks for your recommendation. It does make it possible to boot up normally to the desktop, but only if I select the modesetting X driver. [However, I cannot reproduce that setup, so need to assess it further.] The nouveau X driver crashes and stops the boot-up, with either modeset=1 or modeset=0 in nouveau.conf. The boot messages:

• (EE) Fatal server error:
  (EE) No screens found (EE)

and in /var/log/Xorg.0.log (before the above):

• [...] (EE) [drm] Failed to open DRM device for pci:0000:00:0d.0: -19
  [...] (EE) [drm] Failed to open DRM device for pci:0000:00:0d.0: -19

BTW, the nv drivers work successfully, even without the "settle".
Richard

Another possibility is to try the 'xf86-video-nouveau' PET:

http://distro.ibiblio.org/easyos/amd64/ ... pyro64.pet

Easy Pyro64 0.8.x is using xf86-video-nouveau compiled in OpenEmbedded, whereas the PET was compiled in a running Easy.
Maybe there is a difference, worth a try.

Thanks for testing!

[Cu Chulinux]

Barry,

Still checking logs and setups for different puppies vs Easy (when I have time) but thought I would add this:

With EasyOS 0.8.1 from USB I don't get past the quick starup screen. I exit without making any changes and computer freezes. I hard reset and end up back in quick startup screen.

With EasyOS 0.8.1 from HD I exit quick startup without making changes. Now default is sna. Computer runs ok, I can even click on icons to run Sakura, etc. But as soon as I open the main menu the computer freezes. I change to uxa (again, no other changes made yet - I haven't even set up networking) and I get an empty menu with no text (as I described in a previous post). Actually the highlighted line in the menu shows text but only that. It doesn't freeze (at least not yet). I will go back and try other options and see if I can set up networking. In Easy that often causes freezes too. I may try booting USB to commandline and changing the sna xorg.conf.d file to DISABLED to see if I can run from USB.

Note I have tried 3 different usb sticks to make sure it's not the stick. MD5sum was fine. All very confusing and frustrating, especially when Xenailpup64 runs so well.

Edit: just saw your latest post. Downloading and testing new xwin.
Edit2: would the kernel module not be loaded when restarting X though?

[BarryK]

Edit: just saw your latest post. Downloading and testing new xwin.
Edit2: would the kernel module not be loaded when restarting X though?

Don't know, but it is within the realms of probability.

For the last few days I have been using my Acer Aspire 5742G laptop, as away from home. i3-370M CPU, 4GB RAM. Dual intel and nvidia graphics.

First, I had that wait-loop in rc.sysinit, right where the "#udevadm settle" line is. It waited for the 'i915' and 'nouveau' kernel drivers to load, and it took 4.5 seconds.

So, if the wait-loop wasn't there, and execution got to running 'xwin' to start X within 4.5 seconds, then the kernel drivers will not be ready.

Do not have that problem on any of my computers. On this laptop, with that wait-loop in 'xwin', there is no wait, the drivers are already loaded.

But, I can see the possibility of that not being the case.

Note, my "old" Acer laptop was purchased in 2011:

http://bkhome.org/archive/blog2/201107/ ... g64mn.html

I have an even older one, also an Acer, purchased in 2006, but it is sitting in a closet, never gets used. CPU is only 32-bit, 512MB RAM. It is a good laptop though, don't want to dispose of it.

It could be that this problem is happening now, as the kernel is taking longer to load drivers. I don't know why this is happening. rerwin has also noticed it, at least I think that was the implication of an earlier report from him. One thing to try would be to revert to a much older kernel, see if that makes any difference.

[BarryK]

I may try booting USB to commandline and changing the sna xorg.conf.d file to DISABLED to see if I can run from USB.

Note that you can easily make any changes to Easy usb stick, running another Linux, plug in the Easy usb stick, mount the second partition, and /mnt/<second partition>/.session has all the files, change anything you want.

That's an easy way to put in the new 'xwin'.

[rerwin]

Your tests are indicating that X is starting too soon, the kernel video drivers not loaded.

So, I have modified /usr/bin/xwin to wait until they are loaded. Try the attached, instead of that other recommendation to uncomment "udevadm settle".

If you watch bootup, just before X starts you should see some output.

Another possibility is to try the 'xf86-video-nouveau' PET:

http://distro.ibiblio.org/easyos/amd64/ ... pyro64.pet

Easy Pyro64 0.8.x is using xf86-video-nouveau compiled in OpenEmbedded, whereas the PET was compiled in a running Easy.
Maybe there is a difference, worth a try.

Neither change affected the problem. I am unable to successfully re-create using nouveau with modesetting and have never gotten to a desktop with nouveau and (X driver) nouveau, with or without the "settle" activation. I attach the Xorg log obtained with the xwin loop, the packaged nouveau X driver and udevadm settle uncommented.

I don't see in the xwin loop that anything is being checked other than a test for blacklisting. It always finds the vendor ID and loops 30 times, even if I change the sleep to "1", for 30 seconds (which is about how long my wireless module took to load in Easy).

The attached log shows the hardware supported by the nouveau X video driver, but does not show my VGA card:

• 00:0d.0 VGA compatible controller [0300]: NVIDIA Corporation C61 [GeForce 6150SE nForce 430] [10de:03d0] (rev a2)

After a search, I see an example log entry, "Chipset: C61 (NV4C)", which is listed: "GeForce 6 (NV4x)". So the card seems to be supported by nouveau.

Looking further, I found a page that implies some limitations of this card:
https://h-node.org/videocards/view/en/6 ... ---rev-a2-

FWIW, I see that it is apparently supported by the nvidia-304xx proprietary driver.

[BarryK]

I don't see in the xwin loop that anything is being checked other than a test for blacklisting. It always finds the vendor ID and loops 30 times, even if I change the sleep to "1", for 30 seconds (which is about how long my wireless module took to load in Easy).

In the case statement, this line picks up when the kernel module is loaded:

Code: Select all

   *"*) echo -n "${aVID/*"/} "; continue ;;

Testing on my 2011 Acer laptop:

Code: Select all

# busybox lspci -m -k | grep '"Class 0300"' | cut -f 4,12 -d '"'
8086"i915
10de"nouveau

...which the case statement picks up.

Or, just run this to see all output:

Code: Select all

# busybox lspci -m -k | grep '"Class 0300"'
00:02.0 "Class 0300" "8086" "0046" "1025" "0488" "i915"
01:00.0 "Class 0300" "10de" "0df1" "1025" "0488" "nouveau"

...that last field only appears after the driver has loaded.

Note, it has to be the busybox lspci, the full version works differently.

I am not using the nvidia graphics in this laptop, so could have blacklisted the 'nouveau' module. If I had done that, then would get:

Code: Select all

# busybox lspci -m -k | grep '"Class 0300"'
00:02.0 "Class 0300" "8086" "0046" "1025" "0488" "i915"
01:00.0 "Class 0300" "10de" "0df1" "1025" "0488"

...which is why I put in the blacklist testing, otherwise it would keep looping until times out.

[BarryK]

The attached log shows the hardware supported by the nouveau X video driver, but does not show my VGA card:

• 00:0d.0 VGA compatible controller [0300]: NVIDIA Corporation C61 [GeForce 6150SE nForce 430] [10de:03d0] (rev a2)

After a search, I see an example log entry, "Chipset: C61 (NV4C)", which is listed: "GeForce 6 (NV4x)". So the card seems to be supported by nouveau.

Looking further, I found a page that implies some limitations of this card:
https://h-node.org/videocards/view/en/6 ... ---rev-a2-

You could try turning off glx:

https://unix.stackexchange.com/question ... n-in-linux

The arch linux page has some useful suggestions:

https://wiki.archlinux.org/index.php/nouveau

If you are still having problems loading the module or starting X server append nouveau.config=NvMSI=0 to your kernel parameters

Specific Nvidia chips with Nouveau may give random system lockups and more commonly throw many kernel messages, seen with dmesg. Try adding the nouveau.noaccel=1 kernel parameter.

[BarryK]

Specific Nvidia chips with Nouveau may give random system lockups and more commonly throw many kernel messages, seen with dmesg. Try adding the nouveau.noaccel=1 kernel parameter.

Well, that can be done by editing /etc/modprobe.d/nouveau.conf

Code: Select all

options nouveau modeset=1 noaccel=1

I notice, running "modinfo nouveau", that there is also a "nofbaccel" parameter.

[foxpup]

FWIW, I see that it is apparently supported by the nvidia-304xx proprietary driver.

I have similar card as rerwin - GeForce 7 Series, don't know exactly, I am not near it, driver is 304 too - and same problem with booting straight to X, as reported before.
Could compiling the 304 nvidia driver help? May be a problem to compile it though because the kernel in Easy is recent, nvidia may not have kept up.

[rerwin]

Try adding the nouveau.noaccel=1 kernel parameter.

Well, that can be done by editing /etc/modprobe.d/nouveau.conf

Code: Select all

options nouveau modeset=1 noaccel=1

Whenever I modify /etc/modprobe.d/nouveau.conf, it gets changed to:
options nouveau modeset=0
by the time it is needed during reboot.

I recall that early on in my use of 0.8.1, I changed the modeset in nouveau.conf from 1 to zero. Could that change have been saved in a snapshot somewhere and is getting restored at bootup, overriding anything I might have changed further in nouveau.conf? Even if I delete nouveau.conf in .sessions, instead of the default "modeset=1" version the "modeset=0" version reappears as the current setting.

So, that is preventing me from trying the 'noaccel=1' addition.

BTW, the 'busybox lspci -m -k' command gives:
00:0d.0 "Class 0300" "10de" "03d0" "103c" "2a5b" "nouveau"
in quirky, but:
00:0d.0 "Class 0300" "10de" "03d0" "103c" "2a5b"
in easy, anytime during the session. So, the question is "why is it not showing up?" Lsmod shows it as loaded when I use either the nv or nouveau X driver:

Code: Select all

nouveau              1572864  0
mxm_wmi                16384  1 nouveau
wmi                    20480  2 mxm_wmi,nouveau
video                  36864  1 nouveau
hwmon                  20480  2 k8temp,nouveau
i2c_algo_bit           16384  1 nouveau
ttm                    86016  1 nouveau
drm_kms_helper        126976  1 nouveau
drm                   307200  3 nouveau,ttm,drm_kms_helper
agpgart                32768  3 nouveau,ttm,drm