[Linux-ia64] 2.4.20 / DIG

[Linux-ia64] 2.4.20 / DIG

[Jes Sorensen]

Hi

I am trying to compile Bjorn's 2.4.20 kernel on my old Intel C0 based
box with a RH7.2 install on it (with updates), gcc-2.96.

The Red Hat 2.4.9 kernels work just fine on it, but my selfcompiled
2.4.20 kernels explode before it gets to probing the SCSI bus. In SMP
mode it reboots so fast I can't see exactly where it hands, if I set
maxcpus=1 it gets to saying EFI Variables Facility - then hangs for a
bit and then reboots.

Is this a known problem? Any clues?

Thanks,
Jes

Re: [Linux-ia64] 2.4.20 / DIG

[Bjorn Helgaas]

> I am trying to compile Bjorn's 2.4.20 kernel on my old Intel C0 based
> box with a RH7.2 install on it (with updates), gcc-2.96.
> 
> The Red Hat 2.4.9 kernels work just fine on it, but my selfcompiled
> 2.4.20 kernels explode before it gets to probing the SCSI bus. In SMP
> mode it reboots so fast I can't see exactly where it hands, if I set
> maxcpus=1 it gets to saying EFI Variables Facility - then hangs for a
> bit and then reboots.
> 
> Is this a known problem? Any clues?

It's not know to me, at least.  Any chance you can use a serial
console to capture the output?  You could also check for MCA
log information -- that's a likely cause of an early reboot.  You
don't say what box you have, but typically you can go to the
EFI shell and use something like "errdump mca".

Bjorn

Re: [Linux-ia64] 2.4.20 / DIG

[Jes Sorensen]

>>>>> "Bjorn" = Bjorn Helgaas <bjorn_helgaas@hp.com> writes:

Bjorn> It's not know to me, at least.  Any chance you can use a serial
Bjorn> console to capture the output?  You could also check for MCA log
Bjorn> information -- that's a likely cause of an early reboot.  You
Bjorn> don't say what box you have, but typically you can go to the EFI
Bjorn> shell and use something like "errdump mca".

I'll try hooking up a serial console for it.

The box is an old Intel BigSur beta box that was upgraded with C0 CPUs.

Cheers,
Jes

Re: [Linux-ia64] 2.4.20 / DIG

[Jes Sorensen]

>>>>> "Bjorn" = Bjorn Helgaas <bjorn_helgaas@hp.com> writes:

Bjorn> It's not know to me, at least.  Any chance you can use a serial
Bjorn> console to capture the output?  You could also check for MCA log
Bjorn> information -- that's a likely cause of an early reboot.  You
Bjorn> don't say what box you have, but typically you can go to the EFI
Bjorn> shell and use something like "errdump mca".

Ok, got the serial console stuff going. Output attached at the end.

It looks like it blows up right after the EFI Variables thing. As far as
I can see everything looks perfectly normal, until it explodes.

Any ideas?

Cheers,
Jes


