public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Jack Steiner <steiner@sgi.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [Fedora-ia64-list] kernel 2.6.16-1.2097_FC6 unbootable on Itanium
Date: Thu, 30 Mar 2006 15:16:11 +0000	[thread overview]
Message-ID: <20060330151611.GB3360@sgi.com> (raw)
In-Reply-To: <442AB6DD.4020800@sgi.com>

> I don't know if this helps or not.
> 
> I ran Jes's kernel on the simulator. Unfortunately, he sent me a stripped
> kernel so I have no symbol table.
> 
> The kernel blows up right after printing:
> 
> 	...
> 	Virtual mem_map starts at 0xa0007fffd5f2c000
> 	Built 1 zonelists
> 	Kernel command line: root=/dev/hda2 init=/bin/bash console=ttyS0
> 	PID hash table entries: 1024 (order: 10, 32768 bytes)
> 	Console: colour dummy device 80x25
> 
> The failure is an MCA caused by a cache hit on a memory reference to an
> uncached address. The simulator detects this error & stops.
> 
> The code that took the failure was memcopy (or equiv). I recognized the
> code from the prefetchs and ld/st sequence. The data appears to be
> an ACPI table that is being copied into kernel memory. The current
> reference is using uncached addresses but 15M instructions in the past, the
> table was referenced cached.
 
I found the problem that is causing the cache/uncached collision. This is
most likely NOT what is causing the problem you are currently chasing, but
it is a problem never-the-less.

(Background: I noticed that recent IA64 kernels are making references to the
same address using both cached & uncached addresses. The kernel fails to
boot on the simulator because it detects a cache-hit on an uncached
reference. Mixing cached & uncached references is not supported).


acpi_os_map_memory() has changed the order of checking the EFI attributes on
pages being mapped. In 2.6.15, if the EFI map indicates that an address
supports both cached & uncached references, acpi_os_map_memory() would map
it as cached.

The most recent kernel has changed this behavior so that the address will be
referenced as uncached.


OLD:
        acpi_os_map_memory
                if (EFI_MEMORY_WB & efi_mem_attributes(phys)) {
                        *virt = (void __iomem *)phys_to_virt(phys);
                } else {
                        *virt = ioremap(phys, size);
                }

NEW
        acpi_os_map_memory() unconditionally calls ioremap() to do the
        mapping

        ioremap
                if (efi_mem_attribute_range(offset, size, EFI_MEMORY_UC))
                         return __ioremap(offset, size);

                if (efi_mem_attribute_range(offset, size, EFI_MEMORY_WB))
                         return phys_to_virt(offset);


Earlier in the boot, the ACPI tables are unconditionally references as cached:

        char *__acpi_map_table(unsigned long phys_addr, unsigned long size)
        {
                return __va(phys_addr);
        }



I suspect there was a reason for this change. I'll add Bjorn to the cc
list. 

Is this problem unique to SN systems. The BIOS reports that most
memory ranges support both CACHED & UNCACHED references. I _think_
this is correct.



  parent reply	other threads:[~2006-03-30 15:16 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-29 16:33 [Fedora-ia64-list] kernel 2.6.16-1.2097_FC6 unbootable on Itanium Prarit Bhargava
2006-03-29 16:34 ` Prarit Bhargava
2006-03-29 16:55 ` Chen, Kenneth W
2006-03-29 18:55 ` Prarit Bhargava
2006-03-29 19:01 ` Greg Edwards
2006-03-29 19:55 ` Chen, Kenneth W
2006-03-29 20:13 ` Luck, Tony
2006-03-29 20:51 ` Grant Grundler
2006-03-29 20:57 ` [Fedora-ia64-list] kernel 2.6.16-1.2097_FC6 unbootable on James Bottomley
2006-03-29 20:58 ` [Fedora-ia64-list] kernel 2.6.16-1.2097_FC6 unbootable on Itanium Luck, Tony
2006-03-29 21:36 ` Émeric Maschino
2006-03-29 22:04 ` Jack Steiner
2006-03-30  8:57 ` Jes Sorensen
2006-03-30  9:04 ` Jes Sorensen
2006-03-30  9:08 ` Jes Sorensen
2006-03-30  9:14 ` Keith Owens
2006-03-30 10:11 ` Jes Sorensen
2006-03-30 12:29 ` Jes Sorensen
2006-03-30 13:24 ` Jes Sorensen
2006-03-30 15:16 ` Jack Steiner [this message]
2006-03-30 15:42 ` Prarit Bhargava
2006-03-30 15:43 ` David Mosberger-Tang
2006-03-30 15:49 ` Jack Steiner
2006-03-30 15:53 ` David Mosberger-Tang
2006-03-30 16:34 ` H. J. Lu
2006-03-30 16:38 ` Prarit Bhargava
2006-03-30 16:45 ` H. J. Lu
2006-03-30 16:52 ` Prarit Bhargava
2006-03-30 16:53 ` Bjorn Helgaas
2006-03-30 17:10 ` Jack Steiner
2006-03-30 18:23 ` Luck, Tony
2006-03-30 18:23 ` Prarit Bhargava
2006-03-30 18:54 ` Grant Grundler

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=20060330151611.GB3360@sgi.com \
    --to=steiner@sgi.com \
    --cc=linux-ia64@vger.kernel.org \
    /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