Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 153775 - [RHEL3-U6][Diskdump] Backtrace of OS_INIT doesn't work
Summary: [RHEL3-U6][Diskdump] Backtrace of OS_INIT doesn't work
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel
Version: 3.0
Hardware: ia64
OS: Linux
Target Milestone: ---
Assignee: Nobuhiro Tachino
QA Contact: Brian Brock
Depends On:
Blocks: 156320
TreeView+ depends on / blocked
Reported: 2005-04-05 19:47 UTC by Yuuichi Nagahama
Modified: 2010-10-22 02:52 UTC (History)
11 users (show)

Fixed In Version: RHSA-2005-663
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-09-28 14:53:08 UTC
Target Upstream Version:

Attachments (Terms of Use)
osinit.patch (deleted)
2005-04-05 20:30 UTC, Yuuichi Nagahama
no flags Details | Diff

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2005:663 qe-ready SHIPPED_LIVE Important: Updated kernel packages available for Red Hat Enterprise Linux 3 Update 6 2005-09-28 04:00:00 UTC

Description Yuuichi Nagahama 2005-04-05 19:47:39 UTC
Description of problem:
When crashdump is executed via OS_INIT on IPF machine, backtrace command,
which is a subcommand of crash, does not work correctly.

Two problems were found in the OS_INIT code.

(1) OS_INIT handler has two stages.
     stage1: handler written by assembler
     stage2: handler written by C
    The former is ia64_monarch_init_handler and ia64_slave_init_handler.
    The latter is ia64_init_handler. ia64_init_handler is called only by
    When INIT interrupt is asserted, one cpu calls
    ia64_monarch_init_handler and the others call
    ia64_slave_init_handler. It means that ia64_init_handler is called
    by only one cpu. In that case, backtrace command fails. To make
    backtrace succeed, all cpus need to call ia64_monarch_init_handler.

(2) The second problem occurs by correcting the first problem.
    When OS_INIT handler is called, SAL hands handler some information
    through register. The handler preserves this information in
    ia64_sal_to_os_handoff_state. (Please see
    SAL_TO_OS_MCA_HANDOFF_STATE_SAVE macro in the arch/ia64/kernel/
    mca_asm.S.) If all cpus call ia64_monarch_init_handler at the same
    time, they writes their own information to the
    ia64_sal_to_os_handoff_state simultaneously and break its contents.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Enable Diskdump
2. Push OS_INIT switch
3. bt with crash command
Actual results:
Backtrace command does not work

Expected results:
Backtrace command works correctly

Additional info:

Comment 1 Yuuichi Nagahama 2005-04-05 20:24:09 UTC
How to correct these problems:
(1) When OS_INIT handler is registered with SAL, 
    register ia64_monarch_init_handler as both monarch handler and slave
(2) Prepare ia64_sal_to_os_handoff_state of each cpu beforehand.

Comment 2 Yuuichi Nagahama 2005-04-05 20:30:39 UTC
Created attachment 112728 [details]

The patch is provided by Fujitsu on IT#69948.

Comment 3 Yuuichi Nagahama 2005-04-05 21:49:45 UTC
The fix for the issue will be targeted for RHEL3-U6.

Comment 8 Ernie Petrides 2005-05-27 02:23:30 UTC
A fix for this problem has just been committed to the RHEL3 U6
patch pool this evening (in kernel version 2.4.21-32.5.EL).

Comment 10 Akira Imamura 2005-06-29 21:00:11 UTC
To verify the fix, we've done testing with kernel-2.4.21-32.9.EL. It works 


Comment 15 Red Hat Bugzilla 2005-09-28 14:53:08 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

Note You need to log in before you can comment on or make changes to this bug.