Christopher S. Aker wrote:
Has there been any progress on the race in SKAS? I've been dealing with
2-4 hosts crashing a week. Same thing happens on my old SKAS kernel,
2.6.7 with skas3-v4 or so.
Jeff and I realized that this only happens on Xeon processors where the
model number is > 2. No
/proc/cpuinfo -- model 3
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 3
model name : Intel(R) Xeon(TM) CPU 2.80GHz
stepping: 4
cpu MHz : 2801.996
cache size : 1024 KB
physical id : 0
siblings: 2
fdiv_bug: no
On Tuesday 25 October 2005 18:57, Christopher S. Aker wrote:
> /proc/cpuinfo -- model 3
After some researches, it seems that the matching errata document is this one:
http://www.intel.com/design/xeon/specupdt/302402.htm
which would imply you have a 64-bit enabled processor...
Note 1: that's not
Blaisorblade wrote:
After some researches, it seems that the matching errata document is this one:
http://www.intel.com/design/xeon/specupdt/302402.htm
which would imply you have a 64-bit enabled processor...
Note 1: that's not the only document matching, but the other is for 64-bit
processo
I have skas3-v8 host servers with model 4 processes and good (100+ day)
uptimes. The host server I had issues with (host38) got converted to
Xen and is still having problems. I am seeing issues with host34 that
require the odd restart. That server runs the same CPU model and kernel
code as o
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
Even here, we reuse values from one asm statement to the next without telling
this to GCC - so fix this.
While at it, a bit of improvements to the generated asm code, with better use of
constraints. Still TODO: convert all this to the sysca
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
Since the 4th param is unused, remove it altogether.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
---
arch/um/drivers/chan_kern.c |5 ++---
arch/um/drivers/chan_user.c |2 +-
arch/um/include/chan_user.h |4
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
In a previous patch I shifted an allocation to being atomic.
In this patch, a better but more intrusive solution is implemented, i.e. hold
the lock only when really needing it, especially not over pipe operations, nor
over the culprit alloc
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
Ugly trick to help make malloc not sleeping - we can't do anything else. But
this is not yet optimal, since spinlock don't trigger in_atomic() when
preemption is disabled.
Also, even if ugly, this was already used in one place, and was even
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
Jeff Dike noted that the assembly code for syscall stubs is misassembled with
GCC 3.2.3: the values copied in registers weren't preserved between one asm()
and the following one.
So I fixed the thing by rewriting the __asm__ constraints mor
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
The access_ok_tt() macro is bogus, in that a read access is unconditionally
considered valid.
I couldn't find in SCM logs the introduction of this check, but I went back to
2.4.20-1um and the definition was the same.
Possibly this was don
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
The problems in this area came to light while fixing a compile failure with
GCC 4, in commit bcb01b8a67476e6f748086e626df8424cc27036d. I went comparing this
code with x86_64 frame construction (which we should ABI compatible with) and
resync
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
Remove a stone-age comment (UM *does* have a MMU, i.e. the host), and fix a
dependency (introduced in commit 02edeb586ae4cdd17778923674700edb732a4741) to
do what was intended.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
The below warning was added in place of pte_mkyoung(); if (is_write)
pte_mkdirty();
In fact, if the PTE is not marked young/dirty, our dirty/accessed bit emulation
would cause the TLB permission not to be changed, and so we'd loop, and give
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
printk clears the host errno (I verified this in debugging and it's reasonable
enough, given that it ends via a write call on some fd, especially since
printk() goes on /dev/tty0 which is often the host stdout).
So save errno earlier. There'
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
We were using a long series of (stupid) wrappers which all call
generic_console_write(). Since the wrappers only change the 4th param, which is
unused by the called proc, remove them and call generic_console_write()
directly.
If needed at a
Peter wrote:
I have skas3-v8 host servers with model 4 processes and good (100+ day)
uptimes. The host server I had issues with (host38) got converted to
Xen and is still having problems. I am seeing issues with host34 that
require the odd restart. That server runs the same CPU model and ker
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
Remove RWSEM_GENERIC_SPINLOCK, it's now defined (only if needed) by the
underlying arch/i386/Kconfig.cpu. Leave it only for x86_64. Even there, it's
totally wrong, as they even have the code to support XCHG_ADD.
Signed-off-by: Paolo 'Blaiso
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
i386 enables the xchg based implementation of r/w semaphores for any processor
as good as 486. So it was quite interesting to see x86_64 never using it! And it
was even more interesting to see, in rwsem.h:
/* rwsem.h: R/W semaphores impleme
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
The current value was correct before the introduction of Intel EM64T support -
but now L1_CACHE_SHIFT_MAX can be less than L1_CACHE_SHIFT, which _is_ funny!
Between the few users of cacheline_maxaligned_in_smp, we also have (for
example
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
This was used in the old dark age of 2.4, ARCH_CFLAGS doesn't work any more
since some time, and UM_FASTCALL was never used in 2.6.
Instead, reintroduce the thing more properly now, directly in
include/asm-um/linkage.h.
Signed-off-by: Paol
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
I just noted that -mtune is used, which is only supported on recent GCCs; by
reading http://gcc.gnu.org/gcc-3.4/changes.html, you see "-mcpu has been renamed
to -mtune.", so for GCC < 3.4 we're not using any specific tuning in the
appropriat
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
Make UML share the underlying cpu-specific tuning done on i386.
Actually, for now many config options aren't used a lot - but that can be done
later. Also, UML relies on GCC optimization for things like memcpy and such more
than i386, so sp
On Wednesday 26 October 2005 00:13, Paolo 'Blaisorblade' Giarrusso wrote:
>
> I.e. the implementation was written, is present in the tree, but due to
> this:
>
> #ifdef CONFIG_RWSEM_GENERIC_SPINLOCK
> #include /* use a generic implementation */
> #else
> #include /* use an arch-specific implemen
> No correctness issues, obviously. So this could even be merged for 2.6.14
> (I'm not a fan of this idea, though).
I don't think it's a good idea to mess with this for 2.6.14
In general the maxaligned stuff is imho bogus and should be removed. That is
what CONFIG_X86_GENERIC is for. It doesn't
HT is not disabled on any of my boxes.
Christopher S. Aker wrote:
Peter wrote:
I have skas3-v8 host servers with model 4 processes and good (100+
day) uptimes. The host server I had issues with (host38) got
converted to Xen and is still having problems. I am seeing issues
with host34 that
On Wednesday 26 October 2005 00:22, Andi Kleen wrote:
> On Wednesday 26 October 2005 00:13, Paolo 'Blaisorblade' Giarrusso wrote:
> > I.e. the implementation was written, is present in the tree, but due to
> > this:
> >
> > #ifdef CONFIG_RWSEM_GENERIC_SPINLOCK
> > #include /* use a generic impleme
On Wednesday 26 October 2005 00:24, Andi Kleen wrote:
> > No correctness issues, obviously. So this could even be merged for 2.6.14
> > (I'm not a fan of this idea, though).
>
> I don't think it's a good idea to mess with this for 2.6.14
> In general the maxaligned stuff is imho bogus and should b
On Wednesday 26 October 2005 00:44, Blaisorblade wrote:
> For what I see, that's based on the tradeoff between space and contention -
> for instance there are few zones only, so there's no big waste.
If space is precious it shouldn't be padded at all.
> In practice, interpreting !X86_GENERIC as
On Wednesday 26 October 2005 01:33, Andi Kleen wrote:
> On Wednesday 26 October 2005 00:44, Blaisorblade wrote:
> > For what I see, that's based on the tradeoff between space and contention
> > - for instance there are few zones only, so there's no big waste.
> If space is precious it shouldn't be
30 matches
Mail list logo
