Call trace stops at static callback functions

Call trace stops at static callback functions

[Hauke Mehrtens]

Hi,

When I add a WARN_ON(1) to trigger a backtrace into the static callback
function veth_newlink() in drivers/net/veth.c the backtrace stops at
this functions. When I remove the static from this function the
backtrace is looking like expected.

Call trace with static function:
[   30.686208] Call Trace:
[   30.686583] [<8010ca98>] show_stack+0x90/0x138
[   30.686953] [<8066ae80>] dump_stack+0x94/0xcc
[   30.687122] [<801307cc>] __warn+0x130/0x144
[   30.687293] [<80130898>] warn_slowpath_null+0x44/0x58
[   30.687545] [<c0023800>] 0xc0023800
[   30.687959] ---[ end trace df91e2ca103d67ec ]---

Call trace without static:
[   26.519328] Call Trace:
[   26.519648] [<8010ca98>] show_stack+0x90/0x138
[   26.520067] [<8066ae80>] dump_stack+0x94/0xcc
[   26.520282] [<801307cc>] __warn+0x130/0x144
[   26.520466] [<80130898>] warn_slowpath_null+0x44/0x58
[   26.520773] [<c0023800>] veth_newlink+0x64/0x1464 [veth]
[   26.521041] [<80541628>] __rtnl_newlink+0x5c8/0x790
[   26.521259] [<80541840>] rtnl_newlink+0x50/0x84
[   26.521456] [<8053b430>] rtnetlink_rcv_msg+0x340/0x3ec
[   26.521697] [<80571ba4>] netlink_rcv_skb+0xa0/0x150
[   26.521908] [<805712d8>] netlink_unicast+0x1c4/0x2b0
[   26.522121] [<805716ac>] netlink_sendmsg+0x2e8/0x3f8
[   26.522336] [<804fcf6c>] ___sys_sendmsg+0x144/0x2ac
[   26.522546] [<804fe22c>] __sys_sendmsg+0x4c/0x94
[   26.522748] [<80114a98>] syscall_common+0x34/0x58
[   26.523214] ---[ end trace 9a18b9fb2030ab29 ]---

This was done with kernel 5.2-rc5 build with OpenWrt (GCC 7.4) for Malta
24Kc big endian, the kernel did not contain any extra OpenWrt patches,
only the WARN_ON(1) was added to trigger this call trace.

Is it excepted that the call trace stops at such positions? It would be
really nice if it would go further to better interpret such call traces.

I used this command to call this function:
	ip link add veth0 type veth peer name veth1

I also saw this with kernel 4.9.

Hauke

SGI-IP30

[Carlo Pisani]

hi guys
I am new on this mailing list, is there anyone on SGI-IP30?
I am with kernel 4.18, there are a few quirks ... with the SMP

=)

Re: SGI-IP30

[Paul Burton]

Hi Carlo,

On Sat, Jun 22, 2019 at 02:42:05PM +0200, Carlo Pisani wrote:
> hi guys
> I am new on this mailing list, is there anyone on SGI-IP30?
> I am with kernel 4.18, there are a few quirks ... with the SMP
> 
> =)

Since we don't have IP30 support upstream I presume you must be getting
your kernel source from somewhere else?

I'm afraid I don't have access to any of these old SGI systems myself,
but your best chances are probably:

- Thomas Bodendoerfer who's recently done some work refactoring IP27
  code in an effort to also support IP30 & other systems.

- Maciej W. Rozycki who seems to have an affinity for MIPS machines from
  this era, or at least plenty of knowledge about them :)

- Joshua Kinard who had SMP issues with IP30 over here:
  https://lore.kernel.org/linux-mips/5457187D.6030708@gentoo.org/T/#u
  That was 5 years ago though, so may be a long shot!

Thanks,
    Paul

Re: Call trace stops at static callback functions

[Paul Burton]

Hi Hauke,

On Sat, Jun 22, 2019 at 02:40:26PM +0200, Hauke Mehrtens wrote:
> When I add a WARN_ON(1) to trigger a backtrace into the static callback
> function veth_newlink() in drivers/net/veth.c the backtrace stops at
> this functions. When I remove the static from this function the
> backtrace is looking like expected.
> 
> Call trace with static function:
> [   30.686208] Call Trace:
> [   30.686583] [<8010ca98>] show_stack+0x90/0x138
> [   30.686953] [<8066ae80>] dump_stack+0x94/0xcc
> [   30.687122] [<801307cc>] __warn+0x130/0x144
> [   30.687293] [<80130898>] warn_slowpath_null+0x44/0x58
> [   30.687545] [<c0023800>] 0xc0023800
> [   30.687959] ---[ end trace df91e2ca103d67ec ]---
> 
> Call trace without static:
> [   26.519328] Call Trace:
> [   26.519648] [<8010ca98>] show_stack+0x90/0x138
> [   26.520067] [<8066ae80>] dump_stack+0x94/0xcc
> [   26.520282] [<801307cc>] __warn+0x130/0x144
> [   26.520466] [<80130898>] warn_slowpath_null+0x44/0x58
> [   26.520773] [<c0023800>] veth_newlink+0x64/0x1464 [veth]
> [   26.521041] [<80541628>] __rtnl_newlink+0x5c8/0x790
> [   26.521259] [<80541840>] rtnl_newlink+0x50/0x84
> [   26.521456] [<8053b430>] rtnetlink_rcv_msg+0x340/0x3ec
> [   26.521697] [<80571ba4>] netlink_rcv_skb+0xa0/0x150
> [   26.521908] [<805712d8>] netlink_unicast+0x1c4/0x2b0
> [   26.522121] [<805716ac>] netlink_sendmsg+0x2e8/0x3f8
> [   26.522336] [<804fcf6c>] ___sys_sendmsg+0x144/0x2ac
> [   26.522546] [<804fe22c>] __sys_sendmsg+0x4c/0x94
> [   26.522748] [<80114a98>] syscall_common+0x34/0x58
> [   26.523214] ---[ end trace 9a18b9fb2030ab29 ]---
> 
> This was done with kernel 5.2-rc5 build with OpenWrt (GCC 7.4) for Malta
> 24Kc big endian, the kernel did not contain any extra OpenWrt patches,
> only the WARN_ON(1) was added to trigger this call trace.
> 
> Is it excepted that the call trace stops at such positions? It would be
> really nice if it would go further to better interpret such call traces.

It's not ideal or intentional, no...

It would be interesting to see the disassembly for veth_newlink in both
cases - I wouldn't expect anything to change since the function isn't
called directly so shouldn't get inlined or anything, but it'd be good
to check. If something did change this could be a bug or limitation of
our stack unwinding code (see get_frame_info) which works by examining
code, looking for store instructions that save ra/$31 to the stack &
additions to sp/$29.

Could you also share your .config? I presume CONFIG_KALLSYMS is enabled?

If you look at vmlinux using nm or readelf -s do you see the
veth_newlink symbol?

Thanks,
    Paul

> I used this command to call this function:
> 	ip link add veth0 type veth peer name veth1
> 
> I also saw this with kernel 4.9.
> 
> Hauke

Re: SGI-IP30

[Maciej W. Rozycki]

On Mon, 24 Jun 2019, Paul Burton wrote:

> - Maciej W. Rozycki who seems to have an affinity for MIPS machines from
>   this era, or at least plenty of knowledge about them :)

 Thanks for your words of appreciation, however I have own no actual SGI 
system, so any my advice related to such hardware will be limited to the 
CPU only.  This may not help with a port moving forward.

  Maciej

Re: SGI-IP30

[Thomas Bogendoerfer]

On Mon, 24 Jun 2019 17:55:55 +0000
Paul Burton <paul.burton@mips.com> wrote:

> On Sat, Jun 22, 2019 at 02:42:05PM +0200, Carlo Pisani wrote:
> > hi guys
> > I am new on this mailing list, is there anyone on SGI-IP30?
> > I am with kernel 4.18, there are a few quirks ... with the SMP
> > 
> > =)
> 
> Since we don't have IP30 support upstream I presume you must be getting
> your kernel source from somewhere else?
> 
> I'm afraid I don't have access to any of these old SGI systems myself,
> but your best chances are probably:
> 
> - Thomas Bodendoerfer who's recently done some work refactoring IP27
>   code in an effort to also support IP30 & other systems.

I have a patchset ready for IP30 support, but I'm waiting for two other patchsets,
which need to get merged first :-( This is

https://marc.info/?l=linux-kernel&m=155929848918599&w=2
https://marc.info/?l=linux-kernel&m=155929849418602&w=2

and

https://marc.info/?l=linux-kernel&m=156044570923085&w=2

If wanted I can post the IP30 patchset for review and testing.

Thomas.

-- 
SUSE Linux GmbH
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)

Re: SGI-IP30

[Joshua Kinard]

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

