LinuxQuestions.org
Latest LQ Deal: Linux Power User Bundle
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 11-30-2017, 03:35 PM   #76
Ilgar
Member
 
Registered: Jan 2005
Location: Istanbul, Turkey
Distribution: Slackware64 14.2, Slackwarearm-current
Posts: 973

Rep: Reputation: 113Reputation: 113

I also had a segfault the first time I booted 4.14.0, but no such thing occurred with 4.14.2. However, for me 4.14.x is the "back to sanity" kernel. With 4.13.x, I had boot segfaults/lockups probably due to gpio/irq initialization errors, but the weird thing was that these errors did not occur if I booted into 4.4.x first (the stock kernel). Probably 4.9.x or even 4.12 would be as good. I'm saying 4.4.x because I only had 4.4.x as a backup version to test.

I even filed a bugreport about this at kernel.org:

https://bugzilla.kernel.org/show_bug.cgi?id=197079

It was possible to boot into 4.13.x only right after 4.4.x (if I recall correctly even a Windows boot wouldn't fix it). It looked as if the 4.4.x initialization were "clearing up" some "leftover error" from 4.13.x.

Naturally when I first booted into 4.14.0, I assumed that the segfault that occurred was due to this "leftover" from the previous 4.13.x boots, but reading this thread, I now see it probably wasn't.

Last edited by Ilgar; 11-30-2017 at 03:37 PM.
 
Old 11-30-2017, 03:39 PM   #77
Darth Vader
Senior Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 1,647

Rep: Reputation: 590Reputation: 590Reputation: 590Reputation: 590Reputation: 590Reputation: 590
You run the x86_64 or i586 (32 bits) ? That's very important for us!
 
1 members found this post helpful.
Old 11-30-2017, 03:40 PM   #78
Ilgar
Member
 
Registered: Jan 2005
Location: Istanbul, Turkey
Distribution: Slackware64 14.2, Slackwarearm-current
Posts: 973

Rep: Reputation: 113Reputation: 113
x86_64.
 
Old 11-30-2017, 03:54 PM   #79
Darth Vader
Senior Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 1,647

Rep: Reputation: 590Reputation: 590Reputation: 590Reputation: 590Reputation: 590Reputation: 590
Well, I am glad that 4.14.x series works better for you.

For me, it crashes in a particular Intel powered min-PC which is similar as hardware with a laptop. Under i586. I have no problems with my (other AMD) computers which runs the x86_64 variant.

The only series which show a real stability on my mini-PC under (standard) -current is the ol'good 4.9.x, at least until now ...

Last edited by Darth Vader; 11-30-2017 at 04:35 PM.
 
Old 11-30-2017, 11:22 PM   #80
nobodino
Member
 
Registered: Jul 2010
Location: in France
Distribution: slackware, slackware from scratch, LFS, linux Mint, Niresh (MacOS)...
Posts: 189

Original Poster
Rep: Reputation: 146Reputation: 146
new test:

- eudev-3.1.5 with current SlackBuild + kernel-4.14.3: segfault when switch to 'multi user' mode : immediate infinite [printk] messages...
- no eudev version works with kernel-4.14.3

Last edited by nobodino; 11-30-2017 at 11:25 PM.
 
Old 12-01-2017, 10:00 AM   #81
Darth Vader
Senior Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 1,647

Rep: Reputation: 590Reputation: 590Reputation: 590Reputation: 590Reputation: 590Reputation: 590
@nobodino

Like our BDFL said, also myself I do not think that is EUDEV the guilty one, after my experiments with the Kernel 4.14.3 ...

For example, disabling the bluetooth improved much the system stability, and it does not crash so often.

-------------------------------------------------------

At the end of day, I believe that there are a bunch of cranky modules which go nuts as their balls wants.

Most likely, most of the (Intel) developers paid much more attention to 64 bits architecture, or could be even a "planed obsolescence" of the 32 bits architecture (by Intel?).

Let's say: a suave way to suggest us to dump our computers to trash and buy something new.

Or they "discreetly try" to give us reasons to jump in the x86_64 bandwagon.

Last edited by Darth Vader; 12-01-2017 at 11:04 AM.
 
1 members found this post helpful.
Old 12-01-2017, 01:51 PM   #82
nobodino
Member
 
Registered: Jul 2010
Location: in France
Distribution: slackware, slackware from scratch, LFS, linux Mint, Niresh (MacOS)...
Posts: 189

Original Poster
Rep: Reputation: 146Reputation: 146
On IMG_2 and IMG_3 I posted previously, you can read:
--------------------------------
BUG: unable to handle kernel paging request at 9b6bf61
IP: kmem_cache_alloc+0xa3/0x1f0
--------------------------------
Isn't it a kernel bug?
 
Old 12-01-2017, 03:08 PM   #83
Darth Vader
Senior Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 1,647

Rep: Reputation: 590Reputation: 590Reputation: 590Reputation: 590Reputation: 590Reputation: 590
Quote:
Originally Posted by nobodino View Post
On IMG_2 and IMG_3 I posted previously, you can read:
--------------------------------
BUG: unable to handle kernel paging request at 9b6bf61
IP: kmem_cache_alloc+0xa3/0x1f0
--------------------------------
Isn't it a kernel bug?

It is a freaking kernel bug, sized as a dragon. Just like I said, I think that they messed royally the 4.14.x until now.

Either they do not care, either the colossal amount of new code (around 500K new lines is bigger than the GTK) was too much for them to handle yet, either is with a reason.

I for one I think that around 4.14.25 we will see a really stable kernel. Too much code added in that poor series, like Torvalds menaced them there is no more LTS in the next years.

So, they dumped everything imaginable into.

Last edited by Darth Vader; 12-01-2017 at 03:45 PM.
 
Old 12-01-2017, 04:33 PM   #84
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 1,318

Rep: Reputation: 3709Reputation: 3709Reputation: 3709Reputation: 3709Reputation: 3709Reputation: 3709Reputation: 3709Reputation: 3709Reputation: 3709Reputation: 3709Reputation: 3709
I've been researching this issue, and here's what I've found (so far). I believe it is a kernel bug, and that it is triggered (heh) by "udevadm trigger --type=devices --action=change". It doesn't happen on every machine. I have an Intel Atom netbook running 32-bit -current (4.14.2-smp) that is absolutely stable. I've rebooted it two dozen times in a row without any issues. I've also put this into a loop:

Code:
/sbin/udevadm trigger --type=subsystems --action=change
/sbin/udevadm trigger --type=devices --action=change
/sbin/udevadm settle --timeout=120
This ran over a thousand times in a loop on the Atom machine with no ill effects.

The machine where I'm having issues is an AMD Phenom II X6. That machine, running in x86_64 mode with 4.14.2 is absolutely stable. In i686 mode it crashes during boot about every other time. If the boot succeeds, running "/sbin/udevadm trigger --type=devices --action=change" at the command line will Oops the kernel about every other time.

I built 4.14.3-smp for this machine based on the config-generic-smp-4.14.2-smp .config. I never did get that one to boot without crashing. Then, I played whack-a-mole with suspicious kernel options all day yesterday and didn't yield any improvement. I also built a kernel and modules from the latest kernel-i686-PAE.config from Fedora Rawhide. This also didn't help. I looked at how systemd handles udev, and it's exactly the same as what we do in rc.udev. I removed all of the kernel modules from the system and repeated the tests using our vmlinuz-huge-smp-4.14.2-smp. The udev trigger still killed the machine about half of the time.

Then I started with a brand new kernel config, initially using the options in arch/x86/configs/i386_defconfig. I made a few changes, making sure that SMP was enabled, and building modules for the hardware in the machine.

The resulting kernel was stable on the AMD box. I've not seen a crash there in 32-bit mode yet. I put it in a boot loop and booted the machine successfully 57 times in a row.

So, it's a probably a kernel bug, but it could be worked around by changing a kernel option (or options).

What now? My plan is to put -current back on a 4.9.x kernel, and move the 4.14.x kernels into /testing until we can work out a stable .config that works for a 32-bit 4.14.x kernel. Perhaps a newer 4.14.x kernel will end up working with a .config that's similar to what we use now, but meanwhile we should have working kernels in -current. Expect them soon.
 
15 members found this post helpful.
Old 12-01-2017, 04:49 PM   #85
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2 on Lenovo Thinkpad W520
Posts: 7,867

Rep: Reputation: 2780Reputation: 2780Reputation: 2780Reputation: 2780Reputation: 2780Reputation: 2780Reputation: 2780Reputation: 2780Reputation: 2780Reputation: 2780Reputation: 2780
Would it be too much of a hassle to ship a 4.9.x for 32-bit and a 4.14.x for 64-bit, in case the 4.14.x 32bit can't settle soon enough to be shipped in Slackware 15.0? I ask assuming that most new hardware will be installed on 64-bit machines.

Last edited by Didier Spaier; 12-01-2017 at 04:51 PM.
 
Old 12-01-2017, 04:50 PM   #86
kjhambrick
Senior Member
 
Registered: Jul 2005
Location: Round Rock, TX
Distribution: Slackware64 14.2 + Multilib
Posts: 1,092

Rep: Reputation: 513Reputation: 513Reputation: 513Reputation: 513Reputation: 513Reputation: 513
Wow !

Good catch volkerdi !

I really appreciate your tenacity and I am sure the Upstream Kernel Developers will too !

-- kjh
 
Old 12-01-2017, 04:51 PM   #87
Darth Vader
Senior Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 1,647

Rep: Reputation: 590Reputation: 590Reputation: 590Reputation: 590Reputation: 590Reputation: 590
Thanks for all your efforts, Patrick!

I am pretty sure that the 4.14.x kernels will be tamed sooner or later, but, like yourself said, meantime a kernel on which we can rely would be greatly appreciated.

Last edited by Darth Vader; 12-01-2017 at 04:53 PM.
 
Old 12-01-2017, 05:05 PM   #88
ponce
Senior Member
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 3,883

Rep: Reputation: 1918Reputation: 1918Reputation: 1918Reputation: 1918Reputation: 1918Reputation: 1918Reputation: 1918Reputation: 1918Reputation: 1918Reputation: 1918Reputation: 1918
if can be useful here I noticed kernel panics also with my 32 bit qemu virtual machines, so I appended to the boot kernel parameters for the netconsole module or a console=ttyS0 to debug, but in these cases the vms didn't crash anymore! they started to crash again with no parameters.
 
3 members found this post helpful.
Old 12-01-2017, 05:07 PM   #89
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 1,318

Rep: Reputation: 3709Reputation: 3709Reputation: 3709Reputation: 3709Reputation: 3709Reputation: 3709Reputation: 3709Reputation: 3709Reputation: 3709Reputation: 3709Reputation: 3709
Quote:
Originally Posted by Didier Spaier View Post
Would it be too much of a hassle to ship a 4.9.x for 32-bit and a 4.14.x for 64-bit, in case the 4.14.x 32bit can't settle soon enough to be shipped in Slackware 15.0? I ask assuming that most new hardware will be installed on 64-bit machines.
I don't think you need to be concerned that we're going to rush a Slackware 15.0 out the door any time soon. But yes, if we can't get 4.14.x stable on 32-bit we could consider that. I think we'll be able to make it stable there, though.
 
3 members found this post helpful.
Old 12-01-2017, 05:08 PM   #90
Darth Vader
Senior Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 1,647

Rep: Reputation: 590Reputation: 590Reputation: 590Reputation: 590Reputation: 590Reputation: 590
Ponce, give me several minutes, and I will try right now your suggestion on the standard 4.14.2-smp, on my mini-PC.

Well, a successful boot with 4.14.2-smp, I will reboot several times, which usually is the perfect way for getting a crash.

So, three successful boot, then I enabled the bluetooth modules and got a crash in the next boot.

Overall, it behave similar with the previous existant bluetooth "hack", as stability. At least in my mini-PC.

Last edited by Darth Vader; 12-01-2017 at 05:31 PM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Strange behavior battles Linux - Newbie 5 07-10-2014 09:59 AM
dcgui-qt's strange behavior harken Linux - Software 2 02-24-2005 03:10 PM
Very Strange Behavior raysr Mandriva 4 08-31-2004 03:06 PM
Strange Behavior andrewb758 Linux - Hardware 5 08-31-2003 03:42 PM
strange behavior abhijit Linux - General 3 07-10-2003 12:25 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 08:24 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration