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-29-2017, 03:04 PM   #61
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

Downgraded EUDEV to 3.2.2, like our friend nobodino suggested, on the pure blood Slackware-current with 4.14.2 kernel, latest pull. Of course, on my Intel based mini-PC.

Guess what? It works. Resisted at 8-10 reboots with no laments.

So, now I have three winner combinations:

1. Latest current with the kernel 4.9.65 (smp, generic)
2. Latest current with the EUDEV downgraded to 3.2.2
3. Latest current with SystemD replacing the init system and EUDEV hack.

Could be that we hit a double issue, as in: the latest EUDEV crashes in certain/particular conditions, then drag the kernel after it, because a particular kernel liability?

So, when the Kernel guys do their job, we will obtain plain and simple: a crashing EUDEV?

Last edited by Darth Vader; 11-29-2017 at 03:28 PM.
 
Old 11-29-2017, 07:53 PM   #62
chrisVV
Member
 
Registered: Aug 2010
Posts: 227

Rep: Reputation: 75
Quote:
Originally Posted by Darth Vader View Post
Downgraded EUDEV to 3.2.2, like our friend nobodino suggested, on the pure blood Slackware-current with 4.14.2 kernel, latest pull. Of course, on my Intel based mini-PC.

Guess what? It works. Resisted at 8-10 reboots with no laments.

So, now I have three winner combinations:

1. Latest current with the kernel 4.9.65 (smp, generic)
2. Latest current with the EUDEV downgraded to 3.2.2
3. Latest current with SystemD replacing the init system and EUDEV hack.
...
You don't have to replace the init system. systemd's udev-235 will live peaceably with slackware's current sysvinit, and works OK with the current kernel.
 
Old 11-29-2017, 08:16 PM   #63
aaazen
Member
 
Registered: Dec 2009
Distribution: Slackware
Posts: 314

Rep: Reputation: 151Reputation: 151
Quote:
Originally Posted by volkerdi View Post
Same here, when I was getting a crash. Pretty sure there's a guilty kernel module.

Anyway, _lots_ of patches queued up for 4.14.3 in stable-review. Whatever's causing this is going to be found sooner or later.
4.14.3 should be out very soon.

https://marc.info/?l=linux-kernel&m=151186941914449&w=2

I tested 4.14.3-rc1 and it runs fine on an Intel 64-bit machine and an AMD 64-bit machine. (4.14.2 works fine for me too on 64-bit machines.)

If you are curious and like building kernels, then install the current source (4.14.2), apply this patch -p1 and build it.

http://kernel.org/pub/linux/kernel/v...-4.14.3-rc1.gz

Then you can test 4.14.3-rc1 too.
 
Old 11-29-2017, 09:00 PM   #64
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 Darth Vader View Post
Downgraded EUDEV to 3.2.2, like our friend nobodino suggested, on the pure blood Slackware-current with 4.14.2 kernel, latest pull. Of course, on my Intel based mini-PC.

Guess what? It works. Resisted at 8-10 reboots with no laments.
I'm still getting occasional boot failures with 4.14.2-smp (32-bit).

IMPORTANT:
Has ANYONE seen a failure with 4.14.2 on x86_64? I haven't, and would like to hear about it if anyone has.

Quote:
So, now I have three winner combinations:

1. Latest current with the kernel 4.9.65 (smp, generic)
We knew that already.

Quote:
2. Latest current with the EUDEV downgraded to 3.2.2
I am getting failures at the same rate on 32-bit with eudev-3.2.2 or eudev-3.2.5. With the older one, I have to add the /lib/modprobe.d/edac.conf file from the newer one, or my machine will oops every single time.

Quote:
3. Latest current with SystemD replacing the init system and EUDEV hack.
In case you aren't aware, eudev is the same udev that's used in systemd with a few changes to allow it to build standalone. But eudev is a hack, and systemd less so?

Give it a rest.

I have my doubts that systemd would be any more stable than -current with eudev-3.2.2 that was promised to be one of your "winner combinations."

