Kernel message

Kernel message

[Kostas Gewrgiou]

I got the following from the kernel, (vger-2.2.0-990201)
i was playing with loadkeys at that time, maybe its usefull
in the developers maybe not, i have no idea how to turn this
to something usefull.

  Kostas Gewrgiou

NIP: 0182A070 XER: 00000000 LR: 01801EAC REGS: c3483e90 TRAP: 0500
MSR: 0000d032 EE: 1 PR: 1 FP: 0 ME: 1 IR/DR: 11
TASK = c3482000[277] 'rc5des' mm->pgd c3480000 Last syscall: 78
last math c2af0000
GPR00: E5E74579 7FFFFA84 9B449F0E 0212050F 73E1FEAA 45086972 7C81A0EE
3C571621
GPR08: 83F32258 4B765D95 7356167B 313C4254 18253FCD 46DF33E4 07D0C6CC
63186637
GPR16: CF819E85 799561AC 68D44C12 CD405D72 3D919D13 950149FD 14B690AE
A5959BEF
GPR24: C987064F CDC150F7 B00426E7 85D30A31 1825F482 3E07D996 61FD48F2 
4BD08963




[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Kernel message

[Marcus H. Mendenhall]

This appears (from the mm->pgd reference) to be the same crash I have been
seeing and posting to the list for a while.  I have been trying to trace it
down, but not with much success.  It comes from mm/slab.c and may be
associated with a bad page fault.  Very few people (other than me) have
been reporting it.  I am seeing it on a G3 rev 2 with 128 MB RAM, running
off the stock internal IDE drives.  A possible indication is that it might
be a bug in the IDE driver, causing page fault to fail, since at least one
person running with SCSI drives has indicated he is not seeing this
problem.

Unfortunately, the time I can spend chasing this is small, so unless
someone with a lot more time starts getting annoyed by it, it won't go away
soon.

Marcus Mendenhall


>I got the following from the kernel, (vger-2.2.0-990201)
>i was playing with loadkeys at that time, maybe its usefull
>in the developers maybe not, i have no idea how to turn this
>to something usefull.
>
>  Kostas Gewrgiou
>
>NIP: 0182A070 XER: 00000000 LR: 01801EAC REGS: c3483e90 TRAP: 0500
>MSR: 0000d032 EE: 1 PR: 1 FP: 0 ME: 1 IR/DR: 11
>TASK = c3482000[277] 'rc5des' mm->pgd c3480000 Last syscall: 78
>last math c2af0000
>GPR00: E5E74579 7FFFFA84 9B449F0E 0212050F 73E1FEAA 45086972 7C81A0EE
>3C571621
>GPR08: 83F32258 4B765D95 7356167B 313C4254 18253FCD 46DF33E4 07D0C6CC
>63186637
>GPR16: CF819E85 799561AC 68D44C12 CD405D72 3D919D13 950149FD 14B690AE
>A5959BEF
>GPR24: C987064F CDC150F7 B00426E7 85D30A31 1825F482 3E07D996 61FD48F2
>4BD08963
>



[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Kernel message

[Kostas Gewrgiou]

 Well since i don't have any IDE drives (PowerWave 604/132) i guess
its not a bug in the IDE driver. I think this will help to narrow
the problem. Sorry for the latest answer btw.

 Kostas Gewrgiou.

On Mon, 8 Feb 1999, Marcus H. Mendenhall wrote:

> This appears (from the mm->pgd reference) to be the same crash I have been
> seeing and posting to the list for a while.  I have been trying to trace it
> down, but not with much success.  It comes from mm/slab.c and may be
> associated with a bad page fault.  Very few people (other than me) have
> been reporting it.  I am seeing it on a G3 rev 2 with 128 MB RAM, running
> off the stock internal IDE drives.  A possible indication is that it might
> be a bug in the IDE driver, causing page fault to fail, since at least one
> person running with SCSI drives has indicated he is not seeing this
> problem.
> 
> Unfortunately, the time I can spend chasing this is small, so unless
> someone with a lot more time starts getting annoyed by it, it won't go away
> soon.
> 
> Marcus Mendenhall
> 
> 
> >I got the following from the kernel, (vger-2.2.0-990201)
> >i was playing with loadkeys at that time, maybe its usefull
> >in the developers maybe not, i have no idea how to turn this
> >to something usefull.
> >
> >  Kostas Gewrgiou
> >
> >NIP: 0182A070 XER: 00000000 LR: 01801EAC REGS: c3483e90 TRAP: 0500
> >MSR: 0000d032 EE: 1 PR: 1 FP: 0 ME: 1 IR/DR: 11
> >TASK = c3482000[277] 'rc5des' mm->pgd c3480000 Last syscall: 78
> >last math c2af0000
> >GPR00: E5E74579 7FFFFA84 9B449F0E 0212050F 73E1FEAA 45086972 7C81A0EE
> >3C571621
> >GPR08: 83F32258 4B765D95 7356167B 313C4254 18253FCD 46DF33E4 07D0C6CC
> >63186637
> >GPR16: CF819E85 799561AC 68D44C12 CD405D72 3D919D13 950149FD 14B690AE
> >A5959BEF
> >GPR24: C987064F CDC150F7 B00426E7 85D30A31 1825F482 3E07D996 61FD48F2
> >4BD08963
> >
> 
> 
> 



[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Kernel Message

[Ricky McInnes]

Hello,

	Not sure what info to give ya, just noticed this in my /var/log/messages:

Jun  7 21:16:10 blazin kernel: Intel machine check reporting enabled on CPU#1.
Jun  7 21:16:10 blazin kernel: CPU1: Intel(R) Pentium(R) 4 CPU 2.40GHz 
stepping 09
Jun  7 21:16:10 blazin kernel: Total of 2 processors activated (9555.14 
BogoMIPS).
Jun  7 21:16:10 blazin kernel: cpu_sibling_map[0] = 1
Jun  7 21:16:10 blazin kernel: cpu_sibling_map[1] = 0
Jun  7 21:16:10 blazin kernel: ENABLING IO-APIC IRQs
Jun  7 21:16:10 blazin kernel: Setting 2 in the phys_id_present_map
Jun  7 21:16:10 blazin kernel: ...changing IO-APIC physical APIC ID to 2 ... 
ok.
Jun  7 21:16:10 blazin kernel: ..TIMER: vector=0x31 pin1=2 pin2=0
Jun  7 21:16:10 blazin kernel: testing the IO APIC.......................
Jun  7 21:16:10 blazin kernel:
Jun  7 21:16:10 blazin kernel: An unexpected IO-APIC was found. If this kernel 
release is less than
Jun  7 21:16:10 blazin kernel: three months old please report this to 
linux-smp@vger.kernel.org
Jun  7 21:16:10 blazin kernel: .................................... done.
Jun  7 21:16:10 blazin kernel: Using local APIC timer interrupts.
Jun  7 21:16:10 blazin kernel: calibrating APIC timer ...
Jun  7 21:16:10 blazin kernel: ..... CPU clock speed is 2394.0362 MHz.
Jun  7 21:16:10 blazin kernel: ..... host bus clock speed is 199.2528 MHz.
Jun  7 21:16:10 blazin kernel: cpu: 0, clocks: 997528, slice: 332509
Jun  7 21:16:10 blazin kernel: CPU0<T0:997520,T1:665008,D:3,S:332509,C:997528>
Jun  7 21:16:10 blazin kernel: cpu: 1, clocks: 997528, slice: 332509
Jun  7 21:16:10 blazin kernel: CPU1<T0:997520,T1:332496,D:6,S:332509,C:997528>
Jun  7 21:16:10 blazin kernel: checking TSC synchronization across CPUs: 
passed.
Jun  7 21:16:10 blazin kernel: migration_task 0 on cpu=0
Jun  7 21:16:10 blazin kernel: migration_task 1 on cpu=1

Its Kernel 2.4.21 patched with the CK patchset.

Ricky McInnes

kernel message

[azalel]

ESR value before enabling vector: 00000080
ESR value after enabling vector: 00000000
ENABLING IO-APIC IRQs
Setting 2 in the phys_id_present_map
...changing IO-APIC physical APIC ID to 2 ... ok.
init IO_APIC IRQs
 IO-APIC (apicid-pin) 2-0, 2-5, 2-10, 2-11, 2-20, 2-21, 2-22, 2-23 not 
connected.
..TIMER: vector=0x31 pin1=2 pin2=0
number of MP IRQ sources: 21.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................

IO APIC #2......
.... register #00: 02000000
.......    : physical APIC id: 02
.... register #01: 00178002
.......     : max redirection entries: 0017
.......     : PRQ implemented: 1
.......     : IO APIC version: 0002
 WARNING: unexpected IO-APIC, please mail
          to linux-smp@vger.kernel.org
.... IRQ redirection table:
 NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:   
 00 000 00  1    0    0   0   0    0    0    00
 01 001 01  0    0    0   0   0    1    1    39
 02 001 01  0    0    0   0   0    1    1    31
 03 001 01  0    0    0   0   0    1    1    41
 04 001 01  0    0    0   0   0    1    1    49
 05 000 00  1    0    0   0   0    0    0    00
 06 001 01  0    0    0   0   0    1    1    51
 07 001 01  0    0    0   0   0    1    1    59
 08 001 01  0    0    0   0   0    1    1    61
 09 001 01  0    0    0   0   0    1    1    69
 0a 000 00  1    0    0   0   0    0    0    00
 0b 000 00  1    0    0   0   0    0    0    00
 0c 001 01  0    0    0   0   0    1    1    71
 0d 001 01  0    0    0   0   0    1    1    79
 0e 001 01  0    0    0   0   0    1    1    81
 0f 001 01  0    0    0   0   0    1    1    89
 10 001 01  1    1    0   1   0    1    1    91
 11 001 01  1    1    0   1   0    1    1    99
 12 001 01  1    1    0   1   0    1    1    A1
 13 001 01  1    1    0   1   0    1    1    A9
 14 000 00  1    0    0   0   0    0    0    00
 15 000 00  1    0    0   0   0    0    0    00
 16 000 00  1    0    0   0   0    0    0    00
 17 000 00  1    0    0   0   0    0    0    00
IRQ to pin mappings:
IRQ0 -> 0:2
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ9 -> 0:9
IRQ12 -> 0:12
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
IRQ16 -> 0:16
IRQ17 -> 0:17
IRQ18 -> 0:18
IRQ19 -> 0:19
.................................... done.
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 1807.7077 MHz.
..... host bus clock speed is 267.8084 MHz.
cpu: 0, clocks: 2678084, slice: 1339042
CPU0<T0:2678080,T1:1339024,D:14,S:1339042,C:2678084>
mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xfdb01, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router default [1106/3147] at 00:11.0
PCI->APIC IRQ transform: (B0,I11,P0) -> 19
PCI->APIC IRQ transform: (B0,I13,P0) -> 17
PCI->APIC IRQ transform: (B0,I17,P0) -> 16
PCI->APIC IRQ transform: (B0,I19,P0) -> 18
PCI->APIC IRQ transform: (B0,I20,P0) -> 16
PCI->APIC IRQ transform: (B0,I20,P1) -> 17
PCI->APIC IRQ transform: (B0,I20,P2) -> 18
PCI->APIC IRQ transform: (B1,I0,P0) -> 16
PCI: Via IRQ fixup for 00:14.0, from 11 to 0
PCI: Via IRQ fixup for 00:14.1, from 10 to 1

Re: kernel message

[Randy.Dunlap]

Hi,

Kernel version and machine type/brand/model would be good items
to include in reports like this.

~Randy

> ESR value before enabling vector: 00000080
> ESR value after enabling vector: 00000000
> ENABLING IO-APIC IRQs
> Setting 2 in the phys_id_present_map
> ...changing IO-APIC physical APIC ID to 2 ... ok.
> init IO_APIC IRQs
>  IO-APIC (apicid-pin) 2-0, 2-5, 2-10, 2-11, 2-20, 2-21, 2-22, 2-23 not
> connected.
> ..TIMER: vector=0x31 pin1=2 pin2=0
> number of MP IRQ sources: 21.
> number of IO-APIC #2 registers: 24.
> testing the IO APIC.......................
>
> IO APIC #2......
> .... register #00: 02000000
> .......    : physical APIC id: 02
> .... register #01: 00178002
> .......     : max redirection entries: 0017
> .......     : PRQ implemented: 1
> .......     : IO APIC version: 0002
>  WARNING: unexpected IO-APIC, please mail
>           to linux-smp@vger.kernel.org

Kernel message

[umesh]

Can anyone send me the documentation about dmesg message that how can we
understand by it. I am searching good document which can explain each and
every line of dmesg.

umesh

Re: Kernel message

[Robert P. J. Day]

On Sat, 2 Jun 2007, umesh@websurfer.com.np wrote:

> Can anyone send me the documentation about dmesg message that how
> can we understand by it. I am searching good document which can
> explain each and every line of dmesg.
>
> umesh

  this is really more of a kernel newbie question that belongs on the
newbie list but, if you really want to know the meaning of each line,
you might want to trace the code from kernel startup to see when each
of those lines is printed to see what they represent.

  starting in init/main.c, find the routine "start_kernel" around line
500 and several lines in, you'll see:

...
printk(KERN_NOTICE);
printk(linux_banner);
...

(why these two printk's are broken over two lines is a mystery but ...
whatever.)

  then if you go to init/version.c, you can verify that linux_banner
does indeed represent the normal first line in /var/log/dmesg, such
as:

Linux version 2.6.20-1.2948.fc6
(brewbuilder@hs20-bc1-7.build.redhat.com) (gcc version 4.1.1 20070105
(Red Hat 4.1.1-51)) #1 SMP Fri Apr 27 19:48:40 EDT 2007

  at that point, start following the code to see where each line in
dmesg comes from.

rday

p.s.  please use a better subject line than just "Kernel message".
that doesn't tell anyone what you're actually asking about.

-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================