On 03/12/2015 14:29, Leon Fauster wrote:> Am 03.12.2015 um 15:06 schrieb Duncan Brown <centos2 at duncb.co.uk>: >> On 03/12/2015 13:54, Jonathan Billings wrote: >>> On Thu, Dec 03, 2015 at 01:44:47PM +0000, Duncan Brown wrote: >>>> The last message before it is "switching to clocksource hpet" >>>> >>>> Then the panic scrolls by >>>> >>>> I've no idea if that counts as later or not >>> It's unlikely to be a panic related to your hardware clock (HPET >>> High Precision Event Timer), so it's probably when the kernel is >>> touching something else on your system. >>> >>> The content of the panic is really the only thing that can help. >>> >> That's what I figured, but how do I go about getting a copy of it? >> >> Most of it has scrolled by when it's finished > > start for example with a photo (or video and grab the frame where > the panic occurs) and - disable grub options like rhgb or quit ... > > -- > LF > > > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centosHere is a couple of pictures, http://i.imgur.com/Vqvqn1H.jpg http://i.imgur.com/WQaz1j9.png Any use?
Duncan Brown wrote:> On 03/12/2015 14:29, Leon Fauster wrote: >> Am 03.12.2015 um 15:06 schrieb Duncan Brown <centos2 at duncb.co.uk>: >>> On 03/12/2015 13:54, Jonathan Billings wrote: >>>> On Thu, Dec 03, 2015 at 01:44:47PM +0000, Duncan Brown wrote: >>>>> The last message before it is "switching to clocksource hpet" >>>>> >>>>> Then the panic scrolls by >>>>> >>>>> I've no idea if that counts as later or not >>>> It's unlikely to be a panic related to your hardware clock (HPET >>>> High Precision Event Timer), so it's probably when the kernel is >>>> touching something else on your system. >>>> >>>> The content of the panic is really the only thing that can help. >>>> >>> That's what I figured, but how do I go about getting a copy of it? >>> >>> Most of it has scrolled by when it's finished >> >> start for example with a photo (or video and grab the frame where >> the panic occurs) and - disable grub options like rhgb or quit ...> Here is a couple of pictures,^^ should be are.*> > http://i.imgur.com/Vqvqn1H.jpg > http://i.imgur.com/WQaz1j9.png > > Any use?I'm just guessing here, but it looks to me as though it's looking at inodes - so filesystem, and kernel modules, maybe video - notice the blacklist. Wonder if this is a grub2 issue, and it's not finding the filesystem. This isn't, by chance, a secure boot, not BIOS, system? mark
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. 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>
On 03/12/2015 17:00, m.roth at 5-cent.us wrote:> Duncan Brown wrote: >> On 03/12/2015 14:29, Leon Fauster wrote: >>> Am 03.12.2015 um 15:06 schrieb Duncan Brown <centos2 at duncb.co.uk>: >>>> On 03/12/2015 13:54, Jonathan Billings wrote: >>>>> On Thu, Dec 03, 2015 at 01:44:47PM +0000, Duncan Brown wrote: >>>>>> The last message before it is "switching to clocksource hpet" >>>>>> >>>>>> Then the panic scrolls by >>>>>> >>>>>> I've no idea if that counts as later or not >>>>> It's unlikely to be a panic related to your hardware clock (HPET >>>>> High Precision Event Timer), so it's probably when the kernel is >>>>> touching something else on your system. >>>>> >>>>> The content of the panic is really the only thing that can help. >>>>> >>>> That's what I figured, but how do I go about getting a copy of it? >>>> >>>> Most of it has scrolled by when it's finished >>> start for example with a photo (or video and grab the frame where >>> the panic occurs) and - disable grub options like rhgb or quit ... >> Here is a couple of pictures, > ^^ should be are.* >> http://i.imgur.com/Vqvqn1H.jpg >> http://i.imgur.com/WQaz1j9.png >> >> Any use? > I'm just guessing here, but it looks to me as though it's looking at > inodes - so filesystem, and kernel modules, maybe video - notice the > blacklist. > > Wonder if this is a grub2 issue, and it's not finding the filesystem. This > isn't, by chance, a secure boot, not BIOS, system? > > mark > >No nothing that exciting, BIOS, and xfs on lvm2. Pretty much the standard options anaconda gives you And it boots fine in 3.10.0-229.20.1.el7.x86_64
On 03/12/2015 17:19, 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. > > 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.I had a feeling that would be the case It's installed on an SSD so it goes past instantly I've taken a video and can just about make out "Kernel panic - not syncing: Watchdog detected hard LOCKUP on cpu"
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 ++++++++++++++++++++++++++++++++++++++++
Em 03-12-2015 14:46, Duncan Brown escreveu:> Here is a couple of pictures, > > http://i.imgur.com/Vqvqn1H.jpg > http://i.imgur.com/WQaz1j9.png > > Any use?Of some. It's failing on ftrace initialization while allocating memory, but can't know the real reason. It can be just lack of memory or any other bug. Probably by that stage of the boot, framebuffer is already loaded. Use vga=0x317 boot option to get a bigger resolution and more lines on it, then send another pic. I hope it fits this time. If not, pick 0x31A, if your monitor allows. (kernel src, Documentation/fb/vesafb.txt) | 640x480 800x600 1024x768 1280x1024 ----+------------------------------------- 256 | 0x301 0x303 0x305 0x307 32k | 0x310 0x313 0x316 0x319 64k | 0x311 0x314 0x317 0x31A 16M | 0x312 0x315 0x318 0x31B Marcelo
On 04/12/2015 19:17, Marcelo Ricardo Leitner wrote:> Em 03-12-2015 14:46, Duncan Brown escreveu: >> Here is a couple of pictures, >> >> http://i.imgur.com/Vqvqn1H.jpg >> http://i.imgur.com/WQaz1j9.png >> >> Any use? > > Of some. It's failing on ftrace initialization while allocating > memory, but can't know the real reason. It can be just lack of memory > or any other bug. > > Probably by that stage of the boot, framebuffer is already loaded. Use > vga=0x317 boot option to get a bigger resolution and more lines on it, > then send another pic. > > I hope it fits this time. If not, pick 0x31A, if your monitor allows. > > (kernel src, Documentation/fb/vesafb.txt) > | 640x480 800x600 1024x768 1280x1024 > ----+------------------------------------- > 256 | 0x301 0x303 0x305 0x307 > 32k | 0x310 0x313 0x316 0x319 > 64k | 0x311 0x314 0x317 0x31A > 16M | 0x312 0x315 0x318 0x31B > > Marcelo > > _______________________________________________Hi Marcelo Thanks for the suggestion I've worked through a decent selection and cant get any to show a higher resolution than it's currently at, in fact most just leave me with a blank screen Note I can change the resolution all I want if I boot via the previous kernel cheers Duncan