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] [day] [month] [year] [list]

Date:	Tue, 27 Oct 2009 20:56:11 -0700
From:	"Justin P. Mattock" <justinmattock@...il.com>
To:	Valdis.Kletnieks@...edu
CC:	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: PANIC: early exception 08 rip 246:10 error ffffffff810251b5 cr2
 0

Valdis.Kletnieks@...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




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/