On 8/27/13, Yinghai Lu wrote:
> On Fri, Aug 23, 2013 at 5:51 PM, rui wang wrote:
>> On 8/11/13, Yinghai Lu wrote:
>>> During ioapic hotplug, acpi_register_ioapic will be called.
>>> Now for x86, that function is blank.
>>> Fill that will update __mp
On 8/27/13, Yinghai Lu wrote:
> On Mon, Aug 26, 2013 at 11:44 PM, rui wang wrote:
>> On 8/27/13, Yinghai Lu wrote:
>>> On Fri, Aug 23, 2013 at 5:51 PM, rui wang wrote:
>>>> On 8/11/13, Yinghai Lu wrote:
>>>>> During ioapic hotplug, acpi_register_i
goto exit_disable;
>
> res = &dev->resource[0];
> - if (acpi_register_ioapic(ioapic->handle, res->start, ioapic->gsi_base))
> +
> + if (acpi_register_ioapic(handle, res->start, gsi_base))
> goto exit_release;
Here acpi_register_ioapic
FWIW, I'm using my "I/O Hook" (http://lwn.net/Articles/561359/) as a
tool to test yinghai's IOAPIC patchset. It can be used to test any
kind of hotplug.
For people who don't yet have full hardware support and want to test
the hotplug of IOAPIC, CPU, Memory, IOH, PCIe root, etc., it is an
ideal too
On 8/28/13, Yinghai Lu wrote:
> On Tue, Aug 27, 2013 at 3:25 AM, rui wang wrote:
>> On 8/11/13, Yinghai Lu wrote:
>>> We need to have ioapic setup before normal pci drivers.
>>> otherwise other pci driver can not setup irq.
>>>
>>> So we should not
On 8/15/13, Bjorn Helgaas wrote:
> On Thu, Aug 8, 2013 at 2:09 PM, Alex Williamson
> I don't think this is hotplug-safe. It looks like pci_bus_sem might
> be the right semaphore to hold while verifying that we won't reset any
> unintended devices.
Something like pci_bus_sem locks all the buses,
w.
Thanks
Rui
>> I tested the performance by repeatedly running lspci, which calls into
>> the
>> pci access functions. There's no added overhead observed.
>>
>> Regards,
>> Rui Wang
>> Intel Open Source Technology Center
>>
>> Rui Wang
cally used to generate ACPI events, PCI interrupts, PCIe
AER injection etc., and can thus be used to help test RAS features like
the hotplug of CPU/MEM/IOH on machines that are not capable of generating
the events.
See Documentation/PCI/iohook.txt for usage details.
Signed-off-by: Rui
Add the following kernel functions used to add/delete/query Register
Overrides, and to start/stop the I/O Hook:
hook_add_ovrd
hook_query_ovrd
hook_cleanup_ovrd
hook_start_ovrd
hook_stop_ovrd
hook_get_status
Signed-off-by: Rui Wang
---
drivers/misc
this new version on Westmere-EX. It worked as expected.
Regards,
Rui Wang
Intel Open Source Technology Center
Rui Wang (3):
I/O Hook: core functions and Register Override
I/O Hook: kernel interface to manage the hook
I/O Hook: sysfs interface to emulate h/w events
Documentation/PCI/iohoo
used, so when the hook is disabled (by default), this adds
only a NOP to the core functions, with zero performance penalty.
This is the first step towards the goal of emulating h/w events.
Signed-off-by: Rui Wang
---
arch/Kconfig | 10 +
arch/x86/boot/compressed/Makefile
On 8/11/13, Yinghai Lu wrote:
> Some ioapic controllers do not show up on pci config space,
> or pci device is there but no bar is used and is set by firmware in
> other non standard registers.
>
> We can get ioapic address from ACPI0009's _CRS.
>
> Signed-off-by: Yinghai Lu
> ---
> drivers/pci/
On 8/22/13, rui wang wrote:
> On 8/11/13, Yinghai Lu wrote:
>> Some ioapic controllers do not show up on pci config space,
>> or pci device is there but no bar is used and is set by firmware in
>> other non standard registers.
>>
>> We can get ioapic address f
On 8/11/13, Yinghai Lu wrote:
> During ioapic hotplug, acpi_register_ioapic will be called.
> Now for x86, that function is blank.
> Fill that will update __mp_register_ioapic to use those ioapic.
>
> Signed-off-by: Yinghai Lu
> ---
> arch/x86/kernel/acpi/boot.c | 10 ++
> 1 file changed
used, so when the hook is disabled (by default), this adds
only a NOP to the core functions, with zero performance penalty.
This is the first step towards the goal of emulating h/w events.
Signed-off-by: Rui Wang
---
arch/x86/Kconfig |7 +
arch/x86/boot/compressed/Makefile
ively zero.
I tested the performance by repeatedly running lspci, which calls into the
pci access functions. There's no added overhead observed.
Regards,
Rui Wang
Intel Open Source Technology Center
Rui Wang (3):
IO Hook: core functions and Register Override
IO Hook: kernel interface to
See Documentation/PCI/iohook.txt for usage details.
Signed-off-by: Rui Wang
---
Documentation/PCI/iohook.txt | 290
drivers/misc/Kconfig |1 +
drivers/misc/Makefile|1 +
drivers/misc/iohook/Kconfig |5 +
drivers/misc/iohook/Makefile |1 +
drivers
-off-by: Rui Wang
---
drivers/pci/access.c | 150 ++
include/linux/reg_ovrd.h |9 +++
2 files changed, 159 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/access.c b/drivers/pci/access.c
index fe7b282..81428655 100644
--- a/drivers/pci
setup_res() doesn't actually get any resource because it mistakenly
checks the return value of acpi_dev_filter_resource_type(), which
returns 0 on success, and 1 on failure. Fix it by taking the return
value of non-zero as failing to match the specified resource type.
Signed-off-by: Rui
ecf). Fix it by using
insert_resource() which can request resources by taking the conflicting
resource as the parent.
Signed-off-by: Rui Wang
---
drivers/acpi/ioapic.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/ioapic.c b/drivers/acpi/ioapic.c
inde
appears in "_CRS" of each IOAPIC device. Both ranges should be claimed
from /proc/iomem for exclusive use.
Signed-off-by: Rui Wang
---
drivers/acpi/ioapic.c | 36
1 file changed, 20 insertions(+), 16 deletions(-)
diff --git a/drivers/acpi/ioapic.c
eat of the change, i.e., the addition of calls
to acpi_ioapic_add()."
* Removed acpi_ioapic_add() as an exported symbol.
* Fixed some typos, and s/acpi/ACPI/, s/ioapic/IOAPIC/ throughout.
* Fixed a warning from 0-day testing.
Rui Wang (5):
x86/ioapic: Change prototype of acpi_ioapic_add
IOAPICs present during system boot aren't added to ioapic_list,
thus are unable to be hot-removed. Fix it by calling
acpi_ioapic_add() during root bus enumeration.
Signed-off-by: Rui Wang
---
drivers/acpi/pci_root.c | 10 ++
drivers/pci/setup-bus.c | 5 -
2 files change
Change the argument of acpi_ioapic_add() to a generic ACPI handle, and
move its prototype from drivers/acpi/internal.h to include/linux/acpi.h
so that it can be called from outside the pci_root driver.
Signed-off-by: Rui Wang
---
drivers/acpi/internal.h | 2 --
drivers/acpi/ioapic.c | 6
On Tuesday, Aug 9, 2016 4:23 AM, Bjorn Helgaas wrote:
> On Sun, Jun 26, 2016 at 11:44:57AM +0800, Rui Wang wrote:
> > v5: Remove #ifdef CONFIG_X86 from setup-bus.c, making it neutral to
> archs.
> > v4: Add comments explaining when to call acpi_ioapic_add().
> > v3: Prev
...@ffwll.ch, tony.l...@intel.com,
b...@alien8.de, a...@redhat.com, rui.y.w...@intel.com
Cc: linux-kernel@vger.kernel.org
From: Rui Wang
There are still some places in the fb helper that need to avoid
sleeping in panic context. Here's an example:
[ 65.615496] bad: scheduling from the idle t
Hi Rob,
Yes it's exactly what I'm doing. Please scroll down and review my patch.
Thanks
Rui
On 12/10/14, Rob Clark wrote:
> perhaps fb helpers could use __drm_modeset_lock_all() w/ trylock=true
> in panic context?
>
> BR,
> -R
>
> On Tue, Dec 9, 2014 at 7:09
On 12/4/14, Borislav Petkov wrote:
> On Wed, Dec 03, 2014 at 05:11:49PM +0800, rui wang wrote:
>> The problem is because kdump fails to load a new kernel, and we're
>> executing past crash_kexec() in panic(). And it calls
>> bust_spinlocks(0) which calls into the GP
l.com wrote:
> From: Rui Wang
>
> There are still some places in the fb helper that need to avoid
> sleeping in panic context. Here's an example:
>
> [ 65.615496] bad: scheduling from the idle thread!
> [ 65.620747] CPU: 92 PID: 0 Comm: swapper/92 Tainted: G M
Hi Boris & Tony,
While injecting MCEs using einj, I encountered a panic:
[0.305697] mce: CPU supports 22 MCE banks
[0.310288] BUG: unable to handle kernel NULL pointer dereference at
0100
[0.319057] IP: [] __queue_wor
> On Wed, Jun 17, 2015 at 11:41:56AM +0200, Borislav Petkov wrote:
>> And I was waiting in line to get a chance to do some injection on our
>> EINJ box here too. But it seems you have the required setup already so
>> if you want to give those changes a run, I've uploaded them here:
>>
>> git://g
hat HW_EVENT_ERR_CORRECTED is
defined in edac.h:
enum hw_event_mc_err_type {
HW_EVENT_ERR_CORRECTED,
HW_EVENT_ERR_UNCORRECTED,
HW_EVENT_ERR_FATAL,
HW_EVENT_ERR_INFO,
};
while aer_print_error() uses aer_error_severity_string[] defined as:
static const char *aer_error
d and
> there are
> only %u available.\n",
> + smp_processor_id(), this_count, count);
> + return -ERANGE;
> + }
> + return 0;
> +}
> +
Have you considered the case when an IRQ is destined to more than one CPU? e.g.:
bash#
ot;, the trace event says
"severity=Fatal". What happens is that HW_EVENT_ERR_CORRECTED is
defined in edac.h:
enum hw_event_mc_err_type {
HW_EVENT_ERR_CORRECTED,
HW_EVENT_ERR_UNCORRECTED,
HW_EVENT_ERR_FATAL,
HW_EVENT_ERR_INFO,
};
while aer_print_error()
ggered, a positive number
denotes an IRQ and a negative number denotes a vector, thus
bash# echo -18 > irq
specifies that a machine check exception (int 18) will be triggered.
Signed-off-by: Rui Wang
---
Documentation/PCI/iohook.txt | 31 ++--
arch/x86/include/asm/msr.h | 100
_event: write(0x38302030,
0x4) ==> 0x37822000
modprobe-613 [013] d...12.478001: iohook_event: write(0x38302034,
0x4) ==> 0x0
...
Signed-off-by: Rui Wang
---
Documentation/PCI/iohook.txt | 54 +++-
drivers/misc/iohook/iohook.c | 319 +++
trace h/w access. A new
attribute 'tc' can be defined for any Register Override for tracing
purpose.
Rui Wang (5):
I/O Hook: core functions and Register Override
I/O Hook: Help functions to manage the hook
I/O Hook: sysfs interface to emulate h/w events
I/O Hook
Add the following kernel helper functions used to add/delete/query Register
Overrides, and to start/stop the I/O Hook:
iohook_add_ovrd
iohook_query_ovrd
iohook_cleanup_ovrd
iohook_start_ovrd
iohook_stop_ovrd
iohook_get_status
Signed-off-by: Rui Wang
cally used to generate ACPI events, PCI interrupts, PCIe
AER injection etc., and can thus be used to help test RAS features like
the hotplug of CPU/MEM/IOH on machines that are not capable of generating
the events.
See Documentation/PCI/iohook.txt for usage details.
Signed-off-by: Rui
, etc., similar to how a hardware register behaves when accessed.
Jump Label is used, so when the hook is disabled (by default), this adds
only a NOP to the core functions, with zero performance penalty.
This patch is the first step towards the goal of emulating h/w events.
Signed-off-by: Rui Wang
On 12/19/13, Prarit Bhargava wrote:
>
>
> On 12/03/2013 09:48 PM, rui wang wrote:
>> On 11/20/13, Prarit Bhargava wrote:
>> Have you considered the case when an IRQ is destined to more than one CPU?
>> e.g.:
>>
>> bash# cat /proc/irq/89/smp_affinity_li
On 12/20/13, Prarit Bhargava wrote:
>
>
> On 12/19/2013 01:05 PM, Tony Luck wrote:
>> On Wed, Dec 18, 2013 at 11:50 AM, Tony Luck wrote:
>>> Looks good to me.
>>
>> Though now I've been confused by an offline question about affinity.
>
> Heh :) I'm pursuing it now. Rui has asked a pretty good q
On 12/5/13, Borislav Petkov wrote:
> Yes, the AER tracepoint above should use the AER_* defines and not the
> HW_EVENT_ERR_* ones which are for memory errors.
>
> Wanna send a fix?
>
Yes. Does it translate into something like this?
From: Rui Wang
Date: Fri, 6 Dec 2013 16:47:4
"Corrected"
};
In this case dmesg is correct because info->severity is assigned in
aer_isr_one_error() using the definitions in include/linux/ras.h:
Signed-off-by: Rui Wang
---
include/trace/events/ras.h | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff
On 12/30/13, Prarit Bhargava wrote:
>
>
> On 12/30/2013 07:56 AM, rui wang wrote:
>
>> An irq can be mapped to only one vector number, but can have multiple
>> destination CPUs. i.e. the same irq/vector can appear on multiple
>> CPUs' vector_irq[]. So checking
On 12/29/13, Prarit Bhargava wrote:
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64831
>
> When downing a cpu it is possible that there are unhandled irqs left in
> the APIC IRR register. The following code path shows how the problem
> can occur:
>
> 1. CPU 5 is to go down.
> 2. CPU 5
-git a/arch/x86/kernel/irqinit.c b/arch/x86/kernel/irqinit.c
> index a2a1fbc..7f50156 100644
> --- a/arch/x86/kernel/irqinit.c
> +++ b/arch/x86/kernel/irqinit.c
> @@ -52,7 +52,7 @@ static struct irqaction irq2 = {
> };
>
> DEFINE_PER_CPU(vector_irq_t, vector_irq) = {
> - [0 .
On 12/2/13, Prarit Bhargava wrote:
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64831
>
> When downing a cpu it is possible that there are unhandled irqs left in
> the APIC IRR register. fixup_irqs() goes through the IRR and retriggers
> the IRQs left in the APIC IRR. After this, the
On 12/23/13, Prarit Bhargava wrote:
>
>
> On 12/23/2013 04:41 AM, rui wang wrote:
>> On 12/2/13, Prarit Bhargava wrote:
>>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64831
>>>
>>> When downing a cpu it is possible that there are unhand
On 12/24/13, Prarit Bhargava wrote:
>
>
> On 12/23/2013 11:41 PM, rui wang wrote:
>> On 12/23/13, Prarit Bhargava wrote:
>> > I think I have root caused this to the IRR being set in the down'd cpu.
>> > It
>> > is
>> > admittedly a rare occ
On 12/29/13, Prarit Bhargava wrote:
>
>
> On 12/20/2013 04:41 AM, rui wang wrote:
<>
>> The vector number for an irq is programmed in the LSB of the IOAPIC
>> IRTE (or MSI data register in the case of MSI/MSIx). So there can be
>> only one vector number (althou
Hi All,
Just found the following bug causing machine hang:
[ 487.777538] BUG: unable to handle kernel NULL pointer dereference at
0060
[ 487.777554] IP: [] _raw_spin_lock+0xe/0x30
[ 487.777557] PGD 42e9f7067 PUD 42f2fa067 PMD 0
[ 487.777560] Oops: 0002 [#1] SMP
...
[ 487.777618]
the check early in the function
can fix the problem.
Signed-off-by: Rui Wang
---
drivers/gpu/drm/mgag200/mgag200_cursor.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_cursor.c
b/drivers/gpu/drm/mgag200/mgag200_cursor.c
index 4f2068
cryptd_create_hash() fails by returning -EINVAL. It is because after
8996eafdc ("crypto: ahash - ensure statesize is non-zero") all ahash
drivers must have a non-zero statesize.
This patch fixes the problem by properly assigning the statesize.
Signed-off-by: Rui Wang
---
crypto/cr
ghash_clmulni_intel fails to load on Linux 4.3+ with the following message:
"modprobe: ERROR: could not insert 'ghash_clmulni_intel': Invalid argument"
These two patches need to go together, for the driver to load correctly.
Rui Wang (2):
crypto: ghash-clmulni - Fix l
rt()/export(), and must have a non-
zero statesize.
This patch has been tested with the algif_hash interface. The calculated
digest values, after several rounds of import()s and export()s, match those
calculated by tcrypt.
Signed-off-by: Rui Wang
---
arch/x86/crypto/ghash-clmulni-intel_glue.c | 26
On 11/20/14, Borislav Petkov wrote:
> On Wed, Nov 19, 2014 at 11:34:10PM +, Luck, Tony wrote:
>> The SDM has this to say about EN=0 (in section 15.10.4.1 of volume 3B):
>>
>>When the EN flag is zero but the VAL and UC flags are one in
>>the IA32_MCi_STATUS register, the reported uncorr
On 11/22/14, Borislav Petkov wrote:
>... there are two possibilities:
>
> * error got logged into mcelog and is long out to dmesg.
>
> So we go look at dmesg. Not very easy to do when we panic, I know, so we
> better make sure we have serial connected.
>
>
> [ Btw., we can know when userspace is
On 11/22/14, Borislav Petkov wrote:
> On Sat, Nov 22, 2014 at 10:16:49AM +0800, rui wang wrote:
>> I think both possibilities are valid. But experiments show that the
>> error logs are not in the dmesg preserved by kdump in /var/crash/
>> after panic and reboot, and no
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hi all,
When a machine check panics while the kdump service isn't loaded (e.g.
due to insufficient disk space), we see an infinite stream of error
messages on the console, repeatedly, like this (The machine can never
reboot):
[ 82.733050] bad: scheduling from the idle thread!
[ 82.738304] CPU
On Monday, June 29, 2015 5:25 PM, Daniel Vetter wrote:
> As long as the display is up and running we should have a fair stab at
> showing the oops - it's just that no one has seriously bothered with
> the necessary infastructure, automated testing (it won't work
> otherwise) and driver work.
I th
On Tuesday, June 30, 2015 2:37 PM, Daniel Vetter wrote:
> On Tue, Jun 30, 2015 at 4:53 AM, Rui Wang wrote:
> >
> > I think testing can be done by injecting a fatal machine check
> > exception via einj's debugfs interface. I can reproduce the hard hang every
> time.
&
On Tuesday, June 30, 2015 11:24 PM, Daniel Vetter
wrote:
> On Tue, Jun 30, 2015 at 9:23 AM, Rui Wang wrote:
> > But einj does something more than what an IPI can do, it injects hardware
> > errors which trigger exceptions in NMI context... and the exception handler
> > us
On Friday, June 17, 2016 1:10 AM, Bjorn Helgaas wrote:
> ioapic_insert_resources() is x86-specific, but I'm not sure why; it seems
> like it does things that should be applicable to ia64 as well.
>
> acpi_ioapic_add() is not x86-specific, and it is called from
> acpi_pci_root_add() for the hot-add
ff-by: Rui Wang
---
drivers/acpi/internal.h | 2 --
drivers/acpi/ioapic.c | 7 ---
drivers/acpi/pci_root.c | 13 -
drivers/pci/setup-bus.c | 7 ++-
include/linux/acpi.h| 3 +++
5 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/drivers/acpi/internal.h b/dr
Hi all,
The 1st patch has been discussed before Bjorn went on vacation. I've fixed
all the issues. Bjorn, please advise how we'll move forward.
The remaining patches fix newly found bugs while testing ioapic hotplug.
Regards,
Rui
Rui Wang (4):
x86/ioapic: Support hot-removal
ecf). Fix it by using
insert_resoure() which can request resources by taking the conflicting
resource as the parent.
Signed-off-by: Rui Wang
---
drivers/acpi/ioapic.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/ioapic.c b/drivers/acpi/ioapic.c
inde
IOAPICs present during system boot aren't added to ioapic_list,
thus are unable to be hot-removed. Fix it by calling
acpi_ioapic_add() during root bus enumeration.
Signed-off-by: Rui Wang
---
drivers/acpi/internal.h | 2 --
drivers/acpi/ioapic.c | 7 ---
drivers/acpi/pci_root.c
setup_res() doesn't actually get any resoure because it mistakenly
checks the return value of acpi_dev_filter_resource_type(), which
returns 0 on success, and 1 on failure. Fix it by taking the return
value of non-zero as failing to match the specified resource type.
Signed-off-by: Rui
exclusive use.
Signed-off-by: Rui Wang
---
drivers/acpi/ioapic.c | 36
1 file changed, 20 insertions(+), 16 deletions(-)
diff --git a/drivers/acpi/ioapic.c b/drivers/acpi/ioapic.c
index daf4a40..80b0b1a 100644
--- a/drivers/acpi/ioapic.c
+++ b/drivers/acpi
On Wed, July 27, 2016 4:20 AM Bjorn Helgaas wrote:
> On Wed, Jul 27, 2016 at 12:13:14AM +0800, Rui Wang wrote:
> > IOAPICs present during system boot aren't added to ioapic_list, thus
> > are unable to be hot-removed. Fix it by calling
> > acpi_ioapic_add() d
On Wed, July 27, 2016 4:24 AM, Bjorn Helgaas wrote:
> On Wed, Jul 27, 2016 at 12:13:16AM +0800, Rui Wang wrote:
> > ioapic resource at 0xfecx gets lost from /proc/iomem after
> > hot-removing and then hot-adding the ioapic devices.
> >
> > After system boot, i
pcibios_release_device() of every PCI device under the same parent root
bus, before the IOAPIC is hot-removed. This makes it possible for the
IOAPIC to free any IRQ resource previously unable to get freed.
Signed-off-by: Rui Wang
---
drivers/acpi/internal.h | 1 +
drivers/acpi/ioapic.c | 22
problem. IOAPIC hot-removal works correctly
after applying this patchset.
Rui Wang (2):
x86/PCI: Implement pci_release_device to release IRQ from IOAPIC
x86/ioapic: Split IOAPIC hot-removal into two steps
arch/x86/pci/common.c | 9 +
drivers/acpi/internal.h | 1 +
drivers/acpi/
f
the PCI root bus, so we have the chance to hook every PCI device's
pcibios_release_device(), before we remove the IOAPIC.
This patch implements pcibios_release_device() on x86 to release any
IRQ not released by the driver, so that the IOAPIC can then be safely
hot-removed.
Signed-off-b
problem. IOAPIC hot-removal works correctly
after applying this patchset.
v2: 0001 Fixed a missing stub function causing compiling error on i386
0002 Fixed a typo on the subject line.
Rui Wang (2):
x86/PCI: Implement pcibios_release_device to release IRQ from IOAPIC
x86/ioapic: Split IOA
pcibios_release_device() of every PCI device under the same parent root
bus, before the IOAPIC is hot-removed. This makes it possible for the
IOAPIC to free any IRQ resource previously unable to get freed.
v2: Fixed compiling error on i386 (missing stub of pci_ioapic_remove())
Signed-off-by: Rui Wang
---
drivers
a typo (pcibios_release_device)
Signed-off-by: Rui Wang
---
arch/x86/pci/common.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index 0cb52ae..190e718 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -735,6 +735,15 @@ void
acpi_dev_filter_resource_type() returns 0 on success, and 1 on failure.
A return value of zero means there's a matching resource, so we should
continue within setup_res() to get the resource.
Signed-off-by: Rui Wang
---
drivers/acpi/ioapic.c | 2 +-
1 file changed, 1 insertion(+), 1 del
ecf). Fix it by using
insert_resource() which can request resources by taking the conflicting
resource as the parent.
Signed-off-by: Rui Wang
---
drivers/acpi/ioapic.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/ioapic.c b/drivers/acpi/ioapic.c
inde
I/, s/ioapic/IOAPIC/ throughout.
* Fixed a warning from 0-day testing.
Rui Wang (5):
x86/ioapic: Change prototype of acpi_ioapic_add()
x86/ioapic: Support hot-removal of IOAPICs present during boot
x86/ioapic: Fix setup_res() failing to get resource
x86/ioapic: Fix lost IOAPIC resource af
appears in "_CRS" of each IOAPIC device. Both ranges should be claimed
from /proc/iomem for exclusive use.
Signed-off-by: Rui Wang
---
drivers/acpi/ioapic.c | 36
1 file changed, 20 insertions(+), 16 deletions(-)
diff --git a/drivers/acpi/ioapic.c
IOAPICs present during system boot aren't added to ioapic_list,
thus are unable to be hot-removed. Fix it by calling
acpi_ioapic_add() during root bus enumeration.
Signed-off-by: Rui Wang
---
drivers/acpi/pci_root.c | 10 ++
drivers/pci/setup-bus.c | 5 -
2 files change
Change the argument of acpi_ioapic_add() to a generic ACPI handle, and
move its prototype from drivers/acpi/internal.h to include/linux/acpi.h
so that it can be called from outside the pci_root driver.
Signed-off-by: Rui Wang
---
drivers/acpi/internal.h | 2 --
drivers/acpi/ioapic.c | 6
74 1b
[ 453.829861] RIP [] release_resource+0x22/0x80
[ 453.837188] RSP
[ 453.841673] CR2: 0030
Fix it by assigning the correct pointers to ioapics[i].iomem_res in
ioapic_setup_resources(). Also simplify the function by removing
the redundant 'num' variable.
Signed-
-removing ioapics.
On a 4-socket brickland, hot-removal of the 3 sockets can be done
only after applying these two patches.
Regards,
Rui
Rui Wang (2):
Support hot-removal of IOAPICs present during boot
x86/ioapic: Fix wrong pointers in ioapic_setup_resources()
arch/x86/kernel/apic/io_apic.c | 18
IOAPICs present during system boot aren't added to ioapic_list,
thus are unable to be hot-removed. Fix it by calling
acpi_ioapic_add() during root bus enumeration.
Signed-off-by: Rui Wang
---
drivers/acpi/internal.h | 2 --
drivers/acpi/ioapic.c | 7 ---
drivers/acpi/pci_root.
On Tuesday, June 7, 2016 5:17 PM, Thomas Gleixner wrote:
> On Tue, 7 Jun 2016, Rui Wang wrote:
> > Also simplify the function by removing the redundant 'num' variable.
> Please don't do that. This makes the patch hard to read. Split this into a
> minimal bugfix,
ource, r);
r++;
}
Here r is treated as an arry of struct resource, and the r++ ensures that
each element of the array is inserted separately. Thus we should call
release_resouce() on each element at &res[num].
Signed-off-by: Rui Wang
---
arch/x86/kernel/apic/io_apic.c |
Optimize the function by removing the variable 'num'.
Signed-off-by: Rui Wang
---
arch/x86/kernel/apic/io_apic.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 446702e..e587
ng
to Thomas.
Rui Wang (3):
x86/ioapic: Support hot-removal of IOAPICs present during boot
x86/ioapic: Fix wrong pointers in ioapic_setup_resources()
x86/ioapic: Simplify ioapic_setup_resources()
arch/x86/kernel/apic/io_apic.c | 18 +++---
drivers/acpi/internal.h
IOAPICs present during system boot aren't added to ioapic_list,
thus are unable to be hot-removed. Fix it by calling
acpi_ioapic_add() during root bus enumeration.
Signed-off-by: Rui Wang
---
drivers/acpi/internal.h | 2 --
drivers/acpi/ioapic.c | 7 ---
drivers/acpi/pci_root.
v3: Previous versions break mips. This version fixes it.
IOAPICs present during system boot aren't added to ioapic_list,
thus are unable to be hot-removed. Fix it by calling
acpi_ioapic_add() during root bus enumeration.
Signed-off-by: Rui Wang
---
drivers/acpi/internal.h | 2 --
drivers
On Saturday, June 11, 2016 12:43 AM, Bjorn Helgaas wrote:
> On Wed, Jun 08, 2016 at 05:32:44PM +0800, Rui Wang wrote:
> > @@ -1779,8 +1780,12 @@ void __init
> > pci_assign_unassigned_resources(void)
> > {
> > struct pci_bus *root_bus;
> >
> > - list_f
On Wed, June 22, 2016 10:54 PM Bjorn Helgaas wrote:
> On Wed, Jun 22, 2016 at 03:13:32PM +0800, Rui Wang wrote:
> > On Friday, June 17, 2016 1:10 AM, Bjorn Helgaas wrote:
> > > ioapic_insert_resources() is x86-specific, but I'm not sure why; it
> > > seems li
On Fri, Jun 24, 2016 1:35 AM Bjorn Helgaas wrote:
> On Thu, Jun 23, 2016 at 01:11:41PM +0800, Rui Wang wrote:
> > On Wed, June 22, 2016 11:15 PM Bjorn Helgaas wrote:
> > > [...]
> > > > @@ -1779,8 +1780,12 @@ void __init
> > >
ix it by calling
acpi_ioapic_add() during root bus enumeration.
Signed-off-by: Rui Wang
---
drivers/acpi/internal.h | 2 --
drivers/acpi/ioapic.c | 7 ---
drivers/acpi/pci_root.c | 13 -
drivers/pci/setup-bus.c | 5 -
include/linux/acpi.h| 6 ++
5 files change
Hi all,
I'm here to report two panics which hang forever (the machine cannot reboot).
It is because mgag200 doesn't work in panic context. It sleeps and allocates
memory non-atomically.
These were triggered while injecting machine checks using einj.
1)
[321381.466885] [ cut here ]
On Sat, Jan 30, 2016 5:44 PM Konstantin Khlebnikov wrote:
> On Fri, Jan 8, 2016 at 6:09 PM, Rui Wang wrote:
> ovl_remove_upper() should do d_drop() only after it successfully
> removes the dir, otherwise a subsequent getcwd() system call will
> fail, breaking userspace programs.
1 - 100 of 136 matches
Mail list logo
