RE: x86/non-x86: percpu, node ids, apic ids x86.git fixup

2008-01-31 Thread Luck, Tony
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 whether

RE: x86/non-x86: percpu, node ids, apic ids x86.git fixup

2008-01-31 Thread Luck, Tony
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

RE: x86/non-x86: percpu, node ids, apic ids x86.git fixup

2008-02-05 Thread Luck, Tony
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

RE: [PATCH] Correct printk %pF to work on all architectures

2008-09-04 Thread Luck, Tony
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.

RE: [RFC/PATCH 1/2] pci: Add ability to mmap legacy_io on some platforms

2008-10-03 Thread Luck, Tony
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

RE: x86/non-x86: percpu, node ids, apic ids x86.git fixup

2008-01-30 Thread Luck, Tony
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

RE: x86/non-x86: percpu, node ids, apic ids x86.git fixup

2008-01-30 Thread Luck, Tony
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 type

RE: x86/non-x86: percpu, node ids, apic ids x86.git fixup

2008-01-30 Thread Luck, Tony
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 and

RE: x86/non-x86: percpu, node ids, apic ids x86.git fixup

2008-01-30 Thread Luck, Tony
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

RE: x86/non-x86: percpu, node ids, apic ids x86.git fixup

2008-01-30 Thread Luck, Tony
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

RE: x86/non-x86: percpu, node ids, apic ids x86.git fixup

2008-01-30 Thread Luck, Tony
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've

RE: [PATCH 00/11] Add compression support to pstore

2013-08-01 Thread Luck, Tony
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

RE: [RFC PATCH v2 00/11] Add (de)compression support to pstore

2013-08-16 Thread Luck, Tony
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 ___

RE: [RFC PATCH v2 04/11] pstore: Add compression support to pstore

2013-08-22 Thread Luck, Tony
1[ 383.209057] RIP [813d3946] sysrq_handle_crash+0x16/0x20 4[ 383.209057] RSP 88006f551e80 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

RE: [RFC PATCH v2 04/11] pstore: Add compression support to pstore

2013-09-04 Thread Luck, Tony
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

RE: [PATCH 1/3] pstore: Adjust buffer size for compression for smaller registered buffers

2013-09-11 Thread Luck, Tony
- 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

RE: [PATCH v2] pstore: Adjust buffer size for compression for smaller registered buffers

2013-09-12 Thread Luck, Tony
+ 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

RE: [PATCH 05/14] IA64: adapt for dma_map_ops changes

2012-03-27 Thread Luck, Tony
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

RE: [PATCH EDACv16 1/2] edac: Change internal representation to work with layers

2012-04-27 Thread Luck, 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 suggestion what to do instead here.

RE: [PATCH v4 0/8] Nvram-to-pstore

2013-06-19 Thread Luck, Tony
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

RE: [PATCH 3/3] powerpc/pseries: Support compression of oops text via pstore

2013-06-25 Thread Luck, Tony
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

RE: [RFC,PATCH] Cleanup PC parallel port Kconfig

2011-06-14 Thread Luck, Tony
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

RE: [PATCH v2 00/10] Kconfig: cleanup SERIO_I8042 dependencies

2013-12-18 Thread Luck, Tony
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 tony.l...@intel.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org

RE: [PATCH 1/1] arch Kconfig: remove references to IRQ_PER_CPU

2012-11-13 Thread Luck, Tony
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 tony.l...@intel.com [Hope someone picks up this whole patch ... otherwise I can take the ia64 hunk]

Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

2017-03-16 Thread Luck, Tony
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

Re: [PATCH 0/5] [RFC] printk/ia64/ppc64/parisc64: let's deprecate %pF/%pf printk specifiers

2017-09-18 Thread Luck, Tony
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

RE: [RFC][PATCH v2 0/7] printk/ia64/ppc64/parisc64: let's deprecate %pF/%pf printk specifiers

2017-09-22 Thread Luck, Tony
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

RE: [RFC][PATCH v2 0/7] printk/ia64/ppc64/parisc64: let's deprecate %pF/%pf printk specifiers

2017-09-25 Thread Luck, Tony
> 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

Re: [PATCHv4 0/6] printk/ia64/ppc64/parisc64: let's deprecate %pF/%pf printk specifiers

2017-11-10 Thread Luck, Tony
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.

Re: [PATCHv4 5/6] symbol lookup: introduce dereference_symbol_descriptor()

2017-11-10 Thread Luck, 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",

RE: [RESEND 2/3] powerpc/memcpy: Add memcpy_mcsafe for pmem

2018-04-06 Thread Luck, Tony
> 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

RE: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

2018-03-28 Thread Luck, Tony
> 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

RE: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Luck, Tony
> 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

RE: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Luck, Tony
> 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

RE: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Luck, 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