On 6/24/2019 13:55, Paul Burton wrote:
> Hi Carlo,
> 
> On Sat, Jun 22, 2019 at 02:42:05PM +0200, Carlo Pisani wrote:
>> hi guys
>> I am new on this mailing list, is there anyone on SGI-IP30?
>> I am with kernel 4.18, there are a few quirks ... with the SMP
>>
>> =)
> 
> Since we don't have IP30 support upstream I presume you must be getting
> your kernel source from somewhere else?
> 
> I'm afraid I don't have access to any of these old SGI systems myself,
> but your best chances are probably:
> 
> - Thomas Bodendoerfer who's recently done some work refactoring IP27
>   code in an effort to also support IP30 & other systems.
> 
> - Maciej W. Rozycki who seems to have an affinity for MIPS machines from
>   this era, or at least plenty of knowledge about them :)
> 
> - Joshua Kinard who had SMP issues with IP30 over here:
>   https://lore.kernel.org/linux-mips/5457187D.6030708@gentoo.org/T/#u
>   That was 5 years ago though, so may be a long shot!
> 
> Thanks,
>     Paul


SMP works fine, on my machine at least.  I got it working back in 4.4 a few
years ago, and it's largely just worked fine since then on the one machine I
have.

See attached dmesg.  Below is the output of cat /proc/cpuinfo and cat
/proc/interrupts

# cat /proc/cpuinfo
system type             : SGI Octane
machine                 : Unknown
processor               : 0
cpu model               : R14000 V2.4  FPU V0.0
BogoMIPS                : 898.66
byteorder               : big endian
wait instruction        : no
microsecond timers      : yes
tlb_entries             : 64
extra interrupt vector  : no
hardware watchpoint     : yes, count: 0, address/irw mask: []
isa                     : mips1 mips2 mips3 mips4
ASEs implemented        :
shadow register sets    : 1
kscratch registers      : 0
package                 : 0
core                    : 0
VCED exceptions         : not available
VCEI exceptions         : not available

processor               : 1
cpu model               : R14000 V2.4  FPU V0.0
BogoMIPS                : 898.66
byteorder               : big endian
wait instruction        : no
microsecond timers      : yes
tlb_entries             : 64
extra interrupt vector  : no
hardware watchpoint     : yes, count: 0, address/irw mask: []
isa                     : mips1 mips2 mips3 mips4
ASEs implemented        :
shadow register sets    : 1
kscratch registers      : 0
package                 : 0
core                    : 0
VCED exceptions         : not available
VCEI exceptions         : not available

# cat /proc/interrupts
           CPU0       CPU1
  0:      21151          0     HEART      qla1280
  1:      16904          0     HEART      qla1280
  2:         30          0     HEART      ioc3-eth
  3:        244          0     HEART      ioc3-io
  5:        433          0     HEART      acenic
 42:       3066          0     HEART      cpu0-rsch
 43:          0       4194     HEART      cpu1-rsch
 46:       1328          0     HEART      cpu0-call
 47:          0       3059     HEART      cpu1-call
 50:      31187          0     HEART      heart_timer
 71:         12      25426  MIPS_R10K      timer
ERR:          2

I poured over IRIX headers and even found Stan a few years back on Freenode,
and his recollection was that the CPU interrupts for SMP were not hardwired
to any specific function.  IRIX just chose to use 46-49 for symmon
debugging, and 42-45 for CPU IPI.  So I went with 42-45 for SMP reschedule
and 46-49 for SMP call_function in Linux.  Been working fine for the last
few years.  I even implemented similar logic in IP27's SMP code, so that its
IPI's could be tracked by Linux's IRQ subsystem (current IP27 code does
IPI's in a way that Linux can't track in /proc/interrupts)

I've been running 4.18.20 for the last few months.  4.19 is mostly synced up
to the patches I maintain in Gentoo, but the DMA changes that dropped have
caused some headaches that I haven't worked out yet.  5.0/5.1 is still a
ways off, but I assume will be easier than 4.19 until Thomas' IP27 changes
drop in 5.2.  No timeframe when I'll be able to catch up due to being
swamped with work.

My Octane is probably the most stable non-x86 platform I've got.  Ran it for
almost ~2 months straight for compiling Gentoo's install stages before a
thunderstorm knocked the power out, ending that uptime run.  So I can vouch
that the code should work.  I can't test all combinations of Octane's
hardware, but the base hardware I have will boot Linux and is quite usable.
 There are many known issues w/ PCI, some of which I hope Thomas' patches
will address that I can build my patches off of again.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

