Re: 2.6.29: can't resume from suspend with DMAR (intel iommu) enabled

[Ingo Molnar <mingo@elte.hu>]

* David Woodhouse <dwmw2@infradead.org> wrote:

> On Wed, 2009-03-25 at 19:07 +0100, Ingo Molnar wrote:
> > * David Woodhouse <dwmw2@infradead.org> wrote:
> > 
> > > On Wed, 2009-03-25 at 18:59 +0100, Ingo Molnar wrote:
> > > > 
> > > > that's not easy - i use it right now :)
> > > > 
> > > > That's another reason why warnings and non-panic() behavior are 
> > > > better for developers too. Had it not crashed i could have sent you 
> > > > my dmesg and i would not have turned off DMAR in the BIOS.
> > > > 
> > > > Now it's turned off in my BIOS (first barrier) and i need to reboot 
> > > > the kernel (second barrier) and i need to hack up a kernel in a 
> > > > certain way to produce debug info (third barrier) - in the merge 
> > > > window (fourth barrier ;-).
> > > 
> > > Yeah, trusting BIOS monkeys for this was always going to be a bad 
> > > plan. We should have just known how to set/read the damn hardware 
> > > BARs -- the most likely explanation for this is that your BIOS is 
> > > just lying to you about where it put the registers, I believe.
> > > 
> > > I'd like to put in a basic sanity check when we first ioremap the 
> > > (alleged) DMAR registers. Hopefully, the output I asked for will 
> > > confirm that there's a simple way to do that...
> > 
> > Could you please fix the panic() and add the debug output you'd 
> > like to see? That would give me a kernel to run straight away. 
> > Without me having to think much about what i should run and 
> > when.
> 
> That's distinctly non-trivial. I need to bail out early.

yeah, DMA can start rather early, and we also need early resource 
reservations, right? Or is there some other issue that makes it 
difficult in addition to that?

	Ingo