> You need to mount pstore to access the files.
>
> # mkdir /dev/pstore
> # mount -t pstore - /dev/pstore
>
> to unmount
>
> # umount /dev/pstore
>
> References: http://lwn.net/Articles/421297/
Note that /dev/pstore has fallen out of fashion as the mount point ... we now
(since 3.9)
suggest /
> Introducing headersize in pstore_write() API would need changes at
> multiple places whereits being called. The idea is to move the
> compression support to pstore infrastructure so that other platforms
> could also make use of it.
Any thoughts on the back/forward compatibility as we switch to c
> Could you please review and let me know your comments!!
Skimmed through it today and didn't notice anything I hated. It built fine -
but doesn't seem to be working on top of ERST. This doesn't seem to be your
fault though, when I rebuilt a plain 3.11-rc3 it didn't log anything via pstore
> Needs testing with erst backend, efivars and persistent ram.
Tested against ERST - works fine for me now.
Need to stare at the code to see if there are any more bits that could be
cleaned up.
Thanks for addressing my issues from v1
-Tony
___
Linuxp
<1>[ 383.209057] RIP [] sysrq_handle_crash+0x16/0x20
<4>[ 383.209057] RSP
<4>[ 383.209057] CR2:
<4>[ 383.209057] ---[ end trace 04a1cddad37b4b33 ]---
<3>[ 383.209057] pstore: compression failed for Part 2 returned -5
<3>[ 383.209057] pstore: Capture uncompressed oops/panic
> The reason behind compression failure is the size of big_oops_buf which is too
> big for efivars case. I will do some experiments with different kind of texts
> for buffer size 1024 to check if 100/53 suits for all the cases.
...
> Yes this can be changed to zlib_inflateInit2().
Original patch
- big_oops_buf_sz = (psinfo->bufsize * 100) / 45;
+ big_oops_buf_sz = (psinfo->bufsize * 100) / cmpr;
Tested on an ERST backed system. Seems to be working (we save a little less
information
per ERST record than before this change (uncompressed size goes down from
~17500 to
~16400 by
+ default:
+ cmpr = 60;
+ break;
+ }
Is this the right "default"? It may be a good choice for a backend with a
really
tiny buffer (1 ... 999). But less good for a (theoretical) backend with a
larger
buffer (10001 ... infinity and beyond). Which are you
> This is v2 of the patch series. Changes from version 1:
>
> o Added acks. arm, ia64, and sh are only ones without acks.
ia64 bits look OK
Acked-by: Tony Luck
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listin
> But IRQ_PER_CPU wasn't removed from any of the architecture Kconfig
> files where it was defined or selected. It's completely unused so remove
> the remaining references.
Acked-by: Tony Luck
[Hope someone picks up this whole patch ... otherwise I can take the ia64 hunk]
___
> until part 5 (when ia64 sees the changes to match). You could either merge
> part
> 5 into part 2 (to make a combined x86+ia64 piece
Doh! I see that you already did this in the re-post you did a few hours
ago (which my mail client had filed away in my linux-arch folder).
-Tony
>>> + for (i = 0; i < dimm->mci->n_layers; i++) {
>>> + printk(KERN_CONT "%d", dimm->location[i]);
>>> + if (i < dimm->mci->n_layers - 1)
>>> + printk(KERN_CONT ".");
>>> + }
>>> + printk(KERN_CONT "\n");
>>
>> This looks hacky but I don't have a good su
diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index 38280ef..849805a 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -23,6 +23,7 @@ config IA64
select HAVE_ARCH_TRACEHOOK
select HAVE_DMA_API_DEBUG
select HAVE_GENERIC_HARDIRQS
+ select HAVE_PC_PARPORT
> Given there is no use case for the residue value returned by
> copy_mc_to_kernel() perhaps just return EHWPOISON directly from
> copyuser_highpage_mc() in the short-copy case?
I don't think it hurts to keep the return value as residue count. It isn't
making that code any more complex and could b
>> +INIT_WORK(&p->work, do_sched_memory_failure);
>> +p->pfn = pfn;
>> +schedule_work(&p->work);
>
> There is already memory_failure_queue() that can do this. Can we use it
> directly?
Miaohe Lin,
Yes, can use that. A thousand thanks for pointing it out. I just tried it, and
it work
>> When we do return to user mode the task is going to be busy servicing
>> a SIGBUS ... so shouldn't try to touch the poison page before the
>> memory_failure() called by the worker thread cleans things up.
>
> What about an RT process on a busy system?
> The worker threads are pretty low priority
>> But maybe it is some RMW instruction ... then, if all the above options
>> didn't happen ... we
>> could get another machine check from the same address. But then we just
>> follow the usual
>> recovery path.
> Let assume the instruction that cause the COW is in the 63/64 case, aka,
> it is
>> +vfrom = kmap_local_page(from);
>> +vto = kmap_local_page(to);
>> +ret = copy_mc_to_kernel(vto, vfrom, PAGE_SIZE);
>
> In copy_user_highpage(), kmsan_unpoison_memory(page_address(to), PAGE_SIZE)
> is done after the copy when
> __HAVE_ARCH_COPY_USER_HIGHPAGE isn't defined. Do we need
>> Cannot call memory_failure() directly from the fault handler because
>> mmap_lock (and others) are held.
>
> Could you please explain which lock makes it unfeasible to call
> memory_failure() directly and
> why? I'm somewhat confused. But I agree using memory_failure_queue() should
> be a good
> Yeah, if it was ia64-only, it's a non-issue these days. It's dead and
> in pure maintenance mode from a kernel perspective (if even that).
There's not much "simultaneous" in the SMT on ia64. One thread in a
spin loop will hog the core until the h/w switches to the other thread some
number of cyc
ee-wide patches that they needed. Their time might
have been more productively spent fixing things that actually matter in modern
times.
Acked-by: Tony Luck
-Tony
[1] git log --no-merges --since=2year -- arch/ia64 | grep Author: | sort | uniq
-c | sort -rn
19 Author: Masahiro Yamada
11 Autho
> For what it's worth, Debian and Gentoo both have ia64 ports with active
> users (6.1 looks like it currently fails to build in Debian due to a
> minor packaging issue, but various versions of 6.0 were built and
> published, and one of those is running on the one ia64 Debian builder I
> personally
> diff --git a/lib/lockref.c b/lib/lockref.c
> index 45e93ece8ba0..2afe4c5d8919 100644
> --- a/lib/lockref.c
> +++ b/lib/lockref.c
> @@ -23,7 +23,6 @@
> }
> \
> if (!--retry)
> > > This broke powerpc (and presumably ia64 and sparc64) in current
> > > linux-2.6.git:
> >
> > I'm generating a "fixup patch" right now...
>
> thanks! Sorry about that: we cross-built on ARM but not on SMP non-x86
> platforms so this dependency/breakage went unnoticed.
Yes ... all ia64 buil
> Could you check the patch below? With this applied to latest -git, ia64
> buils fine for me in a cross-compiling environment. (but i dont know
> whether it boots ...)
Uni-processor build still fails with this patch (config is
arch/ia64/configs/tiger_defconfig
with CONFIG_SMP switched from =y
> could you try the full patchset that Travis has just sent and which i've
> put into x86.git, you can pull it from:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git
>
> it's a fixes only tree, ontop of Linus-very-latest. Head 4b9e425c25f84.
> [pull from ssh://master.ker
> I'm having trouble replicating this error. With the latest linux-2.6.git
> plus the patch I just sent, I get the following errors:
>
> drivers/input/mouse/psmouse-base.c:45: error: __param_proto causes a section
> type conflict
> drivers/md/md.c:5881: error: __param_start_ro causes a section ty
> ah, that was the vital clue. The patch below makes the small memory
> model only defined on SMP, and makes the config build/link fine here.
> Does this build and boot on your box?
I applied this on top of the git pull from
git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git
a
> could you send the .config you are using?
Ok. Attached.
-Tony
upconfig
Description: upconfig
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
> this i believe builds an implicit dependency between the mca_asm.o
> position within the image and the ia64_mca_data percpu variable it
> accesses - it relies on the immediate 22 addressing mode that has 4MB of
> scope. Per chance, the .config you sent creates a 14MB image, and the
> percpu v
> I'll start digging on why this doesn't boot ... but you might as well
> send the fixes so far upstream to Linus so that the SMP fix is available
Well a pure 2.6.24 version compiled with CONFIG_SMP=n booted just fine, so
the breakage is recent ... and more than likely related to this change.
I'v
> hm, as far as i could check, on ia64 UP the .percpu section link
> difference was the only ia64 difference i could find out of those
> changes. Could you try to copy a 2.6.24 include/asm-generic/percpu.h,
> include/asm-ia64.h and include/linux/percpu.h into your current tree,
> and see whethe
> So the percpu changes are innocent ... something else since 2.6.24 is
> to blame. Only 5749 commits :-) I'll start bisecting.
12 bisections later ... nothing! I think I got lost in the
maze. Bisection #5 had a crash, but it looked to be a very
differnt crash (and looked to happen later than
> Applied that patch and UP kernel built ok, and then crashed in the
> same place with the memset() to a user-looking address from kmem_cache_alloc()
>
> So the percpu changes are innocent ... something else since 2.6.24 is
> to blame. Only 5749 commits :-) I'll start bisecting.
The bisection na
>> Make dereference_function_descriptor() more accommodating by allowing
>> architecture overrides. I put the three overrides (for parisc64, ppc64
>> and ia64) in arch/kernel/module.c because that's where the kernel
>> internal linker which knows how to deal with function descriptors sits.
>>
>> S
> I didn't have a chance to test that I didn't break ia64, so I would
> be if somebody could give it a spin there ! Thanks !
All my ia64 config variations still build cleanly with
these two patches applied. I booted a couple of systems
too with no obvious ill-effects.
I have the same set of "leg
> So, my reasoning here is: this notifier should fit the info list,
> definitely! But...it's very high risk for kdump. It deep dives into the
> regmap API (there are locks in such code) plus there is an (MM)IO write
> to the device and an ARM firmware call. So, despite the nature of this
> notifier
> Tony / Dinh - can I just *skip* this notifier *if kdump* is set or else
> we run the code as-is? Does that make sense to you?
The "skip" option sounds like it needs some special flag associated with
an entry on the notifier chain. But there are other notifier chains ... so that
sounds messy to m
> What I'm planning to do in the altera_edac notifier is:
>
> if (kdump_is_set)
> return;
Yes. That's what I think should happen.
-Tony
>> The heuristic always initializes the MSR with the per mm PASID IIF the
>> mm has a valid PASID but the MSR doesn't have one. This heuristic usually
>> happens only once on the first #GP in a thread.
>
> But it doesn't guarantee the PASID is the right one. Suppose both the mm
> has a PASID and th
> Are we planning to keep PASID live once a task has used it once or are we
> going to swap it lazily? If the latter, a percpu variable might be better.
Current plan is "touch it once and the task owns it until exit(2)"
Maybe someday in the future when we have data on how applications
actually
> So what’s the RDMSR for? Surely you
> have some state somewhere that says “this task has a PASID.”
> Can’t you just make sure that stays in sync with the MSR? Then, on #GP, if
> the task already has a PASID, you know the MSR is set.
We have state that says the process ("mm") has been allocate
On Wed, Mar 15, 2017 at 03:02:34PM -0700, Till Smejkal wrote:
> I don't agree here. VAS segments are basically in-memory files that are
> handled by
> the kernel directly without using a file system. Hence, if an application
> uses a VAS
> segment to store data the same rules apply as if it uses
Tested patch series on ia64 successfully.
Tested-by: Tony Luck
After this goes upstream, you should submit a patch to get rid of
all uses of %pF (70 instances in 35 files) and %pf (63 in 34)
Perhaps break the patch by top-level directory (e.g. get all the %pF
and %pF in the 17 files under drive
> speaking of upstream, any objections if this patch set will go through
> the printk tree, in one piece?
Seems to be a better idea than trying to coordinate pulls from three
separate "arch/" trees. Fine with me.
-Tony
On Fri, Nov 10, 2017 at 08:48:29AM +0900, Sergey Senozhatsky wrote:
> -Examples::
> -
> - printk("Going to call: %pF\n", gettimeofday);
> - printk("Going to call: %pF\n", p->func);
> - printk("%s: called from %pS\n", __func__, (void *)_RET_IP_);
> - printk("%s: called from %pS\n", _
On Fri, Nov 10, 2017 at 08:48:24AM +0900, Sergey Senozhatsky wrote:
> All Ack-s/Tested-by-s were dropped, since the patch set has been
> reworked. I'm kindly asking arch-s maintainers and developers to test it
> once again. Sorry for any inconveniences and thanks for your help in
> advance.
> The default limit of only 65536 VMAs will also quickly come into play
> if consecutive anon mmaps don't get merged. Of course this can be
> raised, but it has significant resource and performance (fork) costs.
Could the random mmap address chooser look for how many existing
VMAs have space befor
> I thought the cache-aligned might make sense, since usually we'd expect the
> failure to be at a cache-line level, but our copy_tofrom_user does accurate
> accounting
That's one of the wrinkles in the current x86 memcpy_mcsafe(). It starts by
checking alignment of the source address, and moves a
On Sat, Sep 16, 2017 at 12:53:42PM +0900, Sergey Senozhatsky wrote:
> Hello
>
> RFC
>
> On some arches C function pointers are indirect and point to
> a function descriptor, which contains the actual pointer to the code.
> This mostly doesn't matter, except for cases when people
50 matches
Mail list logo
