* Call trace stops at static callback functions @ 2019-06-22 12:40 Hauke Mehrtens 2019-06-22 12:42 ` SGI-IP30 Carlo Pisani 2019-06-24 18:10 ` Call trace stops at static callback functions Paul Burton 0 siblings, 2 replies; 17+ messages in thread From: Hauke Mehrtens @ 2019-06-22 12:40 UTC (permalink / raw) To: linux-mips 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* SGI-IP30 2019-06-22 12:40 Call trace stops at static callback functions Hauke Mehrtens @ 2019-06-22 12:42 ` Carlo Pisani 2019-06-24 17:55 ` SGI-IP30 Paul Burton 2019-06-24 18:10 ` Call trace stops at static callback functions Paul Burton 1 sibling, 1 reply; 17+ messages in thread From: Carlo Pisani @ 2019-06-22 12:42 UTC (permalink / raw) Cc: linux-mips 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 =) ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: SGI-IP30 2019-06-22 12:42 ` SGI-IP30 Carlo Pisani @ 2019-06-24 17:55 ` Paul Burton 2019-06-24 19:16 ` SGI-IP30 Maciej W. Rozycki ` (2 more replies) 0 siblings, 3 replies; 17+ messages in thread From: Paul Burton @ 2019-06-24 17:55 UTC (permalink / raw) To: Carlo Pisani, Thomas Bogendoerfer, Maciej W. Rozycki, Joshua Kinard Cc: linux-mips 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: SGI-IP30 2019-06-24 17:55 ` SGI-IP30 Paul Burton @ 2019-06-24 19:16 ` Maciej W. Rozycki 2019-06-25 8:59 ` SGI-IP30 Thomas Bogendoerfer 2019-06-26 4:23 ` SGI-IP30 Joshua Kinard 2 siblings, 0 replies; 17+ messages in thread From: Maciej W. Rozycki @ 2019-06-24 19:16 UTC (permalink / raw) To: Paul Burton; +Cc: Carlo Pisani, Thomas Bogendoerfer, Joshua Kinard, linux-mips 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: SGI-IP30 2019-06-24 17:55 ` SGI-IP30 Paul Burton 2019-06-24 19:16 ` SGI-IP30 Maciej W. Rozycki @ 2019-06-25 8:59 ` Thomas Bogendoerfer 2019-06-26 4:23 ` SGI-IP30 Joshua Kinard 2 siblings, 0 replies; 17+ messages in thread From: Thomas Bogendoerfer @ 2019-06-25 8:59 UTC (permalink / raw) To: Paul Burton; +Cc: Carlo Pisani, Maciej W. Rozycki, Joshua Kinard, linux-mips 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) ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: SGI-IP30 2019-06-24 17:55 ` SGI-IP30 Paul Burton 2019-06-24 19:16 ` SGI-IP30 Maciej W. Rozycki 2019-06-25 8:59 ` SGI-IP30 Thomas Bogendoerfer @ 2019-06-26 4:23 ` Joshua Kinard 2019-06-26 5:49 ` SGI-IP30 Carlo Pisani 2019-06-27 20:38 ` SGI-IP30 Matt Turner 2 siblings, 2 replies; 17+ messages in thread From: Joshua Kinard @ 2019-06-26 4:23 UTC (permalink / raw) To: Paul Burton, Carlo Pisani, Thomas Bogendoerfer, Maciej W. Rozycki Cc: linux-mips [-- 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: SGI-IP30 2019-06-26 4:23 ` SGI-IP30 Joshua Kinard @ 2019-06-26 5:49 ` Carlo Pisani 2019-07-01 19:27 ` SGI-IP30 Joshua Kinard 2019-06-27 20:38 ` SGI-IP30 Matt Turner 1 sibling, 1 reply; 17+ messages in thread From: Carlo Pisani @ 2019-06-26 5:49 UTC (permalink / raw) To: Joshua Kinard Cc: Paul Burton, Thomas Bogendoerfer, Maciej W. Rozycki, linux-mips > 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: SGI-IP30 2019-06-26 5:49 ` SGI-IP30 Carlo Pisani @ 2019-07-01 19:27 ` Joshua Kinard 0 siblings, 0 replies; 17+ messages in thread From: Joshua Kinard @ 2019-07-01 19:27 UTC (permalink / raw) To: Carlo Pisani Cc: Paul Burton, Thomas Bogendoerfer, Maciej W. Rozycki, linux-mips 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: SGI-IP30 2019-06-26 4:23 ` SGI-IP30 Joshua Kinard 2019-06-26 5:49 ` SGI-IP30 Carlo Pisani @ 2019-06-27 20:38 ` Matt Turner 2019-06-27 22:29 ` SGI-IP30 Carlo Pisani 2019-06-28 9:46 ` SGI-IP30 Carlo Pisani 1 sibling, 2 replies; 17+ messages in thread From: Matt Turner @ 2019-06-27 20:38 UTC (permalink / raw) To: Joshua Kinard Cc: Paul Burton, Carlo Pisani, Thomas Bogendoerfer, Maciej W. Rozycki, linux-mips, René Rebe 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: SGI-IP30 2019-06-27 20:38 ` SGI-IP30 Matt Turner @ 2019-06-27 22:29 ` Carlo Pisani 2019-06-28 8:27 ` SGI-IP30 Carlo Pisani 2019-06-28 9:46 ` SGI-IP30 Carlo Pisani 1 sibling, 1 reply; 17+ messages in thread From: Carlo Pisani @ 2019-06-27 22:29 UTC (permalink / raw) To: Matt Turner Cc: Joshua Kinard, Paul Burton, Thomas Bogendoerfer, Maciej W. Rozycki, linux-mips, René Rebe > 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: SGI-IP30 2019-06-27 22:29 ` SGI-IP30 Carlo Pisani @ 2019-06-28 8:27 ` Carlo Pisani 2019-07-01 18:31 ` SGI-IP30 Joshua Kinard 0 siblings, 1 reply; 17+ messages in thread From: Carlo Pisani @ 2019-06-28 8:27 UTC (permalink / raw) To: Matt Turner Cc: Joshua Kinard, Paul Burton, Thomas Bogendoerfer, Maciej W. Rozycki, linux-mips, René Rebe 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: SGI-IP30 2019-06-28 8:27 ` SGI-IP30 Carlo Pisani @ 2019-07-01 18:31 ` Joshua Kinard 2019-07-01 18:36 ` SGI-IP30 Carlo Pisani 0 siblings, 1 reply; 17+ messages in thread From: Joshua Kinard @ 2019-07-01 18:31 UTC (permalink / raw) To: Carlo Pisani, Matt Turner Cc: Paul Burton, Thomas Bogendoerfer, Maciej W. Rozycki, linux-mips, René Rebe 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: SGI-IP30 2019-07-01 18:31 ` SGI-IP30 Joshua Kinard @ 2019-07-01 18:36 ` Carlo Pisani 2019-07-01 20:29 ` SGI-IP30 Joshua Kinard 0 siblings, 1 reply; 17+ messages in thread From: Carlo Pisani @ 2019-07-01 18:36 UTC (permalink / raw) To: Joshua Kinard Cc: Matt Turner, Paul Burton, Thomas Bogendoerfer, Maciej W. Rozycki, linux-mips, René Rebe > 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 ]--- ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: SGI-IP30 2019-07-01 18:36 ` SGI-IP30 Carlo Pisani @ 2019-07-01 20:29 ` Joshua Kinard 2019-07-01 20:41 ` SGI-IP30 Carlo Pisani 0 siblings, 1 reply; 17+ messages in thread From: Joshua Kinard @ 2019-07-01 20:29 UTC (permalink / raw) To: Carlo Pisani Cc: Matt Turner, Paul Burton, Thomas Bogendoerfer, Maciej W. Rozycki, linux-mips, René Rebe 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: SGI-IP30 2019-07-01 20:29 ` SGI-IP30 Joshua Kinard @ 2019-07-01 20:41 ` Carlo Pisani 0 siblings, 0 replies; 17+ messages in thread From: Carlo Pisani @ 2019-07-01 20:41 UTC (permalink / raw) To: Joshua Kinard Cc: Matt Turner, Paul Burton, Thomas Bogendoerfer, Maciej W. Rozycki, linux-mips, René Rebe > 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? ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: SGI-IP30 2019-06-27 20:38 ` SGI-IP30 Matt Turner 2019-06-27 22:29 ` SGI-IP30 Carlo Pisani @ 2019-06-28 9:46 ` Carlo Pisani 1 sibling, 0 replies; 17+ messages in thread From: Carlo Pisani @ 2019-06-28 9:46 UTC (permalink / raw) To: Matt Turner Cc: Joshua Kinard, Paul Burton, Thomas Bogendoerfer, Maciej W. Rozycki, linux-mips, René Rebe > 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! ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Call trace stops at static callback functions 2019-06-22 12:40 Call trace stops at static callback functions Hauke Mehrtens 2019-06-22 12:42 ` SGI-IP30 Carlo Pisani @ 2019-06-24 18:10 ` Paul Burton 1 sibling, 0 replies; 17+ messages in thread From: Paul Burton @ 2019-06-24 18:10 UTC (permalink / raw) To: Hauke Mehrtens; +Cc: linux-mips 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2019-07-01 20:41 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-06-22 12:40 Call trace stops at static callback functions Hauke Mehrtens 2019-06-22 12:42 ` SGI-IP30 Carlo Pisani 2019-06-24 17:55 ` SGI-IP30 Paul Burton 2019-06-24 19:16 ` SGI-IP30 Maciej W. Rozycki 2019-06-25 8:59 ` SGI-IP30 Thomas Bogendoerfer 2019-06-26 4:23 ` SGI-IP30 Joshua Kinard 2019-06-26 5:49 ` SGI-IP30 Carlo Pisani 2019-07-01 19:27 ` SGI-IP30 Joshua Kinard 2019-06-27 20:38 ` SGI-IP30 Matt Turner 2019-06-27 22:29 ` SGI-IP30 Carlo Pisani 2019-06-28 8:27 ` SGI-IP30 Carlo Pisani 2019-07-01 18:31 ` SGI-IP30 Joshua Kinard 2019-07-01 18:36 ` SGI-IP30 Carlo Pisani 2019-07-01 20:29 ` SGI-IP30 Joshua Kinard 2019-07-01 20:41 ` SGI-IP30 Carlo Pisani 2019-06-28 9:46 ` SGI-IP30 Carlo Pisani 2019-06-24 18:10 ` Call trace stops at static callback functions Paul Burton
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).