Hacking SuperDome

Hacking SuperDome

[Thomas Bogendoerfer]

Hi,

thanks to Madze, I've now access to a HP Superdome;-)

I found the first show stopper, which prevents the kernel from
even throwing out the first messages. The narrow firmware detection
hangs. With the quick hack below I'm now able to boot a UP kernel
(SMP hangs when calling init_per_cpu(smp_processor_id()); in setup.c).

The bigger partition produces following boot log:

HARD Booted.
palo ipl 1.14 root@duet Sat Apr  8 16:08:16 EDT 2006

Boot image contains:
    0/vmlinux64 6484269 bytes @ 0xa000

Information: No console specified on kernel command line. This is
normal.
PALO will choose the console currently used by firmware (serial).
Command line for kernel: 'HOME=/ ip=dhcp console=ttyS0 TERM=vt102
palo_kernel=0/vmlinux'
Selected kernel: /vmlinux from partition 0
Warning: kernel name doesn't end with 32 or 64 -- Guessing... Choosing
64-bit kernelELF64 executable
Entry 00100000 first 00100000 n 3
Segment 0 load 00100000 size 4456448 mediaptr 0x1000
Segment 1 load 00588000 size 399072 mediaptr 0x441000
Segment 2 load 005ec000 size 266374 mediaptr 0x4a3000
Branching to kernel entry point 0x00100000.  If this is the last
message you see, you may need to switch your console.  This is
a common symptom -- search the FAQ and mailing list at parisc-linux.org

Linux version 2.6.29-rc3-00000-g33bfad5-dirty (tsbogend@login) (gcc
version 4.2.1) #23 Sat Feb 7 15:16:57 CET 2009
unwind_init: start = 0x404788c0, end = 0x404a53c0, entries = 11440
WARNING: Out of order unwind entry! 000000004047a400 and
000000004047a410
WARNING: Out of order unwind entry! 000000004047a410 and
000000004047a420
FP[0] enabled: Rev 1 Model 19
The 64-bit Kernel has started...
console [ttyB0] enabled
Initialized PDC Console for debugging.
Determining PDC firmware type: 64 bit PAT.
model 00005e70 00000491 00000000 00000002 3e0f97abec371bc2 00000000
00000008 000000b2 000000b2
vers  00000202
CPUID vers 19 rev 1 (0x00000261)
capabilities 0x3d
model 9000/800/SD32000
parisc_cache_init: Only equivalent aliasing supported!
Memory Ranges:
 0) Start 0x0000000000000000 End 0x00000007ffffffff Size  32768 MB
 1) Start 0x0000000800000000 End 0x00000009ffffffff Size   8192 MB
 2) Start 0x0000000a00000000 End 0x0000000bffffffff Size   8192 MB
 3) Start 0x0000000c00000000 End 0x0000000df7ffffff Size   8064 MB
Total Memory: 57216 MB
Built 4 zonelists in Zone order, mobility grouping on.  Total pages:
14447040
Kernel command line: HOME=/ ip=dhcp console=ttyS0 TERM=vt102
palo_kernel=0/vmlinux
PID hash table entries: 4096 (order: 12, 32768 bytes)
Dentry cache hash table entries: 8388608 (order: 14, 67108864 bytes)
Inode-cache hash table entries: 4194304 (order: 13, 33554432 bytes)
Memory: 57567696k/58589184k available (2869k kernel code, 1019520k
reserved, 1434k data, 264k init)
virtual kernel memory layout:
    vmalloc : 0x0000000000008000 - 0x000000003f000000   (1007 MB)
    memory  : 0x0000000040000000 - 0x0000000e38000000   (57216 MB)
      .init : 0x00000000405ec000 - 0x000000004062e000   ( 264 kB)
      .data : 0x00000000403cd650 - 0x0000000040534000   (1434 kB)
      .text : 0x0000000040100000 - 0x00000000403cd650   (2869 kB)
Calibrating delay loop... 1495.04 BogoMIPS (lpj=2990080)
Security Framework initialized
Mount-cache hash table entries: 256
net_namespace: 544 bytes
NET: Registered protocol family 16
EISA bus registered
Searching for devices...
Two devices have hardware path [255].  IODC data for second device:
00404e0000abRearranging GSC cards sometimes helps
Two devices have hardware path [255].  IODC data for second device:
00404e0000abRearranging GSC cards sometimes helps
Found devices:
1. Caribe DNA Central Agent at 0xfffffffffc000000 [255] { 14, 0x0,
0x007, 0x000aa }
2. Caribe W2 800 at 0xfffffffffc078000 [10] { 0, 0x0, 0x5e7, 0x00004 }
3. Caribe W2 800 at 0xfffffffffc07a000 [11] { 0, 0x0, 0x5e7, 0x00004 }
4. Caribe W2 800 at 0xfffffffffc07c000 [12] { 0, 0x0, 0x5e7, 0x00004 }
5. Caribe W2 800 at 0xfffffffffc07e000 [13] { 0, 0x0, 0x5e7, 0x00004 }
6. Memory at 0xfffffffffc005000 [5] { 1, 0x0, 0x0a8, 0x00009 }
7. REO I/O BC Merced Port at 0xfffffff808000000 [0] { 7, 0x0, 0x804,
0x0000c }
8. Elroy PCI Bridge at 0xfffffff804000000 [0/0] { 13, 0x0, 0x782,
0x0000a }
9. Elroy PCI Bridge at 0xfffffff804002000 [0/1] { 13, 0x0, 0x782,
0x0000a }
10. Elroy PCI Bridge at 0xfffffff804004000 [0/2] { 13, 0x0, 0x782,
0x0000a }
11. Elroy PCI Bridge at 0xfffffff804006000 [0/3] { 13, 0x0, 0x782,
0x0000a }
12. Elroy PCI Bridge at 0xfffffff804008000 [0/4] { 13, 0x0, 0x782,
0x0000a }
13. Elroy PCI Bridge at 0xfffffff80400c000 [0/6] { 13, 0x0, 0x782,
0x0000a }
14. Elroy PCI Bridge at 0xfffffff804010000 [0/8] { 13, 0x0, 0x782,
0x0000a }
15. Elroy PCI Bridge at 0xfffffff804012000 [0/9] { 13, 0x0, 0x782,
0x0000a }
16. Elroy PCI Bridge at 0xfffffff804014000 [0/10] { 13, 0x0, 0x782,
0x0000a }
17. Elroy PCI Bridge at 0xfffffff804016000 [0/11] { 13, 0x0, 0x782,
0x0000a }
18. Elroy PCI Bridge at 0xfffffff804018000 [0/12] { 13, 0x0, 0x782,
0x0000a }
19. Elroy PCI Bridge at 0xfffffff80401c000 [0/14] { 13, 0x0, 0x782,
0x0000a }
CONFIG_SMP=n  ignoring additional CPUs
CPU: probe of 11 failed with error 1
CONFIG_SMP=n  ignoring additional CPUs
CPU: probe of 12 failed with error 1
CONFIG_SMP=n  ignoring additional CPUs
CPU: probe of 13 failed with error 1
CPU(s): 1 x PA8700 (PCX-W2) at 750.000000 MHz
Setting cache flush threshold to 180000 (1 CPUs online)
SBA found REO rev 2 at 0xfffffff808000000
Elroy version TR4.0 (0x5) found at 0xfffffff804000000
Elroy version TR4.0 (0x5) found at 0xfffffff804002000
Elroy version TR4.0 (0x5) found at 0xfffffff804004000
Elroy version TR4.0 (0x5) found at 0xfffffff804006000
Elroy version TR4.0 (0x5) found at 0xfffffff804008000
Elroy version TR4.0 (0x5) found at 0xfffffff80400c000
Elroy version TR4.0 (0x5) found at 0xfffffff804010000
Elroy version TR4.0 (0x5) found at 0xfffffff804012000
Elroy version TR4.0 (0x5) found at 0xfffffff804014000
Elroy version TR4.0 (0x5) found at 0xfffffff804016000
Elroy version TR4.0 (0x5) found at 0xfffffff804018000
Elroy version TR4.0 (0x5) found at 0xfffffff80401c000
powersw: Soft power switch support not available.
bio: create slab <bio-0> at 0
SCSI subsystem initialized
NET: Registered protocol family 2
IP route cache hash table entries: 524288 (order: 10, 4194304 bytes)
TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
TCP reno registered
NET: Registered protocol family 1
Chassis warnings not supported.
Performance monitoring counters enabled for Caribe W2 800
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
msgmni has been set to 32768
alg: No test for stdrng (krng)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
serial 0000:00:00.0: enabling device (0146 -> 0147)
0000:00:00.0: ttyS0 at MMIO 0xfffffff000000000 (irq = 65) is a 16550A
console handover: boot [ttyB0] -> real [ttyS0]
0000:00:00.0: ttyS1 at MMIO 0xfffffff000000008 (irq = 65) is a 16550A
0000:00:00.0: ttyS2 at MMIO 0xfffffff000000010 (irq = 65) is a 16550A
brd: module loaded
loop: module loaded
Linux Tulip driver version 1.1.15 (Feb 27, 2007)
tulip0: no phy info, aborting mtable build
tulip0:  MII transceiver #1 config 1000 status 782d advertising 01e1.
eth0: Digital DS21142/43 Tulip rev 65 at Port 0x80, 00:30:6e:0e:b2:5f,
IRQ 65.
sym53c8xx 0000:18:00.0: enabling device (0146 -> 0147)
sym0: <895> rev 0x2 at pci 0000:18:00.0 irq 67
sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking
sym0: SCSI BUS has been reset.
scsi0 : sym-2.2.3
scsi 0:0:0:0: ABORT operation started
scsi 0:0:0:0: ABORT operation timed-out.
scsi 0:0:0:0: DEVICE RESET operation started

After that it hangs...

The smaller partion hangs even earlier:

HARD Booted.
palo ipl 1.14 root@duet Sat Apr  8 16:08:16 EDT 2006

Boot image contains:
    0/vmlinux64 6484269 bytes @ 0xa000

Information: No console specified on kernel command line. This is
normal.
PALO will choose the console currently used by firmware (serial).
Command line for kernel: 'HOME=/ ip=dhcp console=ttyS0 TERM=vt102
palo_kernel=0/vmlinux'
Selected kernel: /vmlinux from partition 0
Warning: kernel name doesn't end with 32 or 64 -- Guessing... Choosing
64-bit kernelELF64 executable
Entry 00100000 first 00100000 n 3
Segment 0 load 00100000 size 4456448 mediaptr 0x1000
Segment 1 load 00588000 size 399072 mediaptr 0x441000
Segment 2 load 005ec000 size 266374 mediaptr 0x4a3000
Branching to kernel entry point 0x00100000.  If this is the last
message you see, you may need to switch your console.  This is
a common symptom -- search the FAQ and mailing list at parisc-linux.org

Linux version 2.6.29-rc3-00000-g33bfad5-dirty (tsbogend@login) (gcc
version 4.2.1) #23 Sat Feb 7 15:16:57 CET 2009
unwind_init: start = 0x404788c0, end = 0x404a53c0, entries = 11440
WARNING: Out of order unwind entry! 000000004047a400 and
000000004047a410
WARNING: Out of order unwind entry! 000000004047a410 and
000000004047a420
FP[0] enabled: Rev 1 Model 19
The 64-bit Kernel has started...
console [ttyB0] enabled
Initialized PDC Console for debugging.
Determining PDC firmware type: 64 bit PAT.
model 00005e70 00000491 00000000 00000002 3e0f97abec371bc2 00000000
00000008 000000b2 000000b2
vers  00000202
CPUID vers 19 rev 1 (0x00000261)
capabilities 0x3d
model 9000/800/SD32000
parisc_cache_init: Only equivalent aliasing supported!
Total Memory: 8184 MB
Built 1 zonelists in Zone order, mobility grouping on.  Total pages:
2066460
Kernel command line: HOME=/ ip=dhcp console=ttyS0 TERM=vt102
palo_kernel=0/vmlinux
PID hash table entries: 4096 (order: 12, 32768 bytes)
Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
Memory: 8231168k/8380416k available (2869k kernel code, 148692k
reserved, 1434k data, 264k init)
virtual kernel memory layout:
    vmalloc : 0x0000000000008000 - 0x000000003f000000   (1007 MB)
    memory  : 0x0000000040000000 - 0x000000023f800000   (8184 MB)
      .init : 0x00000000405ec000 - 0x000000004062e000   ( 264 kB)
      .data : 0x00000000403cd650 - 0x0000000040534000   (1434 kB)
      .text : 0x0000000040100000 - 0x00000000403cd650   (2869 kB)
Calibrating delay loop... 1495.04 BogoMIPS (lpj=2990080)
Security Framework initialized
Mount-cache hash table entries: 256
net_namespace: 544 bytes
NET: Registered protocol family 16
EISA bus registered
Searching for devices...
Two devices have hardware path [255].  IODC data for second device:
00404e0000abRearranging GSC cards sometimes helps
Two devices have hardware path [255].  IODC data for second device:
00404e0000abRearranging GSC cards sometimes helps
Found devices:
1. Caribe DNA Central Agent at 0xfffffffffc400000 [255] { 14, 0x0,
0x007, 0x000aa }
2. Caribe W2 800 at 0xfffffffffc47a000 [11] { 0, 0x0, 0x5e7, 0x00004 }
3. Caribe W2 800 at 0xfffffffffc47c000 [12] { 0, 0x0, 0x5e7, 0x00004 }
4. Caribe W2 800 at 0xfffffffffc47e000 [13] { 0, 0x0, 0x5e7, 0x00004 }
5. Memory at 0xfffffffffc405000 [5] { 1, 0x0, 0x0a8, 0x00009 }
6. REO I/O BC Merced Port at 0xfffffff888000000 [0] { 7, 0x0, 0x804,
0x0000c }
7. Elroy PCI Bridge at 0xfffffff884000000 [0/0] { 13, 0x0, 0x782,
0x0000a }
8. Elroy PCI Bridge at 0xfffffff884002000 [0/1] { 13, 0x0, 0x782,
0x0000a }
9. Elroy PCI Bridge at 0xfffffff884004000 [0/2] { 13, 0x0, 0x782,
0x0000a }
10. Elroy PCI Bridge at 0xfffffff884006000 [0/3] { 13, 0x0, 0x782,
0x0000a }
11. Elroy PCI Bridge at 0xfffffff884008000 [0/4] { 13, 0x0, 0x782,
0x0000a }
12. Elroy PCI Bridge at 0xfffffff88400c000 [0/6] { 13, 0x0, 0x782,
0x0000a }
13. Elroy PCI Bridge at 0xfffffff884010000 [0/8] { 13, 0x0, 0x782,
0x0000a }
14. Elroy PCI Bridge at 0xfffffff884012000 [0/9] { 13, 0x0, 0x782,
0x0000a }
15. Elroy PCI Bridge at 0xfffffff884014000 [0/10] { 13, 0x0, 0x782,
0x0000a }
16. Elroy PCI Bridge at 0xfffffff884016000 [0/11] { 13, 0x0, 0x782,
0x0000a }
17. Elroy PCI Bridge at 0xfffffff884018000 [0/12] { 13, 0x0, 0x782,
0x0000a }
18. Elroy PCI Bridge at 0xfffffff88401c000 [0/14] { 13, 0x0, 0x782,
0x0000a }
CONFIG_SMP=n  ignoring additional CPUs
CPU: probe of 12 failed with error 1
CONFIG_SMP=n  ignoring additional CPUs
CPU: probe of 13 failed with error 1
CPU(s): 1 x PA8700 (PCX-W2) at 750.000000 MHz
Setting cache flush threshold to 180000 (1 CPUs online)
SBA found REO rev 2 at 0xfffffff888000000
Elroy version TR4.0 (0x5) found at 0xfffffff884000000


First guess would be some PCI setup issues... Any hints ?


BTW. I've tried with __PAGE_OFFSET=0x10000000 and __PAGE_OFFSET=0x40000000
and it doesn't make difference. The boot logs are from a kernel with
only the following hack:

diff --git a/arch/parisc/kernel/firmware.c
b/arch/parisc/kernel/firmware.c
index 03f26bd..a3fb7ef 100644
--- a/arch/parisc/kernel/firmware.c
+++ b/arch/parisc/kernel/firmware.c
@@ -153,12 +153,14 @@ static void convert_to_wide(unsigned long *addr)
 #ifdef CONFIG_64BIT
 void __init set_firmware_width_unlocked(void)
 {
+#if 0
        int ret;

        ret = mem_pdc_call(PDC_MODEL, PDC_MODEL_CAPABILITIES,
                __pa(pdc_result), 0);
        convert_to_wide(pdc_result);
        if (pdc_result[0] != NARROW_FIRMWARE)
+#endif
                parisc_narrow_firmware = 0;
 }

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea.                                                [ RFC1925, 2.3 ]

Re: Hacking SuperDome

[Kyle McMartin]

Oh, I'm jealous now. :)

On Sat, Feb 07, 2009 at 03:29:06PM +0100, Thomas Bogendoerfer wrote:
> +#if 0
>         int ret;
> 
>         ret = mem_pdc_call(PDC_MODEL, PDC_MODEL_CAPABILITIES,
>                 __pa(pdc_result), 0);
>         convert_to_wide(pdc_result);
>         if (pdc_result[0] != NARROW_FIRMWARE)
> +#endif

Yeah, this won't work on Superdome, which has no 32-bit firmware. At
this point in boot, we've got parisc_narrow_firmware set, which will
go kaboom.

We can fix this pretty easily, palo knows if it was started with 64-bit
firmware, we can just bring this into the kernel. I'll hack a patch for
palo this weekend, but you might as well continue just using what you've
got until then.

regards, Kyle

Re: Hacking SuperDome

[Kyle McMartin]

On Sat, Feb 07, 2009 at 11:30:32PM -0500, Kyle McMartin wrote:
> We can fix this pretty easily, palo knows if it was started with 64-bit
> firmware, we can just bring this into the kernel. I'll hack a patch for
> palo this weekend, but you might as well continue just using what you've
> got until then.
> 

I'd forgotten how simplistic our boot protocol is... we've really got
very little way to communicate, well, anything extra, since we didn't
sanitize the other unused registers before branching to the kernel
entrypoint.

Current plan is to define an extensible v2 palo format, using a
4096-byte data page (similar to the command line) and use the top
2048-bytes for the command line (so maybe people will whinge less.)

It's ugly, but aside from doing some ELF jiggery pokery or something, or
reading the first couple instructions from the kernel, we've fairly
little choice... I've decided that since %ret0 is guaranteed to have
the start address of _stext in it, since we returned it from iplload,
I'll just 'borrow' that as a flag to use the v2 boot protocol.
(ie: if %ret0 isn't 0x10000, use v2.)

This may seem unnecessary, but really, we might as well, I seem to
recall d-i running into the command line length being an issue earlier.

regards, Kyle

Re: Hacking SuperDome

[Matthew Wilcox]

On Sun, Feb 08, 2009 at 12:05:16PM -0500, Kyle McMartin wrote:
> I'd forgotten how simplistic our boot protocol is... we've really got
> very little way to communicate, well, anything extra, since we didn't
> sanitize the other unused registers before branching to the kernel
> entrypoint.

The usual solution to this is to put a magic value in a register.  For
example, mount(2) has 0xC0ED in the upper 16 bits of the flag register.
We're not exactly short on registers, so if one of the unused ones is
set to, say 0x0c2cd240, we would know that we're using the v2 protocol.

> Current plan is to define an extensible v2 palo format, using a
> 4096-byte data page (similar to the command line) and use the top
> 2048-bytes for the command line (so maybe people will whinge less.)

Heck, we could put a pointer in the data page, and have the command line
an unlimited length.  Or make one of the unused registers be the command
line.

> It's ugly, but aside from doing some ELF jiggery pokery or something, or
> reading the first couple instructions from the kernel, we've fairly
> little choice... I've decided that since %ret0 is guaranteed to have
> the start address of _stext in it, since we returned it from iplload,
> I'll just 'borrow' that as a flag to use the v2 boot protocol.
> (ie: if %ret0 isn't 0x10000, use v2.)

I'm fully in support, as long as a new palo will boot an old kernel, and
vice versa.  This doesn't seem like it would be too hard.

(Obviously, if you're using an old palo or an old kernel, you have to
live with the limitations of the v1 protocol).

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: Hacking SuperDome

[Matthew Wilcox]

On Sat, Feb 07, 2009 at 03:29:06PM +0100, Thomas Bogendoerfer wrote:
> The bigger partition produces following boot log:
[...]
> sym0: <895> rev 0x2 at pci 0000:18:00.0 irq 67
> sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking
> sym0: SCSI BUS has been reset.
> scsi0 : sym-2.2.3
> scsi 0:0:0:0: ABORT operation started
> scsi 0:0:0:0: ABORT operation timed-out.
> scsi 0:0:0:0: DEVICE RESET operation started
> 
> After that it hangs...

Generally, this means that interrupts are broken; sym2 didn't get an
interrupt saying the command completed.

Looking through the rest of the log, I don't see any information
pertaining to interrupt setup.  I forget whether we have debug related
to interrupts, but I bet we do ...

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: Hacking SuperDome

[Grant Grundler]

On Sat, Feb 07, 2009 at 03:29:06PM +0100, Thomas Bogendoerfer wrote:
> Hi,
> 
> thanks to Madze, I've now access to a HP Superdome;-)

Wow...that's so cool...I didn't this would happen. :)

> The bigger partition produces following boot log:
...

> The smaller partion hangs even earlier:
> 
> HARD Booted.
> palo ipl 1.14 root@duet Sat Apr  8 16:08:16 EDT 2006
> 
> Boot image contains:
>     0/vmlinux64 6484269 bytes @ 0xa000
...
> SBA found REO rev 2 at 0xfffffff888000000
> Elroy version TR4.0 (0x5) found at 0xfffffff884000000
> 
> 
> First guess would be some PCI setup issues... Any hints ?

Look for HPMC's. The console can't keep up with the kernel in general.
When an HPMC occurs, some of the output can get stranded.

I would add "initcall_debug=1" to boot parameters. See kernel/main.c.
Possible add a mdelay(100) after each initcall.

Since Tulip configured properly, I'm going to assume PCI resources
were properly assigned and all PCI Busses enumerated. PCI support
shouldn't be any different than for other PAT PDC machines.

hth,
grant

Re: Hacking SuperDome

[Thomas Bogendoerfer]

On Wed, Feb 11, 2009 at 12:23:12AM -0700, Grant Grundler wrote:
> > First guess would be some PCI setup issues... Any hints ?
> 
> Look for HPMC's. The console can't keep up with the kernel in general.
> When an HPMC occurs, some of the output can get stranded.

never saw an HPMC, but I'm sure it's because lots of output gets lost...

I've done some hacking yesterday and it looks like the basic
problem is, that REO isn't handled properly. As a start it would
be good to know, if the used IOC_IKE_OFFSET in sba_iommu.c is really
correct...

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea.                                                [ RFC1925, 2.3 ]

Re: Hacking SuperDome

[Matthew Wilcox]

On Wed, Feb 11, 2009 at 11:00:52AM +0100, Thomas Bogendoerfer wrote:
> On Wed, Feb 11, 2009 at 12:23:12AM -0700, Grant Grundler wrote:
> > > First guess would be some PCI setup issues... Any hints ?
> > 
> > Look for HPMC's. The console can't keep up with the kernel in general.
> > When an HPMC occurs, some of the output can get stranded.
> 
> never saw an HPMC, but I'm sure it's because lots of output gets lost...
> 
> I've done some hacking yesterday and it looks like the basic
> problem is, that REO isn't handled properly. As a start it would
> be good to know, if the used IOC_IKE_OFFSET in sba_iommu.c is really
> correct...

I've worked my contacts who're still at HP, and can confirm that REO is
basically the same as IKE.  While the terminology has changed, function
0 is the SBA, function 2 is IOC 0 and function 3 is IOC 1, just as with
Ike.  The Rope Control registers are offset in the 0x200 range, the
IOTLB registers are in the 0x300 range and ROPE_CONFIG is at 0x40.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: Hacking SuperDome

[Grant Grundler]

On Wed, Feb 11, 2009 at 11:00:52AM +0100, Thomas Bogendoerfer wrote:
> On Wed, Feb 11, 2009 at 12:23:12AM -0700, Grant Grundler wrote:
> > > First guess would be some PCI setup issues... Any hints ?
> > 
> > Look for HPMC's. The console can't keep up with the kernel in general.
> > When an HPMC occurs, some of the output can get stranded.
> 
> never saw an HPMC, but I'm sure it's because lots of output gets lost...

I only check the "ser pim" output at PDC prompt.
I don't know any other reliable way. Even with HPUX.

grant

> 
> I've done some hacking yesterday and it looks like the basic
> problem is, that REO isn't handled properly. As a start it would
> be good to know, if the used IOC_IKE_OFFSET in sba_iommu.c is really
> correct...
> 
> Thomas.
> 
> -- 
> Crap can work. Given enough thrust pigs will fly, but it's not necessary a
> good idea.                                                [ RFC1925, 2.3 ]
> --
> To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Hacking SuperDome

[Kyle McMartin]

On Wed, Feb 11, 2009 at 12:23:12AM -0700, Grant Grundler wrote:
> Look for HPMC's. The console can't keep up with the kernel in general.
> When an HPMC occurs, some of the output can get stranded.
> 
> I would add "initcall_debug=1" to boot parameters. See kernel/main.c.
> Possible add a mdelay(100) after each initcall.
> 
> Since Tulip configured properly, I'm going to assume PCI resources
> were properly assigned and all PCI Busses enumerated. PCI support
> shouldn't be any different than for other PAT PDC machines.
> 

The interrupt assignment looks a little wonky, don't you think?

Re: Hacking SuperDome

[Kyle McMartin]

On Wed, Feb 11, 2009 at 01:14:25PM -0500, Kyle McMartin wrote:
> > I would add "initcall_debug=1" to boot parameters. See kernel/main.c.
> > Possible add a mdelay(100) after each initcall.
> > 
> > Since Tulip configured properly, I'm going to assume PCI resources
> > were properly assigned and all PCI Busses enumerated. PCI support
> > shouldn't be any different than for other PAT PDC machines.
> > 
> 
> The interrupt assignment looks a little wonky, don't you think?

Try this?

diff --git a/drivers/parisc/iosapic.c b/drivers/parisc/iosapic.c
index 7beffca..25eaf6e 100644
--- a/drivers/parisc/iosapic.c
+++ b/drivers/parisc/iosapic.c
@@ -153,8 +153,8 @@
 
 /* "local" compile flags */
 #undef PCI_BRIDGE_FUNCS
-#undef DEBUG_IOSAPIC
-#undef DEBUG_IOSAPIC_IRT
+#define DEBUG_IOSAPIC
+#define DEBUG_IOSAPIC_IRT
 
 
 #ifdef DEBUG_IOSAPIC
@@ -479,7 +479,7 @@ iosapic_xlate_pin(struct iosapic_info *isi, struct pci_dev *pcidev)
 	pci_read_config_byte(pcidev, PCI_INTERRUPT_PIN, &intr_pin);
 
 	DBG_IRT("iosapic_xlate_pin(%s) SLOT %d pin %d\n",
-		pcidev->slot_name, PCI_SLOT(pcidev->devfn), intr_pin);
+		pci_slot_name(pcidev->slot), PCI_SLOT(pcidev->devfn), intr_pin);
 
 	if (intr_pin == 0) {
 		/* The device does NOT support/use IRQ lines.  */

Re: Hacking SuperDome

[Grant Grundler]

On Wed, Feb 11, 2009 at 01:14:25PM -0500, Kyle McMartin wrote:
> On Wed, Feb 11, 2009 at 12:23:12AM -0700, Grant Grundler wrote:
> > Look for HPMC's. The console can't keep up with the kernel in general.
> > When an HPMC occurs, some of the output can get stranded.
> > 
> > I would add "initcall_debug=1" to boot parameters. See kernel/main.c.
> > Possible add a mdelay(100) after each initcall.
> > 
> > Since Tulip configured properly, I'm going to assume PCI resources
> > were properly assigned and all PCI Busses enumerated. PCI support
> > shouldn't be any different than for other PAT PDC machines.
> > 
> 
> The interrupt assignment looks a little wonky, don't you think?

Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
serial 0000:00:00.0: enabling device (0146 -> 0147)
0000:00:00.0: ttyS0 at MMIO 0xfffffff000000000 (irq = 65) is a 16550A
console handover: boot [ttyB0] -> real [ttyS0]
0000:00:00.0: ttyS1 at MMIO 0xfffffff000000008 (irq = 65) is a 16550A
0000:00:00.0: ttyS2 at MMIO 0xfffffff000000010 (irq = 65) is a 16550A
brd: module loaded
loop: module loaded
Linux Tulip driver version 1.1.15 (Feb 27, 2007)
tulip0: no phy info, aborting mtable build
tulip0:  MII transceiver #1 config 1000 status 782d advertising 01e1.
eth0: Digital DS21142/43 Tulip rev 65 at Port 0x80, 00:30:6e:0e:b2:5f,
IRQ 65.


"IRQ 65" on it's own could be ok.
The fact the serial port and tulip share the IRQ seems odd.

Your suggestion to enable iosapic debug code is a good one.

hth,
grant

Re: Hacking SuperDome

[Kyle McMartin]

> Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
> serial 0000:00:00.0: enabling device (0146 -> 0147)
> 0000:00:00.0: ttyS0 at MMIO 0xfffffff000000000 (irq = 65) is a 16550A
> console handover: boot [ttyB0] -> real [ttyS0]
> 0000:00:00.0: ttyS1 at MMIO 0xfffffff000000008 (irq = 65) is a 16550A
> 0000:00:00.0: ttyS2 at MMIO 0xfffffff000000010 (irq = 65) is a 16550A
> brd: module loaded
> loop: module loaded
> Linux Tulip driver version 1.1.15 (Feb 27, 2007)
> tulip0: no phy info, aborting mtable build
> tulip0:  MII transceiver #1 config 1000 status 782d advertising 01e1.
> eth0: Digital DS21142/43 Tulip rev 65 at Port 0x80, 00:30:6e:0e:b2:5f,

Can you try with CONFIG_GSC turned off? irq 65 *shouldn't* be occuring
there, nor should it be occuring period since with CONFIG_GSC set it's
the IPI irq...

Re: Hacking SuperDome

[Thomas Bogendoerfer]

On Wed, Feb 11, 2009 at 07:36:28PM -0500, Kyle McMartin wrote:
> [...]

I've disabled GSC and applied the iosapic debug patch. Below
are the boot logs of both partitions.

28 CPU partition:

Linux version 2.6.29-rc3-00000-g33bfad5-dirty (tsbogend@login) (gcc
version 4.2.1) #59 Fri Feb 13 21:31:17 CET 2009
unwind_init: start = 0x404718c0, end = 0x4049da80, entries = 11292
WARNING: Out of order unwind entry! 00000000404733d0 and
00000000404733e0
WARNING: Out of order unwind entry! 00000000404733e0 and
00000000404733f0
FP[0] enabled: Rev 1 Model 19
The 64-bit Kernel has started...
console [ttyB0] enabled
Initialized PDC Console for debugging.
Determining PDC firmware type: 64 bit PAT.
model 00005e70 00000491 00000000 00000002 3e0f97abec371bc2 00000000
00000008 000000b2 000000b2
vers  00000202
CPUID vers 19 rev 1 (0x00000261)
capabilities 0x3d
model 9000/800/SD32000
parisc_cache_init: Only equivalent aliasing supported!
Memory Ranges:
 0) Start 0x0000000000000000 End 0x00000007ffffffff Size  32768 MB
 1) Start 0x0000000800000000 End 0x00000009ffffffff Size   8192 MB
 2) Start 0x0000000a00000000 End 0x0000000bffffffff Size   8192 MB
 3) Start 0x0000000c00000000 End 0x0000000df7ffffff Size   8064 MB