Quote:
Could be that we hit a double issue, as in: the latest EUDEV crashes in certain/particular conditions, then drag the kernel after it, because a particular kernel liability?

So, when the Kernel guys do their job, we will obtain plain and simple: a crashing EUDEV?
If the kernel crashes, it's a kernel bug. It's really that simple. If there's *anything* you can run in userspace that can crash the kernel, you have uncovered a kernel bug.

At this point, I seriously doubt based on my testing that eudev has anything to do with this. If eudev was to blame, you'd think it would crash a kernel earlier than 4.14.x.

I think it'll take a bit of patience, but we'll get there with this kernel series. It's an LTS kernel series, so the developers have a lot of motivation to make it stable. We're not the only ones who will be using it.
 
6 members found this post helpful.
Old 11-30-2017, 12:28 AM   #65
willysr
Senior Member
 
Registered: Jul 2004
Location: Jogja, Indonesia
Distribution: Slackware-Current
Posts: 3,703

Rep: Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997
Quote:
Originally Posted by volkerdi View Post
I'm still getting occasional boot failures with 4.14.2-smp (32-bit).

IMPORTANT:
Has ANYONE seen a failure with 4.14.2 on x86_64? I haven't, and would like to hear about it if anyone has.
x86_64 is working fine here on all of my machines, and so does x86 on my desktop
I added kernel.nmi_watchdog=0 in /etc/sysctl.d/50-watchdog.conf though. I'm not sure that helps.
 
Old 11-30-2017, 12:41 AM   #66
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
It is the freaking Bluetooth who bite, at least in my particular case!

My mini-PC has Bluetooth on-board, at least internally. Damn, I do not treated it with (great) attention, because I never used it on this particular PC.

BUT, disabling/blacklisting the Bluetooth module(s), starting with bluetooth and btintel, makes my mini-PC perfectly stable and it works with no crashes, using the clean latest current.

Quote:
Originally Posted by volkerdi View Post
I think it'll take a bit of patience, but we'll get there with this kernel series. It's an LTS kernel series, so the developers have a lot of motivation to make it stable. We're not the only ones who will be using it.
Same here.

I am 101% confident that in several kernel releases we will go back to a stable solution, as I said (in this very thread) from beginning.

All my experiments are made just to try to identify the guilty things, then eventually to report back consistent facts, for the greater good. Personally, I considered my own problem solved after rolling back with success to 4.9.65.

And I think that I have something for you: follow the bluetooth stack.

PS. I have ZERO crashes on another three machines running also 32 bits, but having AMD Phenom processors.

PS2. The Bluetooth from my mini-PC looks being an USB thingie, even it is internal:
Code:
root@darkstar:~# lsusb
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 008 Device 002: ID 275d:0ba6  
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 002: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 002: ID 1a2c:2d23 China Resource Semico Co., Ltd 
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Last edited by Darth Vader; 11-30-2017 at 01:53 AM.
 
Old 11-30-2017, 01:22 AM   #67
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
"And if evidence was not what it seemed?"

We may suppose now that the problem relies on the interaction between eudev and the kernel, because some combinations work and others not.

eudev may act as a 'trigger' or a 'catalyzer' on a kernel module?

Four questions to try to solve the problem:

-1/ Is it be possible to 'catch' what happens when we switch from 'single user' mode to 'multi user' mode?
-2/ Is there a sort of 'database' or configuration 'file' updated between the first boot and the second boot? --> /etc/udev/hdwd.bin ?
-3/ Is it possible to disable udevd from running in 'multi user' mode, and modprobe every single module to see which one segfaults the system if a kernel module is the 'culprit'?
-4/ Could It be a problem with kernel-firmware ?

While upgrading, we've always upgraded the kernel and the firmware, and we focused on kernel, not on its 'close friend'?

Last edited by nobodino; 11-30-2017 at 02:30 AM.
 
Old 11-30-2017, 02:18 AM   #68
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

