aufs future

[ozsouth]

Seems we've now got to the root cause of the last aufs failure. /fs/aufs/i_op.c was the real problem. Although aufs6.6.4 hasn't been released, a patch has, & @peebee successfully made a 6.6.7 kernel. I compiled a 6.6.8 kernel & patch appears to be successful, as it boots fine & in brief testing runs ok.
stat.c & udba were pointers to the problem. It seems (at least for now) the process is: users find problems & specific errors, then a patch or workaround is released. Hopefully that is a only short-term scenario.

I also note that with the 6.6 kernels, if you run df, a mounted 'drive' of about 80kb appears: /sys/firmware/efi/efivars

[peebee]

Seems we've now got to the root cause of the last aufs failure. /fs/aufs/i_op.c was the real problem. Although aufs6.6.4 hasn't been released, a patch has, & @peebee successfully made a 6.6.7 kernel. I compiled a 6.6.8 kernel & patch appears to be successful, as it boots fine & in brief testing runs ok.
stat.c & udba were pointers to the problem. It seems (at least for now) the process is: users find problems & specific errors, then a patch or workaround is released. Hopefully that is a only short-term scenario.

I also note that with the 6.6 kernels, if you run df, a mounted 'drive' of about 80kb appears: /sys/firmware/efi/efivars

k6.6.4 temporary patch (#4206)
https://github.com/puppylinux-woof-CE/w ... f720f94c01

[ozsouth]

Thanks @peebee ! I made those 2 files myself (missed your github entry). Now you've confirmed my creations, I guess I can call my beta 6.6.8 kernel OK.

[ozsouth]

Seems to be more aufs trouble with the 6.7 kernel. As with 6.6.4, kernel commits seem to be breaking aufs more regularly. sfjro is unable to devote time to aufs now (he has the higher priorities of a job and a life - quite reasonable). Posted today on github:

Obviously aufs should follow the changes in mainline kernel.
Hopefully I'll return to aufs in a few months.

There have been no commits to aufs for 2 months now. Fortunately, kernel 6.1.x hasn't broken so far & sfjro provided an untested patch for 6.6.4+ which appears to work.

[BarryK]

Thanks for that patch guys. I am just about to compile 6.6.11 kernel, for easyVoid.

[ozsouth]

@BarryK - I see there is an nfsd error that caused 6.6.12 to be released with a single fix.

[nocsak]

Hi all!

First I would like to say thank you to sfjro for still keep maintaining and developing aufs sources for puppy linux huge kernels!
At second I recognized here: https://github.com/sfjro/aufs-standalone/issues/35 - so aufs sources have some problem with kernel 6.7 versions.
I fully understand the priorities described above and I hope that sfjro can continue to develop aufs.

So, I tried to compile this kernel source first: https://github.com/zen-kernel/zen-kerne ... 6.7.1-lqx1 with those aufs 6.7.y corrections but every way I've tried the compilation has been failed. After I gave up with aufs, I disabled it by kernel-kit and tried again with aufs disabled, but overlayfs enabled in menuconfig. Then compilation was successful.
So I released (currently via Google Drive) this kernel without aufs ability but overlayfs enabled. Edited initrd.gz to include UNIONFS="overlay" rather than "aufs" then repacked and tested new kernel and it works.

For tesing the above mentioned kernel compilation is available here for both standard-classic and symlinked puppy linux structures: https://drive.google.com/drive/folders/ ... w3lxdxI3AB

Screenshot.jpg (82.19 KiB) Viewed 604 times

I hope I didn't choose the wrong topic for this writings and excuse me if I have grammatical mistakes in my expressions here!

[peebee]

So I released (currently via Google Drive) this kernel without aufs ability but overlayfs enabled. Edited initrd.gz to include UNIONFS="overlay" rather than "aufs" then repacked and tested new kernel and it works.

Hi

I see graphics problems with 6.7.x and my Nvidia hardware....... https://gitlab.freedesktop.org/drm/nouveau/-/issues/310

You didn't need to edit initrd - overlayfs will be automatically used (in recent Pups) if aufs is not present.....

There is an experimental build of 6.7.x with aufs at: https://sourceforge.net/projects/lxpup/ ... ther/test/

[nocsak]

Hello peebee!

Thanks for quick reply!

I will check out what yout wrote, both nouveau issue and your 6.7.1 kernel with aufs. I have a hybrid graphics notebook based on 9gen intel i5-9300H CPU, and it's IGP intel UHD 630 and with Nvidia GTX 1050Ti GPU with 4GB GDDR5. Earlier I worte about this VGA switching problem here: viewtopic.php?p=65130#p65130
So I using default nouveau and intel DRI_PRIME swtich instead of Nvidia driver and because I was not able to install on any way Nvidia native drivers to solve the main problem which is VGA-switching.

The only thing I can test is that I have a LED indicating on which GPU is currently used: Blue if intel, Red if Nvidia and I have a shell script based on ffplay and DRI_PRIME - I will check if the nouveau option has issues! But I did not recognized any problem of nouveau maybe another GPU family I have, or maybe because the VGA switching mechanism. The topic where I wrote about nvidia optimus, there are some links which are not alive already... so the kernel paramter was previously

Code: Select all

pci=nommconf

and the kernel config to geenrally set it to disabled by searching to mmconfig and change value in kernel config to not set with hashtag at the beginning of line.

Anyway later I will write a feedback about this with picture under this line - in this comment:

---

OK I've tested my lqx1-k6.7.1 and your k6.7.1-lxpup64 kernel with DRI_PRIME both 0 (intel) and 1 (nouveau) and I haven't experienced any problem during the tests. I've cheked glxgears and a video playback with nouveau DRI_PRIME setup too without any problem on my dual graphics machine.

The above mentioned mmconfig at me is look like this:

Code: Select all

#
# Bus options (PCI etc.)
#
CONFIG_PCI_DIRECT=y
# CONFIG_PCI_MMCONFIG is not set
# CONFIG_PCI_CNB20LE_QUIRK is not set
CONFIG_ISA_BUS=y
CONFIG_ISA_DMA_API=y
CONFIG_AMD_NB=y
# end of Bus options (PCI etc.)

and it is beacuse if enabled then dmesg has a lots of this section after boot:

Code: Select all

[  148.004576] pcieport 0000:00:1d.6: AER: Corrected error received: 0000:03:00.0
[  148.004592] alx 0000:03:00.0: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Receiver ID)
[  148.004593] alx 0000:03:00.0:   device [1969:10a1] error status/mask=00000080/00002000
[  148.004595] alx 0000:03:00.0:    [ 7] BadDLLP               
# 

aufs seems work well with your kernel so thanks for this too and here are the results of glxgears with that kernel too:

Code: Select all

# DRI_PRIME=1 vblank_mode=0 glxgears
ATTENTION: default value of option vblank_mode overridden by environment.
16480 frames in 5.0 seconds = 3295.836 FPS
16463 frames in 5.0 seconds = 3292.510 FPS
16473 frames in 5.0 seconds = 3294.522 FPS
16500 frames in 5.0 seconds = 3299.821 FPS
^C
# DRI_PRIME=0 vblank_mode=0 glxgears
ATTENTION: default value of option vblank_mode overridden by environment.
46299 frames in 5.0 seconds = 9259.721 FPS
47978 frames in 5.0 seconds = 9595.455 FPS
47918 frames in 5.0 seconds = 9583.481 FPS
47966 frames in 5.0 seconds = 9593.161 FPS
^C

Here nouveau results are less values but they always were. (quicksetup says modesetting video driver is currently being used.) And during video playback no issues detected by me with nouveau option:

Screenshot.jpg (33.62 KiB) Viewed 548 times

I'm not really sure but I think your issue with nouveau is GPU family specific maybe.

And here is a (unfortunately Hungarian lanuguage) video about how to make correct fdrv sfs. Maybe it helps too.

https://youtu.be/bpr49oTcWIw?si=2GmsPeFdLlymHptB

The heart of this video is copy-firmware.sh

And yes initrd.gz not has to be edited, it recognized the overlayfs only kernel and booted up well.

Thanks again, best wishes!

[KuLuSz]

I see graphics problems with 6.7.x and my Nvidia hardware....... https://gitlab.freedesktop.org/drm/nouveau/-/issues/310

you can try some commands to check:

1. This command show all (DRM preferred) output resolution modes:

   Code: Select all

   cat /sys/class/drm/*/modes | uniq
   1280x1024
   1920x1440
   1600x1200
   1280x1024
   1152x864
   1024x768
   832x624
   800x600
   640x480
   720x400

2. This command show the (recognised) monitor specific infos:

   Code: Select all

   cat /s*/devi*/*/*/*/drm/*/*/edid | parse-edid
   Checksum Correct
   
   Section "Monitor"
       Identifier "hp 7550"
       ModelName "hp 7550"
       VendorName "HWP"
       # Monitor Manufactured week 47 of 2003
       # EDID version 1.3
       # Analog Display
       DisplaySize 320 240
       Gamma 2.80
       Option "DPMS" "true"
       Horizsync 30-86
       VertRefresh 50-140
       # Maximum pixel clock is 180MHz
       #Not giving standard mode: 640x480, 85Hz
       #Not giving standard mode: 800x600, 85Hz
       #Not giving standard mode: 1024x768, 85Hz
       #Not giving standard mode: 1600x1200, 65Hz
       Modeline     "Mode 0" 94.50 1024 1072 1168 1376 768 769 772 808 +hsync +vsync 
   EndSection
   
   or
   
   cat `realpath /s*/c*/drm/*/edid` | parse-edid

   If Identifier and model name is incorrect , may u have cable problem too... (or plug n play not work properly...)
   (this may help kernel developers find the problem)

[peebee]

https://github.com/sfjro/aufs-standalon ... 1937853551

Here are aufs6.7 and aufs6.6.4.
Hopefully I'll start aufs6.x-rcN for linux-v6.8-rcN series in near
future.

J. R. Okajima

[ozsouth]

aufs 6.8 is released.