>> Ah crap, I see the problem, nioc is most often equal to rioc. Dang.
>> Please try this bandaid, will push a real fix now.
Patches arriving faster than I can test :-) ... The bandaid appears to
be working (no hang yet).
> This is way cleaner.
Will try this next.
-Tony
--
To unsubscribe from t
> > > 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
Trying to boot a build of the latest BK on ia64 I see
a series of messages like this:
mm/memory.c:99: bad pgd e001feba4000.
mm/memory.c:99: bad pgd e001febac000.
mm/memory.c:99: bad pgd e001febc0d10.
mm/memory.c:105: bad pmd f000eef3f200.
mm/memory.c:105: bad pmd f000eef3f000e2c3.
Builds clean and boots on ia64.
I haven't tried any hugetlb operations on it though.
-Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
>> For example, you may have a single page (start,end) address range
>> to free, but if this is enclosed by a large enough (floor,ceiling)
>> then it may free an entire pgd entry.
>>
>> I assume the intention of the API would be to provide the full
>> pgd width in that case?
>
>Yes, that is what s
>> be changed to use pgd_addr_end() to gather up all the vma that
>> are mapped by a single pgd instead of just spanning out the next
>> PMD_SIZE?
>
>Oh, I don't think so. I suppose it could be done at this level,
>but then the lower levels would go back to searching through lots
>of unnecessary c
>How it works is that it knows the extent in each direction
>where mappings do not exist.
>
>Once we know we have a clear span up to the next PMD_SIZE
>modulo (and PUD_SIZE and so on and so forth) we know we
>can liberate the page table chunks covered by such ranges.
Ok ... I see that now (I was m
+* Why all these "- 1"s? Because 0 represents both the bottom
+* of the address space and the top of it (using -1 for the
+* top wouldn't help much: the masks would do the wrong thing).
+* The rule is that addr 0 and floor 0 refer to the bottom of
+* the add
>This patch does:
> - consolidate the three implementations of compat_sys_waitid
> (some were called sys32_waitid).
> - adds sys_waitid syscall to ppc
> - adds sys_waitid and compat_sys_waitid syscalls to ppc64
>
>Parisc seemed to assume th existance of compat_sys_waitid.
>On Tue, Feb 22, 2005 at 09:41:04AM -0500, Jes Sorensen wrote:
>> >> + if (page->flags & PG_uncached)
>>
>> Andrew> dude. That ain't gonna work ;)
>>
>> Pardon my lack of clue, but why not?
>
>I think you're supposed to always use test_bit() to check page flags
You defined PG_uncached as "20" .
>OK, attached is my first cut at slimming down the boundary tests.
>I have only had a chance to try it on i386, so I hate to drop it
>on you like this - but I *have* put a bit of thought into it
>Treat it as an RFC, and I'll try to test it on a wider range of
>things in the next couple of days.
>Though my knowledge of out-of-tree patches is very limited,
>I believe "end == 0" is not possible on any arch - when "end"
>originates from vma->vm_end (or vm_struct->addr + size). There
>are plenty of "BUG_ON(addr >= end)"s dotted around to support that,
>and other places that would be confused
David Mosberger pointed out to me that 2.6.11-rc1 kernel scores
very badly on ia64 in lmbench pipe throughput test (bw_pipe) compared
with earlier kernels.
Nanhai Zou looked into this, and found that the performance loss
began with Linus' patch to speed up pipe performance by allocating
a circular
>Maybe lmbench could add a feature that bw_pipe will fork CPU
>number of children to measure the average throughput.
>
>This will give a much reasonable result when running bw_pipe
>on a SMP Box, at least for Linux.
bw_pipe (along with most/all of the lmbench tools already has
a "-P" argument t
> > Ahh so the need to be able to expand per cpu memory storage on demand
> > is not as critical as we thought.
> >
>
> Yes, but still desirable for future optimizations.
>
> For example, I do think using a per cpu memory storage on net_device refcnt &
> last_rx could give us some speedups.
We
+# Maximum of 128 MB cpu_alloc space per cpu
+config CPU_AREA_ORDER
+ int
+ default "13"
Comment only matches code when page size is 16K ... and we are (slowly)
moving to 64k as the default (which with order 13 allocation would mean
512M)
-Tony
-
To unsubscribe from this list: send th
> These patches propose to break the recursion instead by removing the
> linux/pagemap.h -> linux/highmem.h inclusion. I'd like to know
> whether there are any fundamental reasons that this include should be
> preserved.
Not fundamental reasons, but these patches break the ia64 build for most
con
> One user encountering this behavior is the CPE handler (in
> arch/ia64/kernel/mca.c). When the CPE handler encounters too many
> CPEs (such as a solid single bit error), it sets up a polling timer
> and disables the CPE interrupt (to avoid excessive overhead logging
> the stream of single bit e
> Looks good.
Looks good to me too (I'm to blame for the version posted by Doug
that only fixed ia64 ... I didn't take the time to check whether
there was a CONFIG_COMPAT option for x86_64 ... oops).
> Tony, perhaps it would make sense to define some common CONFIG
> for COMPAT_FOR_U64_ALIGNMENT l
> Half dozens?
I was imagining having to have "help" messages ... which of course we don't.
> config COMPAT_FOR_U64_ALIGNMENT
> bool
> default y
Plausible.
Randy suggested:
> def_bool y
Which is better. But if we unconditionally set this CONFIG variable, then the
code in fs/
At the moment our problem is that there is some code that has
been added to handle the compatability problem caused by u64
objects having different alignment when running on 32-bit and
64-bit systems. This only affects ia64 and x86-64 because all
the other 32/64 bit capable systems wisely avoided
> Sorry about that. I thought my review had caught all of these.
I missed it too (my old gcc version 3.4.6 doesn't pop a warning
for this).
Presumably the same change is needed for clocksource_itc in
arch/ia64/kernel/time.c
-Tony
-
To unsubscribe from this list: send the line "unsubscribe linux
Checking for section mismatches across all of vmlinux is kicking
out a bunch of new warnings. Many of them real, but I have a
few from routines like this:
foo(...)
{
static int first_time = 1;
if (first_time) {
all_i_need = alloc_bootmem(NR_CPUS * xxx);
This issue wandered off onto a long thread "build fix for x86_64" which
died out without a final patch. Here's the summary:
> +#if defined(CONFIG_X86_64) || (defined(CONFIG_IA64) &&
> defined(CONFIG_COMPAT))
It was pointed out that x86-64 also has a CONFIG_COMPAT, so the "right"
#ifdef mess wou
> This patch eliminates the warnings when the clocksoure isn't used.
> It also removes some other unused stuff that goes along with the
> clocksource ..
>
> I don't have access to an ia64 machine, or even a compiler .. So this
> one is untested for that. I'm hoping one of the ia64 guys can help
> t
> > Caused-By : Thomas Renninger <[EMAIL PROTECTED]>
> > commit 29b71a1ca74491fab9fed09e9d835d840d042690
> A patch was sent to Tony. AFAIK it got accepted, not sure whether it
> already is in any and which git tree...
The suggested patch adds manual padding to the acpi_dev
> +#define atomic_read(v) (*(volatile __s32 *)&(v)->counter)
> +#define atomic64_read(v) (*(volatile __s64 *)&(v)->counter)
>
> #define atomic_set(v,i) (((v)->counter) = (i))
> #define atomic64_set(v,i)(((v)->counter) = (i))
Losing the volatile from the "set"
- mca_data = alloc_bootmem(sizeof(struct ia64_mca_cpu)
-* NR_CPUS + KERNEL_STACK_SIZE);
+ mca_data = mca_bootmem(NR_CPUS + KERNEL_STACK_SIZE);
Oops. You moved the multiply by sizeof(struct ia64_mca_cpu) up into
the mca_bootmem()
> commit b716395e2b8e450e294537de0c91476ded2f0395
> Handled-By : Luck, Tony <[EMAIL PROTECTED]>
> Patch1 : http://lkml.org/lkml/2007/7/20/255
> Patch2 : http://lkml.org/lkml/2007/7/20/272
> Status : patch available
Just sent the "please p
With CONFIG_SUSPEND=n I get build errors from at least a couple of
files because of the use of ENOSYS in the stub for pm_suspend().
Should those .c files be forced to include errno.h? Or should we
have the include in pm.h? Assuming the latter ...
Signed-off-by: Tony Luck <[EMAIL PROTECTED]>
---
> > Oops. You moved the multiply by sizeof(struct ia64_mca_cpu) up into
> > the mca_bootmem() function to make it very specific to this use. But
> > mutiply has higher precedence than addition.
>
> Oh crap - good catch.
> Shall I resubmit a corrected patch?
Are there any other ways that we might
> commit 8c8eb78f673c07b60f31751e1e47ac367c60c6b7
Oops. I cut & pasted the wrong commit id. The fix went in as
commit 7091138fb762aed22317b4ff91eb211e7da3865c.
> FYI, I did a git pull yesterday just before I hit this issue so I should
> have had the latest stuff.
So this confuses me. Linus pu
+ } else if (family == 0x20)
+ memcpy(brand, "Montecito", 10);
NAK.
We don't really have names for the different cpu families. "Montecito"
is definitely not the right string to apply here (Montvale will also
have family == 0x20). The old McKinley/Madison strin
> This seems crazy to me. Flushing should occur according to the
> *architecture*, not model-by-model. Even if we happen to get "lucky"
> on pre-Montecito CPUs, that doesn't justify such ugly hacks. Or you
> really want to debug this *again* come next CPU?
Ditto. The only reason we should ever
> Tony, it looks like the patch has not hit Linus tree yet:
Huh? I can see it in his tree via gitweb. Here's the patch:
http://tinyurl.com/3csnu6
and the raw "blob" for sba_iommu.c:
http://tinyurl.com/397cy6
[Scroll down to line 2018 and you'll see the new code in place].
S
> The following commit (4994be1b3fe9120c88022ff5c0c33f6312b17adb) broke
> Linus' Tree between 2.6.22-git15 and 2.6.22-git16 on a 2-node 8-way x455
> (Madison procs). Thanks to Ryan Hodges for bisecting down to this
> commit.
Thanks for taking the time to do the git bisect to identify the problem c
> Adrian Bunk: scripts/mod/file2alias.c is compiled with HOSTCC and ensures that
> kernel_ulong_t is correct, but it can't cope with different padding on
> different architectures.
Surely this is the root cause ... you can't expect that the alignment
rules of HOSTCC to make any sense for an arbitr
>>> struct acpi_device_id {
>>> __u8 id[ACPI_ID_LEN];
>>> + __u8 dummy[FILLUP_LEN];
>>> kernel_ulong_t driver_data;
>>> };
>>
>> What's so special about this structure that we get an error?
>
> It's special because it's a device_id structure, and those structures
> must come out identic
This version looks really clean. Thank for keeping working on
this through 9 versions!
A couple of small issues.
1) In arch/ia64/mm/init.c: __ia64_sync_icache_dcache()
- if (!pte_exec(pte))
- return; /* not an executable page... */
+ BUG_ON(!pte
> What about code-size?
textdata bss dec hex filename
9499911 911620 1313065 11724596 b2e734 vmlinux-before
textdata bss dec hex filename
9504047 911620 1313065 11728732 b2f75c vmlinux-after
So about 4K extra. In the kernel I built (tiger_
> That's distressing. I'm about to resubmit with a volatile cast in
> atomic_set as well, since people expect that behavior and I've been
> shown a legitimate case where it could matter. Does the assembly look
> right with that cast in atomic_set() as well?
No. With the casts to volatile in
> Use atomic64_read to read an atomic64_t.
Thanks Andreas!
Chris: This bug is why the 8-byte loads got changed to 4-byte + sign-extend
by your change to atomic_read().
With this applied together with shuffling the volatile from the
declaration to the usage (in both atomic_read() and atomic_set()
> Possibly. Either that or we've uncovered some latent bugs. Maybe a
> combination of the two. Can you list those 19 changes so we can
evaluate them?
Here are the functions in which they occur in the object file. You
may have to chase down some inlining to find the function that
actually uses
> Here are the functions in which they occur in the object file. You
> may have to chase down some inlining to find the function that
> actually uses atomic_*().
Ignore this ... Andreas' patch was only two lines so I
thought I'd "save time" by just hand-editing the source over
on my build machine.
> Solution (1) above sounds preferable, unless there are mysterious reasons
> why ia64 wants to avoid Kconfig.preempt (adding Tony Luck to Cc:).
Send me a patch and unless it causes more problems than it solves, I'll
put it in.
-Tony
-
To unsubscribe from this list: send the line "unsubscribe lin
@@ -4084,6 +4084,7 @@ P:Pat Gefre
M: [EMAIL PROTECTED]
L: [EMAIL PROTECTED]
S: Supported
+F: Documentation/ia64/serial.txt
SGI VISUAL WORKSTATION 320 AND 540
P: Andrey Panin
Huh? Perhaps this should be:
+F: drivers/serial/sn_console.c
-Tony
-
To unsubscr
> Use volatile consistently in atomic.h on ia64.
> This will do weird things without Andreas Schwab's fix:
> http://lkml.org/lkml/2007/8/10/410
The build is very noisy with the inline versions of atomic_{read,set}
and their 64-bit siblings. Here are the prime culprits (some of them
repeat >100 ti
>> include/linux/skbuff.h:521: warning: passing arg 1 of `atomic_read' discards
>> qualifiers from pointer target type
>> include/net/sock.h:1244: warning: passing arg 1 of `atomic_read' discards
>> qualifiers from pointer target type
>> include/net/tcp.h:958: warning: passing arg 1 of `atomic_re
+ printk(KERN_INFO "Building NUMA distance from ACPI 2.0 SLIT\n");
This printk just looks like noise during boot. Surely this
is normal behavior on a NUMA system?
+ printk(KERN_INFO "No SLIT table, defaulting NUMA distance\n");
But this one deserves more prominence than just KERN_IN
> -#define ACPI_ID_LEN 9
> +#define ACPI_ID_LEN 16 /* only 9 bytes needed here, 16 bytes are used */
What will happen if someone uses more than 9 bytes? With the old
limit there would be a compile time error it someone initialized
with:
{"PNP0C0ABCDEFGH", 0},
But if we change ACPI_ID_
>> 6674: while (atomic_read(&j->DSPWrite) > 0)
>> 6675- atomic_dec(&j->DSPWrite);
>
> If the maintainer of this code doesn't see a compelling reason to add
> cpu_relax() in this loop, then it should be patched.
Shouldn't it be just re-written without the loop:
if ((tmp = atom
> This?
That does the trick, yes.
> (please tell me if you want me to send this to Linus)
I've put it in my tree now ... so I'll ask Linus to pull
it from there.
-Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More ma
Just pulled latest git tree from Linus and a few ia64 configurations
(anything with CONFIG_NUMA=y) won't build.
The offending commit appears to be:
230140cffa7feae90ad50bf259db1fa07674f3a7
Here's the error messages from the compiler:
CC [M] drivers/infiniband/core/cma.o
In file included
> kexec.h is needed by arch/ia64/kernel/process.c so for the
> declaration of kexec_disable_iosapic() which is used in machine_shutdown().
> +#include
I merged this into your earlier change (moving machine_shutdown() into
process.c). Linus pulled it last night.
I also added a "#ifdef CONFIG_KE
On Sun, Feb 11, 2007 at 09:30:21PM -0800, Roland Dreier wrote:
> This patch fixes this by converting dma_{alloc,free}_noncoherent()
> into inline functions that call the corresponding coherent functions,
> instead of trying to do this with macros.
>
> Signed-off-by: Roland Dreier <[EMAIL PROTECTED
> Long term it may make sense for us to give ourselves plenty of
> planning slop of more like 24 months, so if one location doesn't work
> out we have time to work out another one.
That looks way too conservative. If kernel summit had 500+ attendees, I
can see why you'd need a such long lead time
On Tue, Jan 30, 2007 at 07:11:34AM +0100, Jes Sorensen wrote:
> > Not sure that abstract of a discussion thing would really work though.
> > It seems a bit contradicting in itself.
>
> I was thinking more an abstract as in something that should provide a
> short summary of the problem and why it s
Ralph,
I'm seeing dozens of build warnings and errors on ia64 from
infiniband. According to git you touched it last, so even
if you aren't to blame, you are by definition an expert :-)
E.g.
In file included from include/rdma/ib_addr.h:37,
from drivers/infiniband/core/addr.c:39:
> Since pci.h includes it seems like the fix would be
> to move the two lines:
> #define sg_dma_len(sg) ((sg)->dma_length)
> #define sg_dma_address(sg) ((sg)->dma_address)
> to include/asm-ia64/scatterlist.h
Sounds like a good plan ... a test build with this change fixed
> This patch-set aims at removing the current limit on argv+env space aka.
> MAX_ARG_PAGES.
Running with this patch shows that /bin/bash has some unpleasant
O(n^2) performance issues with long argument lists. I made a
1Mbyte file full of pathnames, then timed the execution of:
$ /bin/echo `cat m
> > Interesting. If you're exceeding your stack ulimit, you should be
> > seeing either an "argument list too long" message or getting a
> > SIGSEGV. Have you tried bypassing wc and piping the output straight
> > to a file?
>
> I think it sends SIGKILL on failure paths.
Setting stack limit to un
> > > A good heuristic, though, might be to limit
> > > argument size to a percentage (say 25%) of maximum stack size and
> > > validate this inside copy_strings().
> >
> > This seems to do:
>
> Looks good.
Me too. As I increase the number of arguments, I now have
a smooth cutover from "works"
> > ret = cmpxchg(&last_cycle, last, new);
> > if (ret == last)
> > return new; /* you win! */
> > else
> > return ret; /* you lose. ret is winner's new */
>
> Interesting solution. But there may be multiple updates of last happening.
> Which of the winners is the real winner?
It mi
> I just tried this on an Altix from the test lab, and ia32 bash just
> started.
I don't have any native x86 binaries on my Madison-based testbox, so my
test case was to compile a simple program that counted total length of
argument strings on an x86 box, and copy it to my ia64 box. So that I
wou
> Hmmm - I wonder if my tree is screwed up in some weird way. I'm seeing link
> warnings as well:
>
> WARNING: init/built-in.o - Section mismatch: reference to .init.data: from
> .sdata after 'root_mountflags' (at offset 0x38)
I thought that I'd got the section mis-match warnings down to
just one
> `.exit.text' referenced in section `.init.text' of drivers/built-in.o:
> defined in discarded section `.exit.text' of drivers/built-in.o
This one is a fatal error ... the code is trying to call a function
that has been marked __exit in a driver that has been built-in, instead
of as a module.
> Ahh okay. cscope will do that too But all have __exit.
The trick is that one of them *shouldn't* have __exit. With cscope
you'll have to use the "Find functions calling this function:"
mode to try and find the __init function that is calling an
__exit function.
-Tony
-
To unsubscribe from
> Tony, the ia64 section mismatch "whack-a-mole" is far from over :(
Can you post the .config file that you are using when you see all those
warnings ... I'll start bopping them on their cute little heads.
-Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
> Tony, what system are you using to compile on, OS, etc?
$ cat /etc/redhat-release
Red Hat Enterprise Linux AS release 4 (Nahant Update 5 Beta)
-Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at ht
> I used the sn2_defconfig in the tree :)
So there is something odd happening. Russ complained that he
was still seeing several errors from the sn2_defconfig build
too when I posted the "last fix" to Len. But I don't see them
when I build.
-Tony
-
To unsubscribe from this list: send the line "u
> So is
>
> while (__raw_spin_is_locked(&v));
>
> supposed to work? Or should that be
>
> while (__raw_spin_is_locked(&v))
> cpu_relax();
>
> as well and all the volatiles can/should go away?
cpu_relax() is a really good idea in every spinloop on
hyper-threaded cores. I
> I wonder if there are other uses for the free space?
unsigned long moreflags;
Nick and Hugh were just sparring over adding a couple (or perhaps 8)
flag bits. This would supply 64 new bits ... maybe that would keep
them happy for a few more years.
-Tony
-
To unsubscribe from this list:
> > Saw this when running strace -f on a script on 2.6.21 on ia64:
> >
> > BUG: sleeping function called from invalid context at kernel/fork.c:385
> > in_atomic():1, irqs_disabled():0
... snip ...
> > I could reproduce it via 'strace -f sleep 1'
> >
>
> I'd say this is specific to ia64. Som
> So as ALIGN macro does the same work as ROUNDUP,
Although it is mathematically the same operation, the
semantic associations of the name are important too.
If I have an I/O device that works in blocks of a given
size, I don't think that I'm "aligning" a request to make
it match the capabilities
> We've tested the following architectures: i386, x86_64, um/i386,
> parisc, and frv. These are representative of the various scenarios
> which this patch addresses, but other architecture teams should try it
> out to make sure there aren't any unexpected gotchas.
Doesn't build on ia64: complaint
> You could add them to scripts/checksyscalls.sh itself -- I think it's
> fairly unlikely that those are syscalls which a new arch port is going
> to 'forget' :)
Like this?
diff --git a/scripts/checksyscalls.sh b/scripts/checksyscalls.sh
index f98171f..4d49056 100755
--- a/scripts/checksyscalls.s
+#ifndef is_affinity_mask_valid
+#define is_affinity_mask_valid() 1
+#endif
+
int no_irq_affinity;
static int irq_affinity_write_proc(struct file *file, const char __user
*buffer,
unsigned long count, void *data)
@@ -42,6 +46,9 @@ static int irq_affinity_writ
Looks more complex than necessary. Why do you want to execute
an arch specific script to list the __IGNORE symbols? That would
allow an arch to generate a list with sed/perl/etc. but that
looks like overkill.
If you just have an arch specific file with the right defines.
E.g. for x86_64 in inclu
> It had a dopey little bug:
>
> -#define is_affinity_mask_valid() 1
> +#define is_affinity_mask_valid(val) 1
That would fix warnings on non-ia64 systems (which is
a step in the right direction). But on ia64 I have
the
#define is_affinity_mask_valid is_affinity_mask_valid
in play at that point,
> This implements granule page sized vmemmap support for IA64.
Christoph,
Your calculations here are all based on a granule size of 16M, but
it is possible to configure 64M granules.
With current sizeof(struct page) == 56, a 16M page will hold enough
page structures for about 4.5G of physical sp
On Fri, Apr 13, 2007 at 02:01:40AM +0530, Milind Arun Choudhary wrote:
> - size = ROUNDUP(size, iovp_size);
> + size = ALIGN(size, iovp_size);
Why is "ALIGN" better than "ROUNDUP"? I can't see any point
to this change.
-Tony
-
To unsubscribe from this list: send the line "unsubscribe lin
> What I'm proposing we do is move the irq allocation code out of
> pci_enable_device and the irq freeing code out of pci_disable_device
> in the future.
Sounds rational ... in a world that wasn't dominated by PCI it would
seem to be the logical approach (since the irq code would have much
more ut
> I'm a bit lost here. Are we referring to
>
> if (expr) {
> ...
> } else {
> ...
> }
>
> versus
>
> if (expr) {
> ...
> }
> else {
> ...
> }
This one is already covered by Documentation/CodingStyle
On Fri, Jul 22, 2016 at 04:12:04AM -0300, Marcelo Tosatti wrote:
> How does this patchset handle the following condition:
>
> 6) Create reservations in such a way that the sum is larger than
> total amount of cache, and CPU pinning (example from Karen Noel):
>
> VM-1 on socket-1 with 80% of reser
On Wed, Jul 27, 2016 at 11:20:31AM -0500, Nilay Vaish wrote:
> And over here you have switched to using CLOS ID and you do not
> mention Cache ID at all.
> As I said above, I think Cache ID and CLOS ID are the same thing. If
> that is the case, I think Cache ID should be completely replaced with
>
> Just for my info, why do we need not update MSRs when a cpu goes offline?
The CBM (cache bitmask) MSRs are shared by all the cpus that use that same
cache. So
they mustn't be updated when some of the CPUs go offline, because the remaining
ones
are still using them. I suppose you could do somet
On Tue, Sep 13, 2016 at 03:40:18PM -0700, Dave Hansen wrote:
> Are you sure you don't want to add RDT to disabled-features.h? You have
> a config option for it, so it seems like you should also be able to
> optimize some of these checks away when the config option is off.
Makefile looks like this
On Tue, Sep 13, 2016 at 04:13:04PM -0700, Dave Hansen wrote:
> Yikes, is this a new global lock and possible atomic_inc() on a shared
> variable in the fork() path? Has there been any performance or
> scalability testing done on this code?
>
> That mutex could be a disaster for fork() once the fi
> What are we doing with the recovery bool? You want to keep the cmdline
> switch: mce=recovery?
I want to keep if for new systems ... there will be a lag between me getting
them, and adding new quirks.
> Btw, it needs documenting over mcheck_enable().
Yes - should have been done before. Will s
> You could alternatively use flush and make the worker code schedule the
> work on a still online CPU in the domain instead of blindly rescheduling it
> on the same CPU.
We looked at that when you suggested flush. The problem is that we have
already deleted the current cpu from the bitmask for th
> One thing I missed commenting on in the previous version -
>
> Have you thought of exposing the error records via /sys/firmware/acpi?
> The tables are already exposed there and as BERT is part of ACPI
> logically that's a better fit compared to a misc device.
That was my first thought :-)
But I
From: Tony Luck
Speculative processor accesses may reference any memory that has a
valid page table entry. While a speculative access won't generate
a machine check, it will log the error in a machine check bank. That
could cause escalation of a subsequent error since the overflow bit
will be th
On Thu, Aug 17, 2017 at 11:25:23AM +0100, Punit Agrawal wrote:
> Though, I am OK with "table-data/BERT" as well.
So I coded this up ... and it looks much better than I thought
it might. A bit larger than the previous version that modified
drivers/acpi/apei/bert.c. But on the plus side easy to ext
On Thu, Aug 17, 2017 at 09:28:53PM +0200, Rafael J. Wysocki wrote:
> What about /sys/firmware/acpi/tables/data/ and then one file per table
> under it with the same name as the table file under tables/ ?
"data" works. ACPI table names are all upper-case, so it
can't conflict. Any programs that sca
From: Tony Luck
The ACPI sysfs interface provides a way to read each ACPI table from
userspace via entries in /sys/firmware/acpi/tables/
The BERT table simply provides the size and address of the error
record in BIOS reserved memory and users may want access to this
record.
In an earlier age we
201 - 300 of 1172 matches
Mail list logo
