On Thu, December 3, 2015 11:19 am, Jonathan Billings wrote:> On Thu, Dec 03, 2015 at 04:46:10PM +0000, Duncan Brown wrote: >> Here is a couple of pictures, >> >> http://i.imgur.com/Vqvqn1H.jpg >> http://i.imgur.com/WQaz1j9.png >> >> Any use? > > So, both of those are just the end of the kernel call trace, > unfortunately, it doesn't show what function actually caused the > panic. That'd be above that text, something you could get from an > attached console.That is my main complaint about parallelized boot. My brain is only capable to deal with serial sequence of events, and which next event is deterministically predictable from previous. As with fatal things like kernel panic, it is the previous before the fatalstep is the one that you still can see... It there some way to tell systemd kick in components serially? Severs aside (you can not have everything), this (CentOS 7) is a great system for laptops, the best I saw so far. Like machintosh. Only better. Valeri> > The first one looks like its in the middle of allocating an inode for > a file, the second in looking up some dentry during init (just > guessing though), although both seem to be in an allocation event at > the end of an interrupt (EOI), but that's probably just coincidence. > -- > Jonathan Billings <billings at negate.org> > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos >++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev wrote:> On Thu, December 3, 2015 11:19 am, Jonathan Billings wrote: >> On Thu, Dec 03, 2015 at 04:46:10PM +0000, Duncan Brown wrote: >>> Here is a couple of pictures, >>> >>> http://i.imgur.com/Vqvqn1H.jpg >>> http://i.imgur.com/WQaz1j9.png >>> >>> Any use?<snip>> That is my main complaint about parallelized boot. My brain is only > capable to deal with serial sequence of events, and which next event is > deterministically predictable from previous. As with fatal things like > kernel panic, it is the previous before the fatalstep is the one that you > still can see... > > It there some way to tell systemd kick in components serially? > > Severs aside (you can not have everything), this (CentOS 7) is a great > system for laptops, the best I saw so far. Like machintosh. Only better.For laptops, great. For anything else, not so much. For example, it's supposed to be an *ENTERPRISE* o/s... why does it automatically, without ever asking, install anything wifi? I'm still trying to figure out how to tell a *wired* CentOS 7 workstation to stop even thinking about wifi or wimax, and stop cluttering the logs with debugging garbage. mark
On Dec 3, 2015, at 2:33 PM, Valeri Galtsev <galtsev at kicp.uchicago.edu> wrote:> That is my main complaint about parallelized boot. My brain is only > capable to deal with serial sequence of events, and which next event is > deterministically predictable from previous. As with fatal things like > kernel panic, it is the previous before the fatalstep is the one that you > still can see...This has nothing to do with systemd or a parallelized boot. The kernel panic is happening during the initial load of the kernel and initialization of hardware. I know you love to blame every problem on systemd, but c?mon, this problem is going to happen with *EVERY* init system. -- Jonathan Billings <billings at negate.org>
On Thu, December 3, 2015 7:54 pm, Jonathan Billings wrote:> On Dec 3, 2015, at 2:33 PM, Valeri Galtsev <galtsev at kicp.uchicago.edu> > wrote: >> That is my main complaint about parallelized boot. My brain is only >> capable to deal with serial sequence of events, and which next event is >> deterministically predictable from previous. As with fatal things like >> kernel panic, it is the previous before the fatalstep is the one that >> you >> still can see... > > This has nothing to do with systemd or a parallelized boot. The kernel > panic is happening during the initial load of the kernel and > initialization of hardware. > > I know you love to blame every problem on systemd, but c???mon, this > problem is going to happen with *EVERY* init system. >No, I don't. I'm just that ignorant I guess, and not too attentive to the original description of the problem. My impression was: after the kernel was loaded, when services were getting started, that is when kernel panic had happened. I'm many [bad] things but not a wishful blamer of some piece of architecture I do not like much (compared to different few doing the same I saw in my life some of them I'm still using). But thanks for your note, it's helpful for me (no sarcasm, really). Valeri ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On 12/03/15 20:54, Jonathan Billings wrote:> On Dec 3, 2015, at 2:33 PM, Valeri Galtsev <galtsev at kicp.uchicago.edu> > wrote: >> That is my main complaint about parallelized boot. My brain is only >> capable to deal with serial sequence of events, and which next event is >> deterministically predictable from previous. As with fatal things like >> kernel panic, it is the previous before the fatalstep is the one that >> you still can see... > > This has nothing to do with systemd or a parallelized boot. The kernel > panic is happening during the initial load of the kernel and initialization > of hardware. > > I know you love to blame every problem on systemd, but c?mon, this problem > is going to happen with *EVERY* init system. >No, *you* don't understand what we're saying: pre-systemd, if the o/p saw that one stmt before the panic, they could look at what the system was doing *sequentially*, and so have an idea what it was failing on. With systemd's parallelism, we have no clue, other than what it's done, and no idea what's happening that's failing. mark