Total Memory: 57216 MB
Built 4 zonelists in Zone order, mobility grouping on.  Total pages:
14447040
Kernel command line: HOME=/ ip=dhcp console=ttyS0 TERM=vt102
palo_kernel=0/vmlinux
PID hash table entries: 4096 (order: 12, 32768 bytes)
Dentry cache hash table entries: 8388608 (order: 14, 67108864 bytes)
Inode-cache hash table entries: 4194304 (order: 13, 33554432 bytes)
Memory: 57567828k/58589184k available (2850k kernel code, 1019292k
reserved, 1413k data, 164k init)
virtual kernel memory layout:
    vmalloc : 0x0000000000008000 - 0x000000003f000000   (1007 MB)
    memory  : 0x0000000040000000 - 0x0000000e38000000   (57216 MB)
      .init : 0x00000000405cc000 - 0x00000000405f5000   ( 164 kB)
      .data : 0x00000000403c8828 - 0x000000004052a000   (1413 kB)
      .text : 0x0000000040100000 - 0x00000000403c8828   (2850 kB)
Calibrating delay loop... 1495.04 BogoMIPS (lpj=2990080)
Security Framework initialized
Mount-cache hash table entries: 256
net_namespace: 544 bytes
NET: Registered protocol family 16
Searching for devices...
Two devices have hardware path [255].  IODC data for second device:
00404e0000abRearranging GSC cards sometimes helps
Two devices have hardware path [255].  IODC data for second device:
00404e0000abRearranging GSC cards sometimes helps
Found devices:
1. Caribe DNA Central Agent at 0xfffffffffc000000 [255] { 14, 0x0,
0x007, 0x000aa }
2. Caribe W2 800 at 0xfffffffffc078000 [10] { 0, 0x0, 0x5e7, 0x00004 }
3. Caribe W2 800 at 0xfffffffffc07a000 [11] { 0, 0x0, 0x5e7, 0x00004 }
4. Caribe W2 800 at 0xfffffffffc07c000 [12] { 0, 0x0, 0x5e7, 0x00004 }
5. Caribe W2 800 at 0xfffffffffc07e000 [13] { 0, 0x0, 0x5e7, 0x00004 }
6. Memory at 0xfffffffffc005000 [5] { 1, 0x0, 0x0a8, 0x00009 }
7. REO I/O BC Merced Port at 0xfffffff808000000 [0] { 7, 0x0, 0x804,
0x0000c }
8. Elroy PCI Bridge at 0xfffffff804000000 [0/0] { 13, 0x0, 0x782,
0x0000a }
9. Elroy PCI Bridge at 0xfffffff804002000 [0/1] { 13, 0x0, 0x782,
0x0000a }
10. Elroy PCI Bridge at 0xfffffff804004000 [0/2] { 13, 0x0, 0x782,
0x0000a }
11. Elroy PCI Bridge at 0xfffffff804006000 [0/3] { 13, 0x0, 0x782,
0x0000a }
12. Elroy PCI Bridge at 0xfffffff804008000 [0/4] { 13, 0x0, 0x782,
0x0000a }
13. Elroy PCI Bridge at 0xfffffff80400c000 [0/6] { 13, 0x0, 0x782,
0x0000a }
14. Elroy PCI Bridge at 0xfffffff804010000 [0/8] { 13, 0x0, 0x782,
0x0000a }
15. Elroy PCI Bridge at 0xfffffff804012000 [0/9] { 13, 0x0, 0x782,
0x0000a }
16. Elroy PCI Bridge at 0xfffffff804014000 [0/10] { 13, 0x0, 0x782,
0x0000a }
17. Elroy PCI Bridge at 0xfffffff804016000 [0/11] { 13, 0x0, 0x782,
0x0000a }
18. Elroy PCI Bridge at 0xfffffff804018000 [0/12] { 13, 0x0, 0x782,
0x0000a }
19. Elroy PCI Bridge at 0xfffffff80401c000 [0/14] { 13, 0x0, 0x782,
0x0000a }
CONFIG_SMP=n  ignoring additional CPUs
CPU: probe of 11 failed with error 1
CONFIG_SMP=n  ignoring additional CPUs
CPU: probe of 12 failed with error 1
CONFIG_SMP=n  ignoring additional CPUs
CPU: probe of 13 failed with error 1
CPU(s): 1 x PA8700 (PCX-W2) at 750.000000 MHz
Setting cache flush threshold to 180000 (1 CPUs online)
iosapic_init()
calling get_irt_size (cell 0)
get_irt_size: 0
pdc_pat_get_irt: 0
iosapic Interrupt Routing Table (cell 0)
iosapic start = 0x000000083fc8c800 num_entries 46 entry_size 16
iosapic 8b 10 00 0f 00 00 00 00 fffffff804000800
iosapic 8b 10 00 0f 04 00 00 00 fffffff804000800
iosapic 8b 10 00 0f 00 08 00 00 fffffff804002800
iosapic 8b 10 00 0f 01 08 00 01 fffffff804002800
iosapic 8b 10 00 0f 02 08 00 02 fffffff804002800
iosapic 8b 10 00 0f 03 08 00 03 fffffff804002800
iosapic 8b 10 00 0f 00 10 00 00 fffffff804004800
iosapic 8b 10 00 0f 01 10 00 01 fffffff804004800
iosapic 8b 10 00 0f 02 10 00 02 fffffff804004800
iosapic 8b 10 00 0f 03 10 00 03 fffffff804004800
iosapic 8b 10 00 0f 00 18 00 00 fffffff804006800
iosapic 8b 10 00 0f 01 18 00 01 fffffff804006800
iosapic 8b 10 00 0f 02 18 00 02 fffffff804006800
iosapic 8b 10 00 0f 03 18 00 03 fffffff804006800
iosapic 8b 10 00 0f 00 20 00 00 fffffff804008800
iosapic 8b 10 00 0f 01 20 00 01 fffffff804008800
iosapic 8b 10 00 0f 02 20 00 02 fffffff804008800
iosapic 8b 10 00 0f 03 20 00 03 fffffff804008800
iosapic 8b 10 00 0f 00 30 00 00 fffffff80400c800
iosapic 8b 10 00 0f 01 30 00 01 fffffff80400c800
iosapic 8b 10 00 0f 02 30 00 02 fffffff80400c800
iosapic 8b 10 00 0f 03 30 00 03 fffffff80400c800
iosapic 8b 10 00 0f 00 40 00 00 fffffff804010800
iosapic 8b 10 00 0f 01 40 00 01 fffffff804010800
iosapic 8b 10 00 0f 02 40 00 02 fffffff804010800
iosapic 8b 10 00 0f 03 40 00 03 fffffff804010800
iosapic 8b 10 00 0f 00 48 00 00 fffffff804012800
iosapic 8b 10 00 0f 01 48 00 01 fffffff804012800
iosapic 8b 10 00 0f 02 48 00 02 fffffff804012800
iosapic 8b 10 00 0f 03 48 00 03 fffffff804012800
iosapic 8b 10 00 0f 00 50 00 00 fffffff804014800
iosapic 8b 10 00 0f 01 50 00 01 fffffff804014800
iosapic 8b 10 00 0f 02 50 00 02 fffffff804014800
iosapic 8b 10 00 0f 03 50 00 03 fffffff804014800
iosapic 8b 10 00 0f 00 58 00 00 fffffff804016800
iosapic 8b 10 00 0f 01 58 00 01 fffffff804016800
iosapic 8b 10 00 0f 02 58 00 02 fffffff804016800
iosapic 8b 10 00 0f 03 58 00 03 fffffff804016800
iosapic 8b 10 00 0f 00 60 00 00 fffffff804018800
iosapic 8b 10 00 0f 01 60 00 01 fffffff804018800
iosapic 8b 10 00 0f 02 60 00 02 fffffff804018800
iosapic 8b 10 00 0f 03 60 00 03 fffffff804018800
iosapic 8b 10 00 0f 00 70 00 00 fffffff80401c800
iosapic 8b 10 00 0f 01 70 00 01 fffffff80401c800
iosapic 8b 10 00 0f 02 70 00 02 fffffff80401c800
iosapic 8b 10 00 0f 03 70 00 03 fffffff80401c800
SBA found REO rev 2 at 0xfffffff808000000
Elroy version TR4.0 (0x5) found at 0xfffffff804000000
Backtrace:
 [<00000000402b406c>] lba_fixup_bus+0x36c/0x3d8
 [<00000000401208dc>] pcibios_fixup_bus+0x2c/0x50
 [<000000004010d45c>] pci_scan_child_bus+0x64/0xf0
 [<000000004010d518>] pci_scan_bus_parented+0x30/0x48
 [<00000000405e1f50>] lba_driver_probe+0x950/0xa40
 [<00000000405e1f50>] lba_driver_probe+0x950/0xa40
 [<00000000405e1f50>] lba_driver_probe+0x950/0xa40
 [<00000000405e1f50>] lba_driver_probe+0x950/0xa40
 [<00000000405e1f50>] lba_driver_probe+0x950/0xa40
 [<00000000405e1f50>] lba_driver_probe+0x950/0xa40
 [<00000000405e1f50>] lba_driver_probe+0x950/0xa40
 [<00000000405e1f50>] lba_driver_probe+0x950/0xa40
 [<00000000405e1f50>] lba_driver_probe+0x950/0xa40
 [<00000000405e1f50>] lba_driver_probe+0x950/0xa40
 [<00000000405e1f50>] lba_driver_probe+0x950/0xa40
 [<00000000405e1f50>] lba_driver_probe+0x950/0xa40


