I was very very careful compiling this one and all seemed to go normally this time, so I'm at a loss to explain the panic except for a patch problem.
I do enable KMS- could that be a problem? Any suggestions?

EDIT: Hmmm. I did forget to enable CONFIG_SCHED_AUTOGROUP. Could that cause a kernel panic since cgroup and other items are enabled?

am very much interested to know what is happening here and with zen and your
sources.
i have been investigating and no solutions so far.
the code seems to be same but apparently something else is not right.

ok,

try disabling NUMA (you most likely don't have a numa box)

if that does not help try to disable PAE,

whether that makes a change

from what I read on the net the memory model also seems to be involved in those kind of things so please post the memory model (flat, sparse you have available for selection)

if I understood correctly it's running out of pageflags

gotta go to sleep now ...

i switch from sparse memory option to flat and the kernel compiles
but then panics at boot.
then i removed the PAE option. compiles, boots and now is running fine.
thanks.

@wrc1944
try disabling PAE.

CONFIG_SCHED_AUTOGROUP has no use for a desktop machine._________________this is a strange strange world.

I was very very careful compiling this one and all seemed to go normally this time, so I'm at a loss to explain the panic except for a patch problem.
I do enable KMS- could that be a problem? Any suggestions?

EDIT: Hmmm. I did forget to enable CONFIG_SCHED_AUTOGROUP. Could that cause a kernel panic since cgroup and other items are enabled?

Perhaps a short rundown of what specific kernel options are absolutely required when all these patches are used would help.

all other flags except kztmem are superfluous or in cases I want to try out new grsecurity kernels so that I won't forget anything for the start (they won't do harm if the features are not included in the kernel)

DO NOT enable KMS

I have a 5850 (evergreen) card and enabling it by default & having the radeon-module compiled in leads to hardlock / a kernel panic at the booting

so I tend to let it load later after the init or even load it manually with modeset - after that it works fine

OK. Recompiled without PAE, and set CONFIG_SCHED_AUTOGROUP=y, rebooted and got the same kernel panic.

Then I added radeon.modeset=0 to the kernel line (edited in the grub boot screen), and got same kernel panic.

So, in my case neither PAE or KMS seems to be the problem, or do I need to completely disable KMS in kernel config, and NOT rely on the grub kernel line option radeon.modeset=0?

More reading raised more questions about disabling KMS, as regards to failure to start X problems, and other various poor performance issues.

I'm NOT using an initrd (haven't for years) on hundreds of manually compiled kernels in many distros with no problems. Is this an issue? My basic config is always finely tuned to my hardware, and almost never presents a problem, so I'm thinking this kernel panic must be one of these patches, or I'm simply not aware of a required kernel option.

I'm going back to the other Gentoo ~xf86 box, which doesn't have KMS enabled, and try fresh again now that I know I can at least get the kerenl to compile.

OK. Recompiled without PAE, and set CONFIG_SCHED_AUTOGROUP=y, rebooted and got the same kernel panic.

Then I added radeon.modeset=0 to the kernel line (edited in the grub boot screen), and got same kernel panic.

So, in my case neither PAE or KMS seems to be the problem, or do I need to completely disable KMS in kernel config, and NOT rely on the grub kernel line option radeon.modeset=0?

More reading raised more questions about disabling KMS, as regards to failure to start X problems, and other various poor performance issues.

I'm NOT using an initrd (haven't for years) on hundreds of manually compiled kernels in many distros with no problems. Is this an issue? My basic config is always finely tuned to my hardware, and almost never presents a problem, so I'm thinking this kernel panic must be one of these patches, or I'm simply not aware of a required kernel option.

I'm going back to the other Gentoo ~xf86 box, which doesn't have KMS enabled, and try fresh again now that I know I can at least get the kerenl to compile.

Any other ideas?

yes,

it might be a little difficult or counter-productive to compare a 32bit to a 64bit config

