Tiny Core Linux
Tiny Core Base => TCB Talk => Topic started by: curaga on March 04, 2013, 02:34:50 AM
-
Again it's time to post if you'd like to see any changes in the official kernel config. This only affects x86 and x64, the ARM ports will do their own thing.
Current list of changes to be done:
- more serial ports
- alsa virmidi
- ehci new scheduling
- netconsole as a module
- efi support
- sd.c cache errors to warnings
- some more netlink/iptables xfrm modules
- pcie hotplug
- pcmcia=y
We're targeting 3.7 currently.
This thread will remain open for two weeks.
-
I'm not sure if this minor thing is a kernel issue or not and I haven't spent a lot of effort troubleshooting it but...
I have a system with two sata hard disks and, usually, one USB flash drive plugged in. Occasionally, I plug a second USB stick in for backing up the primary one.
All connected drives mount and work fine (hence the minimal troubleshooting effort) but conky (the conky_plus extension) never recognizes "sdd", the second USB stick, as being mounted. I've always assumed it was some issue with conky, and I still suspect so, but if you could eliminate the possibility that it is some kernel configuration setting, I'd appreciate it.
-
I can't think of anything in the kernel that would cause that.
-
Appreciate this http://forum.tinycorelinux.net/index.php/topic,13212.msg73014.html#msg73014 (http://forum.tinycorelinux.net/index.php/topic,13212.msg73014.html#msg73014)
-
Also is USB 3.0 enabled by default in this kernel ?
-
Any chance to get the RealTek RTL81**** Wireless LAN NIC drivers in staging configured as modules?
-
For those who want to know what is in current try
http://tinycorelinux.net/4.x/x86/release/src/kernel/
-
@coreplayer2
That's the "ehci new scheduling", hadn't forgotten it. USB 3.0 was already enabled in the current kernel. If you're not getting usb 3.0 speeds, that may just be due to the 3.0 kernel not supporting your usb controller.
@tinypoodle
My stance wrt staging/unstable drivers is the same. I won't enable them by default, because no matter how many warnings there are, some noob will always follow a tutorial somewhere to load them and then blame Core when their computer crashes/hangs, loses data, and so on.
They are allowed in the repo if contributed, but it's an important line to keep on what's officially supported and what's not.
-
Question: As the kernel config options for the drivers in question are of "type: tristate", if choosing N in kernel config, can they later be built as modules from same kernel source to work with the stock kernel or not?
-
Yes, as long as it doesn't change other code (such as with ifdefs).
-
Much appreciated: http://forum.tinycorelinux.net/index.php/topic,14987.0.html
I am willing to test the early development releases on the machines I mentioned in the above thread.
Can you share with us when should we expect a 5.0 release based on 3.7+ something kernel?
-
Thanks curaga I should have read more closely
-
Can't give a timeframe other than "when it's ready", sorry. Alphas and RCs will be public as usual when they're passing our testing.
-
Could it has some "kernel tuning"?
(I'm not a Kernel hacker... forget about it if I said something dumb...)
-
What do you mean?
-
Hi curaga
I think he's referring to those secret hidden options in the kernel config file that when enabled make it
run 3 times faster.
-
What do you mean?
I was thinking in something like this: http://www.performancewiki.com/linux-tuning.html
I believe that it is already done, if not, maybe could be useful (or not).
Will study more of the kernel on Core.
-
Hi curaga
I think he's referring to those secret hidden options in the kernel config file that when enabled make it
run 3 times faster.
like
CONFIG_HAS_TURBO_MODE=y?
-
What do you mean?
I was thinking in something like this: http://www.performancewiki.com/linux-tuning.html
What exactly of all of those would you want to see implemented on kernel config level?
-
Compiling in large values for runtime tuneable values wastes memory for the majority of users who are running on minimal hardware.
If you really think you are going to run a large, hi performance database and a high traffic webserver on your Tiny Core Linux, you can
always tune it up in bootlocal.sh.
-
It's been a bit over two weeks. Seems no changes to the original list.
Any requests made after this may still make it in time, but can't give a date.
-
CONFIG_PCCARD=m
CONFIG_YENTA=m
Suggestion to consider changing those 2 from "m" to "y" to support earlier detection of storage devices attached through cardbus at boot.
-
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=68d929862e29a8b52a7f2f2f86a0600423b093cd (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=68d929862e29a8b52a7f2f2f86a0600423b093cd)
This patch is worth a mention because Linux has been said to brick some Samsung notebooks when writes consume more than 50% of NVRAM. As first occurrences where reported, many peeps blamed the Linux kernel, however the fault has since been traced to the notebook's firmware. AIUI the patch has been applied to the latest Linux kernel as a preventative measure. I think it's worth considering for this build..
-
AFAIK there is no configuration option in support "Secure Boot", the required tools it seems run before the boot-loader. But would hate to be limited when a Secure Boot implementation is available by not having the correct supporting options available, am just not 100% sure is all
-
The secureboot signing infra is outside the scope of TC, and would require far too many changes. Will make sure the Samsung patch is included.
@tinypoodle:
Sure, will do.
-
Great, thanks :)
-
Also Thanks
-
We're targeting 3.7 currently.
Can I ask why target 3.7 instead of 3.8? According to kernel.org the 3.7 release is already end-of-life.
As for what additional to include (hopefully I am not too late already).
I would like to see the following added (the xf86 Nouveau driver is much better than the NV driver and requires this):
* CONFIG_DRM_NOUVEAU=m
and the following (for easier/faster hosting of tinycorelinux in a Hyper-V virtual machine):
* CONFIG_HYPERV_BALLON=m
* CONFIG_HYPERV_NET=m
* CONFIG_HYPERV_STORAGE=m
* CONFIG_HYPERV_UTILS=m
* CONFIG_HYPERV=m
-
Can I ask why target 3.7 instead of 3.8? According to kernel.org the 3.7 release is already end-of-life.
3.8 had not matured enough at the time. It's just now getting there, so we're currently testing 3.8.4.
As for what additional to include (hopefully I am not too late already).
It is a bit too late, I'm afraid.
The nouveau driver is far too unstable to ship with confidence. The answer to that is the same as staging quality modules, welcome in the repo if contributed, but not included in the official build.
On HyperV support, since it was now out of staging, it was enabled for testing. Seems HYPERV_NET was missed as it would have needed going back, but it appears HyperV allows emulation of "normal" or legacy network cards too.
-
3.8 had not matured enough at the time. It's just now getting there, so we're currently testing 3.8.4.
Great. That is the same kernel version I have been testing independently for a couple of days. It has been working great on a low end Ivy Bridge based system. It fixed all the stability issues I was having with the 3.0.21 kernel and actually lowered power consumption (watts) significantly.
It is a bit too late, I'm afraid.
No worries.
The nouveau driver is far too unstable to ship with confidence. The answer to that is the same as staging quality modules, welcome in the repo if contributed, but not included in the official build.
Well that helps to explain why I was having issues trying to get it to work (on my custom kernel / xf86 driver build) last night. If I find a solution, I can contribute it if desired.
On HyperV support, since it was now out of staging, it was enabled for testing. Seems HYPERV_NET was missed as it would have needed going back, but it appears HyperV allows emulation of "normal" or legacy network cards too.
One thing to note, with the legacy NIC in Hyper-V one is limited to 100 mbps. That is enough for some purposes, but sometimes one wants the extra bandwidth. I can probably custom compile this for my purposes.
I think there is also a Hyper-V mouse driver that may be useful to some (myself included). I can look it up later if needed.
-
serisman
offtopic to theme of post I know but you may be interested in annoucement of nouveau going to v 1.0.7 or git snapshot equal to that version
http://lists.x.org/archives/xorg-announce/2013-March/002190.html
I use the closed src tcz driver found at TC repository search for nvidia-glx
-
If there is no particular reason to put the 'loop' as module, I would prefer to have it built-in.
It is very unlikely anybody would use TC without loading this module (infact it is loaded in tc-config). If it makes it into the 'built-in' state, there will be no need to 'modprobe' it explicitely in tc-config.
-
It was made a module in the 2.x series IIRC, to enable people to easily replace it with loop-aes. Squashfs, another "always-loaded" module, is a module to enable targeted updates/bugfixes.
-
Thanks! I was not aware of that.
-
Would like to BCache in the kernel.
http://bcache.evilpiepirate.org/
-
It's not in Linus' tree, and you're several weeks late.
-
:) I know. And actually maybe flashcache is better. Just wanted to help percolate the idea of getting an ssd cache solution into the kernel eventually.
Any idea when 5.0 might hit the streets, btw? I take it that 5.0 will be the next release?
-
The first alpha for 5.0 shouldn't be far, but needs more testing before it can be released.
There may be 4.7.x point releases with bugfixes before then.
-
The first alpha for 5.0 shouldn't be far, but needs more testing before it can be released.
There may be 4.7.x point releases with bugfixes before then.
Great!
In the meantime, I wonder if it would be possible to access the config file you are using, so to help with testing (ok, actually I'm just impatient to build it by myself :) ).
-
Thanks curaga and to the core team. I know testing the new kernel must me a monumental task.
8)
-
AFAIK there is no configuration option in support "Secure Boot", the required tools it seems run before the boot-loader. But would hate to be limited when a Secure Boot implementation is available by not having the correct supporting options available, am just not 100% sure is all
So all the laptops with Win 8 logo will come with Secure Boot turned on by default. I have an Acer and a Dell with that being the case, and they don't boot anything off of the USB and CD-Rom which is unsigned.
Are you guys planning to (1) ask users to turn secure boot off if running TC or (2) go the MS signed shim route (like Ubuntu Fedora etc) or (3) do the manual MOK route asking the user to manually add authentication?
-
Are you guys planning to (1) ask users to turn secure boot off if running TC
This one. IIRC it was discussed already.
If the user wants, they can also install one of the shims to chainload a normal (untrusted) grub/other loader.
In the meantime, I wonder if it would be possible to access the config file you are using, so to help with testing (ok, actually I'm just impatient to build it by myself ).
It's barely changed from the 4.x one, but sure:
http://tinycorelinux.net/~curaga/
-
It's barely changed from the 4.x one, but sure:
http://tinycorelinux.net/~curaga/
Thanks! I will try compiling it myself.
-
pay attention please
a friend of mine told me that there is a nasty bug in versions prior to 3.8.10
http://packetstormsecurity.com/files/cve/CVE-2013-2094 this is the bug
http://.sheep.org/~sd/warez/semtex.c and this is the exploit?
I'm sorry, I will not understand much but I bring you the information
-
Though I think this should rather be a thread of its own, here is a suggested fix:
http://arighi.blogspot.it/2013/05/linux-perfevents-root-exploit-cve-2013.html?m=1
-
is version 3.8.10 final ??
and any expected time frame on the alpha release yet please?
-
Yes, that version is final unless something comes up; and no, no timeframe other than "when it's ready".
-
fyi http://lwn.net/Articles/548819/
Output redirection vulnerabilities in recent kernels (Linux 3.8 and various 3.9 rcs are affected, depending on
configuration)
-
Seem not to apply, as we don't enable user namespaces (a still experimental feature).
-
version 3.8.10 so far.. ok thanks curaga
-
It might be too late or not possible, but given that touch screens are becoming increasingly popular, it would be appreciated if modules
- EVDEV
- UINPUT
- HIDRAW ( USB Interface )
- HID_MULTITOUCH
could be enabled in the TinyCore kernel by default. These modules are required by the eGalax touch driver http://home.eeti.com.tw/LinuxDriverDownload.html (http://home.eeti.com.tw/LinuxDriverDownload.html).
-
@Martin Heller
Please check the config first ;)
egrep 'EVDEV|UINPUT|HIDRAW|HID_MULTI' config-3.8.10-tinycore
CONFIG_INPUT_EVDEV=y
CONFIG_INPUT_UINPUT=m
CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV=y
CONFIG_USB_PWC_INPUT_EVDEV=y
CONFIG_HIDRAW=y
CONFIG_HID_MULTITOUCH=m
-
@Martin Heller
Please check the config first ;)
egrep 'EVDEV|UINPUT|HIDRAW|HID_MULTI' config-3.8.10-tinycore
CONFIG_INPUT_EVDEV=y
CONFIG_INPUT_UINPUT=m
CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV=y
CONFIG_USB_PWC_INPUT_EVDEV=y
CONFIG_HIDRAW=y
CONFIG_HID_MULTITOUCH=m
Perfect! Sorry for the noise, and thanks for all the work everybody is putting into TinyCore.
-
NX requires PAE. Any chance of getting these enabled?
Andy
-
It's far too late for 5.x. PAE is a bad hack, any PAE-capable computers should run the 64-bit kernel; see elsewhere on this forum.
-
Will the 64-bit version implement multilib to run 32-bit binaries?
Andy
-
Yes and no. Multilib would bring far too much complexity for the benefit.
However we offer three x86 editions:
32-bit
32-bit with the 64-bit kernel
64-bit (corepure64)
Running the 64-bit kernel with the 32-bit repo is fully supported.
-
How would a dev system work, if I need to compile 64-bit modules and 32-bit programs?
-
Maybe it's too late, but I want CONFIG_DEBUG_FS=y to be set for muxless video card switch. Though CONFIG_VGA_SWITCHEROO=y in the config file, I cannot find it in /sys.
-
You can compile and use a kernel with your own settings.
-
@andyj
There is a 32-to-64 cross-compiler extension (toolchain64.tcz). You'd use that for the modules, standard compiletc for the apps. The env vars to export for such a cross-module build have been posted in this forum; search for my posts with CROSS_COMPILE.
@awabimakoto
DEBUGFS is info leaks and bloat; putting a switch like that there is completely the wrong place for it. Complain to upstream that it should be in /sys.
-
CONFIG_PCCARD=m
CONFIG_YENTA=m
Suggestion to consider changing those 2 from "m" to "y" to support earlier detection of storage devices attached through cardbus at boot.
Tested with PPR and backup on UFD connected to Cardbus-to-USB2.0 at boot, works like a charm, even without "waitusb" :)