[-- Attachment #2: ip30-dmesg-20190626.txt --]
[-- Type: text/plain, Size: 23624 bytes --]

[    0.000000] Linux version 4.18.20-mipsgit-20181112 (root@helcaraxe) (gcc version 9.1.0 (Gentoo 9.1.0 p1.0)) #4 SMP Mon May 13 03:59:58 EDT 2019
[    0.000000] ARCH: SGI-IP30
[    0.000000] PROMLIB: ARC firmware Version 64 Revision 0
[    0.000000] bootconsole [early_impact0] enabled
[    0.000000] CPU0 revision is: 00000f24 (R14000)
[    0.000000] FPU revision is: 00000900
[    0.000000] Checking for the multiply/shift bug... no.
[    0.000000] Checking for the daddiu bug... no.
[    0.000000] Detected 2048MB of physical memory.
[    0.000000] IP30: CPU0: 600 MHz CPU detected.
[    0.000000] Determined physical RAM map:
[    0.000000]  memory: 0000000000004000 @ 0000000000000000 (reserved)
[    0.000000]  memory: 0000000000acd000 @ 0000000020004000 (reserved)
[    0.000000]  memory: 000000000042f000 @ 0000000020ad1000 (usable)
[    0.000000]  memory: 0000000000100000 @ 0000000020f00000 (ROM data)
[    0.000000]  memory: 000000007f000000 @ 0000000021000000 (usable)
[    0.000000]  memory: 0000000000990000 @ 0000000020000000 (usable)
[    0.000000] cma: Reserved 128 MiB at 0x0000000098000000
[    0.000000] IP30: Slot: 0, PrID: 00000f24, PhyID: 0, VirtID: 0
[    0.000000] IP30: Slot: 1, PrID: 00000f24, PhyID: 1, VirtID: 1
[    0.000000] IP30: Detected 2 CPU(s) present.
[    0.000000] Primary instruction cache 32kB, VIPT, 2-way, linesize 64 bytes.
[    0.000000] Primary data cache 32kB, 2-way, VIPT, no aliases, linesize 32 bytes
[    0.000000] Unified secondary cache 2048kB 2-way, linesize 128 bytes.
[    0.000000] Zone ranges:
[    0.000000]   DMA32    [mem 0x0000000020000000-0x00000000ffffffff]
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000020000000-0x0000000020acffff]
[    0.000000]   node   0: [mem 0x0000000020ae0000-0x000000009fffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000020000000-0x000000009fffffff]
[    0.000000] On node 0 totalpages: 32767
[    0.000000]   DMA32 zone: 32 pages used for memmap
[    0.000000]   DMA32 zone: 0 pages reserved
[    0.000000]   DMA32 zone: 32767 pages, LIFO batch:1
[    0.000000] random: get_random_bytes called from start_kernel+0xdc/0x64c with crng_init=0
[    0.000000] percpu: Embedded 2 pages/cpu @(____ptrval____) s44832 r0 d86240 u131072
[    0.000000] pcpu-alloc: s44832 r0 d86240 u131072 alloc=2*65536
[    0.000000] pcpu-alloc: [0] 0 [0] 1
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 32735
[    0.000000] Kernel command line: root=xio(0)pci(15)scsi(0)disk(1)rdisk(0)partition(0) console=tty0 root=/dev/md0 consoleblank=0
[    0.000000] Dentry cache hash table entries: 262144 (order: 5, 2097152 bytes)
[    0.000000] Inode-cache hash table entries: 131072 (order: 4, 1048576 bytes)
[    0.000000] Memory: 1948352K/2097088K available (7338K kernel code, 735K rwdata, 1680K rodata, 384K init, 898K bss, 17664K reserved, 131072K cma-reserved)
[    0.000000] Hierarchical RCU implementation.
[    0.000000]  RCU dyntick-idle grace-period acceleration is enabled.
[    0.000000] NR_IRQS: 128
[    0.000000] IP30: HEART interrupt controller initialized.
[    0.000000]  Offload RCU callbacks from CPUs: (none).
[    0.000000] clocksource: HEART: mask: 0xfffffffffffff max_cycles: 0x2e2049cda, max_idle_ns: 440795202628 ns
[    0.000008] sched_clock: 52 bits at 12MHz, resolution 80ns, wraps every 4398046511080ns
[    0.000559] clocksource: MIPS: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 6369616738 ns
[    0.001095] sched_clock: 32 bits at 300MHz, resolution 3ns, wraps every 7156872702ns
[    0.002426] Console: colour dummy device 80x25
[    0.002784] console [tty0] enabled
[    0.003096] bootconsole [early_impact0] disabled
[    0.003482] Calibrating delay loop... 898.66 BogoMIPS (lpj=4493312)
[    0.090707] pid_max: default: 32768 minimum: 301
[    0.091568] Mount-cache hash table entries: 8192 (order: 0, 65536 bytes)
[    0.091758] Mountpoint-cache hash table entries: 8192 (order: 0, 65536 bytes)
[    0.093344] Checking for the daddi bug... no.
[    0.096295] Hierarchical SRCU implementation.
[    0.097808] smp: Bringing up secondary CPUs ...
[    5.879607] Primary instruction cache 32kB, VIPT, 2-way, linesize 64 bytes.
[    5.879623] Primary data cache 32kB, 2-way, VIPT, no aliases, linesize 32 bytes
[    5.879629] Unified secondary cache 2048kB 2-way, linesize 128 bytes.
[   14.264095] IP30: CPU1: 600 MHz CPU detected.
[   14.264146] CPU1 revision is: 00000f24 (R14000)
[   14.264150] FPU revision is: 00000900
[    0.230888] Synchronize counters for CPU 1: done.
[    0.231229] smp: Brought up 1 node, 2 CPUs
[    0.233037] devtmpfs: initialized
[    0.234195] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.234238] futex hash table entries: 512 (order: 0, 65536 bytes)
[    0.235269] xor: measuring software checksum speed
[    0.330923]    8regs     :   844.800 MB/sec
[    0.431032]    8regs_prefetch:   806.400 MB/sec
[    0.531121]    32regs    :   723.200 MB/sec
[    0.631219]    32regs_prefetch:   748.800 MB/sec
[    0.631253] xor: using function: 8regs (844.800 MB/sec)
[    0.632049] NET: Registered protocol family 16
[    0.641306] cpuidle: using governor menu
[    0.641486] xtalk:n0/f bridge widget (rev D) registered as a platform device.
[    0.641564] xtalk:n0/d bridge widget (rev C) registered as a platform device.
[    0.641642] xtalk:n0/c impact widget (rev B) registered as a platform device.
[    0.641721] xtalk:n0/8 heart widget (rev F) registered as a platform device.
[    0.703867] cryptd: max_cpu_qlen set to 1000
[    0.871683] raid6: int64x1  gen()   333 MB/s
[    1.041946] raid6: int64x1  xor()    82 MB/s
[    1.211958] raid6: int64x2  gen()   487 MB/s
[    1.371663] random: fast init done
[    1.382173] raid6: int64x2  xor()   164 MB/s
[    1.552455] raid6: int64x4  gen()   460 MB/s
[    1.722652] raid6: int64x4  xor()   171 MB/s
[    1.892775] raid6: int64x8  gen()   299 MB/s
[    2.063209] raid6: int64x8  xor()   129 MB/s
[    2.063241] raid6: using algorithm int64x2 gen() 487 MB/s
[    2.063269] raid6: .... xor() 164 MB/s, rmw enabled
[    2.063297] raid6: using intx1 recovery algorithm
[    2.063774] SCSI subsystem initialized
[    2.064751] Advanced Linux Sound Architecture Driver Initialized.
[    2.065551] clocksource: Switched to clocksource HEART
[    2.065850] FS-Cache: Loaded
[    2.066097] CacheFiles: Loaded
[    2.075037] NET: Registered protocol family 2
[    2.075720] tcp_listen_portaddr_hash hash table entries: 4096 (order: 0, 65536 bytes)
[    2.076023] TCP established hash table entries: 16384 (order: 1, 131072 bytes)
[    2.076625] TCP bind hash table entries: 16384 (order: 2, 262144 bytes)
[    2.077605] TCP: Hash tables configured (established 16384 bind 16384)
[    2.077861] UDP hash table entries: 2048 (order: 0, 65536 bytes)
[    2.078147] UDP-Lite hash table entries: 2048 (order: 0, 65536 bytes)
[    2.078624] NET: Registered protocol family 1
[    2.079804] RPC: Registered named UNIX socket transport module.
[    2.079839] RPC: Registered udp transport module.
[    2.079866] RPC: Registered tcp transport module.
[    2.079894] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    2.079933] PCI: CLS 0 bytes, default 128
[    2.081099] workingset: timestamp_bits=46 max_order=15 bucket_order=0
[    2.081243] zbud: loaded
[    2.082560] DLM installed
[    2.082673] FS-Cache: Netfs 'nfs' registered for caching
[    2.083225] NFS: Registering the id_resolver key type
[    2.083295] Key type id_resolver registered
[    2.083324] Key type id_legacy registered
[    2.083430] SGI XFS with ACLs, security attributes, realtime, no debug enabled
[    2.106459] NET: Registered protocol family 38
[    2.106946] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
[    2.107003] io scheduler noop registered
[    2.107032] io scheduler deadline registered (default)
[    2.107061] io scheduler mq-deadline registered (default)
[    2.145475] Console: switching to colour frame buffer device 160x64
[    2.177051] fb0: ImpactSR 1RSS frame buffer device
[    2.218447] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    2.236248] loop: module loaded
[    2.237068] mousedev: PS/2 mouse device common for all mice
[    2.238623] PCI host bridge to bus 0000:00
[    2.238814] pci_bus 0000:00: root bus resource [mem 0x1f200000-0x1f9fffff]
[    2.239091] pci_bus 0000:00: root bus resource [io  0x1fa00000-0x1fbfffff]
[    2.239367] pci_bus 0000:00: root bus resource [bus 00-ff]
[    2.239631] pci 0000:00:00.0: [1077:1020] type 00 class 0x010000
[    2.239693] pci 0000:00:00.0: reg 0x10: [io  0x200000-0x2000ff]
[    2.239718] pci 0000:00:00.0: reg 0x14: [mem 0x00200000-0x00200fff]
[    2.239800] pci 0000:00:00.0: reg 0x30: [mem 0x00210000-0x0021ffff pref]
[    2.240004] pci 0000:00:01.0: [1077:1020] type 00 class 0x010000
[    2.240049] pci 0000:00:01.0: reg 0x10: [io  0x400000-0x4000ff]
[    2.240073] pci 0000:00:01.0: reg 0x14: [mem 0x00400000-0x00400fff]
[    2.240155] pci 0000:00:01.0: reg 0x30: [mem 0x00410000-0x0041ffff pref]
[    2.240319] pci 0000:00:02.0: [10a9:0003] type 00 class 0xff0000
[    2.240369] pci 0000:00:02.0: reg 0x10: [mem 0x00500000-0x005fffff]
[    2.240614] pci 0000:00:03.0: [10a9:0005] type 00 class 0x000000
[    2.240656] pci 0000:00:03.0: reg 0x10: [mem 0x00600000-0x00601fff]
[    2.240994] pci 0000:00:02.0: BAR 0: assigned [mem 0x1f200000-0x1f2fffff]
[    2.241280] pci 0000:00:00.0: BAR 6: assigned [mem 0x1f300000-0x1f30ffff pref]
[    2.241570] pci 0000:00:01.0: BAR 6: assigned [mem 0x1f310000-0x1f31ffff pref]
[    2.241857] pci 0000:00:00.0: BAR 1: assigned [mem 0x1f320000-0x1f320fff]
[    2.242133] pci 0000:00:01.0: BAR 1: assigned [mem 0x1f321000-0x1f321fff]
[    2.242408] pci 0000:00:00.0: BAR 0: assigned [io  0x1fa00000-0x1fa000ff]
[    2.242684] pci 0000:00:01.0: BAR 0: assigned [io  0x1fa00400-0x1fa004ff]
[    2.243018] qla1280: QLA1040 found on PCI bus 0, dev 0
[    2.243240] ip30-bridge: 0000:00:00.0 Bar 0 with size 0x00000100 at bus 0x00000000 vma 0x000000f100000000 is Direct I/O.
[    2.243662] ip30-bridge: 0000:00:00.0 Bar 1 with size 0x00001000 at bus 0x00000000 vma 0x000000f080000000 is Direct 64-bit.
[    2.244094] ip30-bridge: 0000:00:00.0 Bar 6 with size 0x00010000 at bus 0x00010000 vma 0x000000f080010000 is Direct 64-bit.
[    2.244527] qla1280 0000:00:00.0: enabling device (0006 -> 0007)
[    2.245490] scsi(0): Enabling vchannel on BRIDGE for SGI/MIPS
[    2.662300] random: crng init done
[    2.820039] scsi(0:0): Resetting SCSI BUS
[    5.855694] scsi host0: QLogic QLA1040 PCI to SCSI Host Adapter
                      Firmware version:  7.65.06, Driver version 3.27.1
