On 02/13/2015 10:57 AM, Preeti U Murthy wrote:
> On 02/13/2015 06:27 AM, Sam Bobroff wrote:
>> Hello,
>>
>> I'm receiving this while booting a vanilla 3.19 kernel on a Power 8 machine:
>
> Does the below patch fix the issue ?
>
> From: Preeti U Murthy
>
> [PATCH] tick/hrtimer-broadcast: Fix a s
On 02/13/2015 08:16 AM, Sam Bobroff wrote:
> On 13/02/15 08:27, Benjamin Herrenschmidt wrote:
>> On Thu, 2015-02-12 at 15:23 +0530, Vasant Hegde wrote:
>>> Present code checks for update_flash_data in opal_flash_term_callback().
>>> update_flash_data has been statically initialized to zero, and tha
On 02/13/2015 02:57 AM, Benjamin Herrenschmidt wrote:
> On Thu, 2015-02-12 at 15:23 +0530, Vasant Hegde wrote:
>> Present code checks for update_flash_data in opal_flash_term_callback().
>> update_flash_data has been statically initialized to zero, and that
>> is the value of FLASH_IMG_READY. Also
On 02/13/2015 06:27 AM, Sam Bobroff wrote:
> Hello,
>
> I'm receiving this while booting a vanilla 3.19 kernel on a Power 8 machine:
Does the below patch fix the issue ?
From: Preeti U Murthy
[PATCH] tick/hrtimer-broadcast: Fix a suspicious RCU usage in the tick
broadcast path
---
kernel/ti
The patch introduces list to hold the PCI device specific reset
methods. With help of the list, we can register PCI device specific
reset method dynamically as we do in next one patch.
Signed-off-by: Gavin Shan
---
drivers/pci/pci.h| 1 +
drivers/pci/quirks.c | 75 ++
Currently, PCI VFIO infrastructure depends on pci_reset_function()
to ensure the PCI device in clean state when passing to guest, or
being returned back to host. However, the function doesn't work
(or well) on some PCI devices, which potentially brings pending
traffic over the boundary between host
It'd better to have "struct pci_dev_reset_method" as its name.
Signed-off-by: Gavin Shan
---
drivers/pci/pci.h| 2 +-
drivers/pci/quirks.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 4091f82..e67b22f 100644
--- a/driver
VFIO PCI infrastructure depends on pci_reset_function() to do reset on
PCI devices so that they would be in clean state when host or guest grabs
them. Unfortunately, the function doesn't work (or not well) on some PCI
devices that require EEH PE reset.
The patchset extends the quirk for PCI device
The patch exposes function pci_dev_add_specific_reset() to allow
registering PCI device specific reset methods.
Signed-off-by: Gavin Shan
---
drivers/pci/quirks.c | 64
include/linux/pci.h | 9
2 files changed, 73 insertions(+)
dif
The patch fixes the comments about ppc_md.pcibios_fixup(), which
should be called after allocating resources.
Signed-off-by: Gavin Shan
---
arch/powerpc/include/asm/machdep.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/machdep.h
b/arch/powerpc/in
On 13/02/15 08:27, Benjamin Herrenschmidt wrote:
> On Thu, 2015-02-12 at 15:23 +0530, Vasant Hegde wrote:
>> Present code checks for update_flash_data in opal_flash_term_callback().
>> update_flash_data has been statically initialized to zero, and that
>> is the value of FLASH_IMG_READY. Also code
Hello,
I'm receiving this while booting a vanilla 3.19 kernel on a Power 8 machine:
[2.522179] device-mapper: uevent: version 1.0.3
[2.522741] device-mapper: ioctl: 4.29.0-ioctl (2014-10-28)
initialised: dm-de...@redhat.com
[2.543590]
[2.543630] ===
[
On Thu, 2015-02-12 at 15:23 +0530, Vasant Hegde wrote:
> Present code checks for update_flash_data in opal_flash_term_callback().
> update_flash_data has been statically initialized to zero, and that
> is the value of FLASH_IMG_READY. Also code update initialization happens
> during subsys init.
P
On 02/11/2015 04:27 PM, Anshuman Khandual wrote:
On 02/11/2015 11:57 AM, Neelesh Gupta wrote:
Provide an unregister interface for the opal message notifiers
to be called when not needed like during driver unload/remove.
Why only for unload/remove, you can also use it in cases where you need
to
Present code checks for update_flash_data in opal_flash_term_callback().
update_flash_data has been statically initialized to zero, and that
is the value of FLASH_IMG_READY. Also code update initialization happens
during subsys init.
So if reboot is issued before the subsys init stage then we endu
On 02/12/2015 10:55 AM, Stewart Smith wrote:
> Not all OPAL platforms support resending system dumps, so check
> that current firmware supports it first. Otherwise we get firmware
> complaining:
> "OPAL: Called with bad token 91 !"
>
> Signed-off-by: Stewart Smith
Acked-by: Vasant Hegde
-Vasa
On 02/12/2015 10:55 AM, Stewart Smith wrote:
> Otherwise firmware complains: "OPAL: Called with bad token 74 !"
> as not all OPAL systems have the ability to resend error logs.
>
> Signed-off-by: Stewart Smith
Acked-by: Vasant Hegde
-Vasant
> ---
> arch/powerpc/platforms/powernv/opal-elog
On 02/12/2015 10:55 AM, Stewart Smith wrote:
> Correct use of REGISTER/UNREGISTER is to check if the token exists
> before calling. If we don't we get a "OPAL: Called with bad token 101 !"
> error, which is harmless but may be alarming to some.
>
> Signed-off-by: Stewart Smith
Acked-by: Vasant H
On 12.02.2015 07:24, Michael Ellerman wrote:
On Wed, 2015-02-11 at 08:36 +, Bogdan Purcareata wrote:
In certain scenarios - e.g. seccomp filtering with ERRNO as default action -
the system call fails for other reasons than the syscall not being available.
The seccomp filter can be configured
19 matches
Mail list logo