Kernel Fault: Code=26 regs=000000083fc42cf0 (Addr=0000000000000028)

     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00001000000001001111111100001111 Not tainted
r00-03  000000ff0804ff0f 00000000405c7f00 00000000402b154c
000000083fc1b188
r04-07  00000000405b9700 000000083fc1c400 000000083fc1b000
0000000000000007
r08-11  000000083fc8c028 000000083fc088c0 0000000000000000
000000083fc1c558
r12-15  000000083fc1c568 000000083fc1c578 0000000040510f10
000000083fc1c548
r16-19  000000083fc1c490 00000000405bcf00 000000083fc1c4c8
0000000000000000
r20-23  0000000000044048 0000000000000040 0000000000000003
0000000000000001
r24-27  0000000000000000 0000000000000010 00000000405606f4
00000000405b9700
r28-31  0000000000000000 000000083fc1c400 000000083fc42cf0
0000000000000001
sr00-03  0000000000000000 0000000000000000 0000000000000000
0000000000000000
sr04-07  0000000000000000 0000000000000000 0000000000000000
0000000000000000

IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000402b155c
00000000402b1560
 IIR: 53990050    ISR: 0000000000000000  IOR: 0000000000000028
 CPU:        0   CR30: 000000083fc40000 CR31: f7fc7fe9ffe3ffe7
 ORIG_R28: 000000004013d598
 IAOQ[0]: iosapic_fixup_irq+0xd4/0x448
 IAOQ[1]: iosapic_fixup_irq+0xd8/0x448
 RP(r2): iosapic_fixup_irq+0xc4/0x448