[    5.862361] qla1280: QLA1040 found on PCI bus 0, dev 1
[    5.862628] ip30-bridge: 0000:00:01.0 Bar 0 with size 0x00000100 at bus 0x00000100 vma 0x000000f100000100 is Direct I/O.
[    5.863110] ip30-bridge: 0000:00:01.0 Bar 1 with size 0x00001000 at bus 0x00020000 vma 0x000000f080020000 is Direct 64-bit.
[    5.863622] ip30-bridge: 0000:00:01.0 Bar 6 with size 0x00010000 at bus 0x00030000 vma 0x000000f080030000 is Direct 64-bit.
[    5.864140] qla1280 0000:00:01.0: enabling device (0006 -> 0007)
[    6.047211] scsi 0:0:1:0: Direct-Access     IBM-ESXS ST973401LC    FN B41D PQ: 0 ANSI: 4
[    6.048346] scsi(0:0:1:0):
[    6.048353]  Sync: period 10, offset 12
[    6.048479] , Wide
[    6.048642] , Tagged queuing: depth 31

[    6.096065] scsi 0:0:2:0: Direct-Access     IBM-ESXS ST973401LC    FN B41D PQ: 0 ANSI: 4
[    6.106075] scsi(0:0:2:0):
[    6.106082]  Sync: period 10, offset 12
[    6.115061] , Wide
[    6.124143] , Tagged queuing: depth 31

[    6.169359] scsi 0:0:3:0: Direct-Access     IBM-ESXS ST973401LC    FN B41D PQ: 0 ANSI: 4
[    6.179384] scsi(0:0:3:0):
[    6.179390]  Sync: period 10, offset 12
[    6.188384] , Wide
[    6.197545] , Tagged queuing: depth 31

[    6.491039] scsi(1:0): Resetting SCSI BUS
[    8.101368] sd 0:0:1:0: Power-on or device reset occurred
[    8.109771] sd 0:0:2:0: Power-on or device reset occurred
[    8.117926] sd 0:0:3:0: Power-on or device reset occurred
[    8.128996] sd 0:0:1:0: [sda] 143374000 512-byte logical blocks: (73.4 GB/68.4 GiB)
[    8.137191] sd 0:0:2:0: [sdb] 143374000 512-byte logical blocks: (73.4 GB/68.4 GiB)
[    8.145257] sd 0:0:3:0: [sdc] 143374000 512-byte logical blocks: (73.4 GB/68.4 GiB)
[    8.153116] sd 0:0:1:0: [sda] Write Protect is off
[    8.160936] sd 0:0:1:0: [sda] Mode Sense: b3 00 10 08
[    8.160979] sd 0:0:3:0: [sdc] Write Protect is off
[    8.168704] sd 0:0:3:0: [sdc] Mode Sense: b3 00 10 08
[    8.168745] sd 0:0:2:0: [sdb] Write Protect is off
[    8.176316] sd 0:0:2:0: [sdb] Mode Sense: b3 00 10 08
[    8.177557] sd 0:0:1:0: [sda] Write cache: disabled, read cache: enabled, supports DPO and FUA
[    8.185308] sd 0:0:3:0: [sdc] Write cache: disabled, read cache: enabled, supports DPO and FUA
[    8.192915] sd 0:0:2:0: [sdb] Write cache: disabled, read cache: enabled, supports DPO and FUA
[    8.212790]  sda: sda1 sda2 sda3 sda4 sda5 sda6 sda9 sda11
[    8.220513]  sdc: sdc1 sdc2 sdc3 sdc4 sdc5 sdc6 sdc9 sdc11
[    8.227919]  sdb: sdb1 sdb2 sdb3 sdb4 sdb5 sdb6 sdb9 sdb11
[    8.237809] sd 0:0:1:0: [sda] Attached SCSI disk
[    8.245936] sd 0:0:3:0: [sdc] Attached SCSI disk
[    8.258431] sd 0:0:2:0: [sdb] Attached SCSI disk
[    9.535586] scsi host1: QLogic QLA1040 PCI to SCSI Host Adapter
                      Firmware version:  7.65.06, Driver version 3.27.1
[    9.556383] ip30-bridge: 0000:00:02.0 Bar 0 with size 0x00100000 at bus 0x00100000 vma 0x000000f080100000 is Direct 64-bit.
[   11.677929] ioc3: part: [030-0891-003], serial: [KBB731] => class IP30 System Board
[   11.688189] ioc3-eth: Ethernet address is 08:00:69:0e:11:0c.
[   11.697264] IOC3 0000:00:02.0 eth0: link up, 100Mbps, full-duplex, lpa 0x85E1
[   11.705591] eth0: Using PHY 1, vendor 0x15f42, model 2, rev 3.
[   11.713921] eth0: IOC3 SSRAM has 128 kbyte.
[   11.722850] rtc-ds1685 rtc-ds1685: registered as rtc0
[   11.756679] 0000:00:02.0: ttyS0 at IOC3 0xf080120178 (irq = 0, base_baud = 458333) is a 16550A
[   11.785950] 0000:00:02.0: ttyS1 at IOC3 0xf080120170 (irq = 0, base_baud = 458333) is a 16550A
[   11.794433] IOC3 Master Driver loaded for 0000:00:02.0
[   11.802753] ip30-bridge: 0000:00:03.0 Bar 0 with size 0x00002000 at bus 0x00200000 vma 0x000000f080200000 is Direct 64-bit.
[   11.829263] PCI host bridge to bus 0001:00
[   11.837875] pci_bus 0001:00: root bus resource [mem 0x1d200000-0x1d9fffff]
[   11.846593] pci_bus 0001:00: root bus resource [io  0x1da00000-0x1dbfffff]
[   11.855193] pci_bus 0001:00: root bus resource [bus 01-ff]
[   11.863744] pci 0001:00:01.0: [11fe:080e] type 00 class 0x078000
[   11.863804] pci 0001:00:01.0: reg 0x10: [mem 0x00200000-0x0020007f]
[   11.863829] pci 0001:00:01.0: reg 0x14: [io  0x200000-0x20007f]
[   11.863853] pci 0001:00:01.0: reg 0x18: [io  0x204000-0x2040ff]
[   11.864130] pci 0001:00:02.0: [10b9:5237] type 00 class 0x0c0310
[   11.864179] pci 0001:00:02.0: reg 0x10: [mem 0x00300000-0x00300fff]
[   11.864339] pci 0001:00:02.0: PME# supported from D0 D1 D3hot D3cold
[   11.864499] pci 0001:00:02.1: [10b9:5237] type 00 class 0x0c0310
[   11.864545] pci 0001:00:02.1: reg 0x10: [mem 0x00000000-0x00000fff]
[   11.864683] pci 0001:00:02.1: PME# supported from D0 D1 D3hot D3cold
[   11.864843] pci 0001:00:02.2: [10b9:5237] type 00 class 0x0c0310
[   11.864889] pci 0001:00:02.2: reg 0x10: [mem 0x00000000-0x00000fff]
[   11.865028] pci 0001:00:02.2: PME# supported from D0 D1 D3hot D3cold
[   11.865187] pci 0001:00:02.3: [10b9:5239] type 00 class 0x0c0320
[   11.865236] pci 0001:00:02.3: reg 0x10: [mem 0x00000000-0x000000ff]
[   11.865388] pci 0001:00:02.3: PME# supported from D0 D3hot D3cold
[   11.865588] pci 0001:00:03.0: [10a9:0009] type 00 class 0x020000
[   11.865635] pci 0001:00:03.0: reg 0x10: [mem 0x00400000-0x00403fff]
[   11.865987] pci 0001:00:03.0: BAR 0: assigned [mem 0x1d200000-0x1d203fff]
[   11.874286] pci 0001:00:02.0: BAR 0: assigned [mem 0x1d204000-0x1d204fff]
[   11.882663] pci 0001:00:02.1: BAR 0: assigned [mem 0x1d205000-0x1d205fff]
[   11.890998] pci 0001:00:02.2: BAR 0: assigned [mem 0x1d206000-0x1d206fff]
[   11.899080] pci 0001:00:01.0: BAR 2: assigned [io  0x1da00000-0x1da000ff]
[   11.906938] pci 0001:00:02.3: BAR 0: assigned [mem 0x1d207000-0x1d2070ff]
[   11.914661] pci 0001:00:01.0: BAR 0: assigned [mem 0x1d207100-0x1d20717f]
[   11.922395] pci 0001:00:01.0: BAR 1: assigned [io  0x1da00400-0x1da0047f]
[   11.930194] acenic.c: v0.92 08/05/2002  Jes Sorensen, linux-acenic@SunSITE.dk
                                           http://home.cern.ch/~jes/gige/acenic.html