A suggestion: just disable (remove the executable bit) the /etc/rc.d/rc.udev, reboot and manually load every module from your known list.

BTW, I for one, I would like to ensure that the essential modules for your FS, also keyboard and mouse, are loaded via initrd.

PS. Ensure that your /dev devices are proper created in some way.

PS2. Would be nice in this particular case to have a way to blacklist everything. This way we can keep the (E)UDEV ability to create device files.

Maybe our BDFL knows a way for blacklisting all modules, with no mercy.

Last edited by Darth Vader; 11-30-2017 at 02:32 AM.
 
Old 11-30-2017, 02:38 AM   #69
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
I will test this evening the first suggestion.
I rebuild SFS with eudev-3.2.3 this time, and tonight it should be finished.
 
Old 11-30-2017, 02:47 AM   #70
tazza
Member
 
Registered: Jul 2005
Distribution: Slackware64 -current
Posts: 98

Rep: Reputation: 31
Quote:
Originally Posted by volkerdi View Post
I'm still getting occasional boot failures with 4.14.2-smp (32-bit).

IMPORTANT:
Has ANYONE seen a failure with 4.14.2 on x86_64? I haven't, and would like to hear about it if anyone has.
I know you're after failures rather than lack therof, but for what it's worth it's running fine on i5-7600k with 8 gig Geil DDR4 on an MSI MB that I haven't bothered upgrading the bios for since day dot.

I mention it because 4.14.0 hung on first boot, but then worked afterwards. No probs whatsoever on 4.14.2 and no downtime since install.
 
1 members found this post helpful.
Old 11-30-2017, 04:32 AM   #71
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
BIOS is up to date.
 
Old 11-30-2017, 05:05 AM   #72
tazza
Member
 
Registered: Jul 2005
Distribution: Slackware64 -current
Posts: 98

Rep: Reputation: 31
Quote:
Originally Posted by nobodino View Post
BIOS is up to date.
I don't understand how this contributes anything. I only mentioned my situation. My core 2 quad with latest bios dates from years back was fine. In short it's not a bios issue. I was just pointing out I was slack on my 7600K (if it aint broke don't fix it).
 
Old 11-30-2017, 11:14 AM   #73
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
The 4.14.3 is there.

Preparing the popcorn while waiting for our BDFL to pull the fresh Kernel packages into -current ...

Last edited by Darth Vader; 11-30-2017 at 01:18 PM.
 
Old 11-30-2017, 01:56 PM   #74
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
results: not what we could have expected

- eudev-3.2.5 + kernel-4.14.3 segfaults on third reboot (IMG_1)
- eudev-3.2.3 + kernel-4.14.3 sefaults on first boot
- eudev-3.2.2 + kernel-4.14.3: how to say it? Disturbing!
- it boots normally in single user mode
- when switching to multi user mode: something segfaults but no hardlock,I had access to the console : ls and so on (IMG_2)
- then I typed 'reboot', and complete lock-up! (IMG_3)
Attached Thumbnails
Click image for larger version

Name:	IMG_1.jpg
Views:	25
Size:	196.0 KB
ID:	26440   Click image for larger version

Name:	IMG_2.jpg
Views:	30
Size:	175.7 KB
ID:	26441   Click image for larger version

Name:	IMG_3.jpg
Views:	27
Size:	167.4 KB
ID:	26442  

Last edited by nobodino; 12-01-2017 at 01:49 PM.
 
Old 11-30-2017, 02:17 PM   #75
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
Same here.

Not even EUDEV 3.2.2 was not prone this time for crashing with 4.14.3. I hope to see better news with the official / Patrick's Kernel packages.

Long story short, I tucked the tail in a gracious way and ran back on the 4.9.65 safe heaven. Now building the 4.9.66 in that mini-PC.

PS. That blacklisting/disabling the bluetooth sadly just improved visible the stability, but still crashes appear. Not so often, but they appear.

Last edited by Darth Vader; 11-30-2017 at 03:26 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