ELILO boot: 
kernel     is  'vmlinuz-2.4.20'
arguments  are 'root=/dev/sda7 console=ttyS0,115200n8 console=tty0 ro'
Using gzip_elf64 loader
Uncompressing Linux... done
Linux version 2.4.20 (jes@itanic) (gcc version 3.0.2 20010928 (prerelease)) #133EFI v1.02 by INTEL: SALsystab=0x3ff236b0 ACPI=0x3ffd9f80 ACPI 2.0=0xe2000 MPS\0CPU 0: mapping PAL code [0x3ff40000-0x3ff7b000) into [0xe00000003c000000-0xe000)efi.trim_bottom: ignoring 540KB of memory at 0x1000 due to granule hole at 0x0
efi.trim_bottom: ignoring 64512KB of memory at 0x100000 due to granule hole at 0SAL v2.90: oem=INTEL   MSL     REF     SAL     , productSAL: entry: pal_proc=0x3ff48010, sal_proc=0x3fe46d90
SAL: Platform features BusLock IRQ_Redirection 
SAL: AP wakeup using external interrupt vector 0xf0
CPU 0: 51 virtual and 44 physical address bits
ACPI: RSDP (v002 Intel                      ) @ 0x00000000000e2000
ACPI: XSDT (v001 Intel  W460GXBS 00000.00001) @ 0x000000003ffd8030
ACPI: FADT (v003 Intel  W460GXBS 00000.00002) @ 0x000000003ffd8068
ACPI: MADT (v001 Intel  W460GXBS 00000.00000) @ 0x000000003ffd9ec0
ACPI: Local APIC address 0xc0000000fee00000
ACPI: LSAPIC (acpi_id[0x00] lsapic_id[0x00] lsapic_eid[0x00] enabled)
CPU 0 (0x0000) enabled (BSP)
ACPI: LSAPIC (acpi_id[0x01] lsapic_id[0x03] lsapic_eid[0x00] enabled)
CPU 1 (0x0300) enabled
ACPI: IOSAPIC (id[0x2] global_irq_base[0x0] address[00000000fec00000])
iosapic_init: Disabling PC-AT compatible 8259 interrupts
IOSAPIC: version 2.1, address 0xfec00000, GSIs 0x0-0x3f
ACPI: INT_SRC_OVR (bus[0] irq[0x9] global_irq[0x21] polarity[0x3] trigger[0x3])
register_intr: changing vector 39 from IO-SAPIC-edge to IO-SAPIC-level
2 CPUs available, 2 CPUs total
Mca related initialization done
On node 0 totalpages: 60523
zone(0): 60523 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: BOOT_IMAGE=scsi0:/vmlinuz-2.4.20 root=/dev/sda7 console=ttoFPSWA interface at 0x3f146010, revision 1.6
CPU 0: base freq\x133.324MHz, ITC ratio\x11/2, ITC freqs3.283MHz
Console: colour VGA+ 80x25
Calibrating delay loop... 730.88 BogoMIPS
Placing software IO TLB between 0xe000000004008000 - 0xe000000004208000
Memory: 953920k/968368k available (3890k code, 14448k reserved, 2549k data, 192)Dentry cache hash table entries: 65536 (order: 6, 1048576 bytes)
Inode cache hash table entries: 65536 (order: 6, 1048576 bytes)
Mount-cache hash table entries: 16384 (order: 4, 262144 bytes)
Buffer-cache hash table entries: 65536 (order: 5, 524288 bytes)
Page-cache hash table entries: 65536 (order: 5, 524288 bytes)
POSIX conformance testing by UNIFIX
Boot processor id 0x0/0x0
SMP: starting up secondaries.
CPU 1: mapping PAL code [0x3ff40000-0x3ff7b000) into [0xe00000003c000000-0xe000)CPU 1: 51 virtual and 44 physical address bits
CPU 1: synchronized ITC with CPU 0 (last diff 0 cycles, maxerr 519 cycles)
CPU 1: base freq\x133.324MHz, ITC ratio\x11/2, ITC freqs3.283MHz
Calibrating delay loop... 730.88 BogoMIPS
CPU1: CPU has booted.
Before bogomips.
Total of 2 processors activated (1460.76 BogoMIPS).
Waiting on wait_init_idle (map = 0x2)
All processors have done init_idle
ACPI: Subsystem revision 20020517
PCI: Using SAL to access configuration space
ACPI: Interpreter enabled
ACPI: Using IOSAPIC for interrupt routing
ACPI: System [ACPI] (supports S0 S1 S4 S5)
ACPI: PCI Root Bridge [PCI0] (00:00)
ACPI: PCI Root Bridge [PCI1] (00:01)
ACPI: PCI Root Bridge [PCI2] (00:02)
ACPI: PCI Root Bridge [PCI3] (00:03)
ACPI: PCI Root Bridge [CBN] (00:04)
PCI->APIC IRQ transform: (00:01.0 INTA) -> CPU 0x0000 vector 48
PCI->APIC IRQ transform: (00:02.0 INTA) -> CPU 0x0000 vector 49
PCI->APIC IRQ transform: (00:03.2 INTD) -> CPU 0x0000 vector 50
PCI->APIC IRQ transform: (00:03.3 INTB) -> CPU 0x0000 vector 51
PCI->APIC IRQ transform: (00:04.0 INTA) -> CPU 0x0000 vector 52
PCI->APIC IRQ transform: (00:05.0 INTA) -> CPU 0x0000 vector 53
PCI->APIC IRQ transform: (01:00.0 INTA) -> CPU 0x0000 vector 54
PCI->APIC IRQ transform: (01:02.0 INTA) -> CPU 0x0000 vector 55
PCI->APIC IRQ transform: (01:02.1 INTB) -> CPU 0x0000 vector 56
PCI->APIC IRQ transform: (01:0f.0 INTA) -> CPU 0x0000 vector 57
PCI->APIC IRQ transform: (02:00.0 INTA) -> CPU 0x0000 vector 58
PCI->APIC IRQ transform: (02:0f.0 INTA) -> CPU 0x0000 vector 59
PCI->APIC IRQ transform: (03:00.0 INTA) -> CPU 0x0000 vector 60
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
perfmon: version 1.2 IRQ 238
perfmon: 14 PMCs, 18 PMDs, 4 counters (32 bits)
PAL Information Facility v0.5
EFI Variables Facility v0.05 2002-Mar-26

Re: [Linux-ia64] 2.4.20 / DIG

[Andreas Schwab]

Jes Sorensen <jes@wildopensource.com> writes:

|> Hi
|> 
|> I am trying to compile Bjorn's 2.4.20 kernel on my old Intel C0 based
|> box with a RH7.2 install on it (with updates), gcc-2.96.
|> 
|> The Red Hat 2.4.9 kernels work just fine on it, but my selfcompiled
|> 2.4.20 kernels explode before it gets to probing the SCSI bus. In SMP
|> mode it reboots so fast I can't see exactly where it hands, if I set
|> maxcpus=1 it gets to saying EFI Variables Facility - then hangs for a
|> bit and then reboots.
|> 
|> Is this a known problem? Any clues?

