Tiny Core Linux
Tiny Core Extensions => TCE Talk => Extension requests => Topic started by: madmax on October 24, 2019, 06:05:08 PM
-
Hello:
The kernel modules required by the Nouveau driver are:
1. drm.ko
2. drm_kms_helper.ko
3. ttm.ko
4. nouveau.ko.
See: https://nouveau.freedesktop.org/wiki/InstallNouveau/ (https://nouveau.freedesktop.org/wiki/InstallNouveau/)
For some reason, nouveau.ko is not loaded along with drm.ko, drm_kms_helper.ko, ttm.ko. when loading xf86-video-nouveau.tcz.
tc@box:~$ slocate drm.ko
/usr/local/lib/modules/4.19.10-tinycore/kernel/drivers/gpu/drm/hisilicon/hibmc/hibmc-drm.ko.gz
/usr/local/lib/modules/4.19.10-tinycore/kernel/drivers/gpu/drm/drm.ko.gz
/usr/local/lib/modules/4.19.10-tinycore/kernel/drivers/gpu/drm/bochs/bochs-drm.ko.gz
tc@box:~$
tc@box:~$ slocate drm_kms_helper.ko
/usr/local/lib/modules/4.19.10-tinycore/kernel/drivers/gpu/drm/drm_kms_helper.ko.gz
tc@box:~$
tc@box:~$ slocate ttm.ko
/usr/local/lib/modules/4.19.10-tinycore/kernel/drivers/gpu/drm/ttm/ttm.ko.gz
tc@box:~$ slocate nouveau.ko
tc@box:~$
Loading xf86-video-nouveau.tcz as suggested for Xorg 7.7 ie: without an xorg.conf file brings up this error in the Xor.0.log file:
[ 24.326] (EE) [drm] Failed to open DRM device for pci:0000:02:00.0: -19
[ 24.452] (EE) [drm] Failed to open DRM device for pci:0000:02:00.0: -19
It would seem that the errors are caused by the nouveau.ko not being loaded.
See https://nouveau.freedesktop.org/wiki/TroubleShooting/#index1h3 (https://nouveau.freedesktop.org/wiki/TroubleShooting/#index1h3).
I guess (?) xf86-video-nouveau.tcz needs an update to include nouveau.ko or maybe it is easier if nouveau.ko can be made into .tcz listed in the dep files to be installed along with xf86-video-nouveau.tcz.
Thanks in advance,
MM
-
Hi madmax
I wonder if this is causing you problems:
# CONFIG_DRM_NOUVEAU is not setfound here:
http://tinycorelinux.net/10.x/x86/release/src/kernel/config-4.19.10-tinycore
-
Hello Rich:
I wonder if this is causing you problems:
# CONFIG_DRM_NOUVEAU is not setfound here:
http://tinycorelinux.net/10.x/x86/release/src/kernel/config-4.19.10-tinycore
Well ...
Evaluating what that configuration entry actually does is really way (way) over my head so I really could not say.
I never got around to doing anyhing more than .bat files and opted for working in the hardware aspects of IT, where I was rather a 'natural' and thus, more proficient. ie: made more money.
By the time I wanted to learn about scripts and compiling, I was too busy making ends meet and had no time for it.
So I can only refer to what the freedesktop.org pages point out.
ie:
Is X using the right driver (DDX)?
Do not use nv driver in X. Use nouveau instead. Check your Xorg.0.log file and make sure you see lines like NOUVEAU(0). If you do not use such lines, check your xorg.conf.
and
Kernel
The kernel modules required by Nouveau (drm.ko, drm_kms_helper.ko, ttm.ko and nouveau.ko) are built from a Linux kernel tree.
Just to try out/check/compare, I booted up a Mint 17.x live DVD (which boots with Nouveau drivers) and two of my three screens came up with the correct resolution of 1280x1024. I do recall that some minor tweaking of the xorg.conf file was required to get all three running as a single desktop, but that was all.
All the files required by the troubleshooting page freedesktop.org were present in the Mint 17.x live system.
Thanks a lot for your input.
Cheers,
MM
-
Hi madmax
The configuration item CONFIG_DRM_NOUVEAU:
prompt: Nouveau (NVIDIA) cards
type: tristate
depends on: CONFIG_DRM && CONFIG_PCI && CONFIG_MMU
defined in drivers/gpu/drm/nouveau/Kconfig
found in Linux kernels: 3.17â3.19, 4.0â4.20, 5.0â5.3, 5.4-rc+HEAD
modules built: nouveau
Found here:
https://cateee.net/lkddb/web-lkddb/DRM_NOUVEAU.html
Some more info in this thread:
http://forum.tinycorelinux.net/index.php?topic=21484.0
-
Hello Rich:
Found here:
https://cateee.net/lkddb/web-lkddb/DRM_NOUVEAU.html
Some more info in this thread:
http://forum.tinycorelinux.net/index.php?topic=21484.0
Thanks for the information but I must say that I don't really know exactly what to make of all this.
I could not make much out of of the info in the cateee.net link until I read the other forum link.
At first sight and even after reading it over, it all seems rather contradictory and must confess that I'm rather puzzled.
So, here's what I understand:
(please allow for my lack of programming/compiling know-how and correct me if I am wrong somewhere)
1.
According to https://nouveau.freedesktop.org/wiki/InstallNouveau/ (https://nouveau.freedesktop.org/wiki/InstallNouveau/) the kernel modules required by the Nouveau driver are:
1. drm.ko
2. drm_kms_helper.ko
3. ttm.ko
4. nouveau.ko.
See: https://nouveau.freedesktop.org/wiki/InstallNouveau/
2.
According to https://nouveau.freedesktop.org/wiki/TroubleShooting (https://nouveau.freedesktop.org/wiki/TroubleShooting) the nv driver should not be used in X, the nouveau driver being the right one to use.
3.
The nouveau driver is available for downloading/installation from the Tinycore repositories (at least as far back as 7.1) but it does not work properly due to nouveau.ko not being loaded. The error messages in Xorg.0.log plus the information in the above troubleshooting page would indicate that is exactly the issue at hand.
4.
If I understood correctly, the nouveau.ko module not loading and the consequent malfunctioning of the nouveau driver are linked and the direct result of the kernel not being configured to load it.
ie:
# CONFIG_DRM_NOUVEAU is not set
5.
Reading the post from exactly two years ago that you've linked to, it would seem that this was done purposedly owing to the nouveau driver being considered at that time "still far too unstable" without any further explanation and recommending the use of the nv driver (which does not work properly with my card as I have found out) or the NVidia propietary driver, which is unavailable in 10.1 and has been unavailable at least from 7.2.
I don't know if the criteria used two years ago to deem the nouveau driver "still far too unstable" are still valid today, but said criteria was certainly not shared by Ubuntu and Ubuntu based distributions such as Mint where it works perfectly well on the same hardware.
Wouldn't it be much easier to enable CONFIG_DRM_NOUVEAU and post a big fat warning in the info section saying that it was "still far too unstable"?
It would certainly be much more time effective. = ^/
You have generously been answering all my questions and helping me out in my attempts to get my NVidia card to work properly for a good while, only to arrive many posts later to the fact that the nouveau driver is available for download but crippled at kernel configuration level.
I propose to those responsible for compiling the kernel that CONFIG_DRM_NOUVEAU be set.
I volunteer to test the nouveau driver and see if it still shows any stability problems.
Thank you Rich for all your help.
Best,
MM
-
Can your video hardware use the nvidia-390.116-4-KERNEL and nvidia-glx-390.116-KERNEL extensions?
-
Hello Juanito:
... use the nvidia-390.116-4-KERNEL and nvidia-glx-390.116-KERNEL extensions?
Unfortunately not.
I tried the 390.116 drivers at the very start but Xorg.0.log complained saying that the installed hardware needs the 340 legacy drivers.
At the moment I am attempting to use the Xvesa driver.
I get the 1280x1024 resolution but the tearing when I move a window (or scroll) makes it all but unusable, the same happens with the xfbdev driver.
Thanks,
MM
-
Did you try Xorg-7.7 with the xf86-video-vesa driver - i.e. without loading the xf86-video-nouveau extension?
-
Hello:
... try Xorg-7.7 with the xf86-video-vesa driver - i.e. without loading the xf86-video-nouveau extension?
Yes, one of the first things I tried.
X would not start.
Cheers,
MM
PS: copied the log to the wrong place so it vanished. There's a int10 issue but let me know if you need to see it.
-
nouveau-KERNEL extension posted - I don't have the hardware to test.
-
Hello Juanito:
nouveau-KERNEL extension posted - I don't have the hardware to test.
Thank you very much. =-)
I'll load it and see how it works.
Do you want me to run any specific tests?
Let me know and I'll post or send you the results.
Cheers,
MM
-
Hello Juanito:
I'll load it and see how it works.
Unfortunately there has been no change.
Things are like when I posted here:
http://forum.tinycorelinux.net/index.php/topic,23259.0.html (http://forum.tinycorelinux.net/index.php/topic,23259.0.html)
Specifically Reply #3.
[ 24.326] (EE) [drm] Failed to open DRM device for pci:0000:02:00.0: -19
[ 24.452] (EE) [drm] Failed to open DRM device for pci:0000:02:00.0: -19
I'm attaching Xorg.0.log for this session.
Note that even though Xfbdev is being loaded, Xorg.0.log says it cannot open the module.
Also, the nouveau module is installed but not being loaded
tc@box:~$ slocate nouveau
/mnt/sda1/tce/optional/xf86-video-nouveau.tcz.md5.txt
/mnt/sda1/tce/optional/nouveau-4.19.10-tinycore.tcz.md5.txt
/mnt/sda1/tce/optional/nouveau-4.19.10-tinycore.tcz
/mnt/sda1/tce/optional/nouveau-4.19.10-tinycore.tcz.dep
/mnt/sda1/tce/optional/xf86-video-nouveau.tcz
/usr/local/lib/libdrm_nouveau.so.2.0.0
/usr/local/lib/libdrm_nouveau.so.2
/usr/local/lib/libdrm_nouveau.so
/usr/local/lib/xorg/modules/drivers/nouveau_drv.so
/usr/local/lib/modules/4.19.10-tinycore/kernel/drivers/gpu/drm/nouveau
/usr/local/lib/modules/4.19.10-tinycore/kernel/drivers/gpu/drm/nouveau/nouveau.ko.gz
/usr/local/tce.installed/xf86-video-nouveau
/usr/local/tce.installed/nouveau-4.19.10-tinycore
tc@box:~$
tc@box:~$ lsmod | grep nouveau
tc@box:~$
tc@box:~$ sudo modprobe nouveau
modprobe: can't load module nouveau (kernel.tclocal/drivers/gpu/drm/nouveau/nouveau.ko.gz): unknown symbol in module, or unknown parameter
tc@box:~$
Also found this in dmesg:
[ 14.803025] nouveau: Unknown symbol drm_legacy_mmap (err -2)
[ 14.876423] nouveau: Unknown symbol drm_legacy_mmap (err -2)
Thanks for the effort, specially on a saturday.
MM
-
Look at the depends line in “modinfo nouveau” to see which module is missing.
-
Hello:
... depends line in “modinfo nouveau” to see which module is missing.
OK
tc@box:~$ modinfo nouveau
filename: /lib/modules/4.19.10-tinycore/kernel.tclocal/drivers/gpu/drm/nouveau/nouveau.ko.gz
author: Nouveau Project
description: nVidia Riva/TNT/GeForce/Quadro/Tesla/Tegra K1+
license: GPL and additional rights
---- snip ----
alias: pci:v000012D2d*sv*sd*bc03sc*i*
alias: pci:v000010DEd*sv*sd*bc03sc*i*
depends: drm,drm_kms_helper,ttm,agpgart,mxm-wmi,wmi,video,i2c-algo-bit
---- snip ----
tc@box:~$
tc@box:~$ lsmod | grep drm
drm_kms_helper 86016 0
fb_sys_fops 12288 1 drm_kms_helper
syscopyarea 12288 1 drm_kms_helper
sysfillrect 12288 1 drm_kms_helper
sysimgblt 12288 1 drm_kms_helper
drm 212992 2 drm_kms_helper,ttm
agpgart 24576 2 ttm,drm
tc@box:~$
tc@box:~$ lsmod | grep wmi
mxm_wmi 12288 0
wmi 16384 1 mxm_wmi
tc@box:~$
tc@box:~$ lsmod | grep video
video 28672 0
backlight 12288 1 video
tc@box:~$
tc@box:~$ lsmod | grep algo
i2c_algo_bit 12288 0
tc@box:~$
It would seem that they are all there (?).
Thanks,
MM
-
Hello:
It would seem that they are all there (?).
Sorry, I neglected to add ttm and agpgart, but they are present:
tc@box:~$ lsmod | grep ttm
ttm 53248 0
drm 212992 2 drm_kms_helper,ttm
agpgart 24576 2 ttm,drm
tc@box:~$
tc@box:~$ lsmod | grep agpgart
agpgart 24576 2 ttm,drm
tc@box:~$
Do let me know if there's anything else I can do.
Thanks in advance,
MM
-
Hmm - it looks like the missing module is not listed..
-
Hello:
Hmm - it looks like the missing module is not listed..
From what I understand, all dependencies are met.
Just guessing here ...
Could it possibly be a mismatch issue?
See: https://nouveau.freedesktop.org/wiki/TroubleShooting/#index1h3 (https://nouveau.freedesktop.org/wiki/TroubleShooting/#index1h3)
Your DDX does not work with your current kernel and/or libdrm. There are at least three possible reasons for this: the nouveau DRM kernel module is not loaded, a version mismatch between the Nouveau DRM and libdrm, or KMS being disabled.
A search for the error string in dmesg got me only four hits, but this one may have a clue (?):
https://pyra-handheld.com/boards/threads/contributing-to-pyraos.83744/page-3 (https://pyra-handheld.com/boards/threads/contributing-to-pyraos.83744/page-3)
Trying to force load:
root@letux:~# modprobe -f pvrsrvkm
[ 183.101188] pvrsrvkm: bad vermagic: kernel tainted.
[ 183.106342] Disabling lock debugging due to kernel taint
[ 183.112517] pvrsrvkm: loading out-of-tree module taints kernel.
[ 183.120513] pvrsrvkm: Unknown symbol drm_legacy_mmap (err -2)
modprobe: ERROR: could not insert 'pvrsrvkm': Unknown symbol in module, or unknown parameter (see dmesg)
root@letux:~#
This means the 4.19.4-letux-lpae-zmatt-pyra kernel module is not compatible to the 4.19.4-letux kernel...
In other words: an archive of pvrsrvkm.ko variants isn't enough if the matching kernel image + other modules is missing.
I don't know what to make of it (or the rest of the thread) but you surely can.
Thanks in advance,
MM
-
Hello:
... the depends line in “modinfo nouveau” to see which module is missing.
Like I said earlier and unless I am missing something, all module depencencies seem to have been met.
ie: the result of *depends* (drm,drm_kms_helper,ttm,agpgart,mxm-wmi,wmi,video,i2c-algo-bit) is shown when each of the dependencies are looked for via lsmod.
So, what could be the issue now with the nouveau-KERNEL extension you posted?
I understand that you do not have access to the hardware but I can run any tests you need.
Do you need me to run any more tests?
Thanks in advance,
MM
-
Hi madmax
I suggest starting with some basic information so we can compare what's not working with what is.
Execute:
dmesg > dmesg.txt
lsmod > lsmod.txt
Boot up the working Mint disk.
Execute:
dmesg > dmesgMint.txt
lsmod > lsmodMint.txt
Attach those 4 files to your next post.
-
Hello Rich:
... some basic information so we can compare ...
Done.
Let me know if you need anything else.
Thanks a lot for your help.
Best,
MM
-
Hello Rich:
... some basic information so we can compare ...
I was thinking that maybe comparing the outputs of modinfo mouveau could be useful to you.
I'm attaching both, from Mint and from TC.
Cheers,
MM
-
Hmm - maybe CONFIG_DRM_LEGACY needs to set as well...
-
Hello Juanito:
Hmm - maybe CONFIG_DRM_LEGACY needs to set as well...
You may be right, sort of makes sense.
It's just an educated guess on my behalf, but seeing that my Quadro FX580 cards are only supported by the NVidia 340.xx legacy drivers, it could be (?) that setting CONFIG_DRM_LEGACY would enable the Nouveau drivers to work as they should.
If you would upload the nouveau-KERNEL extension with both the CONFIG_DRM_NOUVEAU and CONFIG_DRM_LEGACY options set, I'll test it and report back attaching the new versions of the files I uploaded earlier.
Thank you very much for your help in this matter.
Best,
MM
-
CONFIG_DRM_LEGACY cannot be set standalone, it needs (at least) "Enable legacy drivers".
From Kconfig: menuconfig DRM_LEGACY
bool "Enable legacy drivers (DANGEROUS)"
depends on DRM && MMU
select DRM_VM
help
Enable legacy DRI1 drivers. Those drivers expose unsafe and dangerous
APIs to user-space, which can be used to circumvent access
restrictions and other security measures. For backwards compatibility
those drivers are still available, but their use is highly
inadvisable and might harm your system.
That notwithstanding, I believe you would need to remaster tinycore (vmlinuz) for these changes to work.
-
Hello Juanito:
CONFIG_DRM_LEGACY cannot be set standalone, it needs (at least) "Enable legacy drivers".
From Kconfig: menuconfig DRM_LEGACY
bool "Enable legacy drivers (DANGEROUS)"
depends on DRM && MMU
select DRM_VM
help
Enable legacy DRI1 drivers. Those drivers expose unsafe and dangerous
APIs to user-space, which can be used to circumvent access
restrictions and other security measures. For backwards compatibility
those drivers are still available, but their use is highly
inadvisable and might harm your system.
That notwithstanding, I believe you would need to remaster tinycore (vmlinuz) for these changes to work.
Am I to undestand that, at least in TC10.x, the only way to get the Nouveau drivers to work properly is by remastering TinyCore?
Thanks in advance,
MM
-
affirmative - I believe that vmlinuz would need to be replaced and an extension made for the additional modules.
Note that, given the kconfig warning, it is unlikely that this functionality would be added in future versions of tinycore.
-
Hi Juanito
CONFIG_DRM_LEGACY cannot be set standalone, it needs (at least) "Enable legacy drivers".
From Kconfig: menuconfig DRM_LEGACY
bool "Enable legacy drivers (DANGEROUS)"
depends on DRM && MMU
select DRM_VM
help
Enable legacy DRI1 drivers. Those drivers expose unsafe and dangerous
APIs to user-space, which can be used to circumvent access
restrictions and other security measures. For backwards compatibility
those drivers are still available, but their use is highly
inadvisable and might harm your system.
That notwithstanding, I believe you would need to remaster tinycore (vmlinuz) for these changes to work.
That looks like may be the issue. From drm_vm.c:
int drm_legacy_mmap(struct file *filp, struct vm_area_struct *vma)
{
struct drm_file *priv = filp->private_data;
struct drm_device *dev = priv->minor->dev;
int ret;
if (drm_dev_is_unplugged(dev))
return -ENODEV;
mutex_lock(&dev->struct_mutex);
ret = drm_mmap_locked(filp, vma);
mutex_unlock(&dev->struct_mutex);
return ret;
}
EXPORT_SYMBOL(drm_legacy_mmap);
It seems odd that nouveau didn't include drm_vm as a dependency.
-
Hello Juanito:
Now that the xfe issue has been solved, I'd like to see if we get back to this one: TinyCore, Nouveau, it's lack of stability and why it won't work in TC.
... vmlinuz would need to be replaced and an extension made for the additional modules.
... given the kconfig warning, it is unlikely that this functionality would be added in future versions ...
I've been spending some time burning DVDs and checking what drivers different distributions use and what goes on inside the kernel configuration files.
While I clearly understand the type of problems that enabling DRM_LEGACY could entail ...
menuconfig DRM_LEGACY
bool "Enable legacy drivers (DANGEROUS)"
depends on DRM && MMU
select DRM_VM
help
Enable legacy DRI1 drivers. Those drivers expose unsafe and dangerous
APIs to user-space, which can be used to circumvent access
restrictions and other security measures. For backwards compatibility
those drivers are still available, but their use is highly
inadvisable and might harm your system.
... the fact that Devuan, Mint, Open Suse and Ubuntu (to name just these four) use Nouveau drivers in their distributions makes me think that we may be looking at this the wrong way or there's something we are missing. (using the pronoun we very generously).
I, for one, am missing absolutely everything, but I'm trying. 8^O!
What I mean to say is that the chaps in charge of packaging these mainstream distributions are certainly not oblivious to the menuconfig DRM_LEGACY warning you have quoted and there is absolutely nothing that leads me to think they are going rogue with respect to kernel security issues, so to speak. Especially in the case of the Devuan maintainers.
But in all these distributions the Nouveau drivers work out of the box with the right native resolution for the installed screen and will run my three screen hardware setup with just some tweaking of a bespoke xorg.conf file, to the extent that said file can be transplanted between distributions without much issue.
So ...
What is going on?
I booted up Devuan, Mint and OpenSuse to see what I could find in terms of kernel configuration and try to compare it to the TCore kernel configuration, but I can't find it. I did found some pertinent entries (ie: Nouveau and DRM_LEGACY) in the other distribution files, albeit in different places.
Devuan kernel configuration:
ACP (Audio CoProcessor) Configuration
#
CONFIG_DRM_AMD_ACP=y
CONFIG_DRM_NOUVEAU=m <<<<<<<
CONFIG_NOUVEAU_DEBUG=5
CONFIG_NOUVEAU_DEBUG_DEFAULT=3
CONFIG_DRM_NOUVEAU_BACKLIGHT=y
CONFIG_DRM_I915=m
# CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT is not set
CONFIG_DRM_I915_USERPTR=y
# CONFIG_DRM_I915_GVT is not set
---
# Display Interface Bridges
#
# CONFIG_DRM_ANALOGIX_ANX78XX is not set
CONFIG_HSA_AMD=m
CONFIG_DRM_LEGACY=y <<<<<<<
CONFIG_DRM_TDFX=m
CONFIG_DRM_R128=m
# CONFIG_DRM_I810 is not set
CONFIG_DRM_MGA=m
CONFIG_DRM_SIS=m
CONFIG_DRM_VIA=m
CONFIG_DRM_SAVAGE=m
Mint 17.1 kernel configuration. Note that there is no DRM_LEGACY entry:
# I2C encoder or helper chips
#
CONFIG_DRM_I2C_ADV7511=m
CONFIG_DRM_I2C_CH7006=m
CONFIG_DRM_I2C_SIL164=m
CONFIG_DRM_I2C_NXP_TDA998X=m
CONFIG_DRM_PTN3460=m
CONFIG_DRM_TDFX=m
CONFIG_DRM_R128=m
CONFIG_DRM_RADEON=m
# CONFIG_DRM_RADEON_UMS is not set
CONFIG_DRM_NOUVEAU=m <<<<<<<
CONFIG_NOUVEAU_DEBUG=5
CONFIG_NOUVEAU_DEBUG_DEFAULT=3
CONFIG_DRM_NOUVEAU_BACKLIGHT=y
CONFIG_DRM_I810=m
CONFIG_DRM_I915=m
CONFIG_DRM_I915_KMS=y
CONFIG_DRM_I915_FBDEV=y
CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT=y
CONFIG_DRM_MGA=m
CONFIG_DRM_SIS=m
CONFIG_DRM_VIA=m
CONFIG_DRM_SAVAGE=m
CONFIG_DRM_VMWGFX=m
CONFIG_DRM_VMWGFX_FBCON=y
CONFIG_DRM_GMA500=m
CONFIG_DRM_GMA600=y
CONFIG_DRM_GMA3600=y
CONFIG_DRM_UDL=m
CONFIG_DRM_AST=m
# CONFIG_DRM_MGAG200 is not set
CONFIG_DRM_CIRRUS_QEMU=m
CONFIG_DRM_QXL=m
# CONFIG_DRM_BOCHS is not set
CONFIG_DRM_PANEL=y
Open Suse kernel configuration:
# AMD Library routines
#
CONFIG_CHASH=m
# CONFIG_CHASH_STATS is not set
# CONFIG_CHASH_SELFTEST is not set
CONFIG_DRM_NOUVEAU=m <<<<<<<
CONFIG_NOUVEAU_DEBUG=5
CONFIG_NOUVEAU_DEBUG_DEFAULT=3
# CONFIG_NOUVEAU_DEBUG_MMU is not set
CONFIG_DRM_NOUVEAU_BACKLIGHT=y
CONFIG_DRM_I915=m
# CONFIG_DRM_I915_ALPHA_SUPPORT is not set
CONFIG_DRM_I915_CAPTURE_ERROR=y
CONFIG_DRM_I915_COMPRESS_ERROR=y
CONFIG_DRM_I915_USERPTR=y
CONFIG_DRM_I915_GVT=y
CONFIG_DRM_I915_GVT_KVMGT=m
---
# Display Interface Bridges
#
# CONFIG_DRM_ANALOGIX_ANX78XX is not set
CONFIG_HSA_AMD=m
# CONFIG_DRM_HISI_HIBMC is not set
CONFIG_DRM_TINYDRM=m
CONFIG_TINYDRM_MIPI_DBI=m
CONFIG_TINYDRM_ILI9225=m
CONFIG_TINYDRM_ILI9341=m
# CONFIG_TINYDRM_MI0283QT is not set
CONFIG_TINYDRM_REPAPER=m
CONFIG_TINYDRM_ST7586=m
CONFIG_TINYDRM_ST7735R=m
CONFIG_DRM_XEN=y
CONFIG_DRM_XEN_FRONTEND=m
# CONFIG_DRM_LEGACY is not set <<<<<<<
CONFIG_DRM_PANEL_ORIENTATION_QUIRKS=m
# CONFIG_DRM_LIB_RANDOM is not set
Like I said earlier, I can't make heads or tails of all this but I think the secret to making Nouveau feasible in TCore is there.
I'm attaching the full configuration files for you to see. In case you need more info, please let me know.
Cheers,
MM
-
Since I don't have the hardware to test, I suggest you compile the kernel yourself - i.e.
$ tce-load -i compiletc perl5 bash ncursesw-dev bc glibc_apps elfutils-dev
$ tar xf linux-4.19.10-patched.txz
$ cp config-4.19.10-tinycore64 linux-4.19.10/.config
$ cd linux-4.19.10
$ make oldconfig
$ make menuconfig [figure out which combination enables the module with the missing symbols]
$ make
Once done, you'll need bzImage/vmlinuz, the nouveau module and whatever the modules with the missing symbols are called.
-
...and once you can compile the kernel, you can also compile the Nvidia drivers, which support your card much better than nouveau.
-
Hi madmax
I think I figured out the Unknown symbol drm_legacy_mmap issue.
Short answer:
Follow Juanitos directions. Then, when you run make menuconfig , go to Device Drivers->Graphics support->Nouveau (NVIDIA) cards.
Select m , then save and exit. Then run make . When make finishes (several hours) you need to replace your kernel (32 or 64 bit)
with the one that was just built (arch/x86/boot/bzImage or arch/ia64/boot/bzImage).
Long answer:
When you enable Device Drivers->Graphics support->Nouveau (NVIDIA) cards , it adds CONFIG_DRM_VM=y to the kernel config
file. This enables drm_vm.c to be compiled so the drm_legacy_mmap symbol can be resolved. CONFIG_DRM_VM is listed as
a bool (y or n) which means it can't be compiled as a module. It has to be compiled into the kernel. Since it's not compiled into
your kernel, the nouveau driver can't be loaded.
CONFIG_DRM_LEGACY is not required.
-
Hello Rich:
Sorry for the delay, I was waiting for your post before replying to Juanito and Curaga at the same time.
Since I don't have the hardware to test, I suggest you compile the kernel yourself ...
...and once you can compile the kernel, you can also compile the Nvidia drivers, which support your card much better than nouveau.
To be honest, these are not the replies I was hoping for. ;^ )
Like I have said before, I'm not a programmer/coder nor do I have any experience in compiling anything.
My limit is/was all the *.bat files I used/clobbered together from on-line sources to use in DOS/Windows environments (long ago now) and my attempts at understanding bash/scripting unfortunately have not borne fruit.
Hardware wise, from an early age I have been able to diagnose, disassemble and (most times) fix any IT box that has crossed my path.
Actually made a living from that when there was no work available for me as an architect.
But I digress ...
If I were knowledgeable enough to be do that ie: know how to complile an application or make something out of what a source code says, I would have long ago compiled the last version of the NVidia Legacy drivers and sent them to you so that they would be available in the repository for anyone to download.
So compiling a kernel is not something I can do but I do have the necessary legacy NVidia hardware and I have offered my help to test anything you need to test and report back with the results.
I think I figured out the Unknown symbol drm_legacy_mmap issue.
Thank you for taking the time to sift through the kernel configuration files from the other distributions.
I was sure the answer to the problem had to be there as the nouveau driver worked without issues in all of them and only need a screen location xorg.conf file in multiple screen setups.
Seeing that all of them had CONFIG_DRM_NOUVEAU=m and not =y or =n sort of waved a flag at me but had no idea what is was about or if it was of any importance at all.
When you enable Device Drivers->Graphics support->Nouveau (NVIDIA) cards, it adds CONFIG_DRM_VM=y to the kernel config file. This enables drm_vm.c to be compiled so the drm_legacy_mmap symbol can be resolved. CONFIG_DRM_VM is listed as a bool (y or n) which means it can't be compiled as a module. It has to be compiled into the kernel. Since it's not compiled into your kernel, the nouveau driver can't be loaded.
CONFIG_DRM_LEGACY is not required.
Good to know that CONFIG_DRM_LEGACY is not required for nouveau to work properly.
The prospect was rather worrying for if it was, there would have been something seriously wrong with the nouveau drivers.
Now, if (?) I understand your explanation correctly, the TC kernel needs to have Device Drivers->Graphics support->Nouveau (NVIDIA) cards set to =m so that the nouveau driver can be loaded. ie: the TC kernel has to have support for NVidia cards enabled.
If this is so, the fact that the TC kernel does not have it set to =m is the reason for the nouveau driver not loading/working properly.
ie: a driver available in the repository.
Wouldn't this be a kernel misconfiguration issue which could be corrected in a new updated version (10.2)?
Once again, thank you very much for having taken the time to address this problem.
Best regards,
MM
-
Hi madmax
Now, if (?) I understand your explanation correctly, the TC kernel needs to have Device Drivers->Graphics support->Nouveau (NVIDIA) cards set to =m so that the nouveau driver can be loaded. ie: the TC kernel has to have support for NVidia cards enabled.
That's basically correct. Enabling Nouveau causes some code to be added to the kernel when it gets compiled.
If this is so, the fact that the TC kernel does not have it set to =m is the reason for the nouveau driver not loading/working properly.
ie: a driver available in the repository.
The current kernel was not compiled to support the Nouveau driver.
Wouldn't this be a kernel misconfiguration issue which could be corrected in a new updated version (10.2)?
It's not mis-configured, just not configured to support the Nouveau driver. Unless a serious problem is found, the kernel
doesn't get updated for a current release.
-
..nor do I have any experience in compiling anything.
Compiling the kernel is not difficult and the instructions have been given earlier in the thread - why not give it a go?
If you have problems, there are forum members here willing to help.
-
Hello Rich:
The current kernel was not compiled to support the Nouveau driver.
I see.
It would seem then that my starting this thread ...
http://forum.tinycorelinux.net/index.php/topic,23259.msg145735.html#msg145735 (http://forum.tinycorelinux.net/index.php/topic,23259.msg145735.html#msg145735)
... to figure out why the nouveau driver was not working properly was rather an exercise in futility.
Just to end up here to find out that, no matter what and unless I compile the kernel myself, the Nouveau driver I downloaded from the repository would not work properly.
Ever.
Right, let me see if I understood:
1. The obvious
NVidia cards under Linux work either with the proprietary driver or with the open source Nouveau driver, albeit not as well.
Although this is a common complaint among Linux users on the web, the fact that mainstream distributions use them for their live/installation DVDs would seem to indicate that they work well enough if you are commited to using only open source drivers.
2. The facts
The proprietary 340.XX legacy drivers are presently not available in the TC10.x repository (I prerfectly understand why this is so) but the only possible alternative (Nouveau) is not supported by the TC kernel even though the drivers are available for download from the repository.
3. The surprise
The fact that the Nouveau drivers are not supported by the TC kernel is not due to a kernel mis-configuration or an involuntary lapse but an actual decision made by the kernel maintainers.
I'd be obliged if I could get an answer to a couple of questions:
- Why is the TC kernel not compiled to support the Nouveau driver?
Sort of goes in the opposite direction other distributions maintain with respect to the Nouveau drivers, surely there must be very good reason for this being so.
(Please don't tell me that different distributions make different decisions, I've already read that elsewhere.)
- With the TC kernel not compiled to support the Nouveau driver, what sense does it make to have the Nouveau drivers available for download if they will not work properly?
More so in the absense of any warning or indication that the drivers will not work properly, because ...
... not configured to support the Nouveau driver. Unless a serious problem is found, the kernel doesn't get updated for a current release.
You will surely undertsand why I would consider that having an open source driver in a (any) distribution's current repository which will not work properly because that distribution's current kernel is not compiled to support it would undoutedly make it into any distribution's serious problems list.
A driver problem, a kernel problem or both at the same time.
But then, maybe that's just me.
And I'm not a programmer or a kernel maintainer and my saying all this does not in any way undermine the fact that I highly value and appreciate the work you guys do for TC.
If perchance this is not considered a serious (or serious enough) problem, would it be realistic for me to expect that the TC10.2 release, whenever that comes along, will be compiled to support the open source Nouveau drivers?
Thank you very much for the clarifications you posted earlier and in advance for answering these questions.
You've been a real sport all along. ; ^)
Best,
MM
-
Hello Juanito:
Compiling the kernel is not difficult and ...
Says the chap in charge of maintaining the kernel of a unique Linux distribution! ;^ D !!!
... why not give it a go?
If you have problems, there are forum members here willing to help.
I know and I thank you for the encouragement and the offer.
But for this I really need an 'out of the box' or 'Bob's your uncle' solution.
I have (as surely you do also) far too many things on my plate at this time to stare down a kernel compilation rabbit-hole.
Maybe further on.
Cheers,
MM
-
Hi madmax
Why is the TC kernel not compiled to support the Nouveau driver?
Sort of goes in the opposite direction other distributions maintain with respect to the Nouveau drivers, surely there must be very good reason for this being so.
(Please don't tell me that different distributions make different decisions, I've already read that elsewhere.)
I don't know the answer to that. Maybe it was deemed that xf86-video-nv.tcz was adequate. It did successfully detect your hardware.
Maybe Juanito or curaga will weigh in on this.
With the TC kernel not compiled to support the Nouveau driver, what sense does it make to have the Nouveau drivers available for download if they will not work properly?
More so in the absense of any warning or indication that the drivers will not work properly, because ...
That's easy. Juanito had no way of knowing the Nouveau driver required a kernel compilation. The CONFIG_DRM_VM=y option
does not show up in the configuration menu so you don't even know it exists, let alone getting set to yes.
-
Says the chap in charge of maintaining the kernel
In fact that's @curaga ;)
If you confirm that you will not be recompiling the kernel (bzImage/vmlinuz), I'll delete the nouveau-KERNEL extensions since they will not work without a recompiled vmlinuz.
-
Nouveau is the same as the staging and experimental drivers. Anything that has a good chance of crashing your computer, losing your data, corrupting your screen and so on, must be heavily opt-in. I much prefer answering to "why is there no driver X" than to "your distro crashed my computer, I lost Y hours of writing and will tell so to everyone I know".
"Why not enable them with heavy warnings" - the newbies will not see those warnings. They will google or find on the forum to install xxx.tcz, and they will do so without reading the info file in most cases. That's why the policy is that such drivers may be contributed, but never in the official capacity. If you install for example the graphics- or scsi- extension, you will only get official kernel drivers, those that are generally considered safe, stable and usable.
-
Hello Rich:
I don't know the answer to that.
OK, fair enough.
Maybe it was deemed that xf86-video-nv.tcz was adequate.
OK, maybe that was what happened.
But freedesktop.org (https://nouveau.freedesktop.org/wiki/TroubleShooting) clearly says that xf86-video-nv driver should not be used and that the nouveau driver is the correct one to use. As they are the one who wrote it I expext they have good reason to say that.
It did successfully detect your hardware.
Maybe Juanito or curaga will weigh in on this.
I'm sure that you will concurr with me that detecting the hardware is just the start of a complex path to working properly.
Something that xf86-video-nv was shown unable to do.
Juanito had no way of knowing the Nouveau driver required a kernel compilation. The CONFIG_DRM_VM=y option
does not show up in the configuration menu so you don't even know it exists, let alone getting set to yes.
OK.
What you say makes complete sense.
But we are all at a different spot now and know (thanks to your looking into it) what is needed for the nouveau driver to work properly (ie: actually load) with the TC kernel so it seems that the road is paved to an easy solution to the problem of NVidia card support in TinyCore using open source drivers.
I was more than anything looking forward to reading your answer to the last question I asked in my previous post, one which I consider the most important:
... not configured to support the Nouveau driver. Unless a serious problem is found, the kernel doesn't get updated for a current release.
If perchance this is not considered a serious (or serious enough) problem, would it be realistic for me to expect that the TC10.2 release, whenever that comes along, will be compiled to support the open source Nouveau drivers?
Thanks in advance.
Best,
MM
-
Hi madmax
... not configured to support the Nouveau driver. Unless a serious problem is found, the kernel doesn't get updated for a current release.
If perchance this is not considered a serious (or serious enough) problem, would it be realistic for me to expect that the TC10.2 release, whenever that comes along, will be compiled to support the open source Nouveau drivers?
Even if a TC10.2 were released, I doubt the kernel would be recompiled for this issue.
The way I see it, If you want Nouveau support in the Tinycore kernel, you have 2 choices:
1. Wait for TC11 and see if curaga is willing to enable it.
2. Recompile the kernel yourself. Juanito provided instructions. People are available to answer questions. The hardest part is
waiting for the computer to finish the compilation.
-
Hello Rich:
Even if a TC10.2 were released, I doubt the kernel would be recompiled for this issue.
I see.
... If you want Nouveau support in the Tinycore kernel, you have 2 choices:
Indeed, it would seem that I am the only one who wants/needs/is asking for Nouveau support in the TC kernel.
This thread is already three pages long and with over 1000 views, it's only me, you, juanito and curaga.
No other TC end users, although I have read a few posts by a couple of others in my situation.
1. Wait for TC11 and see if curaga is willing to enable it.
Well ...
It seems to me that curaga has been both succinct and clear about what he thinks about Nouveau.
Willing is not a term I'd use. ;^ )
I have tried (and think I've succeeded) to make a case for the Nouveau drivers in TC, to the extent of pointing out the fact that Nouveau drivers are available for download but disabled in the TC kernel but to no avail.
As you may gather, I strongly disagree with his view on this matter.
But then I am not the kernel maintainer.
On one hand it rather flies in the face of what those in charge of all the other distributions I have cited would evidently opine and on the other (at least in my view) it does both open source software and Linux a disservice as it all but eliminates the possibility of anyone with older NVidia cards/hardware to be able to use TinyCore.
Lest, of course, they compile their own proprietary drivers or TC kernel to be able to load the Nouveau drivers.
2. Recompile the kernel yourself. Juanito provided instructions. People are available to answer questions.
The hardest part is waiting for the computer to finish the compilation.
Indeed.
Like I said, I really appreciate that but at the moment I have many things I have to deal with and really cannot delve into the complications of compiling a kernel at this time.
When I came upon TC a few years ago I was delighted to find a Linux distribution with this ease of use, reduced size and capacity to just start over in case of mistakes. It proved to be and still is the most important tool in I have for administering my main rig or reviving friends' old laptops/notebooks,
Most importantly, it helped me save my at the time installation (PCLinuxOS/MInt and Devuan) more than once.
I will (of course) continue to use it for what I have always used it for, just without a desktop requiring NVidia drivers for my older cards.
Will have to polish up on my command line skills.
Thanks a lot for taking the time to participate in this thread.
You've been a real sport. ;^)
Best regards and a good week-end,
MM
-
cannot delve into the complications of compiling a kernel at this time.
It takes ten minutes to set things up, 1-2 hours unattended to compile and then a couple of minutes to save the required files...
-
cannot delve into the complications of compiling a kernel at this time.
It takes ten minutes to set things up, 1-2 hours unattended to compile and then a couple of minutes to save the required files...
I took my turn of staring into the "rabbit-hole" of kernel compilation the other day and I can say this statement is not true.
I am trying to keep an old POS system alive. Right now it is running Ubuntu 12.04 with the proprietary nvidia driver. Due to customer demands I need to switch to a more recent operating system. With the hardware and memory constraints I am facing, I want to give TinyCore a shot. I noticed nouveau-4.14.10-tinycore (http://forum.tinycorelinux.net/index.php/topic,22113.msg138474.html#msg138474), read up on trials with nv (http://forum.tinycorelinux.net/index.php/topic,23259.msg145729.html#msg145729) and finally found this thread.
I compiled individual kernel modules, but I never compiled the kernel itself or the whole module structure. Juanito made it sound like this was an easy one. Alas, it is not. So far, I spent an entire day on this and gained nothing. This is what I did:
- I setup a virtual i386 machine since my target is i386 and all my developer systems are amd64. There seem to be some tricks involving schroot, but after spending an hour of finding out how that may work, using a virtual machine seemed to be easier.
- I downloaded the pre-patched TinyCore kernel, enabled support for nouveau and waited for the build to finish.
- I replaced the vmlinuz with the newly build kernel and… drm_legacy_mmap still cannot be found.
- I then discovered that the symbol indeed is defined, but not in the kernel but rather in drm.ko.gz. I am not familiar with TinyCore but I guess this meat I had to "remaster" the graphics-KERNEL-tinycore extension.
- With the new graphics extension in place, trying to load nouveau triggers a loading a dependency. However backlight cannot be loaded as the symbol backlight_device_get_by_type is already owned by kernel. Which seems to be a known problem (http://forum.tinycorelinux.net/index.php/topic,22077.msg138378.html#msg138378).
At this point, I am stumped. Why would menuconfig emit a configuration which leads to modules which cannot actually be used by the kernel the build produces? I am trying to produce a solution that is not only usable by me, but also by madmax and quite possibly other interested users. Any pointers of what I missed?
-
nouveau is enabled in the tc-11.x kernel - see http://forum.tinycorelinux.net/index.php/topic,23439.0.html
-
Hi hoehermann
Welcome to the forum.
----SNIP----
5. With the new graphics extension in place, trying to load nouveau triggers a loading a dependency. However backlight cannot be loaded as the symbol backlight_device_get_by_type is already owned by kernel. Which seems to be a known problem (http://forum.tinycorelinux.net/index.php/topic,22077.msg138378.html#msg138378).[/li][/list]
At this point, I am stumped. Why would menuconfig emit a configuration which leads to modules which cannot actually be used by the kernel the build produces? I am trying to produce a solution that is not only usable by me, but also by madmax and quite possibly other interested users. Any pointers of what I missed?
A couple of months ago I had to recompile a kernel to get some hardware on an ASUS T100 Transformer recognized and ran into
the same problem ("is already owned by kernel" error).
The error ("is already owned by kernel") is basically saying a symbol that a module is defining is already defined by the kernel. When
configuring a kernel, selecting certain options will force some drivers to be built into the kernel instead of as a module. So, assuming
you already have existing kernel modules, DRIVER_A is a module depending on DRIVER_B. You select a kernel option that requires
DRIVER_B to be built into the kernel. If you try loading DRIVER_A with the new kernel, it will attempt to load DRIVER_B (a dependency)
and you get that symbol "is already owned by kernel" error. This means DRIVER_A also needs to be recompiled so it no longer tries
to load DRIVER_B.
What I wound up doing is recompiling all modules when I changed the kernel. Here's a step by step for the whole procedure:
Compile a kernel:
tce-load -i compiletc perl5 bash ncursesw-dev bc glibc_apps elfutils-dev
wget http://tinycorelinux.net/10.x/x86_64/release/src/kernel/config-4.19.10-tinycore64
wget http://tinycorelinux.net/10.x/x86_64/release/src/kernel/linux-4.19.10-patched.txz
tar xf linux-4.19.10-patched.txz
cd linux-4.19.10
make mrproper
# Start with the most recent config file.
cp ../config-4.19.10-tinycore64 .config
make oldconfig
make menuconfig [make your changes]
# I like to save a copy of the config file to use as a starting point for the next time.
cp .config ../config-4.19.10-tinycore64-asusT100CHIrev1
# Compile kernel
make -j 2 bzImage
# Copy the kernel where the bootloader can find it.
cp arch/x86/boot/bzImage /mnt/sdg1/Linux/vmlinuzASUS64rev1
# Compile modules
make -j 2 modules
# Place the modules somewhere for packaging.
mkdir -p /home/tc/tmp/ASUS/modules/usr/local
make INSTALL_MOD_PATH=/home/tc/tmp/ASUS/modules/usr/local modules_install
cd /home/tc/tmp/ASUS/
# I like to keep the mod.alias, mod.builtin, mod.dep, mod.order, and mod.symbols files.
mv modules/usr/local/lib/modules/4.19.10-tinycore64/modules.* .
# Remove the 2 links in modules/usr/local/lib/modules/4.19.10-tinycore64/
rm modules/usr/local/lib/modules/4.19.10-tinycore64/build
rm modules/usr/local/lib/modules/4.19.10-tinycore64/source
# Set up sorter.sh to package all the modules.
cd ..
mkdir sorter
cd sorter
tce-load -i squashfs-tools zsync
wget https://github.com/tinycorelinux/sorter/archive/master.zip
unzip master.zip
cd sorter-master/
# This creates all of the Tinycore module packages and leaves them in the current directory.
./sorter.sh 4.19.10-tinycore64 /home/tc/tmp/ASUS/modules
# Back to the tmp directory.
cd ../../
# Fetch a 32 bit root file system.
wget http://tinycorelinux.net/10.x/x86/release/distribution_files/rootfs.gz
# Copy the module archive that's part of the base system
cp sorter/sorter-master/modules64.gz modulesASUS64rev1.gz
# Make a new initrd, 64 bit modules with 32 bit root file system (32 bit apps) in this example.
cat rootfs.gz modulesASUS64rev1.gz > coreASUS64rev1.gz
# Copy the initrd where the bootloader can find it.
cp coreASUS64rev1.gz /mnt/sdg1/Linux/
The downloads only need to be done once. If you need to compile again, use the config file you saved previously as a starting point.
Created directories to archive the results of each build. This allows you to revert to a previous build and keeps matching config,
kernels, modules, and initrd files together. Append rev1 to the config, kernel, and initrd filenames and place them in a rev1
directory along with their matching modules.
Compile times on a Dell Dimension E310 were 52 minutes for the kernel and 3 hours 45 minutes for the modules.
-
Thank you for your detailed explanation, Rich. I tried to replace the official versions with my custom build ones like this:
apt install bison flex ncurses-dev
wget http://tinycorelinux.net/10.x/x86/release/src/kernel/linux-4.19.10-patched.txz
tar xf linux-4.19.10-patched.txz
pushd linux-4.19.10/
wget -O .config http://tinycorelinux.net/10.x/x86/release/src/kernel/config-4.19.10-tinycore
make oldconfig
make menuconfig
make
cp arch/i386/boot/bzImage ${target}/tce/boot/vmlinuz
popd
wget --no-clobber http://tinycorelinux.net/10.x/x86/tcz/graphics-4.19.10-tinycore.tcz
unsquashfs graphics-4.19.10-tinycore.tcz
mksquashfs squashfs-root/ graphics-4.19.10-tinycore.tcz
pushd squashfs-root/usr/local/lib/modules/4.19.10-tinycore/kernel/
for m in $(find . -type f) ; do echo $(basename ${m%%.gz}) && cp ../../../../../../../linux-4.19.10/${m%%.gz} ${m%%.gz} && gzip -f ${m%%.gz} ; done
popd
mksquashfs squashfs-root/ graphics-4.19.10-tinycore.tcz
rm -r squashfs-root/
cp graphics-4.19.10-tinycore.tcz ${target}/tce/optional
md5sum ${target}/tce/optional/graphics-4.19.10-tinycore.tcz > ${target}/tce/optional/graphics-4.19.10-tinycore.tcz.md5.txt
wget --no-clobber http://tinycorelinux.net/10.x/x86/tcz/nouveau-4.19.10-tinycore.tcz
unsquashfs nouveau-4.19.10-tinycore.tcz
mksquashfs squashfs-root/ nouveau-4.19.10-tinycore.tcz
pushd squashfs-root/usr/local/lib/modules/4.19.10-tinycore/kernel/
for m in $(find . -type f) ; do echo $(basename ${m%%.gz}) && cp ../../../../../../../linux-4.19.10/${m%%.gz} ${m%%.gz} && gzip -f ${m%%.gz} ; done
popd
mksquashfs squashfs-root/ nouveau-4.19.10-tinycore.tcz
rm -r squashfs-root/
cp nouveau-4.19.10-tinycore.tcz ${target}/tce/optional
md5sum ${target}/tce/optional/nouveau-4.19.10-tinycore.tcz > ${target}/tce/optional/nouveau-4.19.10-tinycore.tcz.md5.txt
However, I ended up with a vmlinux wich actually positively included backlight_device_get_by_type. Only after reading your post I realize that my custom build also needs to replace /lib/modules/4.19.10-tinycore/kernel/drivers/video/backlight/backlight.ko.gz which is not part of either of the extensions I "remastered" but of the core.gz. Well, another thing learned, I guess.
nouveau is enabled in the tc-11.x kernel - see http://forum.tinycorelinux.net/index.php/topic,23439.0.html
Well I guess I made this a lot harder on me than I needed to. :D Thank you for the new version! :)
-
Hi hoehermann
Thank you for your detailed explanation, Rich. ...
You are welcome. I felt since you ran into the same issue that bit me, some clarification was in order in case anyone else has the
same problem.
One other note about kernel configuration. Selecting an option may force a module to be built in to the kernel. De-selecting that
same option will not undue that change. You have to be aware that it happened, track down the effected driver, and change its
status back to module if that's what you want.
-
One other note about kernel configuration. Selecting an option may force a module to be built in to the kernel. De-selecting that same option will not undue that change. You have to be aware that it happened, track down the effected driver, and change its status back to module (…)
This is valuable information for the next time I configure a kernel build. Thank you for sharing your knowledge. :)
-
Just a heads-up: After using TCL for a couple of weeks now, I can report nouveau is working perfectly fine for me. :) Good work and thank you!