PANIC: early exception 08 rip 246:10 error ffffffff810251b5 cr2 0

PANIC: early exception 08 rip 246:10 error ffffffff810251b5 cr2 0

[Justin P. Mattock]

I was looking into seeing if kdump might be able to log this in, but 
after reading up
I realized that kdump is something that needs to be on then if a crash 
occurs,
  then kexec to the rescue.

Anyways I posted a picture on my facebook page of this, and also will 
send a post
manually writing this down.
Basically when I use ohci1394_dma=early on the boot param
this happens. if I don't use that boot option then the system runs fine.

[    0.000000] [<ffffffff81639995>] start_kernel+0x82/0x34d
[    0.000000] [<ffffffff816392a5>] x86_64_start_reservations+0xac/0xb0
[    0.000000] [<ffffffff816393a1>] x86_64_start_kernel+0xf8/0x107
PANIC: early exception 08 rip 246:10 error ffffffff810251b5 cr2 0
[    0.000000] Pid: 0, comm: swapper Not tainted 
2.6.32-rc4-00001-g1896a85 #35
[    0.000000] Call Trace:
[    0.000000] [<ffffffff8163919e>] early_idt_handler+0x5e/0x71
[    0.000000] [<ffffffff813b9958>] ? panic+0x10c/0x12e
[    0.000000] [<ffffffff8164f777>] ___alloc_bootmem_node+0x0/0x60
[    0.000000] [<ffffffff8164f8eb>] __alloc_bootmem+0xb/0xd
[    0.000000] [<ffffffff813aba66>] spp_getpage+0x3a/0x6f
[    0.000000] [<ffffffff8102770d>] fill_pte+0x22/0xde
[    0.000000] [<ffffffff810278e7>] set_pte_vaddr_pud+0x2c/0x48
[    0.000000] [<ffffffff81027963>] set_pte_vaddr+0x60/0x65
[    0.000000] [<ffffffff8102b82e>] __native_set_fixmap+0x24/0x2c
[    0.000000] [<ffffffff81660252>] 
init_ohci1394_dma_on_all_controllers+0x9b/0x345
[    0.000000] [<ffffffff8163be6b>] setup_arch+0x543/0x950
[    0.000000] [<ffffffff813b99b6>] ? printk+0x3c/0x3e
[    0.000000] [<ffffffff810646b6>] ? 
clockevents_register_notifier+0x3e/0x48
[    0.000000] [<ffffffff81639995>] start_kernel+0x82/0x34d
[    0.000000] [<ffffffff816392a5>] x86_64_start_reservations+0xac/0xb0
[    0.000000] [<ffffffff816393a1>] x86_64_start_kernel+0xf8/0x107
[    0.000000] RIP 0x10

The system is a LFS pure64 build on an imac,macbook(both systems the
same, and both crash like this).

Any ideas on this, and also any ideas on how I could try and grab a
syslog this early in the boot?

Justin P. Mattock

Re: PANIC: early exception 08 rip 246:10 error ffffffff810251b5 cr2 0

[Justin Mattock]

On Fri, Oct 23, 2009 at 4:45 PM, Justin P. Mattock
<justinmattock@gmail.com> wrote:
> I was looking into seeing if kdump might be able to log this in, but after
> reading up
> I realized that kdump is something that needs to be on then if a crash
> occurs,
>  then kexec to the rescue.
>
> Anyways I posted a picture on my facebook page of this, and also will send a
> post
> manually writing this down.
> Basically when I use ohci1394_dma=early on the boot param
> this happens. if I don't use that boot option then the system runs fine.
>
> [    0.000000] [<ffffffff81639995>] start_kernel+0x82/0x34d
> [    0.000000] [<ffffffff816392a5>] x86_64_start_reservations+0xac/0xb0
> [    0.000000] [<ffffffff816393a1>] x86_64_start_kernel+0xf8/0x107
> PANIC: early exception 08 rip 246:10 error ffffffff810251b5 cr2 0
> [    0.000000] Pid: 0, comm: swapper Not tainted 2.6.32-rc4-00001-g1896a85
> #35
> [    0.000000] Call Trace:
> [    0.000000] [<ffffffff8163919e>] early_idt_handler+0x5e/0x71
> [    0.000000] [<ffffffff813b9958>] ? panic+0x10c/0x12e
> [    0.000000] [<ffffffff8164f777>] ___alloc_bootmem_node+0x0/0x60
> [    0.000000] [<ffffffff8164f8eb>] __alloc_bootmem+0xb/0xd
> [    0.000000] [<ffffffff813aba66>] spp_getpage+0x3a/0x6f
> [    0.000000] [<ffffffff8102770d>] fill_pte+0x22/0xde
> [    0.000000] [<ffffffff810278e7>] set_pte_vaddr_pud+0x2c/0x48
> [    0.000000] [<ffffffff81027963>] set_pte_vaddr+0x60/0x65
> [    0.000000] [<ffffffff8102b82e>] __native_set_fixmap+0x24/0x2c
> [    0.000000] [<ffffffff81660252>]
> init_ohci1394_dma_on_all_controllers+0x9b/0x345
> [    0.000000] [<ffffffff8163be6b>] setup_arch+0x543/0x950
> [    0.000000] [<ffffffff813b99b6>] ? printk+0x3c/0x3e
> [    0.000000] [<ffffffff810646b6>] ?
> clockevents_register_notifier+0x3e/0x48
> [    0.000000] [<ffffffff81639995>] start_kernel+0x82/0x34d
> [    0.000000] [<ffffffff816392a5>] x86_64_start_reservations+0xac/0xb0
> [    0.000000] [<ffffffff816393a1>] x86_64_start_kernel+0xf8/0x107
> [    0.000000] RIP 0x10
>
> The system is a LFS pure64 build on an imac,macbook(both systems the
> same, and both crash like this).
>
> Any ideas on this, and also any ideas on how I could try and grab a
> syslog this early in the boot?
>
> Justin P. Mattock
>
>
>

I can't seem to locate a right mailing list
for ieee1394 for Linux. Anyways here is a
url to flickr which has the image of the PANIC:
http://www.flickr.com/photos/44066293@N08/4046711653/
(hopefully you don't need to sign up to view)

As for the problem, interesting thing here is if I add
a printk to:

if ((class == 0xffffffff))
printk(KERN_BUG "init_ohci1394_dma: finished initializing OHCI DMA\n");
continue; /* No device at this func */

the system will boot-up, and the PANIC will not occur.


-- 
Justin P. Mattock

Re: PANIC: early exception 08 rip 246:10 error ffffffff810251b5 cr2 0

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 929 bytes --]

On Mon, 26 Oct 2009 11:34:20 PDT, Justin Mattock said:

> I can't seem to locate a right mailing list
> for ieee1394 for Linux. Anyways here is a
> url to flickr which has the image of the PANIC:
> http://www.flickr.com/photos/44066293@N08/4046711653/
> (hopefully you don't need to sign up to view)
> 
> As for the problem, interesting thing here is if I add
> a printk to:
> 
> if ((class == 0xffffffff))
> printk(KERN_BUG "init_ohci1394_dma: finished initializing OHCI DMA\n");
> continue; /* No device at this func */
> 
> the system will boot-up, and the PANIC will not occur.

Note that just sticking a printk in there without a { } pair enclosing
the printk and continue will change the semantics drastically - if the
conditional is true, it will do the printk instead of continuing. And
possibly more important, the continue just became unconditional.

What *exactly* does your code look like now?

[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

Re: PANIC: early exception 08 rip 246:10 error ffffffff810251b5 cr2 0

[Justin P. Mattock]

Valdis.Kletnieks@vt.edu wrote:
> On Mon, 26 Oct 2009 11:34:20 PDT, Justin Mattock said:
>
>    
>> I can't seem to locate a right mailing list
>> for ieee1394 for Linux. Anyways here is a
>> url to flickr which has the image of the PANIC:
>> http://www.flickr.com/photos/44066293@N08/4046711653/
>> (hopefully you don't need to sign up to view)
>>
>> As for the problem, interesting thing here is if I add
>> a printk to:
>>
>> if ((class == 0xffffffff))
>> printk(KERN_BUG "init_ohci1394_dma: finished initializing OHCI DMA\n");
>> continue; /* No device at this func */
>>
>> the system will boot-up, and the PANIC will not occur.
>>      
>
> Note that just sticking a printk in there without a { } pair enclosing
> the printk and continue will change the semantics drastically - if the
> conditional is true, it will do the printk instead of continuing. And
> possibly more important, the continue just became unconditional.
>
> What *exactly* does your code look like now?
>    
as of now in init_ohci1394_dma.c
I did:



void __init init_ohci1394_dma_on_all_controllers(void)
{
     int num, slot, func;

     if (!early_pci_allowed())
         return;

     /* Poor man's PCI discovery, the only thing we can do at early boot */
     for (num = 0; num < 32; num++) {
         for (slot = 0; slot < 32; slot++) {
             for (func = 0; func < 8; func++) {
                 u32 class = read_pci_config(num,slot,func,
                             PCI_CLASS_REVISION);
                 if ((class == 0xffffffff))
+                    printk(KERN_DEBUG "putting a printk here keeps the 
machine from a panic\n");
                     continue; /* No device at this func */

                 if (class>>8 != PCI_CLASS_SERIAL_FIREWIRE_OHCI)
                     continue; /* Not an OHCI-1394 device */

                 init_ohci1394_controller(num, slot, func);
                 break; /* Assume one controller per device */
             }
         }
     }
     printk(KERN_INFO "init_ohci1394_dma: finished initializing OHCI 
DMA\n");
}


interesting thing here, is I just was wanting to see were this thing was
crashing. when adding this in(above) Ill see a long string during boot
for a few seconds and then the machine boots up.
  Now if I add a printk(example below) to here:



void __init init_ohci1394_dma_on_all_controllers(void)
{
     int num, slot, func;

     if (!early_pci_allowed())
         return;

     /* Poor man's PCI discovery, the only thing we can do at early boot */
     for (num = 0; num < 32; num++) {
         for (slot = 0; slot < 32; slot++) {
             for (func = 0; func < 8; func++) {
                 u32 class = read_pci_config(num,slot,func,
                             PCI_CLASS_REVISION);
                 if ((class == 0xffffffff))
                     continue; /* No device at this func */

                 if (class>>8 != PCI_CLASS_SERIAL_FIREWIRE_OHCI)
+                    printk(KERN_DEBUG "putting a printk here keeps the 
machine from a panic\n");
                     continue; /* Not an OHCI-1394 device */

                 init_ohci1394_controller(num, slot, func);
                 break; /* Assume one controller per device */
             }
         }
     }
     printk(KERN_INFO "init_ohci1394_dma: finished initializing OHCI 
DMA\n");
}



In dmesg I will see maybe 5 to 10 debug messages and then
onto init_ohci1394_initialize.
keep in mind I'm not familiar with any of this, but just looking
at the code I see 0xffffffff and searching(google) tells me
that that's something with 32bit, should maybe there be something
with 0xffffffffffffffffff 64bit?

Justin P. Mattock

Re: PANIC: early exception 08 rip 246:10 error ffffffff810251b5 cr2 0

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 2615 bytes --]

On Mon, 26 Oct 2009 14:16:34 PDT, "Justin P. Mattock" said:
  
> as of now in init_ohci1394_dma.c
> I did:
> 
> 
> 
> void __init init_ohci1394_dma_on_all_controllers(void)
> {
>      int num, slot, func;
> 
>      if (!early_pci_allowed())
>          return;
> 
>      /* Poor man's PCI discovery, the only thing we can do at early boot */
>      for (num = 0; num < 32; num++) {
>          for (slot = 0; slot < 32; slot++) {
>              for (func = 0; func < 8; func++) {
>                  u32 class = read_pci_config(num,slot,func,
>                              PCI_CLASS_REVISION);
>                  if ((class == 0xffffffff))
> +                    printk(KERN_DEBUG "putting a printk here keeps the  machine from a panic\n");
>                      continue; /* No device at this func */

Try this instead:

                   
                   printk(KERN_DEBUG "trying class=%d num=%d slot=%d func=%d\n",
                             class, num, slot, func);
                   if ((class == 0xffffffff)) {
                       printk(KERN_DEBUG "No device here\n");
                       continue; /* No device at this func */
                   }

The curly brackets are important.  This version will still panic, and it will
probably spew a lot of msgs, but we'll hopefully find out which num/slot/func
is giving it indigestion. 


> interesting thing here, is I just was wanting to see were this thing was
> crashing. when adding this in(above) Ill see a long string during boot
> for a few seconds and then the machine boots up.
>  Now if I add a printk(example below) to here:

>                  if (class>>8 != PCI_CLASS_SERIAL_FIREWIRE_OHCI)
> +                    printk(KERN_DEBUG "putting a printk here keeps the machine from a panic\n");
>                      continue; /* Not an OHCI-1394 device */

> In dmesg I will see maybe 5 to 10 debug messages and then
> onto init_ohci1394_initialize.

That's because you forgot the curlies, and the 'continue;' is now unconditional
Now ou hit it *every* time, so you *never* do the test against
PCI_CLASS_SERIAL_FIREWIRE-OHCI and you never call init_ohci1394_controller();

And I suspect your *real* problem is something gone astray down in
init_ohci1394_conrtroller() - so if you change the code to never call it,
it never goes astray and you boot OK.

> keep in mind I'm not familiar with any of this, but just looking
> at the code I see 0xffffffff and searching(google) tells me
> that that's something with 32bit, should maybe there be something
> with 0xffffffffffffffffff 64bit?

No - it's "u32 class", so treated as a 32-bit.





[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

Re: PANIC: early exception 08 rip 246:10 error ffffffff810251b5 cr2 0

[Justin P. Mattock]

Valdis.Kletnieks@vt.edu wrote:
> On Mon, 26 Oct 2009 14:16:34 PDT, "Justin P. Mattock" said:
>
>    
>>      
>
> Try this instead:
>
>
>                     printk(KERN_DEBUG "trying class=%d num=%d slot=%d func=%d\n",
>                               class, num, slot, func);
>                     if ((class == 0xffffffff)) {
>                         printk(KERN_DEBUG "No device here\n");
>                         continue; /* No device at this func */
>                     }
>
> The curly brackets are important.  This version will still panic, and it will
> probably spew a lot of msgs, but we'll hopefully find out which num/slot/func
> is giving it indigestion.
>
>
>    
O.K.thanks for the test printk.
(didn't even think of putting a curly bracket in there)

here's the results from your test printk:
(this goes on for some time during boot)

[    0.000000] trying class=-1 num=31 slot=30 func=7
[    0.000000] No device here
[    0.000000] trying class=-1 num=31 slot=31 func=0
[    0.000000] No device here
[    0.000000] trying class=-1 num=31 slot=31 func=1
[    0.000000] No device here
[    0.000000] trying class=-1 num=31 slot=31 func=2
[    0.000000] No device here
[    0.000000] trying class=-1 num=31 slot=31 func=3
[    0.000000] No device here
[    0.000000] trying class=-1 num=31 slot=31 func=4
[    0.000000] No device here
[    0.000000] trying class=-1 num=31 slot=31 func=5
[    0.000000] No device here
[    0.000000] trying class=-1 num=31 slot=31 func=6
[    0.000000] No device here
[    0.000000] trying class=-1 num=31 slot=31 func=7
[    0.000000] No device here
[    0.000000] init_ohci1394_dma: finished initializing OHCI DMA
[    0.000000] ACPI: RSDP 00000000000fe020 00024 (v02 APPLE )
[    0.000000] ACPI: XSDT 000000003fefd1c0 00074 (v01 APPLE   Apple00
000000A5      01000013)
[    0.000000] ACPI: FACP 000000003fefb000 000F4 (v03 APPLE   Apple00
000000A5 Loki 0000005F)


I'm going to have a look at this today, and look to
see if I can fix this.(also the guys e-mail bk@suse.de
keeps giving me a fail to send message so I took it off
for now, and then later I'll try to find that person and
update his e-mail).

Justin P. Mattock

Re: PANIC: early exception 08 rip 246:10 error ffffffff810251b5 cr2 0

[Justin P. Mattock]

My bad I just realized with your printk's I forgot
again to add the curly's(those little things are
hard to see).

The results are similar with the messages, except
with the curly's the system will panic the same as above
and not boot.
(So I guess it was good to forget the curly's
to some extent).

Justin P. mattock

Re: PANIC: early exception 08 rip 246:10 error ffffffff810251b5 cr2 0

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 864 bytes --]

On Tue, 27 Oct 2009 12:07:34 PDT, "Justin P. Mattock" said:

> The results are similar with the messages, except
> with the curly's the system will panic the same as above
> and not boot.

As I expected - I explained why already.  And in fact, I intentionally did
that, so that the *last* one of those added messages before your panic
will output the info regarding the device that caused it (hacking around
the panic would mean that you'd get a whole bunch of messages and not have
an easy way to tell *which one* caused the now-bypassed issue...)

> (So I guess it was good to forget the curly's
> to some extent).

So out of curiosity, what did the messages actually *SAY*?  They should
be pointing at the device that's giving your system indigestion, so it's
useful to actually include the output (I didn't pull that printk format
string out of thin air.. ;)


[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

Re: PANIC: early exception 08 rip 246:10 error ffffffff810251b5 cr2 0

[Justin P. Mattock]

Valdis.Kletnieks@vt.edu wrote:
> On Tue, 27 Oct 2009 12:07:34 PDT, "Justin P. Mattock" said:
>
>    
>> The results are similar with the messages, except
>> with the curly's the system will panic the same as above
>> and not boot.
>>      
>
> As I expected - I explained why already.  And in fact, I intentionally did
> that, so that the *last* one of those added messages before your panic
> will output the info regarding the device that caused it (hacking around
> the panic would mean that you'd get a whole bunch of messages and not have
> an easy way to tell *which one* caused the now-bypassed issue...)
>
>    
>> (So I guess it was good to forget the curly's
>> to some extent).
>>      
>
> So out of curiosity, what did the messages actually *SAY*?  They should
> be pointing at the device that's giving your system indigestion, so it's
> useful to actually include the output (I didn't pull that printk format
> string out of thin air.. ;)
>
>    
o.k. you should be able to view
this:(let me know if you can't and I can
manually write out, and in time find a public
photo sharing suite to make things easier).

http://www.flickr.com/photos/44066293@N08/4050317695

When this happens I see lots of messages from the print
during boot, then this happens.

Justin P. Mattock

Re: PANIC: early exception 08 rip 246:10 error ffffffff810251b5 cr2 0

[Justin P. Mattock]

Valdis.Kletnieks@vt.edu wrote:
> On Tue, 27 Oct 2009 12:07:34 PDT, "Justin P. Mattock" said:
>
>    
>> The results are similar with the messages, except
>> with the curly's the system will panic the same as above
>> and not boot.
>>      
>
> As I expected - I explained why already.  And in fact, I intentionally did
> that, so that the *last* one of those added messages before your panic
> will output the info regarding the device that caused it (hacking around
> the panic would mean that you'd get a whole bunch of messages and not have
> an easy way to tell *which one* caused the now-bypassed issue...)
>
>    
>> (So I guess it was good to forget the curly's
>> to some extent).
>>      
>
> So out of curiosity, what did the messages actually *SAY*?  They should
> be pointing at the device that's giving your system indigestion, so it's
> useful to actually include the output (I didn't pull that printk format
> string out of thin air.. ;)
>
>    
So after looking around I managed to get the machine to boot
by commenting out(just to see) some calls in
init_ohci1394_controller

these are the ones:

set_fixmap_nocache(FIX_OHCI1394_BASE, ohci_base);

init_ohci1394_reset_and_init_dma(&ohci);


Then kind of isolating the issue I looked into
set_fixmap_nocache
Now looking at fixmap.h I see some comments about
x86_64 integration, leading me to believe maybe this is what/why
I'm hitting a panic.

Justin P. mattock