Try disabling CONFIG_IA64_MCA, IIRC this is a problem of a missing
hardware component.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [Linux-ia64] 2.4.20 / DIG

[Jes Sorensen]

>>>>> "Andreas" = Andreas Schwab <schwab@suse.de> writes:

Andreas> Try disabling CONFIG_IA64_MCA, IIRC this is a problem of a
Andreas> missing hardware component.

Bingo! Give that man a cigar!

Thanks a lot, I am back in business!

Cheers,
Jes

Re: [Linux-ia64] 2.4.20 / DIG

[Bjorn Helgaas]

On Tuesday 11 March 2003 2:04 pm, Jes Sorensen wrote:
> >>>>> "Andreas" = Andreas Schwab <schwab@suse.de> writes:
> 
> Andreas> Try disabling CONFIG_IA64_MCA, IIRC this is a problem of a
> Andreas> missing hardware component.
> 
> Bingo! Give that man a cigar!
> 
> Thanks a lot, I am back in business!

Did you ever look at the MCA logs from the EFI shell?  It would be
nice if we could make the kernel smart enough to avoid this failure.

Andreas, do you remember any more details of the problem?

Bjorn

Re: [Linux-ia64] 2.4.20 / DIG

[Jes Sorensen]

>>>>> "Bjorn" = Bjorn Helgaas <bjorn_helgaas@hp.com> writes:

Bjorn> On Tuesday 11 March 2003 2:04 pm, Jes Sorensen wrote:
>> Thanks a lot, I am back in business!

Bjorn> Did you ever look at the MCA logs from the EFI shell?  It would
Bjorn> be nice if we could make the kernel smart enough to avoid this
Bjorn> failure.

Must admit I didn't - are those preserved across a power cycle? The box
locks up solid and I need to power cycle it to bring it back.

Cheers,
Jes

Re: [Linux-ia64] 2.4.20 / DIG

[Bjorn Helgaas]

On Tuesday 11 March 2003 2:15 pm, Jes Sorensen wrote:
> Bjorn> Did you ever look at the MCA logs from the EFI shell?  It would
> Bjorn> be nice if we could make the kernel smart enough to avoid this
> Bjorn> failure.
> 
> Must admit I didn't - are those preserved across a power cycle?

They should be.  Of course, it will only make sense if you still
have symbols from the kernel that caused the MCA.

Re: [Linux-ia64] 2.4.20 / DIG

[Jes Sorensen]

>>>>> "Bjorn" = Bjorn Helgaas <bjorn_helgaas@hp.com> writes:

>>  Must admit I didn't - are those preserved across a power cycle?

Bjorn> They should be.  Of course, it will only make sense if you still
Bjorn> have symbols from the kernel that caused the MCA.

Urgh, brown paper bag time ... I was running a very old version of EFI
on it (103B). Upgrading to 117C made the problem go away, the proper way.

Doh ;-( sorry for the noise.

Cheers,
Jes

Re: [Linux-ia64] 2.4.20 / DIG

[Alex Williamson]

Jes Sorensen wrote:
> 
> >>>>> "Bjorn" = Bjorn Helgaas <bjorn_helgaas@hp.com> writes:
> 
> >>  Must admit I didn't - are those preserved across a power cycle?
> 
> Bjorn> They should be.  Of course, it will only make sense if you still
> Bjorn> have symbols from the kernel that caused the MCA.
> 
> Urgh, brown paper bag time ... I was running a very old version of EFI
> on it (103B). Upgrading to 117C made the problem go away, the proper way.
> 
> Doh ;-( sorry for the noise.
> 

   Ah, this is probably a good thing to point out.  I was helping
someone debug a similar issue last week.  They were kind enough
to trace it to the CPE polling.  They also upgraded firmware and
the problem went away.  Apparently SAL_GET_STATE_INFO(CPE) doesn't
work on any 103 flavors of Itanium firmware.  I don't know when it
was fixed, but I think we're in consensus that fw 117 works.

	Alex

--
Alex Williamson                                  Linux Development Lab
alex_williamson@hp.com                                 Hewlett Packard
970-898-9173                                          Fort Collins, CO

RE: [Linux-ia64] 2.4.20 / DIG

[Wichmann, Mats D]

> I am trying to compile Bjorn's 2.4.20 kernel on my old Intel C0 based
> box with a RH7.2 install on it (with updates), gcc-2.96.
> 
> The Red Hat 2.4.9 kernels work just fine on it, but my selfcompiled
> 2.4.20 kernels explode before it gets to probing the SCSI bus. In SMP
> mode it reboots so fast I can't see exactly where it hands, if I set
> maxcpus=1 it gets to saying EFI Variables Facility - then hangs for a
> bit and then reboots.
> 
> Is this a known problem? Any clues?

I'd bet your firmware's out of date.  I got around 
the same problem by upgrading.