In my haste, I stupidly just clicked once in xconfig and made them modules, instead of twice to built them in. I'm loosing my mind trying to get this to work.

OK- SUCCESS! After fixing up my kernel config (NO KMS enabled in kernel, cgroups with auto set, zram and kztmem enabled under staging drivers, kztmem on grub kernel line, and all other needed kernel options, everything compiled/installed/booted with no problems. Finally! Of course, what did I expect?

However I'm curious as to what the new and unusual dmesg output means??? What happened to all the usual stuff in dmesg?

now if I only knew whether those statements shall get me to be concerned about it

I haven't seen any data loss or corruption yet

Well, I just started the big full kde-4.5.5-kde-4.6.0 updates booted to your kernel, so I guess that'll be a good test.

I'l check on that CONFIG_DEBUG_SPINLOCK=y you mention, but IIRC it isn't enabled. I always build the leanest kernel possible, so I disable debug stuff unless I really have a specific reason to have it enabled. I'll let you know shortly- got some other things to do for a few hours while kde updates run.

OK- no CONFIG_DEBUG_SPINLOCK item found (only spinlock except for the IO Schedulers unset items) is this one, # CONFIG_RWSEM_GENERIC_SPINLOCK is not set, but I do have these other debug items set:

It has 8GB ram, so I've always selected under Processor type and features->High memory support 64GB, which allows 32 bit systems to use more than 4GB. This box has 2 ~x86 and one ~amd64 Gentoo installs, each on its own partition). While I do have a 64bit cpu, I'm running a 32bit Gentoo install and trying to compile this new kernel on it.

Code:

64GB (HIGHMEM64G)

CONFIG_HIGHMEM64G:

Select this if you have a 32-bit processor and more than 4
gigabytes of physical RAM.

Easy to miss this, but it also enforces PAE even if you disable it manually in your config file, or with xconfig/menuconfig.

In any case, this (along with the KMS being enabled) was preventing compiling the plusv13 kernel. I thought I had disabled PAE, but didn't realize that selecting 64GB high memory was overriding my no PAE setting.

Anyway, I've now got this new kernel on my main box, and will give it a good try for a few days and see what happens.

so it's ideal use case would be boxes which has relatively more CPU power than RAM available (e.g. where you can't upgrade RAM but can spare some CPU performance),
e.g. mobile devices, subnotebooks, tablets, etc.

a perfect example would be a laptop where you would want to reduce harddisk-access or even send it to standby and run a swap in cache (ramzswap) - in this case kztmem would be a nice addition

Update on kernel:
FWIW, on my main Gentoo box, with this kernel I'm having problems with the xorg-server crashing and sending me immediately to the kdm login screen. It happens randomly every 10-20 minutes, and I can't really tie it to any specific action, browser, or application. 2.6.37-ck1 and 2.6.38-rc's don't do this, and can't recall any other kernel ever doing this either. It's so unpredictable that it's not really usable like it is- can't trust it not to suddenly crash X at any time, and often.

Any ideas as to what might be the problem? A specific patch in the set? It's not a hardware problem, as all other distros on this box work fine, and the same Gentoo install booted to other kernels (with KMS enabled) don't exhibit this behavior either. I'm thinking it has something to do with having to disable the KMS feature on with this kernel. Not sure if my binary distros have KMS or not- will check later.

On my other box (the one still updating to kde-4.6.0), I'm having various graphical corruption problems, and the kde compile it taking way longer than usual (like at least 50% longer). However, I'm not ready to suspect the kernel yet, as this box is way underpowered and trying to run a new larger monitor. After kde finishes up (if ever ), I'll be able to tell more about it- don't want to implicate the kernel just yet. This old athon-xp box is currently at it's full cpu limit with the kde compile, and pretty much struggling to redraw the display with any action taken with an old radeon 9000 pro 64mb card. Awaiting a new motherboard/cpu with ddr3 ram, so next week when I do the upgrade I'll test this kernel some more with a decent system._________________Main box- AsRock x370 Gaming K4
Ryzen 1700, 3.0GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
Gentoo ~amd64 plasma, glibc-2.25-r3, gcc-7.1.0-r1 kernel-4.12.6 gentoo USE=experimental

Update on kernel:
FWIW, on my main Gentoo box, with this kernel I'm having problems with the xorg-server crashing and sending me immediately to the kdm login screen. It happens randomly every 10-20 minutes, and I can't really tie it to any specific action, browser, or application. 2.6.37-ck1 and 2.6.38-rc's don't do this, and can't recall any other kernel ever doing this either. It's so unpredictable that it's not really usable like it is- can't trust it not to suddenly crash X at any time, and often.

Any ideas as to what might be the problem? A specific patch in the set? It's not a hardware problem, as all other distros on this box work fine, and the same Gentoo install booted to other kernels (with KMS enabled) don't exhibit this behavior either. I'm thinking it has something to do with having to disable the KMS feature on with this kernel. Not sure if my binary distros have KMS or not- will check later.

On my other box (the one still updating to kde-4.6.0), I'm having various graphical corruption problems, and the kde compile it taking way longer than usual (like at least 50% longer). However, I'm not ready to suspect the kernel yet, as this box is way underpowered and trying to run a new larger monitor. After kde finishes up (if ever ), I'll be able to tell more about it- don't want to implicate the kernel just yet. This old athon-xp box is currently at it's full cpu limit with the kde compile, and pretty much struggling to redraw the display with any action taken with an old radeon 9000 pro 64mb card. Awaiting a new motherboard/cpu with ddr3 ram, so next week when I do the upgrade I'll test this kernel some more with a decent system.

it might be related to the kernel or graphics driver by itself

post the error message of /var/log/Xorg.0.log or /var/log/Xorg.0.log.old (if any)

kOT! remember me? Nice kernel patchset. I just wanted to chime in my two cents and say that the performance issues of disk I/O (I'm still using a mix of r4, xfs, and btrfs) that started a little in .35, got way worse in the latter portion or .36, are completely alleviated in .37. I'm back to the nostalgic high responsiveness and performance of BFS + BFQ. I know r4 isn't something you'll be using soon due to you current workloads, but if you have time to give BFS some love again, you may like it. For a make -j4 on my kernel, it's about 5% faster, but unlike CFS, I can call up disk intensive commands with minimal impact on both (such as an emerge update). Take Care!_________________Atlas (HDTV PVR, HTTP & Media server)
http://atlas.selfip.net/Info/

kOT! remember me? Nice kernel patchset. I just wanted to chime in my two cents and say that the performance issues of disk I/O (I'm still using a mix of r4, xfs, and btrfs) that started a little in .35, got way worse in the latter portion or .36, are completely alleviated in .37. I'm back to the nostalgic high responsiveness and performance of BFS + BFQ. I know r4 isn't something you'll be using soon due to you current workloads, but if you have time to give BFS some love again, you may like it. For a make -j4 on my kernel, it's about 5% faster, but unlike CFS, I can call up disk intensive commands with minimal impact on both (such as an emerge update). Take Care!

Hi DigitalCorpus,

of course I remember you - you're THE Reiser4 expert ! Of course after me (just joking )

* either for feature-related reasons (BFQ, Reiser4)
* or data-safety and stability- and performance-related (with ext4) [to be able to activate multiple page-io submission again - ENABLE AT YOUR OWN RISK via mblk_io_submit mount-option (will be activated by default >2.6.39 in upstream, again]

* either for feature-related reasons (BFQ, Reiser4)
* or data-safety and stability- and performance-related (with ext4) [to be able to activate multiple page-io submission again - ENABLE AT YOUR OWN RISK via mblk_io_submit mount-option (will be activated by default >2.6.39 in upstream, again]