public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Edgar Hucek <hostmaster@ed-soft.at>
To: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: linux-acpi@vger.kernel.org, "Tolentino,
	Matthew E" <matthew.e.tolentino@intel.com>
Subject: Re: ACPI Troubles with 2.6.16-rc3
Date: Fri, 17 Feb 2006 18:27:37 +0100	[thread overview]
Message-ID: <43F60789.3040503@ed-soft.at> (raw)
In-Reply-To: <200602171014.49656.bjorn.helgaas@hp.com>

Hi.

The memory mapp is on the wiki.
btw: The wiki have a new homepage :
http://www.mactel-linux.org/wiki/Main_Page

Later this day i'll put information together how to boot Linux on the
Intel iMac. You wi'll be surprised how simple it is ;)

cu

Edgar

Bjorn Helgaas wrote:
> On Friday 17 February 2006 00:54, Edgar Hucek wrote:
>> The machine is an Apple Intel iMac 17" Dual Core booted with
>> elilo.
> 
> Nice work.  I think I could help debug this much better with my own
> Intel iMac :-)
> 
> Your wiki (http://xbox-linux.org/mactel/index.php/Main_Page) mentions
> changes to elilo.  Can you detail those?  The elilo maintainer works
> across the aisle and would like to make this work out of the box.  Or
> maybe you just had to remove the ExitBootServices call, so the kernel
> can keep using the firmware console or something?
> 
> If you have a way to capture the EFI memmap, could you post that on
> your wiki page as well?  I guess you could collect basically the same
> information by turning on EFI_DEBUG in arch/i386/kernel/efi.c.
> 
> The memmap I've seen (from another iMac) has a few strange things:
> 
>> Type       Start            End               # Pages          Attributes
>> reserved   000000000009F000-000000000009FFFF  0000000000000001 000000000000000F
>> available  0000000000100000-000000007BD1DFFF  000000000007BC1E 000000000000000F
> 
> No MemMapIO region for VGA frame buffer.  Intel ia64 boxes have the
> same bug.
> 
>> MemMapIO   00000000E00F8000-00000000E00F8FFF  0000000000000001 8000000000000000
>> MemMapIO   00000000FED1C000-00000000FED1FFFF  0000000000000004 8000000000000000
>> MemMapIO   00000000FFFB0000-00000000FFFDFFFF  0000000000000030 8000000000000000
> 
> Marked "runtime", but no access types supported.  I'd expect at least
> UC to be set.
> 
> And the PCI windows aren't mentioned.  I'd expect 0x80000000-0x88000000
> and some other regions to be MemMapIO.  I guess you can learn this from
> the ACPI root bridge descriptions, so maybe it's not strictly required.
> 
> But as for your specific issue, I'd expect your memmap to show that the
> ACPI tables are in memory that supports WB, so acpi_os_map_memory()
> will just use phys_to_virt() instead of ioremap(), which is what your
> dmesg showed:
> 
>> ACPI: XSDT (v001 APPLE   Apple00 0x00000039      0x01000013) @ 0x1fefd120
>> ...
>> iounmap: bad address dfefd000
>>  [<c0253684>] acpi_tb_get_table_header+0x67/0x92
>>  [<c02536c2>] acpi_tb_get_table+0x13/0x55
>>  [<c02538b2>] acpi_tb_get_table_rsdt+0x1f/0x99
>>  [<c0253971>] acpi_load_tables+0x45/0xa9
>>  [<c0443d56>] acpi_early_init+0x46/0xf6
> 
> (0xdfefd000 = 0x1fefd000 + 0xc0000000)
> 
> In that case, the iounmap() will certainly fail, as Shaohua points out.
> His test patch forces acpi_os_map_memory() to always use ioremap(), but
> that didn't help your situation.  My guess is you hit the
> "if(!PageReserved(page))" case in __ioremap(), and we're missing
> a SetPageReserved() somewhere in the EFI memory initialization, but
> I'm not enough of an x86/VM expert propose anything.
> 
> Sorry for rambling on so long without contributing anything...  Maybe
> Matt will have some ideas.
> 


  reply	other threads:[~2006-02-17 17:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-17  7:54 ACPI Troubles with 2.6.16-rc3 Edgar Hucek
2006-02-17 17:14 ` Bjorn Helgaas
2006-02-17 17:27   ` Edgar Hucek [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-02-20  8:43 Li, Shaohua
2006-02-17  4:52 Li, Shaohua
2006-02-17  7:32 ` Edgar Hucek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43F60789.3040503@ed-soft.at \
    --to=hostmaster@ed-soft.at \
    --cc=bjorn.helgaas@hp.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=matthew.e.tolentino@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox