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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 27 Oct 2009 02:23:19 -0400
From:	Valdis.Kletnieks@...edu
To:	"Justin P. Mattock" <justinmattock@...il.com>
Cc:	Linux Kernel <linux-kernel@...r.kernel.org>,
	Bernhard Kaindl <bk@...e.de>
Subject: Re: PANIC: early exception 08 rip 246:10 error ffffffff810251b5 cr2 0

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.





Content of type "application/pgp-signature" skipped