[   11.945884] ip30-bridge: 0001:00:03.0 Bar 0 with size 0x00004000 at bus 0x00000000 vma 0x000000d080000000 is Direct 64-bit.
[   11.954084] 0001:00:03.0: SGI AceNIC
[   11.954090] Gigabit Ethernet at 0xd080000000,
[   11.962168] irq 5
[   11.978799]   Tigon II (Rev. 6), Firmware: 0.0.0,
[   11.984167] MAC: 08:00:69:14:69:9c
[   12.000501]   PCI cache line size set incorrectly (0 bytes) by BIOS/FW,
[   12.000508] correcting to 128
[   12.016988]   PCI bus width: 64 bits, speed: 33MHz, latency: 64 clks
[   12.074154] 0001:00:03.0: Firmware up and running
[   12.083733] NET: Registered protocol family 26
[   12.092552] NET: Registered protocol family 10
[   12.102794] Segment Routing with IPv6
[   12.111562] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[   12.120564] NET: Registered protocol family 17
[   12.129128] 8021q: 802.1Q VLAN Support v1.8
[   12.137981] sctp: Hash tables configured (bind 4096/4096)
[   12.146796] Key type dns_resolver registered
[   12.156664] rtc-ds1685 rtc-ds1685: setting system clock to 2019-06-20 05:16:04 UTC (1561007764)
[   12.165737] ALSA device list:
[   12.174699]   #0: SGI RAD Audio at 0xf080200000
[   12.222749] input: AT Raw Set 2 keyboard as /devices/pci0000:00/0000:00:02.0/serio0/input/input0
[   12.473637] input: ImPS/2 Logitech Wheel Mouse as /devices/pci0000:00/0000:00:02.0/serio1/input/input2
[   14.293233] md: Waiting for all devices to be available before autodetect
[   14.302992] md: If you don't use raid, use raid=noautodetect
[   14.313625] md: Autodetecting RAID arrays.
[   14.456847] md: autorun ...
[   14.466680] md: sdb5 has different UUID to sdb6
[   14.476492] md: sdb4 has different UUID to sdb6
[   14.486233] md: sdb3 has different UUID to sdb6
[   14.495971] md: sdb1 has different UUID to sdb6
[   14.505729] md: sdc5 has different UUID to sdb6
[   14.515283] md: sdc4 has different UUID to sdb6
[   14.524746] md: sdc3 has different UUID to sdb6
[   14.533869] md: sdc1 has different UUID to sdb6
[   14.542676] md: sda5 has different UUID to sdb6
[   14.551268] md: sda4 has different UUID to sdb6
[   14.559680] md: sda3 has different UUID to sdb6
[   14.567897] md: sda1 has different UUID to sdb6
[   14.576720] md: running: <sdb6><sdc6><sda6>
[   14.585742] md/raid:md4: device sdb6 operational as raid disk 1
[   14.593657] md/raid:md4: device sdc6 operational as raid disk 2
[   14.601704] md/raid:md4: device sda6 operational as raid disk 0
[   14.612270] md/raid:md4: raid level 5 active with 3 out of 3 devices, algorithm 2
[   14.768222] md4: detected capacity change from 0 to 2263613440
[   14.775792] md: sdb4 has different UUID to sdb5
[   14.783133] md: sdb3 has different UUID to sdb5
[   14.790589] md: sdb1 has different UUID to sdb5
[   14.797953] md: sdc4 has different UUID to sdb5
[   14.805098] md: sdc3 has different UUID to sdb5
[   14.812309] md: sdc1 has different UUID to sdb5
[   14.819531] md: sda4 has different UUID to sdb5
[   14.826678] md: sda3 has different UUID to sdb5
[   14.833801] md: sda1 has different UUID to sdb5
[   14.841631] md: running: <sdb5><sdc5><sda5>
[   14.849690] md/raid:md3: device sdb5 operational as raid disk 1
[   14.856933] md/raid:md3: device sdc5 operational as raid disk 2
[   14.864023] md/raid:md3: device sda5 operational as raid disk 0
[   14.873665] md/raid:md3: raid level 5 active with 3 out of 3 devices, algorithm 2
[   14.887017] md3: detected capacity change from 0 to 4714135552
[   14.893694] md: sdb3 has different UUID to sdb4
[   14.900334] md: sdb1 has different UUID to sdb4
[   14.906932] md: sdc3 has different UUID to sdb4
[   14.913356] md: sdc1 has different UUID to sdb4
[   14.919793] md: sda3 has different UUID to sdb4
[   14.925963] md: sda1 has different UUID to sdb4
[   14.932690] md: running: <sdb4><sdc4><sda4>
[   14.939582] md/raid:md2: device sdb4 operational as raid disk 1
[   14.945481] md/raid:md2: device sdc4 operational as raid disk 2
[   14.951398] md/raid:md2: device sda4 operational as raid disk 0
[   14.959929] md/raid:md2: raid level 5 active with 3 out of 3 devices, algorithm 2
[   14.971449] md2: detected capacity change from 0 to 109521403904
[   14.977476] md: sdb1 has different UUID to sdb3
[   14.983353] md: sdc1 has different UUID to sdb3
[   14.989248] md: sda1 has different UUID to sdb3
[   14.995616] md: running: <sdb3><sdc3><sda3>
[   15.002158] md/raid:md1: device sdb3 operational as raid disk 1
[   15.007713] md/raid:md1: device sdc3 operational as raid disk 2
[   15.013066] md/raid:md1: device sda3 operational as raid disk 0
[   15.021113] md/raid:md1: raid level 5 active with 3 out of 3 devices, algorithm 2
[   15.039410] md1: detected capacity change from 0 to 23622057984
[   15.044772] md: running: <sdb1><sdc1><sda1>
[   15.050679] md/raid:md0: device sdb1 operational as raid disk 1
[   15.055629] md/raid:md0: device sdc1 operational as raid disk 2
[   15.060460] md/raid:md0: device sda1 operational as raid disk 0
[   15.067921] md/raid:md0: raid level 5 active with 3 out of 3 devices, algorithm 2
[   15.081453] md0: detected capacity change from 0 to 4294705152
[   15.086508] md: ... autorun DONE.
[   15.157204] XFS (md0): Mounting V5 Filesystem
[   15.797708] XFS (md0): Ending clean mount
[   15.823891] VFS: Mounted root (xfs filesystem) readonly on device 9:0.
[   15.833380] devtmpfs: mounted
[   15.840112] Freeing unused kernel memory: 384K
[   15.845766] This architecture does not have kernel memory protection.
[   18.145242] eth1: Optical link UP (Full Duplex, Flow Control: TX RX)
[   31.408622] Adding 1048512k swap on /dev/sda2.  Priority:1 extents:1 across:1048512k
[   31.424506] Adding 1048512k swap on /dev/sdb2.  Priority:1 extents:1 across:1048512k
[   31.440530] Adding 1048512k swap on /dev/sdc2.  Priority:1 extents:1 across:1048512k
[   31.916775] XFS (md1): Mounting V5 Filesystem
[   33.243814] XFS (md1): Ending clean mount
[   33.439977] XFS (md2): Mounting V5 Filesystem
[   34.094700] XFS (md2): Ending clean mount
[   34.516999] XFS (md3): Mounting V5 Filesystem
[   35.230208] XFS (md3): Ending clean mount
[   35.317999] XFS (md4): Mounting V5 Filesystem
[   35.963730] XFS (md4): Ending clean mount
[   49.174603] udevd[1701]: starting version 3.2.7
[   49.259590] udevd[1701]: specified group 'video' unknown
[   49.260533] udevd[1701]: specified group 'tape' unknown
[   49.433771] udevd[1701]: starting eudev-3.2.7
[   55.316732] eth1: Enabling Jumbo frame support

Re: SGI-IP30

[Carlo Pisani]

> SMP works fine, on my machine at least.  I got it working back in 4.4 a few
> years ago, and it's largely just worked fine since then on the one machine I
> have.

here I am with
- kernel v4.18.20 + Gentoo patches
- mips64-unknown-linux-gnu {binutils v2.29.1, gcc-v7.4.0) emerged by
Gentoo crossdev

crossdev --b 2.30-2 --g 8.2.0  --l 2.22-r1 --k 4.3 -s2 -A n32 -t
mips64-unknown-linux-gnu --without-headers -v

my Octane is
>> hinv
                   System: IP30
                Processor: 600 Mhz R14000, 2M secondary cache
                Processor: 600 Mhz R14000, 2M secondary cache, (cpu 1)
              Memory size: 1536 Mbytes
                  Network: ef0 ethernet (100/10 base-T)
                SCSI Disk: scsi(0)disk(1)
                SCSI Disk: scsi(0)disk(2)
                SCSI Disk: scsi(0)disk(3)
                    Audio: RAD Audio Processor

