On 5/10/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
> After commenting out clear_kernel_mapping() line, the system would
> have sync flood and reset from time to time. However when with this
> clear_kernel_mapping() line, no system reset happened.
Hmm, that should not happen. Normally the problems
On 5/10/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
> After commenting out clear_kernel_mapping() line, the system would
> have sync flood and reset from time to time. However when with this
> clear_kernel_mapping() line, no system reset happened.
Hmm, that should not happen. Normally the problems
>
> As we know that CPU prefetch never cross the page boundary, in this
That only applies to sequential prefetch. But speculative execution can
prefetch pretty much any address. That is why the clear_kernel_mapping is
needed.
In BIOS setup, there's "Speculative TLB Reload". Is this "Speculativ
Hi,
The following is extracted from function gart_iommu_init()
..
/*
* Unmap the IOMMU part of the GART. The alias of the page is
* always mapped with cache enabled and there is no full cache
* coherency across the GART remapping. The unmapping avoids
* automatic prefetches from the CPU alloc
On 4/11/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
On Wed, 2007-04-11 at 17:53 +0800, Zhao Forrest wrote:
> I got some new information:
> Before soft lockup message is out, we have:
> [EMAIL PROTECTED] home]# cat /proc/slabinfo |grep buffer_head
> buffer_head 109279
On 4/11/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
On Wed, 2007-04-11 at 02:53 -0700, Paul Jackson wrote:
> I'm confused - which end of ths stack is up?
>
> cpuset_exit doesn't call do_exit, rather it's the other
> way around. But put_files_struct doesn't call do_exit,
> rather do_exit calls
: globalstat 37602996 11589379
11743736 01 6983 20507478
1708818 : cpustat 35254625 2350704 16027174 1068367
Does this huge number of buffer_head cause the soft lockup?
Thanks,
Forrest
On 4/11/07, Pekka Enberg <[EMAIL PROTECTED]> wrote:
On 4/11/07
0x2d2/0x8b1
[] cpuset_exit+0x0/0x6c
[] get_signal_to_deliver+0x427/0x456
[] do_notify_resume+0x9c/0x7a9
[] default_wake_function+0x0/0xe
[] audit_syscall_exit+0x2cd/0x2ec
[] int_signal+0x12/0x17
On 4/11/07, Pekka Enberg <[EMAIL PROTECTED]> wrote:
On 4/11/07, Zhao Forrest <[EMAIL PROTECTED]&g
Hi,
We're using RHEL5 with kernel version 2.6.18-8.el5.
When doing a stress test on raw device for about 3-4 hours, we found
the soft lockup message in dmesg.
I know we're not reporting the bug on the latest kernel, but does any
expert know if this is the known issue in old kernel? Or why
kmem_ca
Hi,
Sometimes we could hotplug a PCIE device, which require more MMIO
resource than that reserved by BIOS.
My question is: is there a way for kernel to reserved more MMIO
resource for a PCIE-hotplug-capable slot? I searched the
kernel-parameters.txt, but didn't find any related information.
Tha
Thanks for your report.
A git-bisect might be a bit of overkill considering that there were only
two patches applied beween 2.6.16.4 and 2.6.16.5:
Andi Kleen (2):
x86_64: Clean up execve
x86_64: When user could have changed RIP always force IRET (CVE-2006-0744)
I've attached both p
On 11/29/06, Adrian Bunk <[EMAIL PROTECTED]> wrote:
On Wed, Nov 29, 2006 at 12:18:18AM -0800, Zhao Forrest wrote:
> On 11/28/06, Andi Kleen <[EMAIL PROTECTED]> wrote:
> >
> >> I first need to contact the author of test case if we could send the
> >> tes
On 11/28/06, Andi Kleen <[EMAIL PROTECTED]> wrote:
> I first need to contact the author of test case if we could send the
> test case to open source. The test case is called "crashme",
Is that the classical crashme as found in LTP or an enhanced one?
Do you run it in a special way? Is the crash
On 11/27/06, Andi Kleen <[EMAIL PROTECTED]> wrote:
On Monday 27 November 2006 11:02, Zhao Forrest wrote:
> Hi Andi,
>
> The kernel 2.6.18.3 runs very well on my x64 server with 2 CPU's and
> 8G memory; however kernel 2.6.16.32 kernel panic(Kernel panic - not
> synci
Hi Andi,
The kernel 2.6.18.3 runs very well on my x64 server with 2 CPU's and
8G memory; however kernel 2.6.16.32 kernel panic(Kernel panic - not
syncing: Attempted to kill init) under the stress test. After I use
mem=4000M for kernel 2.6.16.32, the kernel panic doesn't happen under
stress test.
15 matches
Mail list logo