Backtrace:
 [<00000000402b406c>] lba_fixup_bus+0x36c/0x3d8
 [<00000000401208dc>] pcibios_fixup_bus+0x2c/0x50
 [<000000004010d45c>] pci_scan_child_bus+0x64/0xf0
 [<000000004010d518>] pci_scan_bus_parented+0x30/0x48
 [<00000000405e1f50>] lba_driver_probe+0x950/0xa40
 [<00000000405e1f50>] lba_driver_probe+0x950/0xa40
 [<00000000405e1f50>] lba_driver_probe+0x950/0xa40
 [<00000000405e1f50>] lba_driver_probe+0x950/0xa40
 [<00000000405e1f50>] lba_driver_probe+0x950/0xa40
 [<00000000405e1f50>] lba_driver_probe+0x950/0xa40
 [<00000000405e1f50>] lba_driver_probe+0x950/0xa40
 [<00000000405e1f50>] lba_driver_probe+0x950/0xa40
 [<00000000405e1f50>] lba_driver_probe+0x950/0xa40
 [<00000000405e1f50>] lba_driver_probe+0x950/0xa40
 [<00000000405e1f50>] lba_driver_probe+0x950/0xa40
 [<00000000405e1f50>] lba_driver_probe+0x950/0xa40

Kernel panic - not syncing: Kernel Fault


4 CPU partition (one CPU is faulty and disabled):

Linux version 2.6.29-rc3-00000-g33bfad5-dirty (tsbogend@login) (gcc
version 4.2.1) #59 Fri Feb 13 21:31:17 CET 2009
unwind_init: start = 0x404718c0, end = 0x4049da80, entries = 11292
WARNING: Out of order unwind entry! 00000000404733d0 and
00000000404733e0
WARNING: Out of order unwind entry! 00000000404733e0 and
00000000404733f0
FP[0] enabled: Rev 1 Model 19
The 64-bit Kernel has started...
console [ttyB0] enabled
Initialized PDC Console for debugging.
Determining PDC firmware type: 64 bit PAT.
model 00005e70 00000491 00000000 00000002 3e0f97abec371bc2 00000000
00000008 000000b2 000000b2
vers  00000202
CPUID vers 19 rev 1 (0x00000261)
capabilities 0x3d
model 9000/800/SD32000
parisc_cache_init: Only equivalent aliasing supported!
Total Memory: 8184 MB
Built 1 zonelists in Zone order, mobility grouping on.  Total pages:
2066460
Kernel command line: HOME=/ ip=dhcp console=ttyS0 TERM=vt102
palo_kernel=0/vmlinux
PID hash table entries: 4096 (order: 12, 32768 bytes)
Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
Memory: 8231424k/8380416k available (2850k kernel code, 148464k
reserved, 1413k data, 164k init)
virtual kernel memory layout:
    vmalloc : 0x0000000000008000 - 0x000000003f000000   (1007 MB)
    memory  : 0x0000000040000000 - 0x000000023f800000   (8184 MB)
      .init : 0x00000000405cc000 - 0x00000000405f5000   ( 164 kB)
      .data : 0x00000000403c8828 - 0x000000004052a000   (1413 kB)
      .text : 0x0000000040100000 - 0x00000000403c8828   (2850 kB)
Calibrating delay loop... 1495.04 BogoMIPS (lpj=2990080)
Security Framework initialized
Mount-cache hash table entries: 256
net_namespace: 544 bytes
NET: Registered protocol family 16
Searching for devices...
Two devices have hardware path [255].  IODC data for second device:
00404e0000abRearranging GSC cards sometimes helps
Two devices have hardware path [255].  IODC data for second device:
00404e0000abRearranging GSC cards sometimes helps
Found devices:
1. Caribe DNA Central Agent at 0xfffffffffc400000 [255] { 14, 0x0,
0x007, 0x000aa }
2. Caribe W2 800 at 0xfffffffffc47a000 [11] { 0, 0x0, 0x5e7, 0x00004 }
3. Caribe W2 800 at 0xfffffffffc47c000 [12] { 0, 0x0, 0x5e7, 0x00004 }
4. Caribe W2 800 at 0xfffffffffc47e000 [13] { 0, 0x0, 0x5e7, 0x00004 }
5. Memory at 0xfffffffffc405000 [5] { 1, 0x0, 0x0a8, 0x00009 }
6. REO I/O BC Merced Port at 0xfffffff888000000 [0] { 7, 0x0, 0x804,
0x0000c }
7. Elroy PCI Bridge at 0xfffffff884000000 [0/0] { 13, 0x0, 0x782,
0x0000a }
8. Elroy PCI Bridge at 0xfffffff884002000 [0/1] { 13, 0x0, 0x782,
0x0000a }
9. Elroy PCI Bridge at 0xfffffff884004000 [0/2] { 13, 0x0, 0x782,
0x0000a }
10. Elroy PCI Bridge at 0xfffffff884006000 [0/3] { 13, 0x0, 0x782,
0x0000a }
11. Elroy PCI Bridge at 0xfffffff884008000 [0/4] { 13, 0x0, 0x782,
0x0000a }
12. Elroy PCI Bridge at 0xfffffff88400c000 [0/6] { 13, 0x0, 0x782,
0x0000a }
13. Elroy PCI Bridge at 0xfffffff884010000 [0/8] { 13, 0x0, 0x782,
0x0000a }
14. Elroy PCI Bridge at 0xfffffff884012000 [0/9] { 13, 0x0, 0x782,
0x0000a }
15. Elroy PCI Bridge at 0xfffffff884014000 [0/10] { 13, 0x0, 0x782,
0x0000a }
16. Elroy PCI Bridge at 0xfffffff884016000 [0/11] { 13, 0x0, 0x782,
0x0000a }
17. Elroy PCI Bridge at 0xfffffff884018000 [0/12] { 13, 0x0, 0x782,
0x0000a }
18. Elroy PCI Bridge at 0xfffffff88401c000 [0/14] { 13, 0x0, 0x782,
0x0000a }
CONFIG_SMP=n  ignoring additional CPUs
CPU: probe of 12 failed with error 1
CONFIG_SMP=n  ignoring additional CPUs
CPU: probe of 13 failed with error 1
CPU(s): 1 x PA8700 (PCX-W2) at 750.000000 MHz
Setting cache flush threshold to 180000 (1 CPUs online)
iosapic_init()
calling get_irt_size (cell 4)
get_irt_size: 0
pdc_pat_get_irt: 0
iosapic Interrupt Routing Table (cell 4)
iosapic start = 0x000000023f090c00 num_entries 46 entry_size 16
iosapic 8b 10 00 0f 00 00 04 00 fffffff884000800
iosapic 8b 10 00 0f 04 00 04 00 fffffff884000800
iosapic 8b 10 00 0f 00 08 04 00 fffffff884002800
iosapic 8b 10 00 0f 01 08 04 01 fffffff884002800
iosapic 8b 10 00 0f 02 08 04 02 fffffff884002800
iosapic 8b 10 00 0f 03 08 04 03 fffffff884002800
iosapic 8b 10 00 0f 00 10 04 00 fffffff884004800
iosapic 8b 10 00 0f 01 10 04 01 fffffff884004800
iosapic 8b 10 00 0f 02 10 04 02 fffffff884004800
iosapic 8b 10 00 0f 03 10 04 03 fffffff884004800
iosapic 8b 10 00 0f 00 18 04 00 fffffff884006800
iosapic 8b 10 00 0f 01 18 04 01 fffffff884006800
iosapic 8b 10 00 0f 02 18 04 02 fffffff884006800
iosapic 8b 10 00 0f 03 18 04 03 fffffff884006800
iosapic 8b 10 00 0f 00 20 04 00 fffffff884008800
iosapic 8b 10 00 0f 01 20 04 01 fffffff884