(yes, there is no GFX, it's a headless configuration)

my test reports:

kernel type
- No Forced Preemption: stable
- Voluntary Kernel Preemption: it works, but it has some issues with
smp_stop() and panic()
- Preemptible Kernel: completely unstable, the kernel panics in 20 seconds

I have a ram-rootfs, based on uclibc/mips3-be. It's attached to the
kernel, so "bash" is the first process.

CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE="../rootfs/mips3be-uclibc-2008"
CONFIG_INITRAMFS_ROOT_UID=0
CONFIG_INITRAMFS_ROOT_GID=0
CONFIG_RD_GZIP=y

I have three SCSI hard drives, and they do work, but I prefer net-booing

Once booted, it works properly. The 20-hours burning-in test is passed!
(two gcc sessions + nbench in a while(1) { do(); } loop )

When I exit from "bash", the kernel correctly calls the panic()
function, which calls ip30_machine_restart()
(arch/mips/sgi-ip30/ip30-power.c) but this function is not able to
restart the Octane, so it simply hangs and I have to manually force a
hardware reset. Sometimes the machine seems gone insane, and I have to
press the "reset" button several times before I can see the red light.

the solution is adding "isolcpus=1" to command line. This way the
kernel does reboot/restart correctly.

CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE="ip=off isolcpus=1 console=ttyS0,9600 rdinit=/sbin/bash
init=/bin/bash"
CONFIG_CMDLINE_OVERRIDE=y

I have also fixed the power-down function (ds1685_rtc_poweroff_ip30,
drivers/rtc/rtc-ds1685.c) since the kernel does not power down, it
simply hangs forever.

/*
 * sgi-ip30
 * ========
 *
 * ds1685_rtc_poweroff_ip30 - uses the RTC chip to power the system off.
 * @pdev: pointer to platform_device structure.
 */
void __noreturn
ds1685_rtc_poweroff_ip30(struct platform_device *pdev)
{
        u8 val;
        struct ds1685_priv *rtc;

        printk("ip30: ds1685_rtc_poweroff\n");

        /* Check for valid RTC data, else, spin forever. */
        if (unlikely(!pdev))
        {
                pr_emerg("ds1685_rtc_poweroff_ip30, platform device
data not available, spinning forever ...\n");
                while(1);
                unreachable();
        }
        else
        {
                /* Get the rtc data. */
                rtc = platform_get_drvdata(pdev);

                if (!rtc->no_irq)
                {
                        disable_irq_nosync(rtc->irq_num);
                }

                /* prepare the RTC for waking us up so we don't wind up dead */
                val = rtc->read(rtc, 0x4b);
                val &= 0x2a;
                val |= 0x81;
                rtc->write(rtc, 0x4b, val);

                while(1)
                {
                         rtc->write(rtc, 0x4a, 0x08);
                         dev_warn(&pdev->dev, "Powerdown.\n");
                         msleep(100);
                }
                unreachable();
                /* there is no way out */
        }
}
EXPORT_SYMBOL(ds1685_rtc_poweroff_ip30);

This source comes from kernel 2.6.17, and it works properly. Instead
of patching the existing ds1685_rtc_poweroff(), I have just created a
dedicated function ds1685_rtc_poweroff_ip30() ...


-

Everything I have tried with the PCI ... doesn't work. The ShoeHorn
panics the kernel, the ShoeBox seems to have quirks

Re: SGI-IP30

[Matt Turner]

Rene Rebe (cc'd) has a YouTube channel [0] where he posts interesting
videos about old hardware, including the Octane [1]. He's got a modern
kernel running on the Octane.

[0] https://www.youtube.com/channel/UCJLLl6AraX1POemgLfhirwg
[1] https://www.youtube.com/user/renerebe/search?query=sgi

Re: SGI-IP30

[Carlo Pisani]

> Rene Rebe (cc'd) has a YouTube channel [0] where he posts interesting
> videos about old hardware, including the Octane

it's based on kernel 4.12, I have tried it, and it doesn't add
anything to the Gentoo kernel + patches. Perhaps some improvements on
the GFX. I have recently asked exactly *what* his patches do improve,
no reply.

This request is for understanding if/where my team has to be focused
on testing since there are too many things to care about. E.g. PCI?
SMP? R14k stability? etc

Re: SGI-IP30

[Carlo Pisani]

guys
I have just tested the shoehorn in SlotC: there are quirks, but at
least the kernel doesn't panic

to summarize:
ShoeHorn in XIO-SlotA: panics
ShoeHorn in XIO-SlotB: not yet tested
ShoeHorn in XIO-SlotC: doesn't panic
ShoeHorn in XIO-SlotD: panics

- UP -
A | B
D | C

ShoeBox: doesn't panic

Re: SGI-IP30

[Carlo Pisani]

> Rene Rebe (cc'd)

I have just talked with him about his patches: he said that he mostly
fixed some PCI bridge endianness and did some progress with the Impact
cursor and video mode reverse engineering.

https://t2sde.org/packages/linux-ip30

Good, very very interesting!

Re: SGI-IP30

[Joshua Kinard]

On 6/28/2019 04:27, Carlo Pisani wrote:
> guys
> I have just tested the shoehorn in SlotC: there are quirks, but at
> least the kernel doesn't panic
> 
> to summarize:
> ShoeHorn in XIO-SlotA: panics
> ShoeHorn in XIO-SlotB: not yet tested
> ShoeHorn in XIO-SlotC: doesn't panic
> ShoeHorn in XIO-SlotD: panics
> 
> - UP -
> A | B
> D | C
> 
> ShoeBox: doesn't panic

XIO Slot A and D are typically where the graphics boards go for Impact
(depending on the Impact board).  Slot B might give issues as well because
Odyssey, which is two XIO slots wide, usually occupies A & B (though it only
ever plugs into a single XIO connector).  The Panics are probably due to
some hardcoded logic in Stan's original patches I mentioned that always
assume the presence of a graphics board, because Octane was primarily a
graphics workstation.

Is the shoehorn adapter you have the very rare Octane model, or an Origin
version modified with an Octane XIO locking latch?

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: SGI-IP30

[Carlo Pisani]

> The Panics are probably due to some hardcoded logic in Stan's original patches
> I mentioned that always assume the presence of a graphics board

with or without the MGRAS card, I have the same behavior.
Which is the file you are talking about? ip30-xtalk?

> Is the shoehorn adapter you have the very rare Octane model, or an Origin
> version modified with an Octane XIO locking latch?

It's an origina2k modified with the XIO locking latch. With Irix, it
works without any problem.

Anyway, it seems there are problems with the PCI, related to the BAR,
or to how it's configured, or to the memory window ... the kernel
panic complaining a "BUS error"

IOC3 Master Driver loaded for 0000:00:02.0
PCI host bridge to bus 0001:00
pci_bus 0001:00: root bus resource [mem 0x1a200000-0x1a9fffff]
pci_bus 0001:00: root bus resource [io  0x1aa00000-0x1abfffff]
pci_bus 0001:00: root bus resource [bus 01-ff]
pci 0001:00:01.0: BAR 0: assigned [mem 0x1a200000-0x1a200fff]
pci 0001:00:01.1: BAR 0: assigned [mem 0x1a201000-0x1a201fff]
pci 0001:00:01.2: BAR 0: assigned [mem 0x1a202000-0x1a2020ff]
ip30-bridge: 0001:00:01.0 Bar 0 with size 0x00001000 at bus 0x00000000
vma 0x000000b080000000 is Direct 64-bit.
Data bus error, epc == a8000000203c9884, ra == a8000000203c987c
Oops[#1]:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.18.20-Merciless-Moray-ip30 #74
$ 0   : 0000000000000000 ffffffff9404fde0 900000b080000000 000000b080000000
$ 4   : a80000007ead6000 0000000000000000 0000000000000006 0000000000000002
$ 8   : a80000007ead6000 0000000000000000 0000000000000005 0000000000000000
$12   : a80000007fc8bfe0 000000000000fd00 0000000000000000 fffffffffffffffe
$16   : a80000007ead6000 900000b080000000 00000000000c0000 a8000000205f0000
$20   : a80000007ead6000 a8000000205b1898 00000007443a9d5a a800000020a90000
$24   : 0000000000000220 0000000000000000
$28   : a80000007fc88000 a80000007fc8bae0 0000000000000007 a8000000203c987c
Hi    : 0000000000008509
Lo    : 000000000000038b
epc   : a8000000203c9884 0xa8000000203c9884
ra    : a8000000203c987c 0xa8000000203c987c
Status: 9404fde3        KX SX UX KERNEL EXL IE
Cause : 0000001c (ExcCode 07)
PrId  : 00000f24 (R14000)
Modules linked in:
Process swapper/0 (pid: 1, threadinfo=00000000b9e5e6bd,
task=000000005215823f, tls=0000000000000000)
Stack : 0000000000000007 a80000007fc8bae8 a80000007fc8bae8 11a4d0c4ecae9ccd
        a8000000205b1868 a800000020a90000 a8000000205924e0 a8000000205924c8
        a80000007ead6000 a8000000205b1898 00000007443a9d5a a800000020a90000
        0000000000000007 a800000020301550 0000000000000007 a80000007ead6000
        a80000007e59ac28 a80000007e59ac00 a8000000205f0000 a800000020ac0000
        a800000020660000 0000000000000000 a800000020a90000 a8000000202e64ec
        a80000007e59ac00 a80000007ead6000 a80000007e59ac28 a8000000202e65e8
        a80000007e59ac18 a80000007e59ac18 a80000007e59ac00 a8000000203f5df0
        a800000020623a30 a80000007fc8bbe8 a80000007fc8bbe8 11a4d0c4ecae9ccd
        a80000007e366600 a800000020620000 a8000000205f0000 a80000007fd46b80
        ...
Call Trace:
[<a800000020301550>] 0xa800000020301550
[<a8000000202e64ec>] 0xa8000000202e64ec
[<a8000000202e65e8>] 0xa8000000202e65e8
[<a8000000203f5df0>] 0xa8000000203f5df0
[<a8000000203f6094>] 0xa8000000203f6094
[<a800000020657eb0>] 0xa800000020657eb0
[<a80000002034fa50>] 0xa80000002034fa50
[<a80000002034d58c>] 0xa80000002034d58c
[<a80000002063133c>] 0xa80000002063133c
[<a80000002034d798>] 0xa80000002034d798
[<a80000002034d670>] 0xa80000002034d670
[<a80000002034acb0>] 0xa80000002034acb0
[<a80000002063133c>] 0xa80000002063133c
[<a80000002034c5b8>] 0xa80000002034c5b8
[<a800000020657adc>] 0xa800000020657adc
[<a80000002034e1a0>] 0xa80000002034e1a0
[<a8000000206579a0>] 0xa8000000206579a0
[<a800000020004530>] 0xa800000020004530
[<a800000020632454>] 0xa800000020632454
[<a8000000204fc750>] 0xa8000000204fc750
[<a8000000204fc760>] 0xa8000000204fc760
[<a8000000204fc750>] 0xa8000000204fc750
[<a80000002000c168>] 0xa80000002000c168

Code: 02002025  1040ffdd  00408825 <8c550004> 9e12003c  0000000f
32a20100  10400011  00000000

---[ end trace e8faa9089454f71d ]---

Re: SGI-IP30

[Joshua Kinard]

On 6/26/2019 01:49, Carlo Pisani wrote:>> SMP works fine, on my machine at
least.  I got it working back in 4.4 a few
>> years ago, and it's largely just worked fine since then on the one machine I
>> have.
>
> here I am with
> - kernel v4.18.20 + Gentoo patches
> - mips64-unknown-linux-gnu {binutils v2.29.1, gcc-v7.4.0) emerged by
> Gentoo crossdev
>
> crossdev --b 2.30-2 --g 8.2.0  --l 2.22-r1 --k 4.3 -s2 -A n32 -t
> mips64-unknown-linux-gnu --without-headers -v
>
> my Octane is
>>> hinv
>                    System: IP30
>                 Processor: 600 Mhz R14000, 2M secondary cache
>                 Processor: 600 Mhz R14000, 2M secondary cache, (cpu 1)
>               Memory size: 1536 Mbytes
>                   Network: ef0 ethernet (100/10 base-T)
>                 SCSI Disk: scsi(0)disk(1)
>                 SCSI Disk: scsi(0)disk(2)
>                 SCSI Disk: scsi(0)disk(3)
>                     Audio: RAD Audio Processor
>
> (yes, there is no GFX, it's a headless configuration)
>
> my test reports:
>
> kernel type
> - No Forced Preemption: stable
> - Voluntary Kernel Preemption: it works, but it has some issues with
> smp_stop() and panic()
> - Preemptible Kernel: completely unstable, the kernel panics in 20 seconds
>
> I have a ram-rootfs, based on uclibc/mips3-be. It's attached to the
> kernel, so "bash" is the first process.
>
> CONFIG_BLK_DEV_INITRD=y
> CONFIG_INITRAMFS_SOURCE="../rootfs/mips3be-uclibc-2008"
> CONFIG_INITRAMFS_ROOT_UID=0
> CONFIG_INITRAMFS_ROOT_GID=0
> CONFIG_RD_GZIP=y
>
> I have three SCSI hard drives, and they do work, but I prefer net-booing
>
> Once booted, it works properly. The 20-hours burning-in test is passed!
> (two gcc sessions + nbench in a while(1) { do(); } loop )
>
> When I exit from "bash", the kernel correctly calls the panic()
> function, which calls ip30_machine_restart()
> (arch/mips/sgi-ip30/ip30-power.c) but this function is not able to
> restart the Octane, so it simply hangs and I have to manually force a
> hardware reset. Sometimes the machine seems gone insane, and I have to
> press the "reset" button several times before I can see the red light.

Yeah, I get this sometimes on a normal reboot from userland.  You usually
have to press reset twice, one second apart.  If it works, the system
LED/bulb will blink once, then it'll "click" and the red LED will come on
for a few seconds indicating PROM reset.  It may be a bug in the PROM
somewhere, or a bug in how the Octane's Linux restart code works.  The
restart code literally just flips a specific register in HEART to trigger a
reset.  It is possible there needs to be some special housekeeping done
beforehand so that HEART doesn't wind up in an unknown hardware state, which
I suspect is the underlying problem.


> the solution is adding "isolcpus=1" to command line. This way the
> kernel does reboot/restart correctly.

I'll have to look into that kernel flag.  I haven't heard of it before.


> I have also fixed the power-down function (ds1685_rtc_poweroff_ip30,
> drivers/rtc/rtc-ds1685.c) since the kernel does not power down, it
> simply hangs forever.

I believe Thomas found and fixed the bug in it recently and sent it upstream
(or was that something else?).  I remember the shutdown function working in
the past, but assumed something upstream broke it, or something upstream
exposed an existing bug that causes this breakage now.


> /*
>  * sgi-ip30
>  * ========
>  *
>  * ds1685_rtc_poweroff_ip30 - uses the RTC chip to power the system off.
>  * @pdev: pointer to platform_device structure.
>  */
> void __noreturn
> ds1685_rtc_poweroff_ip30(struct platform_device *pdev)
> {
[snip]

> }
> EXPORT_SYMBOL(ds1685_rtc_poweroff_ip30);
>
> This source comes from kernel 2.6.17, and it works properly. Instead
> of patching the existing ds1685_rtc_poweroff(), I have just created a
> dedicated function ds1685_rtc_poweroff_ip30() ...

Are you sure that's from 2.6.17?  I believe I cribbed the basic logic for
RTC shutdown from O2 (IP32), which uses the same RTC chip, and I did most of
my work on the RTC driver during the 3.x kernel series, getting rtc-ds1685.c
added with the release of Linux 4.0 in 2015.

Could you do a diff against the 4.18 kernel source so I can more easily see
the changed logic?


> Everything I have tried with the PCI ... doesn't work. The ShoeHorn
> panics the kernel, the ShoeBox seems to have quirks

Can you make sure that you don't have a Rev A or Rev B BRIDGE chip on that
shoehorn?  There are known issues/errata with those revs.  The Octane
Shoebox usually carries a Rev C BRIDGE, and the system board a Rev D BRIDGE
(except for very old boards I think).  I don't know the .  I can't promise
that every Rev A/B errata is worked around (or can be worked around).  I
know I added one or two extra cases that I found buried in the 2.5.70 IA64
Altix port code that was obviously cribbed from IRIX by SGI themselves.  But
I think those were for Rev C...

Also, I'll add that PCI support on these SGI machines usually works by the
sheer force of luck alone.  The one PCI card I have in my shoebox is a Tigon
II 1gbps ethernet card (copper), commonly marketed as an SGI Acenic.  It's
one of the few cards that's generally worked w/o issue (and a good
substitute for the annoying IOC3 ethernet), likely because it's an SGI part.
 I haven't tested much beyond that, since my Octane is primarily a build box
these days.

I personally have never had luck with USB flash drives, except OHCI USB1.x
on a Via USB controller years ago.  Sparc systems also had issues way back
then w/ USB mass storage because a lot of PCI drivers assumed everything in
Linux was little-endian.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: SGI-IP30

[Joshua Kinard]

On 7/1/2019 14:36, Carlo Pisani wrote:
>> The Panics are probably due to some hardcoded logic in Stan's original patches
>> I mentioned that always assume the presence of a graphics board
> 
> with or without the MGRAS card, I have the same behavior.
> Which is the file you are talking about? ip30-xtalk?

The it's probably some kind of issue with the addressing math in IP30's
headers somewhere.  As I've said before, it's not a configuration I've ever
tried, so I never had a motivation to try and hunt it down to fix.  If I
need to run headless, I just "setenv console=d1" and re-init the system to
run from my serial console server.

If you want to investigate, under the Gentoo-patched kernel, start looking
in arch/mips/include/asm/mach-ip30/*.h for IP30's specific defines.  And for
Xtalk stuff, that is in arch/mips/include/asm/xtalk/*.h.

A lot of the changes I did there were just to add descriptive macros for
addresses that were formerly coded as raw integers/hex.  A lot of the macros
are never actually used anywhere, but essentially serve as documentation.

As far as hardwiring the graphics, Slot A actually reports in as Widget C
during xtalk scan, because we enumerate backwards from Widget F (BaseIO):

Widget | Device
-------|--------
  F    | BaseIO
  E    | Unused
  D    | PCI Shoebox
  C    | XIO Slot A
  B    | XIO Slot B
  A    | XIO Slot C
  9    | XIO Slot D
  8    | HEART
  0    | XBOW
 1-7   | Unused/Reserved

The Widget assignments for XBOW, HEART, and BaseIO are apparently hardwired
on the PCB itself.  I don't know what Widget E is for, or if it's even
exposed anywhere, but I suspect it's simply unused based on a look at IRIX
header files.  Widgets 1-7 are not accessible and, I think, are used
internally by the Crossbar switch for routing stuff on the system board.

I did a cursory skim of the headers, and I personally do not see where I
have any macros locked into specific widgets that actually get used
anywhere.  I do code in that the first graphics slot if Widget C and assign
that to a macro, but the assigned macro isn't used in any actual code, so
more documentation.

I don't have the cycles right now to look over the C code in-depth in either
the xtalk code (ip30-xtalk.c) or the bridge glue code (ip30-bridge.c).
Those two are responsible for setting up the XIO bus and then probing the
BRIDGE chips found in any of the slots.

>> Is the shoehorn adapter you have the very rare Octane model, or an Origin
>> version modified with an Octane XIO locking latch?
> 
> It's an origina2k modified with the XIO locking latch. With Irix, it
> works without any problem.

Generally, modifying an Origin XIO board to work on Octane does not present
problems (I've done it myself before), but you do want to check that the
latch is aligning the compression connector up correctly and that it's
latching properly.  If that connector doesn't seat right, you can
potentially have a whole host of problems, including possible damage to the
surface pads of the connector.  From what I've heard, faulty compression
connectors are absolute devils to debug, because the side-effects are very
random, almost like bad memory in a PC.


> Anyway, it seems there are problems with the PCI, related to the BAR,
> or to how it's configured, or to the memory window ... the kernel
> panic complaining a "BUS error"
> 
> IOC3 Master Driver loaded for 0000:00:02.0
> PCI host bridge to bus 0001:00
> pci_bus 0001:00: root bus resource [mem 0x1a200000-0x1a9fffff]
> pci_bus 0001:00: root bus resource [io  0x1aa00000-0x1abfffff]
> pci_bus 0001:00: root bus resource [bus 01-ff]
> pci 0001:00:01.0: BAR 0: assigned [mem 0x1a200000-0x1a200fff]
> pci 0001:00:01.1: BAR 0: assigned [mem 0x1a201000-0x1a201fff]
> pci 0001:00:01.2: BAR 0: assigned [mem 0x1a202000-0x1a2020ff]
> ip30-bridge: 0001:00:01.0 Bar 0 with size 0x00001000 at bus 0x00000000
> vma 0x000000b080000000 is Direct 64-bit.
> Data bus error, epc == a8000000203c9884, ra == a8000000203c987c
> Oops[#1]:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.18.20-Merciless-Moray-ip30 #74
> $ 0   : 0000000000000000 ffffffff9404fde0 900000b080000000 000000b080000000
> $ 4   : a80000007ead6000 0000000000000000 0000000000000006 0000000000000002
> $ 8   : a80000007ead6000 0000000000000000 0000000000000005 0000000000000000
> $12   : a80000007fc8bfe0 000000000000fd00 0000000000000000 fffffffffffffffe
> $16   : a80000007ead6000 900000b080000000 00000000000c0000 a8000000205f0000
> $20   : a80000007ead6000 a8000000205b1898 00000007443a9d5a a800000020a90000
> $24   : 0000000000000220 0000000000000000
> $28   : a80000007fc88000 a80000007fc8bae0 0000000000000007 a8000000203c987c
> Hi    : 0000000000008509
> Lo    : 000000000000038b
> epc   : a8000000203c9884 0xa8000000203c9884
> ra    : a8000000203c987c 0xa8000000203c987c
> Status: 9404fde3        KX SX UX KERNEL EXL IE
> Cause : 0000001c (ExcCode 07)
> PrId  : 00000f24 (R14000)
> Modules linked in:
> Process swapper/0 (pid: 1, threadinfo=00000000b9e5e6bd,
> task=000000005215823f, tls=0000000000000000)
> Stack : 0000000000000007 a80000007fc8bae8 a80000007fc8bae8 11a4d0c4ecae9ccd
>         a8000000205b1868 a800000020a90000 a8000000205924e0 a8000000205924c8
>         a80000007ead6000 a8000000205b1898 00000007443a9d5a a800000020a90000
>         0000000000000007 a800000020301550 0000000000000007 a80000007ead6000
>         a80000007e59ac28 a80000007e59ac00 a8000000205f0000 a800000020ac0000
>         a800000020660000 0000000000000000 a800000020a90000 a8000000202e64ec
>         a80000007e59ac00 a80000007ead6000 a80000007e59ac28 a8000000202e65e8
>         a80000007e59ac18 a80000007e59ac18 a80000007e59ac00 a8000000203f5df0
>         a800000020623a30 a80000007fc8bbe8 a80000007fc8bbe8 11a4d0c4ecae9ccd
>         a80000007e366600 a800000020620000 a8000000205f0000 a80000007fd46b80
>         ...
> Call Trace:
> [<a800000020301550>] 0xa800000020301550
> [<a8000000202e64ec>] 0xa8000000202e64ec
> [<a8000000202e65e8>] 0xa8000000202e65e8
> [<a8000000203f5df0>] 0xa8000000203f5df0
> [<a8000000203f6094>] 0xa8000000203f6094
> [<a800000020657eb0>] 0xa800000020657eb0
> [<a80000002034fa50>] 0xa80000002034fa50
> [<a80000002034d58c>] 0xa80000002034d58c
> [<a80000002063133c>] 0xa80000002063133c
> [<a80000002034d798>] 0xa80000002034d798
> [<a80000002034d670>] 0xa80000002034d670
> [<a80000002034acb0>] 0xa80000002034acb0
> [<a80000002063133c>] 0xa80000002063133c
> [<a80000002034c5b8>] 0xa80000002034c5b8
> [<a800000020657adc>] 0xa800000020657adc
> [<a80000002034e1a0>] 0xa80000002034e1a0
> [<a8000000206579a0>] 0xa8000000206579a0
> [<a800000020004530>] 0xa800000020004530
> [<a800000020632454>] 0xa800000020632454
> [<a8000000204fc750>] 0xa8000000204fc750
> [<a8000000204fc760>] 0xa8000000204fc760
> [<a8000000204fc750>] 0xa8000000204fc750
> [<a80000002000c168>] 0xa80000002000c168
> 
> Code: 02002025  1040ffdd  00408825 <8c550004> 9e12003c  0000000f
> 32a20100  10400011  00000000
> 
> ---[ end trace e8faa9089454f71d ]---

You really need to enable debugging symbols in your kernel for stack dumps
to have any meaning.  Those address offsets are going to be unique to your
kernel build, so they are of no use to anyone else.

The early widget addresses you show, 0x1axxxxxx, imply the bus error is
happening in Slot C (widget A).  You said Slot C works fine?  Did you mean
Slot D works fine instead?  The snippet of dmesg you put in your other
e-mail definitely shows Slot D (widget 9) being populated by something that
has a BRIDGE chip in it.  Does that address space probe correctly (0x19xxxxxx)?

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: SGI-IP30

[Carlo Pisani]

> The early widget addresses you show, 0x1axxxxxx

can you give me a memory mapping table for the those XIO devices?

> shows Slot D (widget 9) being populated by something that has a BRIDGE chip in it.

The BRIGE is a ShoeHorn. I have three units here and two Octanes.
They have always shown the same behavior.

My conclusion is: the hardware is not damaged, it's a software problem.

> Does that address space probe correctly (0x19xxxxxx)?

It seems so. Anyway, even the ShoeBox is probed correctly but it
doesn't work correctly!
It doesn't panic, but it shows a lot of quirks.

What have I to enable in the kernel to debug the PCI and stuff?