On 03/06/2014 07:51 PM, Steven Rostedt wrote:
On Thu, 06 Mar 2014 14:25:28 +0900
Fernando Luis Vázquez Cao wrote:
From: Fernando Luis Vazquez Cao
Prevent tracing of preempt_disable/enable() in sched_clock_cpu().
When CONFIG_DEBUG_PREEMPT is enabled, preempt_disable/enable() are
traced and
From: Fernando Luis Vazquez Cao
Prevent tracing of preempt_disable/enable() in sched_clock_cpu().
When CONFIG_DEBUG_PREEMPT is enabled, preempt_disable/enable() are
traced and this causes trace_clock() users (and probably others) to
go into an infinite recursion. Systems with a stable sched_clock
(2013年08月17日 01:46), Frederic Weisbecker wrote:
On Fri, Aug 16, 2013 at 06:26:54PM +0200, Oleg Nesterov wrote:
On 08/16, Frederic Weisbecker wrote:
On Fri, Aug 16, 2013 at 06:02:01PM +0200, Oleg Nesterov wrote:
+ do {
+ seq = read_seqcount_begin(&ts->sleeptime_seq);
+
(2013年08月19日 20:10), Peter Zijlstra wrote:
On Fri, Aug 16, 2013 at 06:46:28PM +0200, Frederic Weisbecker wrote:
Option A:
Should we flush that iowait to the src CPU? But then it means we must handle
concurrent updates to iowait_sleeptime, idle_sleeptime from the migration
code and from idle en
The kernel sets the NX bit in the early page tables without checking whether
the CPU actually supports this feature. If it doesn't the first attempt to use
them will cause a kernel hang. Since these are temporary page tables marked as
initdata this fix takes the approach of not bothering with the N
It looks like the manual merge 0d69a3c731e120b05b7da9fb976830475a3fbc01 ("Merge
branches 'for-3.9/sony' and 'for-3.9/steelseries' into for-linus") accidentally
removed Sony RF receiver with USB product id 0x0374 from the "have special
driver" list, effectively nullifying a464918419f94a0043d2f549d6d
Hi Jiri,
On Tue, 2013-01-15 at 17:02 +0100, Jiri Kosina wrote:
> On Tue, 15 Jan 2013, Fernando Luis Vázquez Cao wrote:
>
> > Some Vaio desktop computers, among them the VGC-LN51JGB multimedia PC, have
> > a RF receiver, multi-interface USB device 054c:0374, that is used to conn
(Moving discussion to LKML)
Hi Thomas, Frederic,
Tetsuo Handa reported that the iowait time obtained through /proc/stat
is not monotonic.
The reason is that get_cpu_iowait_time_us() is inherently racy;
->idle_entrytime and ->iowait_sleeptime can be updated from another
CPU (via update_ts_time_st
From: Fernando Luis Vázquez Cao
This file is generated so it does not get cleaned automagically. In other words
we need to added to the clean-files list.
Signed-off-by: Fernando Luis Vázquez Cao
---
diff -urNp linux-3.9-rc1-orig/scripts/mod/Makefile
linux-3.9-rc1/scripts/mod/Makefile
Substitute ALC889 for ALC882 in macro and function names.
Cc: sta...@vger.kernel.org
Cc: alsa-de...@alsa-project.org
Signed-off-by: Fernando Luis Vazquez Cao
---
diff -urNp linux-3.7.6-orig/sound/pci/hda/patch_realtek.c
linux-3.7.6/sound/pci/hda/patch_realtek.c
--- linux-3.7.6-orig/sound/pci/hd
The problem addressed by this fixup is not specific to Vaio Z, affecting
some Vaio all-in-one desktop PCs too. Update the code comments accordingly.
Cc: sta...@vger.kernel.org
Cc: alsa-de...@alsa-project.org
Signed-off-by: Fernando Luis Vazquez Cao
---
diff -urNp linux-3.7.6-orig/Documentation/s
Some Vaio all-in-one desktop PCs (for example VGC-LN51JGB) are affected by
the same issue that caused Vaio Z laptops to become silent: the speaker pin
must be connected to the first DAC even though the codec itself advertises
flexible routing through any of the DACs.
Use the no-primary-hp fixup fo
Document what the fix-up is does and make it more robust by ensuring
that it is only applied to the USB interface that corresponds to the
mouse (sony_report_fixup() is called once per interface during probing).
Cc: linux-in...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.ker
Some Vaio desktop computers, among them the VGC-LN51JGB multimedia PC, have
a RF receiver, multi-interface USB device 054c:0374, that is used to connect
a wireless keyboard and a wireless mouse.
The keyboard works flawlessly, but the mouse (VGP-WMS3 in my case) does not
seem to be generating any p
Some Vaio desktop computers, among them the VGC-LN51JGB multimedia PC, have
a RF receiver, multi-interface USB device 054c:0374, that is used to connect
a wireless keyboard and a wireless mouse.
The keyboard works flawlessly, but the mouse (VGP-WMS3 in my case) does not
seem to be generating any p
Signed-off-by: Fernando Luis Vazquez Cao <[EMAIL PROTECTED]>
---
diff -urNp linux-2.6.24-rc2-orig/drivers/ata/sata_nv.c
linux-2.6.24-rc2/drivers/ata/sata_nv.c
--- linux-2.6.24-rc2-orig/drivers/ata/sata_nv.c 2007-11-07 10:28:41.0
+0900
+++ linux-2.6.24-rc2/drivers/ata/sata_nv.c 2007-
Remove dead code while at it.
Signed-off-by: Fernando Luis Vazquez Cao <[EMAIL PROTECTED]>
---
diff -urNp linux-2.6.24-rc1-git13-orig/drivers/video/sis/sis.h
linux-2.6.24-rc1-git13/drivers/video/sis/sis.h
--- linux-2.6.24-rc1-git13-orig/drivers/video/sis/sis.h 2007-10-10
05:31:38.0 +090
Remove dead code while at it.
Signed-off-by: Fernando Luis Vazquez Cao <[EMAIL PROTECTED]>
---
diff -urNp linux-2.6.24-rc1-git13-orig/drivers/usb/misc/sisusbvga/sisusb.c
linux-2.6.24-rc1-git13/drivers/usb/misc/sisusbvga/sisusb.c
--- linux-2.6.24-rc1-git13-orig/drivers/usb/misc/sisusbvga/sisusb.c
Hi Karsten,
What happened to this patch? Should I send it to Andrew or will you take
it in your tree before pushing it upstream?
Thank you in advance.
- Fernando
On Sat, 2007-08-25 at 21:30 +0200, Karsten Keil wrote:
> [PATCH] isdn/sc: remove unused REQUEST_IRQ and unnecessary
>
> REQUEST_IRQ
Playing with the latest -mm kernel I stumbled upon the following compile
error:
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CALLscripts/checksyscalls.sh
:1389:2: warning: #warning syscall revokeat not implemented
:1393:2: warning: #warning syscall frevoke not imple
REQUEST_IRQ is never used, so delete it. In the process get rid of the
macro FREE_IRQ which makes the code unnecessarily difficult to read.
Signed-off-by: Fernando Luis Vazquez Cao <[EMAIL PROTECTED]>
---
diff -urNp linux-2.6.23-rc3-orig/drivers/isdn/sc/debug.h
linux-2.6.23-rc3/drivers/isdn/sc/d
On Wed, 2007-08-22 at 13:28 -0500, Linas Vepstas wrote:
> On Wed, Aug 22, 2007 at 07:44:41PM +1000, Paul Mackerras wrote:
> > Fernando Luis Vázquez Cao writes:
> >
> > > amiga_request_irq and mach_request_irq are never used, so delete them.
> >
> > OK, but i
On Wed, 2007-08-22 at 19:44 +1000, Paul Mackerras wrote:
> Fernando Luis Vázquez Cao writes:
>
> > amiga_request_irq and mach_request_irq are never used, so delete them.
>
> OK, but is there a particular reason you want to do this?
Hi Paul,
Thank you for your reply.
I am
sys_free_irq is never used, so delete it.
Signed-off-by: Fernando Luis Vazquez Cao <[EMAIL PROTECTED]>
---
diff -urNp linux-2.6.23-rc3-orig/arch/ppc/amiga/ints.c
linux-2.6.23-rc3/arch/ppc/amiga/ints.c
--- linux-2.6.23-rc3-orig/arch/ppc/amiga/ints.c 2007-08-22 17:14:32.0
+0900
+++ linux-
sys_request_irq is never used, so delete it.
Signed-off-by: Fernando Luis Vazquez Cao <[EMAIL PROTECTED]>
---
diff -urNp linux-2.6.23-rc3-orig/arch/ppc/amiga/ints.c
linux-2.6.23-rc3/arch/ppc/amiga/ints.c
--- linux-2.6.23-rc3-orig/arch/ppc/amiga/ints.c 2007-07-09 08:32:17.0
+0900
+++ lin
amiga_free_irq and mach_free_irq are never used, so delete them.
Signed-off-by: Fernando Luis Vazquez Cao <[EMAIL PROTECTED]>
---
diff -urNp linux-2.6.23-rc3-orig/arch/ppc/amiga/config.c
linux-2.6.23-rc3/arch/ppc/amiga/config.c
--- linux-2.6.23-rc3-orig/arch/ppc/amiga/config.c 2007-08-22
amiga_request_irq and mach_request_irq are never used, so delete them.
Signed-off-by: Fernando Luis Vazquez Cao <[EMAIL PROTECTED]>
---
diff -urNp linux-2.6.23-rc3-orig/arch/ppc/amiga/config.c
linux-2.6.23-rc3/arch/ppc/amiga/config.c
--- linux-2.6.23-rc3-orig/arch/ppc/amiga/config.c 2007-0
On Mon, 2007-07-30 at 11:22 -0700, Andrew Morton wrote:
> On Mon, 30 Jul 2007 18:58:14 +0900
> Fernando Luis V__zquez Cao <[EMAIL PROTECTED]> wrote:
>
> > >
> > > So bad things might happen because of this change. And if they do, they
> > > will take a lng time to be discovered, because non
On Fri, 2007-07-20 at 14:43 -0700, Andrew Morton wrote:
> On Fri, 20 Jul 2007 11:20:43 +0900
> Fernando Luis V__zquez Cao <[EMAIL PROTECTED]> wrote:
>
> > With the advent of kdump it is possible that device drivers receive
> > interrupts generated in the context of a previous kernel. Ideally
> >
I made an interesting finding while testing the two patches below.
http://lkml.org/lkml/2007/7/19/685
http://lkml.org/lkml/2007/7/19/687
These patches modify the traditional CONFIG_DEBUG_KERNEL in such a way
that the request_irq prints a warning if after calling the handler it
returned IRQ_HANDLE
On Wed, 2007-07-25 at 08:27 -0700, Kok, Auke wrote:
> Fernando Luis Vázquez Cao wrote:
> > I made an interesting finding while testing the two patches below.
> >
> > http://lkml.org/lkml/2007/7/19/685
> > http://lkml.org/lkml/2007/7/19/687
> >
> &g
I made an interesting finding while testing the two patches below.
http://lkml.org/lkml/2007/7/19/685
http://lkml.org/lkml/2007/7/19/687
These patches modify the traditional CONFIG_DEBUG_KERNEL in such a way
that the request_irq prints a warning if after calling the handler it
returned IRQ_HANDLE
With the advent of kdump it is possible that device drivers receive
interrupts generated in the context of a previous kernel. Ideally
quiescing the underlying devices should suffice but not all drivers do
this, either because it is not possible or because they did not
contemplate this case. Thus dr
request_irq() and setup_irq() are not fast paths and free_irq() much
less so. In fact, by enabling this feature unconditionally we would have
_everyone_ (unknowingly) testing devices drivers, which hopefully will
result in more bug-reports and, in turn, better drivers.
Signed-off-by: Fernando Luis
On Wed, 2007-07-18 at 15:46 -0700, Andrew Morton wrote:
> On Tue, 17 Jul 2007 19:09:57 +0900
> Fernando Luis V__zquez Cao <[EMAIL PROTECTED]> wrote:
>
> > With the advent of kdump it is possible that device drivers receive
> > interrupts generated in the context of a previous kernel. Ideally
> > q
With the advent of kdump it is possible that device drivers receive
interrupts generated in the context of a previous kernel. Ideally
quiescing the underlying devices should suffice but not all drivers
do this, either because it is not possible or because they did not
contemplate this case. Thus dr
I keep seeing uses of try_module_get(THIS_MODULE) which seem to mimic
the behavior of the former MOD_INC_USE_COUNT. The UBI driver is one
example:
int ubi_get_device_info(int ubi_num, struct ubi_device_info *di)
{
const struct ubi_device *ubi;
if (!try_module_get(THIS_MODULE))
The use of try_module_get(THIS_MODULE) in ubi_get_device_info does not
offer real protection against unexpected driver unloads, since we could
be preempted before try_modules_get gets executed. It is the caller who
should manipulate the refcounts. Besides, ubi_get_device_info is an
exported symbol
On Tue, 2007-05-15 at 11:18 +0900, Simon Horman wrote:
> "Remove hardcoding of hard_smp_processor_id on UP systems",
> 2f4dfe206a2fc07099dfad77a8ea2f4b4ae2140f in Linus' tree, moved
> the definition of hard_smp_processor_id linux/smp.h to asm/smp.h
> for UP systems. This causes a regression on ARM
On Thu, 2007-04-26 at 12:18 +0530, Vivek Goyal wrote:
> On Wed, Apr 25, 2007 at 08:03:04PM +0900, Fernando Luis Vázquez Cao wrote:
> >
> > static __inline__ void apic_wait_icr_idle(void)
> > {
> > while (apic_read(APIC_ICR) & APIC_ICR_BUSY)
> > cpu_rel
On Wed, 2007-04-25 at 15:11 +0200, Andi Kleen wrote:
> On Wednesday 25 April 2007 14:55:12 Fernando Luis Vázquez Cao wrote:
> > On Wed, 2007-04-25 at 14:26 +0200, Andi Kleen wrote:
> > > > static __inline__ void apic_wait_icr_idle(void)
> > > > {
> >
On Wed, 2007-04-25 at 22:55 +1000, Keith Owens wrote:
> Fernando Luis =?ISO-8859-1?Q?V=E1zquez?= Cao (on Wed, 25 Apr 2007 20:13:28
> +0900) wrote:
> >+static __inline__ unsigned long safe_apic_wait_icr_idle(void)
> >+{
> >+unsigned long send_status;
> >+int timeout;
> >+
> >+timeout =
On Wed, 2007-04-25 at 14:26 +0200, Andi Kleen wrote:
> > static __inline__ void apic_wait_icr_idle(void)
> > {
> > - while (apic_read( APIC_ICR ) & APIC_ICR_BUSY)
> > + while (apic_read(APIC_ICR) & APIC_ICR_BUSY)
> > cpu_relax();
> > }
> >
> > +static __inline__ unsigned int sa
On Wed, 2007-04-25 at 14:33 +0200, Andi Kleen wrote:
> On Wednesday 25 April 2007 13:51:12 Fernando Luis Vázquez Cao wrote:
> > Use safe_apic_wait_icr_idle to check ICR idle bit if the vector is
> > NMI_VECTOR to avoid potential hangups in the event of crash when kdump
> > tr
Use safe_apic_wait_icr_idle to check ICR idle bit if the vector is
NMI_VECTOR to avoid potential hangups in the event of crash when kdump
tries to stop the other CPUs.
Signed-off-by: Fernando Luis Vazquez Cao <[EMAIL PROTECTED]>
---
diff -urNp linux-2.6.21-rc7-orig/include/asm-x86_64/ipi.h
linux
Use safe_apic_wait_icr_idle to check ICR idle bit if the vector is
NMI_VECTOR to avoid potential hangups in the event of crash when kdump
tries to stop the other CPUs.
Signed-off-by: Fernando Luis Vazquez Cao <[EMAIL PROTECTED]>
---
diff -urNp linux-2.6.21-rc7-orig/arch/i386/kernel/smp.c
linux-2
Implement __send_IPI_dest_field which can be used to send IPIs when the
"destination shorthand" field of the ICR is set to 00 (destination
field). Use it whenever possible.
Signed-off-by: Fernando Luis Vazquez Cao <[EMAIL PROTECTED]>
---
diff -urNp linux-2.6.21-rc7-orig/arch/x86_64/kernel/genapic
Implement __send_IPI_dest_field which can be used to send IPIs when the
"destination shorthand" field of the ICR is set to 00 (destination
field). Use it whenever possible.
Signed-off-by: Fernando Luis Vazquez Cao <[EMAIL PROTECTED]>
---
diff -urNp linux-2.6.21-rc7-orig/arch/i386/kernel/smp.c
li
inquire_remote_apic is used for APIC debugging, so use
safe_apic_wait_icr_idle instead of apic_wait_icr_idle to avoid possible
lockups when APIC delivery fails.
Signed-off-by: Fernando Luis Vazquez Cao <[EMAIL PROTECTED]>
---
diff -urNp linux-2.6.21-rc7-orig/arch/x86_64/kernel/smpboot.c
linux-2
__inquire_remote_apic is used for APIC debugging, so use
safe_apic_wait_icr_idle instead of apic_wait_icr_idle to avoid possible
lockups when APIC delivery fails.
Signed-off-by: Fernando Luis Vazquez Cao <[EMAIL PROTECTED]>
---
diff -urNp linux-2.6.21-rc7-orig/arch/i386/kernel/smpboot.c
linux-2
The functionality provided by the new safe_apic_wait_icr_idle is being
open-coded all over "kernel/smpboot.c". Use safe_apic_wait_icr_idle
instead to consolidate code and ease maintenance.
Signed-off-by: Fernando Luis Vazquez Cao <[EMAIL PROTECTED]>
---
diff -urNp linux-2.6.21-rc7-orig/arch/x86_6
The functionality provided by the new safe_apic_wait_icr_idle is being
open-coded all over "kernel/smpboot.c". Use safe_apic_wait_icr_idle
instead to consolidate code and ease maintenance.
Signed-off-by: Fernando Luis Vazquez Cao <[EMAIL PROTECTED]>
---
diff -urNp linux-2.6.21-rc7-orig/arch/i386/
apic_wait_icr_idle looks like this:
static __inline__ void apic_wait_icr_idle(void)
{
while (apic_read(APIC_ICR) & APIC_ICR_BUSY)
cpu_relax();
}
The busy loop in this function would not be problematic if the
corresponding status bit in the ICR were always updated, but that does
not seem to
apic_wait_icr_idle looks like this:
static __inline__ void apic_wait_icr_idle(void)
{
while (apic_read(APIC_ICR) & APIC_ICR_BUSY)
cpu_relax();
}
The busy loop in this function would not be problematic if the
corresponding status bit in the ICR were always updated, but that does
not seem to
--- Background
On i386 and x86_64, in the event of a crash, kdump attempts to stop all
other CPUs before proceeding to boot into the dump capture kernel.
Depending on the sub-architecture several implementations exist as
detailed below.
- i386
smp_send_nmi_allbutself
send_IPI_mask(mask, NMI_VE
On Tue, 2007-04-24 at 16:22 +0200, Andi Kleen wrote:
> > Why would you need any kind of lock when just changing a single bit,
> > if it didn't affect other bits of the same word? Just as you don't
> > need a lock when simply assigning a word, setting a bit to 0 or 1
> > is simple in itself (it doe
On Tue, 2007-04-10 at 18:18 -0700, Andrew Morton wrote:
> On Tue, 10 Apr 2007 20:48:38 -0400
> Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
>
> > I get the following build error when building 2.6.21-rc6-mm1 for
> > sparc64:
> >
> >
> > /opt/crosstool/gcc-3.4.5-glibc-2.3.6/sparc64-unknown-linux
Always ask the hardware to determine the hardware processor id in both
UP and SMP kernels.
Signed-off-by: Fernando Luis Vazquez Cao <[EMAIL PROTECTED]>
---
diff -urNp linux-2.6.21-rc5-orig/include/asm-ia64/smp.h
linux-2.6.21-rc5/include/asm-ia64/smp.h
--- linux-2.6.21-rc5-orig/include/asm-ia64/s
On Wed, 2007-04-04 at 17:56 +0900, Fernando Luis Vázquez Cao wrote:
> hard_smp_processor_id used to be just a macro that hard-coded
> hard_smp_processor_id to 0 in the non SMP case. When booting non SMP
> kernels on hardware where the boot ioapic id is not 0 this turns out to
>
hard_smp_processor_id used to be just a macro that hard-coded
hard_smp_processor_id to 0 in the non SMP case. When booting non SMP
kernels on hardware where the boot ioapic id is not 0 this turns out to
be a problem. This is happens frequently in the case of kdump and once
in a great while in the
hard_smp_processor_id used to be just a macro that hard-coded
hard_smp_processor_id to 0 in the non SMP case. When booting non SMP
kernels on hardware where the boot ioapic id is not 0 this turns out to
be a problem. This is happens frequently in the case of kdump and once
in a great while in the
This new version (v.2) fixes generic arch i386 up build, has (hopefully)
clearer explanations, and does not break git bisect searches.
---
With the advent of kdump, the assumption that the boot CPU when running
an UP kernel is always the CPU with a particular hardware ID (often 0)
(usually referred
With the advent of kdump, the assumption that the boot CPU when booting
an UP
kernel is always the CPU with a particular hardware ID (often 0)
(usually
referred to as BSP on some architectures) is not valid anymore. The
reason being that the dump capture kernel boots on the crashed CPU (the
CPU tha
On Fri, 2007-03-02 at 00:39 -0800, Andrew Morton wrote:
> On Fri, 02 Mar 2007 17:31:21 +0900 Fernando Luis Vázquez Cao <[EMAIL
> PROTECTED]> wrote:
>
> > On Thu, 2007-03-01 at 10:03 +0100, Heiko Carstens wrote:
> > > On Thu, Mar 01, 2007 at 04:18:23PM +0900, F
On Thu, 2007-03-01 at 10:03 +0100, Heiko Carstens wrote:
> On Thu, Mar 01, 2007 at 04:18:23PM +0900, Fernando Luis Vázquez Cao wrote:
> > Move definition of hard_smp_processor_id to asm/smp.h on alpha, m32r,
> > powerpc, s390, sparc, sparc64, and um architectures.
> >
> &
Provide hard_smp_processor_id definition also for non apic case.
Signed-off-by: Fernando Luis Vazquez Cao <[EMAIL PROTECTED]>
---
diff -urNp linux-2.6.21-rc2-orig/include/asm-i386/smp.h
linux-2.6.21-rc2/include/asm-i386/smp.h
--- linux-2.6.21-rc2-orig/include/asm-i386/smp.h2007-03-02
16
On Fri, 2007-03-02 at 09:44 +0530, Vivek Goyal wrote:
> On Thu, Mar 01, 2007 at 09:06:48AM -0500, Benjamin LaHaise wrote:
> > On Thu, Mar 01, 2007 at 04:16:13PM +0900, Fernando Luis Vázquez Cao wrote:
> > > As a consequence, the hardcoding of hard_smp_processor_id() to 0 on UP
On Thu, 2007-03-01 at 09:06 -0500, Benjamin LaHaise wrote:
> On Thu, Mar 01, 2007 at 04:16:13PM +0900, Fernando Luis Vázquez Cao wrote:
> > As a consequence, the hardcoding of hard_smp_processor_id() to 0 on UP
> > systems (see "linux/smp.h") is not correct.
> &g
On Thu, 2007-03-01 at 13:29 +0530, Vivek Goyal wrote:
> On Thu, Mar 01, 2007 at 04:16:59PM +0900, Fernando Luis Vázquez Cao wrote:
> > Use the APIC to determine the hardware processor id when APIC support
> > has been selected, independently of whether CONFIG_SMP is set or not.
>
Move definition of hard_smp_processor_id to asm/smp.h on alpha, m32r,
powerpc, s390, sparc, sparc64, and um architectures.
Signed-off-by: Fernando Luis Vazquez Cao <[EMAIL PROTECTED]>
---
diff -urNp linux-2.6.21-rc2/include/asm-alpha/smp.h
linux-2.6.21-rc2-hwcpuid/include/asm-alpha/smp.h
--- lin
Always ask the hardware to determine the hardware processor id in both UP and
SMP kernels.
Signed-off-by: Fernando Luis Vazquez Cao <[EMAIL PROTECTED]>
---
diff -urNp linux-2.6.21-rc2/include/asm-ia64/smp.h
linux-2.6.21-rc2-hwcpuid/include/asm-ia64/smp.h
--- linux-2.6.21-rc2/include/asm-ia64/sm
Use the APIC to determine the hardware processor id in both UP and SMP
kernels.
Signed-off-by: Fernando Luis Vazquez Cao <[EMAIL PROTECTED]>
---
diff -urNp linux-2.6.21-rc2/include/asm-x86_64/smp.h
linux-2.6.21-rc2-hwcpuid/include/asm-x86_64/smp.h
--- linux-2.6.21-rc2/include/asm-x86_64/smp.h
Use the APIC to determine the hardware processor id when APIC support
has been selected, independently of whether CONFIG_SMP is set or not.
Signed-off-by: Fernando Luis Vazquez Cao <[EMAIL PROTECTED]>
---
diff -urNp linux-2.6.21-rc2/include/asm-i386/smp.h
linux-2.6.21-rc2-hwcpuid/include/asm-i38
With the advent of kdump, the assumption that the boot CPU when running
an UP kernel is always the CPU with a hardware ID of 0 (usually referred
to as BSP on some architectures) does not hold true anymore. The reason
being that the dump capture kernel boots on the crashed CPU (the CPU
that invoked
With the advent of kdump, the assumption that the boot CPU when booting
an UP kernel is always the CPU with a hardware ID of 0 (usually referred
to as BSP on some architectures) is not valid anymore.
Signed-off-by: Fernando Luis Vazquez Cao <[EMAIL PROTECTED]>
---
diff -urNp linux-2.6.21-rc2/incl
Initialize affinity only when building SMP kernels.
Signed-off-by: Fernando Luis Vazquez Cao <[EMAIL PROTECTED]>
---
--- linux-2.6.21-rc2-dtt/arch/i386/kernel/io_apic.c 2007-03-06
15:20:14.0 +0900
+++ linux-2.6.21-rc2-kdump/arch/i386/kernel/io_apic.c 2007-03-06
15:51:45.0
Initialize affinity only when building SMP kernels.
Signed-off-by: Fernando Luis Vazquez Cao <[EMAIL PROTECTED]>
---
--- linux-2.6.21-rc2-dtt/arch/x86_64/kernel/io_apic.c 2007-03-06
15:20:14.0 +0900
+++ linux-2.6.21-rc2-kdump/arch/x86_64/kernel/io_apic.c 2007-03-06
15:48:52.0
Initialize affinity only when building SMP kernels.
Signed-off-by: Fernando Luis Vazquez Cao <[EMAIL PROTECTED]>
---
--- linux-2.6.21-rc2-dtt/arch/x86_64/kernel/io_apic.c 2007-03-06
15:20:14.0 +0900
+++ linux-2.6.21-rc2-kdump/arch/x86_64/kernel/io_apic.c 2007-03-06
15:48:52.0
Initialize affinity only when building SMP kernels.
Signed-off-by: Fernando Luis Vazquez Cao <[EMAIL PROTECTED]>
---
--- linux-2.6.21-rc2-dtt/arch/i386/kernel/io_apic.c 2007-03-06
15:20:14.0 +0900
+++ linux-2.6.21-rc2-kdump/arch/i386/kernel/io_apic.c 2007-03-06
15:51:45.0
Initialize affinity only when building SMP kernels.
Signed-off-by: Fernando Luis Vazquez Cao <[EMAIL PROTECTED]>
---
--- linux-2.6.21-rc2-dtt/arch/i386/kernel/io_apic.c 2007-03-06
15:20:14.0 +0900
+++ linux-2.6.21-rc2-kdump/arch/i386/kernel/io_apic.c 2007-03-06
15:51:45.0
On Thu, 2006-12-07 at 11:50 -0500, Phillip Susi wrote:
> Marc Haber wrote:
> > I went back to 2.6.18.3 to debug this, and the system ran for three
> > days without problems and without corrupting
> > /var/cache/apt/pkgcache.bin. After booting 2.6.19 again, it took three
> > hours for the file corru
81 matches
Mail list logo