ser pim:

HPMC Information

  HPMC Chassis Codes:      Extension:
  ------------------       -----------------
  0xb80008000000620f       0x0000000000000000
  0xb80008000000621c       0x0000000000000000
  0xb800082011016c2c       0x0000000000000000
  0xb80008000000626c       0x0000000000000000
  0x180008000000633c       0x0000000000000000
  0xb80008000000624c       0x00000000000000ea
  0xb8000800000062fc       0x00000000000000eb
  0xb8000800000062fc       0x00000000000000ec


Timestamp = 02:27:05 GMT    Feb 14 2009

General Registers 0 - 31
00-03  0000000000000000  0000000000000000  00000081ff8a9cb0
00000081ffc40000
04-07  00000081ffc40330  00000081ffc407b0  00000081ffc407b0
00000081ffc40680
08-11  000000023f022a20  0000000000000040  0000000000000002
00000000005412c0
12-15  00ffff04ffffff94  0000000000000008  0000000000000001
000000000053f1c0
16-19  603c9b9103f774b0  00000081ffc407b8  603c9b9103f774b0
603c9b9103f774b0
20-23  000000000053f1c0  0000000000000001  0000000000000008
00ffff04ffffff94
24-27  00000000005412c0  0000000000000002  0000000000000040
00000081ff9d76f0
28-31  00000081ffc40000  0000000000541810  00000000005417d0
00000081ffc40690

Control Registers 0 - 31
00-03  0000000000000000  0000000000000000  0000000000000000
0000000000000000
04-07  0000000000000000  0000000000000000  0000000000000000
0000000000000000
08-11  0000000000000000  0000000000000000  00000000000000c0
0000000000000031
12-15  0000000000000000  0000000000000000  0000000000103000
8000000000000000
16-19  00000020f70a0b02  0000000000000081  00000081ff8a9d64
000000000e6010df
20-23  000000000436440f  40000000ddf774b0  0000000008000108
8000000000000000
24-27  000000000052c000  000000000052c000  13f8e363a2f7c22b
13f8e343a2f7c22b
28-31  13f8e363a2f7c22b  9358f363a2b78323  000000023f020000
93b8f363a2b5c32b

Space Registers 0 - 7
00-03  0000000000000000  0000000000000000  0000000000000000
0000000000000000
04-07  0000000000000000  0000000000000000  0000000000000000
0000000000000000

Floating Point Registers 0 - 32
00-03  3b530fb761871637  f8be7beddfd0c244  d33fe1b257d77169
9944bc7fcf9b9221
04-07  1d906672bdc4223c  706fa77cab85706c  39fc0b5cdecc65cc
f467c37df74ee338
08-11  58e5a620d50cc070  b3f94d7ed58db410  d8948e47b7d0520a
fa0d021e579d246e
12-15  b8efd63f36764318  d17f0642fd85bc68  96ad979ebfd0640c
9edd22a7bf87a038
16-19  bbb5f63b0b84602b  63be400edfc16009  ba3c061dbed926f0
3c3596fff61c520c
20-23  1a2547ef7b460028  f859cd6e93a14a60  000000000000006f
00000000000000de
24-27  0000000000000000  ffcf1b1f5994e41c  db24613fc40c04e8
9a55837ebb4070ec
28-31  5ecd789fcacc7244  0000000200c08110  1a30a004d78a36ac
0000800010000000

IIA Space                    = 0x0000000000000081
IIA Offset                   = 0x00000081ff8a9d68
Check Type                   = 0x0000000020000000
CPU State                    = 0x000000009e000004
Cache Check                  = 0x0000000000000000
TLB Check                    = 0x0000000000000000
Bus Check                    = 0x000000000030000d
Assists Check                = 0x0000000000000000
Assist State                 = 0x0000000000000000
Path Info                    = 0x0000000000000000
System Responder Address     = 0xfffffffffc47a000
System Requestor Address     = 0x0000000000000000
Summary                      = 0xcb83000000000000
Available Memory             = 0x00000001ff800000
CPU DR2                      = 0x020211a10c002004
CPU Status 0                 = 0x3240c30000000000
CPU Status 1                 = 0x8000000000000000
CPU S Address Log            = 0x483ffffffffc0000
CPU RS Log                   = 0xc1bff0ffff417238
Time Stamp                   = 0x2009021400022705
System Firmware Revision     = 0x00000ac600002401
PDC Relocation Address       = 0x00000081ff800000


Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea.                                                [ RFC1925, 2.3 ]

Re: Hacking SuperDome

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1138 bytes --]

On Sat, 2009-02-07 15:29:06 +0100, Thomas Bogendoerfer <tsbogend@alpha.franken.de> wrote:
> Linux version 2.6.29-rc3-00000-g33bfad5-dirty (tsbogend@login) (gcc
[...]
> sym53c8xx 0000:18:00.0: enabling device (0146 -> 0147)
> sym0: <895> rev 0x2 at pci 0000:18:00.0 irq 67
> sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking
> sym0: SCSI BUS has been reset.
> scsi0 : sym-2.2.3
> scsi 0:0:0:0: ABORT operation started
> scsi 0:0:0:0: ABORT operation timed-out.
> scsi 0:0:0:0: DEVICE RESET operation started
> 
> After that it hangs...
> The smaller partion hangs even earlier:

Just to name it (even though it might be a general interrupt problem),
IIRC there just was some email on LKML that some other guy had about the
same sym2 hangs in more conventional ix86 hardware...

So for a test, you might want to replace sym2 with one that's a bit
older...

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
Signature of:              What we do for ourselves dies with us. What we do for
the second  :         others and the world remains and is immortal. (Albert Pine)

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]