Tested on my POWER8 machine.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jan 7 2019
Dec 10 2018
In D17806#394036, @sbruno wrote:This panic is fairly reliable on our Power8 box. Is it related to this change or is it unrelated? I'm not convinced this panic should keep this review blocked as it resolves other things.
panic: Memory modified after free 0xc0000000850584a0(32) val=0 @ 0xc0000000850584a0 cpuid = 31 time = 1544381394 KDB: stack backtrace: 0xe000000090207030: at .kdb_backtrace+0x5c 0xe000000090207160: at .vpanic+0x1b4 0xe000000090207220: at .panic+0x38 0xe0000000902072b0: at .trash_ctor+0x58 0xe000000090207330: at .trash_fini+0x1c 0xe0000000902073b0: at .uma_zdestroy+0x164 0xe000000090207460: at .uma_zdestroy+0x42c 0xe0000000902074f0: at .sys_swapoff+0x2c4 0xe000000090207580: at .uma_zfree_pcpu_arg+0x340 0xe000000090207610: at .zone_drain+0x18 0xe000000090207690: at .uma_avail+0x4c4 0xe000000090207720: at .zone_drain+0x410 0xe0000000902077b0: at .uma_reclaim_worker+0x20c 0xe000000090207860: at .fork_exit+0xd0 0xe000000090207900: at .fork_trampoline+0x10 0xe000000090207930: at -0x4 KDB: enter: panic
Dec 7 2018
Great!
Thanks for fixing the issue I left behind on this!
Nov 1 2018
Oct 29 2018
In D17601#379168, @mmacy wrote:I just rebased to today's HEAD from that of the 6th. This change makes my system unbootable. I haven't delved in to it, but my guess is I don't have enough contiguous memory below the limit (my system has 512GB)
Oct 17 2018
Aug 9 2018
In D16633#353456, @jhibbits wrote:Approved. A cleaner solution might be to add another SI_SUB_ node, or reuse an existing one for all cases. But this unblocks us, and is sufficient. SI_SUB_INIT_IF looks like a good one (no need to do it now).
Aug 8 2018
May 9 2018
May 7 2018
Yes, it is working fine for me.
I tried a couple different number of CPUs, with and without usefdt, and it all worked fine.
Although for me /chosen/cpu always seems to exist, so the /chosen/fdtbootcpu part wasn't tested.
- Use /chosen/{cpu,fdtbootcpu} to detect boot CPU
Minor style fix
Ok, good to know, let me try that.
In D15174#320379, @nwhitehorn wrote:We should fix that, too, though. This code assumes that we are booting on CPU 0 -- the same assumption could continue as a stopgap until we figure out a reliable way to evaluate the boot processor.
Apr 25 2018
In D15174#320058, @nwhitehorn wrote:Is there a reason not to just adopt the PowerNV version of this code, which already does the right thing?
Apr 24 2018
Made cpu discovery accept non-contiguous ids
- Made cpu discovery accept non-contiguous ids
Apr 23 2018
Apr 19 2018
Thanks @jhibbits! Can you commit the change for me?
Apr 17 2018
- Addressing review's comments