All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.