Page 14 of 17
Posted: Sun 07 Jun 2020, 10:00
by peebee
@mash
@bigpup
are either / both of you booting directly from ssd??
Posted: Sun 07 Jun 2020, 11:32
by peebee
bigpup wrote:
Need the kernel driver.
r8822be.ko
The kernel configs for 4.14.160 as shipped have:
# CONFIG_RTL8XXXU is not set
whereas Porteus kernel has:
CONFIG_RTL8XXXU=m
CONFIG_RTL8XXXU_UNTESTED=y
CONFIG_RTW88=m
CONFIG_RTW88_CORE=m
CONFIG_RTW88_PCI=m
CONFIG_RTW88_8822BE=y
CONFIG_RTW88_8822CE=y
# CONFIG_RTW88_DEBUG is not set
# CONFIG_RTW88_DEBUGFS is not set
The recent 5.4.44 kernel (32 bit) was built with Porteus configs.
The 64-bit 5.4.6 kernel only has
CONFIG_RTL8XXXU=m
# CONFIG_RTL8XXXU_UNTESTED is not set
# CONFIG_RTW88 is not set
whereas the latest 5.7.1 64bit has:
CONFIG_RTL8XXXU=m
CONFIG_RTL8XXXU_UNTESTED=y
CONFIG_RTW88=m
CONFIG_RTW88_CORE=m
CONFIG_RTW88_PCI=m
CONFIG_RTW88_8822BE=y
CONFIG_RTW88_8822CE=y
# CONFIG_RTW88_DEBUG is not set
# CONFIG_RTW88_DEBUGFS is not set
I'll fix for 20.06 kernel config if we fix "the problem" but in the meantime you could try
5.7.1 or
5.4.44
Posted: Sun 07 Jun 2020, 15:06
by bigpup
peebee wrote:@mash
@bigpup
are either / both of you booting directly from ssd??
I am booting from an internal emmc drive.
Posted: Sun 07 Jun 2020, 16:43
by mash
@mash
@bigpup
are either / both of you booting directly from ssd??
I'm booting from USB flash drive.
If bigpup's machine will boot with that initrd:
https://www.mediafire.com/file/a72erhw7 ... 01.gz/file we can narrow it to two commits from 6th December.
Yes, they do not look suspicious.
EDIT:
Well, one of these commits is causing problem.
BUILD_FROM_WOOF='HEAD;266c30cca;2019-12-06 22:00:40 +1000' which is just one commit before them is working.
This is initrd which worked for me:
https://www.mediafire.com/file/op0b95ae ... 06.gz/file
Posted: Mon 08 Jun 2020, 06:34
by bigpup
For my WIFI problem I tried changing to the 5.7.1 64bit kernel.
No help.
I think I actually need the kernel driver r8822be.ko
in /lib/modules/5.7.1/kernel/drivers......
Several possible places to but it.
If I correctly understand, that driver has to be compiled for the kernel being used.
I am going back to the original kernel for ScPup64 20.01+6
I need a r8822be.ko kernel driver for it.
Posted: Mon 08 Jun 2020, 07:16
by 01micko
I just downloaded that initrd and indeed it doesn't conatin the 'Please wait...' part.. intriguing if that causes the problem!
I could understand if booting off an sdcard .. maybe I'll grab latest scpup and try and boot on my dell laptop which as far as I know supports booting from such. I'll need to use gyro's frgalpup too because I have secure boot enabled, for testing.
@mash. If you click on an initrd.gz in rox filer it opens up at /root so you can edit it easily.Click it again and it can be updated. Maybe worth a shot.
Posted: Mon 08 Jun 2020, 09:05
by peebee
bigpup wrote:For my WIFI problem I tried changing to the 5.7.1 64bit kernel.
Hi @bigpup
Googling shows lots of problems with Realtek 8822be .....
One suggestion seen is that the rtw88 driver is the one to use - this is in 5.7.1
https://www.reddit.com/r/linux/comments ... der_linux/
https://bugs.launchpad.net/ubuntu/+sour ... ug/1806472
Posted: Mon 08 Jun 2020, 11:02
by gyro
I find it hard to get my head around the possibility that the contents of the 'init' script could be causing the problem, since it works fine in other machines, including mine.
Yes, I have had a new "init" script cause a kernel panic, but it's always been a syntax error in the script, it would have failed on any hardware.
It might be interesting to take the initrd.gz that works for "mash" and replace the "init" script with the one from the current ScPup64 initrd.gz (that fails), and see if that works.
My 2 cents worth.
gyro
Posted: Mon 08 Jun 2020, 17:11
by bigpup
I find it hard to get my head around the possibility that the contents of the 'init' script could be causing the problem, since it works fine in other machines, including mine
It is not a problem in all computers.
Just some of them.
I have one that boots with no problem.
I have a laptop that it is a problem.
Using an older initrd.gz fixed the problem.
01micko seems to think he knows what may be causing it.
See his above post.
Posted: Mon 08 Jun 2020, 18:13
by mash
OK, I think I got it. This post should be prepended by Jean-Luc Picard's facepalm.
"The problem" exists only in some circumstances which I describe. I am curious if anyone of you tried to boot from SD card and succeeded because my SD card and/or reader was the case of the problem.
So, the problem exists only on my HP Probook machine that I boot in UEFI native mode and only if I insert SD card before/during boot. Since I use that card to store big SFS files it is almost always present in my built-in reader.
HP Probooks are known to have a little bit faulty UEFI firmware - e.g. you cannot boot from SD card in UEFI mode even if you set it in UEFI/BIOS settings.
Actually reverting this commit:
https://github.com/puppylinux-woof-CE/w ... ce73f08d0b (just edited initrd manually as 01micko wrote) makes problem disappear. So, not waiting text but grep -> tail piping (?).
So for me there are 2 workarounds:
1. remove SD card when booting
2. edit initrd manually from some working puppy
Thanks peebee and 01micko for directing me.
Posted: Mon 08 Jun 2020, 23:18
by bigpup
On my HP Stream 14
Having a SD card plugged in or not has no affect.
But, I do need the different initrd.gz to get it to boot.
ScPup64 20.01 is frugal install on internal emmc drive.
Posted: Tue 09 Jun 2020, 06:35
by 01micko
mash wrote:OK, I think I got it. This post should be prepended by Jean-Luc Picard's facepalm.
"The problem" exists only in some circumstances which I describe. I am curious if anyone of you tried to boot from SD card and succeeded because my SD card and/or reader was the case of the problem.
So, the problem exists only on my HP Probook machine that I boot in UEFI native mode and only if I insert SD card before/during boot. Since I use that card to store big SFS files it is almost always present in my built-in reader.
HP Probooks are known to have a little bit faulty UEFI firmware - e.g. you cannot boot from SD card in UEFI mode even if you set it in UEFI/BIOS settings.
Actually reverting this commit:
https://github.com/puppylinux-woof-CE/w ... ce73f08d0b (just edited initrd manually as 01micko wrote) makes problem disappear. So, not waiting text but grep -> tail piping (?).
So for me there are 2 workarounds:
1. remove SD card when booting
2. edit initrd manually from some working puppy
Thanks peebee and 01micko for directing me.
Well maybe my commit is buggy! That shouldn't happen so either I revert the commit or put in further tests to make sure we booted off the particular device. Latter is the real solution.
The facility in question was intended to support usb stick installs also, with a look to the future that possibly more puppy distros may be shipped as image files rather than, or as well as, iso files.
Posted: Tue 09 Jun 2020, 08:09
by gyro
01micko wrote:Well maybe my commit is buggy! That shouldn't happen so either I revert the commit or put in further tests to make sure we booted off the particular device. Latter is the real solution.
I still can't get my head aroud the ides that there is a coding bug in that code that is directly causing a kernel panic.
I wonder if it has to do with lack of support for mmc devices in Puppy kernels.
For some hardware, typical Puppy kernels depend on a module from '/lib/modules/4.4.187/kernel/drivers/mmc/host' to support a local mmc device. But for most of the 'init' script, the kernel has no access to it's modules, since the zdrv is not available yet.
This is true for my Lenevo ThinkPad, which has an internal mmc device but needs '/lib/modules/4.4.187/kernel/drivers/mmc/host/sdhci-acpi.ko' to access it. The result is the 'init' script cannot see the mmc device.
This could be tested by "mash" by booting with his SD card out, then after inserting the SD card, see if "lsmod" shows any of the modules in '/lib/modules/4.4.187/kernel/drivers/mmc/host/'
An alternative would be to use
http://www.murga-linux.com/puppy/viewtopic.php?t=118416.
If it is a "module" issue, it can be fixed with a recompiled kernel, or
http://www.murga-linux.com/puppy/viewtopic.php?t=118416.
I also gather that "Quirky" kernels might have better support for mmc devices.
gyro
Posted: Tue 09 Jun 2020, 08:28
by peebee
gyro wrote:If it is a "module" issue, it can be fixed with a recompiled kernel,
Do you know what kernel config is needed?
Thanks
Posted: Tue 09 Jun 2020, 08:29
by bigpup
bigpup wrote:ScPup64 20.01+6
Frugal install using save folder.
Using the 5.4.6 kernel.
No wifi support for my wifi hardware.
Code: Select all
Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8822BE 802.11a/b/g/n/ac WiFi adapter [10ec:b822]
• Kernel Driver: r8822beS
• Memory Used: 768.00 KB
• Path: /lib/modules/4.19.23/kernel/drivers/staging/rtlwifi/r8822be.ko
• Description: Realtek 802.11n PCI wireless core
• Description: PCI basic driver for rtlwifi
• Description: Realtek 8822BE 802.11n PCI wireless
Got the needed firmware installed.
Need the kernel driver.
r8822be.ko
This source package has the needed driver.
I have used this to get driver for other Puppies.
Realtek source package for wifi
https://github.com/rtlwifi-linux/rtlwifi-next
running make and make install get errors.
Yes I unzipped the package.
Have the devx and kernel sources sfs's loaded.
Can someone try compiling this driver package.
Posted: Tue 09 Jun 2020, 09:26
by 01micko
gyro wrote:01micko wrote:Well maybe my commit is buggy! That shouldn't happen so either I revert the commit or put in further tests to make sure we booted off the particular device. Latter is the real solution.
I still can't get my head aroud the ides that there is a coding bug in that code that is directly causing a kernel panic.
I wonder if it has to do with lack of support for mmc devices in Puppy kernels.
For some hardware, typical Puppy kernels depend on a module from '/lib/modules/4.4.187/kernel/drivers/mmc/host' to support a local mmc device. But for most of the 'init' script, the kernel has no access to it's modules, since the zdrv is not available yet.
This is true for my Lenevo ThinkPad, which has an internal mmc device but needs '/lib/modules/4.4.187/kernel/drivers/mmc/host/sdhci-acpi.ko' to access it. The result is the 'init' script cannot see the mmc device.
This could be tested by "mash" by booting with his SD card out, then after inserting the SD card, see if "lsmod" shows any of the modules in '/lib/modules/4.4.187/kernel/drivers/mmc/host/'
An alternative would be to use
http://www.murga-linux.com/puppy/viewtopic.php?t=118416.
If it is a "module" issue, it can be fixed with a recompiled kernel, or
http://www.murga-linux.com/puppy/viewtopic.php?t=118416.
I also gather that "Quirky" kernels might have better support for mmc devices.
gyro
Regardless, it shouldn't happen.
I introduced the facility to resize an f2fs or ext4 partition specifically for the raspberry pi which essentially needs the mmc/sdcard driver (whatever it is) built in to the kernel to facilitate boot. This enabled me to ship a 4GB or 2GB image that could be copied via dd, copy or unzip directly to the card device no matter the size, so long as it exceeded the the size of the image. As stated, this was to be extended to usb sticks so I do need to revise the code at some point.
I'm suspecting that peebee's kernel has the necessary driver compiled into the kernel image, and that is why @mash sees the problem. I'm not so sure that a
debugsave can't be performed (which I bugfixed recently) which may or may not have shed more light.
I'll have to have a think about this one...
Posted: Tue 09 Jun 2020, 10:45
by gyro
peebee wrote:gyro wrote:If it is a "module" issue, it can be fixed with a recompiled kernel,
Do you know what kernel config is needed?
Thanks
Of course not.
Only somone who has the hardware with the problem can say which mcc kernel module gets loaded.
I know which module my Lenevo ThinkPad required, but the HP might require a different one.
Besides, unless someone does some more testing, we'll never know if it's because the "init" script caused the kernel to try to use a non-existent module, or not. And without a HP machine with the issue, I can't test that.
gyro
Posted: Tue 09 Jun 2020, 10:56
by gyro
01micko wrote:I'm suspecting that peebee's kernel has the necessary driver compiled into the kernel image.
What evidence do you have for such a statement?
How could "peebee" ensure that the needed module is compiled into the kernel, if he doesn't know which module it is.
At the moment, we don't know if it is a module problem.
If it is, we don't know which module.
I suspect exactly the opposite, that "mash" is experiencing the issue because the needed module, is in fact a module, and not compiled into the kernel, and therefore un-available in "init".
gyro
Posted: Tue 09 Jun 2020, 19:08
by mash
This could be tested by "mash" by booting with his SD card out, then after inserting the SD card, see if "lsmod" shows any of the modules in '/lib/modules/4.4.187/kernel/drivers/mmc/host/'
No, it doesn't. I looked into dmesg and run diff on lsmod output before and after inserting SD card, and nothing.
Posted: Wed 10 Jun 2020, 00:39
by perdido
bigpup wrote:bigpup wrote:ScPup64 20.01+6
Frugal install using save folder.
Using the 5.4.6 kernel.
No wifi support for my wifi hardware.
Code: Select all
Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8822BE 802.11a/b/g/n/ac WiFi adapter [10ec:b822]
• Kernel Driver: r8822beS
• Memory Used: 768.00 KB
• Path: /lib/modules/4.19.23/kernel/drivers/staging/rtlwifi/r8822be.ko
• Description: Realtek 802.11n PCI wireless core
• Description: PCI basic driver for rtlwifi
• Description: Realtek 8822BE 802.11n PCI wireless
Got the needed firmware installed.
Need the kernel driver.
r8822be.ko
This source package has the needed driver.
I have used this to get driver for other Puppies.
Realtek source package for wifi
https://github.com/rtlwifi-linux/rtlwifi-next
running make and make install get errors.
Yes I unzipped the package.
Have the devx and kernel sources sfs's loaded.
Can someone try compiling this driver package.
Hi bigpup,
Compiled a driver in scpup64 kernel 5.4.6 from sources at
https://github.com/mid-kid/r8822be
I stuck it here
http://ibm-pc.org/puppy/scpup64/k5.4.6/ ... r8822be.ko
It needs firmware rtl8822befw.bin
No idea if it will work as I don't have a device with that chipset.
Code: Select all
# modinfo r8822be.ko
filename: /initrd/mnt/dev_save/scpup64/ScPup64save/root/r8822be-master/r8822be.ko
description: Realtek 802.11n PCI wireless core
license: GPL
author: Larry Finger <Larry.FInger@lwfinger.net>
author: Realtek WlanFAE <wlanfae@realtek.com>
author: lizhaoming <chaoming_li@realsil.com.cn>
description: PCI basic driver for rtlwifi
license: GPL
author: Larry Finger <Larry.FInger@lwfinger.net>
author: Realtek WlanFAE <wlanfae@realtek.com>
author: lizhaoming <chaoming_li@realsil.com.cn>
firmware: rtlwifi/rtl8822befw.bin
description: Realtek 8822BE 802.11n PCI wireless
license: GPL
author: Larry Finger <Larry.Finger@lwfinger.net>
author: Realtek WlanFAE <wlanfae@realtek.com>
description: Realtek 802.11n PCI wireless core
license: GPL
author: Larry Finger <Larry.FInger@lwfinger.net>
author: Realtek WlanFAE <wlanfae@realtek.com>
description: Realtek 802.11n PCI wireless core
license: GPL
author: Larry Finger <Larry.FInger@lwfinger.net>
author: Realtek WlanFAE <wlanfae@realtek.com>
alias: pci:v000010ECd0000B822sv*sd*bc*sc*i*
depends: mac80211,cfg80211
retpoline: Y
name: r8822be
vermagic: 5.4.6-lxpup64 SMP mod_unload modversions
parm: debug_level:int
parm: swenc:Set to 1 for software crypto (default 0)
(bool)
parm: ips:Set to 0 to not use link power save (default 1)
(bool)
parm: swlps:Set to 1 to use SW control power save (default 0)
(bool)
parm: fwlps:Set to 1 to use FW control power save (default 1)
(bool)
parm: msi:Set to 1 to use MSI interrupts mode (default 1)
(bool)
parm: dma64:Set to 1 to use DMA 64 (default 0)
(bool)
parm: aspm:Set to 1 to enable ASPM (default 1)
(int)
parm: debug:Set debug level (0-5) (default 0)
parm: debug_mask:Set debug mask (default 0) (ullong)
parm: disable_watchdog:Set to 1 to disable the watchdog (default 0)
(bool)