On Thu 2017-05-25 14:50:14, Sergey Senozhatsky wrote:
> On (05/25/17 11:14), Sumit Gemini wrote:
> >Thanks Sergey and i forgot to add other guys in discussion.
> >
> >
> >[1]lkml.kernel.org/r/20170509082859.854-1-sergey.senozhat...@gmail.com
> >
> >Now I'm going for backporting t
On (05/25/17 11:14), Sumit Gemini wrote:
>Thanks Sergey and i forgot to add other guys in discussion.
>
>
>[1]lkml.kernel.org/r/20170509082859.854-1-sergey.senozhat...@gmail.com
>
>Now I'm going for backporting the kernel with RFC, as you suggested me
>yesterday.
or you can
On (05/24/17 17:26), Sergey Senozhatsky wrote:
> On (05/24/17 12:57), Sumit Gemini wrote:
> >Hi Sergey,
> >
> >Can I get solution for this issue? As i tried to stop martian source
> >packets but team did not agree on it. Please suggest me what can i do?
>
> oh, um... hm. there is no q
On (05/24/17 12:57), Sumit Gemini wrote:
>Hi Sergey,
>
>Can I get solution for this issue? As i tried to stop martian source
>packets but team did not agree on it. Please suggest me what can i do?
oh, um... hm. there is no quick solution I can suggest (assuming that
the lockup was act
Got this crash, could this crash related to call printk recursively?
> Could you please tell me why i got this crash? Do you see any suspicious
> entry here?
>
> [2324956.184374] Kernel panic - not syncing: Watchdog detected hard LOCKUP
> on cpu 1
> [2324956.184374] Pid
> On Sun, Mar 05, 2017 at 10:48:50PM +0200, Meelis Roos wrote:
> > Added some CC-s because of bisect find. Whole context should be still
> > here.
> >
> > > > > > > > This is on my trusty IBM PC365, dual Pentium Pro. 4.10 worked
> > > > > > > > fine,
> > > > > > > > 4.10.0-09686-g9e314890292c a
On Sun, Mar 05, 2017 at 10:48:50PM +0200, Meelis Roos wrote:
> Added some CC-s because of bisect find. Whole context should be still
> here.
>
> > > > > > > This is on my trusty IBM PC365, dual Pentium Pro. 4.10 worked
> > > > > > > fine,
> > > > > > > 4.10.0-09686-g9e314890292c and 4.10.0-1077
Added some CC-s because of bisect find. Whole context should be still
here.
> > > > > > This is on my trusty IBM PC365, dual Pentium Pro. 4.10 worked fine,
> > > > > > 4.10.0-09686-g9e314890292c and 4.10.0-10770-g2d6be4abf514 exhibit a
> > > > > > problem. Ocassionally NMI watchdog kicks in and
On Thu, 2 Mar 2017, Thomas Gleixner wrote:
> On Wed, 1 Mar 2017, Thomas Gleixner wrote:
> > On Thu, 2 Mar 2017, Meelis Roos wrote:
> >
> > > > > This is on my trusty IBM PC365, dual Pentium Pro. 4.10 worked fine,
> > > > > 4.10.0-09686-g9e314890292c and 4.10.0-10770-g2d6be4abf514 exhibit a
> > >
> On Thu, 2 Mar 2017, Thomas Gleixner wrote:
> > On Wed, 1 Mar 2017, Thomas Gleixner wrote:
> > > On Thu, 2 Mar 2017, Meelis Roos wrote:
> > >
> > > > > > This is on my trusty IBM PC365, dual Pentium Pro. 4.10 worked fine,
> > > > > > 4.10.0-09686-g9e314890292c and 4.10.0-10770-g2d6be4abf514 exhi
> > > > > This is on my trusty IBM PC365, dual Pentium Pro. 4.10 worked fine,
> > > > > 4.10.0-09686-g9e314890292c and 4.10.0-10770-g2d6be4abf514 exhibit a
> > > > > problem. Ocassionally NMI watchdog kicks in and discovers one of the
> > > > > CPUs in LOCKUP. The system keeps running fine. The
On Wed, 1 Mar 2017, Thomas Gleixner wrote:
> On Thu, 2 Mar 2017, Meelis Roos wrote:
>
> > > > This is on my trusty IBM PC365, dual Pentium Pro. 4.10 worked fine,
> > > > 4.10.0-09686-g9e314890292c and 4.10.0-10770-g2d6be4abf514 exhibit a
> > > > problem. Ocassionally NMI watchdog kicks in and di
> > This is on my trusty IBM PC365, dual Pentium Pro. 4.10 worked fine,
> > 4.10.0-09686-g9e314890292c and 4.10.0-10770-g2d6be4abf514 exhibit a
> > problem. Ocassionally NMI watchdog kicks in and discovers one of the
> > CPUs in LOCKUP. The system keeps running fine. The first lockup was
> > di
On Thu, 2 Mar 2017, Meelis Roos wrote:
> > > This is on my trusty IBM PC365, dual Pentium Pro. 4.10 worked fine,
> > > 4.10.0-09686-g9e314890292c and 4.10.0-10770-g2d6be4abf514 exhibit a
> > > problem. Ocassionally NMI watchdog kicks in and discovers one of the
> > > CPUs in LOCKUP. The system
ting full-duplex based on MII#1 link partner
capability of 45e1
[1.280014] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery
directory
[1.280110] NFSD: starting 90-second grace period (net c158b340)
[1.295055] NMI watchdog: Watchdog detected hard LOCKUP on cpu 0
[1.
On Wed, 1 Mar 2017, Meelis Roos wrote:
> This is on my trusty IBM PC365, dual Pentium Pro. 4.10 worked fine,
> 4.10.0-09686-g9e314890292c and 4.10.0-10770-g2d6be4abf514 exhibit a
> problem. Ocassionally NMI watchdog kicks in and discovers one of the
> CPUs in LOCKUP. The system keeps running fi
t-ro
[1.634004] loop: module loaded
[1.639004] perf: interrupt took too long (2537 > 2500), lowering
kernel.perf_event_max_sample_rate to 78800
[1.639004] NMI watchdog: Watchdog detected hard LOCKUP on cpu 0
[1.639004] Modules linked in: msr cpuid loop evdev snd_cmipci
snd_mpu401_uart snd_opl3_lib snd_hwdep s
On 10/10/2015 12:52 AM, Al Stone wrote:
On 10/09/2015 03:02 PM, Rafael J. Wysocki wrote:
On Thursday, October 08, 2015 05:05:00 PM Al Stone wrote:
On 10/08/2015 04:50 PM, Rafael J. Wysocki wrote:
On Thursday, October 08, 2015 02:32:15 PM Al Stone wrote:
On 10/08/2015 02:41 PM, Rafael J. Wysoc
On 10/09/2015 03:02 PM, Rafael J. Wysocki wrote:
> On Thursday, October 08, 2015 05:05:00 PM Al Stone wrote:
>> On 10/08/2015 04:50 PM, Rafael J. Wysocki wrote:
>>> On Thursday, October 08, 2015 02:32:15 PM Al Stone wrote:
On 10/08/2015 02:41 PM, Rafael J. Wysocki wrote:
> On Thursday, Oct
On Thursday, October 08, 2015 05:05:00 PM Al Stone wrote:
> On 10/08/2015 04:50 PM, Rafael J. Wysocki wrote:
> > On Thursday, October 08, 2015 02:32:15 PM Al Stone wrote:
> >> On 10/08/2015 02:41 PM, Rafael J. Wysocki wrote:
> >>> On Thursday, October 08, 2015 10:37:55 PM Rafael J. Wysocki wrote:
>
On 10/08/2015 04:50 PM, Rafael J. Wysocki wrote:
> On Thursday, October 08, 2015 02:32:15 PM Al Stone wrote:
>> On 10/08/2015 02:41 PM, Rafael J. Wysocki wrote:
>>> On Thursday, October 08, 2015 10:37:55 PM Rafael J. Wysocki wrote:
On Thursday, October 08, 2015 10:36:40 AM Al Stone wrote:
On Thursday, October 08, 2015 02:32:15 PM Al Stone wrote:
> On 10/08/2015 02:41 PM, Rafael J. Wysocki wrote:
> > On Thursday, October 08, 2015 10:37:55 PM Rafael J. Wysocki wrote:
> >> On Thursday, October 08, 2015 10:36:40 AM Al Stone wrote:
> >>> On 10/08/2015 05:44 AM, Hanjun Guo wrote:
> O
On 10/08/2015 02:41 PM, Rafael J. Wysocki wrote:
> On Thursday, October 08, 2015 10:37:55 PM Rafael J. Wysocki wrote:
>> On Thursday, October 08, 2015 10:36:40 AM Al Stone wrote:
>>> On 10/08/2015 05:44 AM, Hanjun Guo wrote:
On 10/08/2015 11:21 AM, kernel test robot wrote:
> FYI, we notice
On Thursday, October 08, 2015 10:37:55 PM Rafael J. Wysocki wrote:
> On Thursday, October 08, 2015 10:36:40 AM Al Stone wrote:
> > On 10/08/2015 05:44 AM, Hanjun Guo wrote:
> > > On 10/08/2015 11:21 AM, kernel test robot wrote:
> > >> FYI, we noticed the below changes on
> > >>
> > >> https://git.k
On Thursday, October 08, 2015 10:36:40 AM Al Stone wrote:
> On 10/08/2015 05:44 AM, Hanjun Guo wrote:
> > On 10/08/2015 11:21 AM, kernel test robot wrote:
> >> FYI, we noticed the below changes on
> >>
> >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> >> commit 7494b
On 10/08/2015 05:44 AM, Hanjun Guo wrote:
> On 10/08/2015 11:21 AM, kernel test robot wrote:
>> FYI, we noticed the below changes on
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>> commit 7494b07ebaae2117629024369365f7be7adc16c3 ("ACPI: add in a
>> bad_madt_entry
On 10/08/2015 11:21 AM, kernel test robot wrote:
FYI, we noticed the below changes on
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
commit 7494b07ebaae2117629024369365f7be7adc16c3 ("ACPI: add in a bad_madt_entry()
function to eventually replace the macro")
[0.0
Stefan Beller wrote:
I noticed a machine to hang after a few days of uptime,
i.e. the USB, networking etc are all gone, but the machine is still up
and displaying the login screen.
I am running
$ uname -a
Linux sd 3.12.5-302.fc20.i686 #1 SMP Tue Dec 17 21:01:18 UTC 2013 i686 i686
i386 G
I got these messages:
[108655.024413] [ cut here ]
[108655.024413] WARNING: CPU: 0 PID: 0 at kernel/watchdog.c:272
watchdog_overflow_callback+0xac/0xd0()
[108655.024413] Watchdog detected hard LOCKUP on cpu 0
[108655.024413] Modules linked in:
[108655.024413] fuse
quadpc kernel: [263676.682565] WARNING: at
/build/buildd/linux-3.5.0/kernel/watchdog.c:242
watchdog_overflow_callback+0x9a/0xc0()
Aug 13 15:42:12 quadpc kernel: [263676.682566] Hardware name: System Product
Name
Aug 13 15:42:12 quadpc kernel: [263676.682567] Watchdog detected hard LOCKUP on
cpu 2
Hello list,
today i kvm host crashed running vanilla kernel 3.8.9.
The call trace looks like this:
Kernel panic - not syncing: Watchdog detected hard LOCKUP on cpu 18
Pid: 29053, comm: kvm Tainted: G O 3.8.9+16-ph #1
Call Trace:
[] panic+0xbf/0x1df
[] ? native_sched_clock+0x13/0x80
31 matches
Mail list logo
