Hi,
With 4.1-rc2 the rackmeter driver for G5 Xserve is giving bogus
led patterns. So far I have seen at least the following:
a) With static load the leds seems to be sane and report CPU
usage properly, but after few minutes they go completely OFF,
even if the CPU load remains high.
b) On a compl
On Sat, May 09, 2015 at 07:23:33PM +0200, Wolfram Sang wrote:
> Commit 3a3dd0186f619b ("i2c/powermac: Improve detection of devices from
> device-tree") added a codec device instantiation workaround
> unconditionally although it is only needed for onyx. Do it conditionally
> since keywest has its ow
On Tue, May 05, 2015 at 01:11:28PM -0400, Chris Metcalf wrote:
> We were returning zero if no bytes could be written to the Tilera
> hypervisor console device, but this causes the output to be truncated.
> By returning -EAGAIN the tty hvc driver will come back and try again,
> which gives the seman
On Sun, 2015-05-10 at 21:32 +0300, Aaro Koskinen wrote:
> Hi,
>
> With 4.1-rc2 the rackmeter driver for G5 Xserve is giving bogus
> led patterns. So far I have seen at least the following:
>
> a) With static load the leds seems to be sane and report CPU
> usage properly, but after few minutes the
On Sun, 2015-05-10 at 20:34 +0200, Wolfram Sang wrote:
> Okay, so this patch is bogus. I understand now that onyx uses another
> codec than TAS, so this change will regress on other machines.
> However,
> it shows that this unconditional instantiation of the TAS breaks sound
> on Macintoshs which s
Before 69111bac42f5 ("powerpc: Replace __get_cpu_var uses"), in
save_mce_event, index got the value of mce_nest_count, and
mce_nest_count was incremented *after* index was set.
However, that patch changed the behaviour so that mce_nest count was
incremented *before* setting index.
This causes an
On Thu, May 07, 2015 at 05:12:24PM -0500, Bjorn Helgaas wrote:
>Hi Gavin,
>
>[Please run "git log --oneline drivers/pci/setup-bus.c" and observe the
>capitalization convention.]
>
Bjorn, thanks for review. Yeah, it should be something like
"PCI: " for the subject. I'll fix it up in next revisi
On 05/05/2015 10:02 PM, David Gibson wrote:
On Fri, May 01, 2015 at 05:12:45PM +1000, Alexey Kardashevskiy wrote:
On 05/01/2015 02:23 PM, David Gibson wrote:
On Fri, May 01, 2015 at 02:01:17PM +1000, Alexey Kardashevskiy wrote:
On 04/29/2015 04:31 PM, David Gibson wrote:
On Sat, Apr 25, 2015
On Mon, May 04, 2015 at 03:07:30PM +0800, Wei Yang wrote:
>During the EEH procedure, when a device's driver is not EEH aware or no
^
EEH recovery,
>driver is binded with a device, EEH core would do hotplug on this devices.
^^
On Mon, May 04, 2015 at 03:07:31PM +0800, Wei Yang wrote:
>This patch caches the index of a VF in its PF in pci_dn.
>
At least you can mention the purpose of vf_index to make the commit log
complete. The following message looks better?
The patch caches the VF index in pci_dn, which can be used to
On 05/05/2015 09:58 PM, David Gibson wrote:
On Fri, May 01, 2015 at 04:53:08PM +1000, Alexey Kardashevskiy wrote:
On 05/01/2015 03:12 PM, David Gibson wrote:
On Fri, May 01, 2015 at 02:10:58PM +1000, Alexey Kardashevskiy wrote:
On 04/29/2015 04:40 PM, David Gibson wrote:
On Sat, Apr 25, 2015
On 05/05/2015 09:50 PM, David Gibson wrote:
On Fri, May 01, 2015 at 04:05:24PM +1000, Alexey Kardashevskiy wrote:
On 05/01/2015 02:33 PM, David Gibson wrote:
On Thu, Apr 30, 2015 at 07:33:09PM +1000, Alexey Kardashevskiy wrote:
On 04/30/2015 05:22 PM, David Gibson wrote:
On Sat, Apr 25, 2015
On Mon, May 04, 2015 at 03:07:34PM +0800, Wei Yang wrote:
Please reorder PATCH[6] with this one because the EEH device is expected
to be created before EEH PE.
>On powernv platform, VF PE is a special PE which is different from the Bus
>PE. On the EEH side, it needs a corresponding concept to ha
Hello Eduardo,
As Rui Zhang did not response for a long time.
Could you help to review this Thermal Management driver?
Thanks.
---
Best Regards,
Hongtao
> -Original Message-
> From: Jia Hongtao-B38951
> Sent: Tuesday, April 28, 2015 3:34 PM
> To: rui.zh...@intel.com
> Cc: linux...@vger.
On Mon, May 04, 2015 at 03:07:35PM +0800, Wei Yang wrote:
Please order this patch and PATCH[5] because EEH device is expected to
be created before EEH PE.
>EEH on powerpc platform needs eeh_dev structure to track the pci device
^^^
On Mon, May 04, 2015 at 03:07:36PM +0800, Wei Yang wrote:
>Before VF PE introduced, there isn't a method to reset an individual pci
^^^^
is PCI
>function. And sin
Hi,
On Thu, 7 May 2015 12:43:11 Corey Minyard wrote:
>
> The only thing I would suggest is passing the irq level
> (IRQ_TYPE_LEVEL_HIGH) as
> part of the openfirmware data instead of hard-coding it.
I intend to do that in future once our firmware is updated to pass this
information (via
the de
On 05/10/2015 04:45 AM, Rafael J. Wysocki wrote:
> On Saturday, May 09, 2015 10:33:05 PM Rafael J. Wysocki wrote:
>> On Saturday, May 09, 2015 10:11:41 PM Rafael J. Wysocki wrote:
>>> On Saturday, May 09, 2015 11:19:16 AM Preeti U Murthy wrote:
Hi Rafael,
On 05/08/2015 07:48 PM, Rafa
On Mon, May 04, 2015 at 03:07:37PM +0800, Wei Yang wrote:
>Since FW is not aware of VFs, the restore action for VF should be done in
^^
skiboot firmware
>kernel.
>
>This patch introduces pnv_eeh_vf_restore_config() for VF.
>
Would it be better?
The patch introduces function pnv_eeh_
On Sat, May 09, 2015 at 10:18:42AM +1000, Alexey Kardashevskiy wrote:
>On 05/01/2015 04:02 PM, Gavin Shan wrote:
>>The patch enables M64 window on P7IOC, which has been enabled on
>>PHB3. Comparing to PHB3, there are 16 M64 BARs and each of them
>>are divided to 8 segments.
>
>"compared to somethin
On Sat, May 09, 2015 at 08:24:14PM +1000, Alexey Kardashevskiy wrote:
>On 05/01/2015 04:02 PM, Gavin Shan wrote:
>>We're having the hardware or enforced (on P7IOC) limitation: M64
>
>I would think if it is enforced, then it is enforced by hardware but you say
>"hardware OR enforced" :)
>
PHB3 does
On 05/11/2015 12:11 PM, Alexey Kardashevskiy wrote:
On 05/05/2015 10:02 PM, David Gibson wrote:
On Fri, May 01, 2015 at 05:12:45PM +1000, Alexey Kardashevskiy wrote:
On 05/01/2015 02:23 PM, David Gibson wrote:
On Fri, May 01, 2015 at 02:01:17PM +1000, Alexey Kardashevskiy wrote:
On 04/29/2015
On Sat, May 09, 2015 at 08:53:38PM +1000, Alexey Kardashevskiy wrote:
>On 05/01/2015 04:02 PM, Gavin Shan wrote:
>>The PHB's IO or M32 window is divided evenly to segments, each of
>>them can be mapped to arbitrary PE# by IODT or M32DT. Current code
>>figures out the consumed IO and M32 segments by
On Sat, May 09, 2015 at 09:43:16PM +1000, Alexey Kardashevskiy wrote:
>On 05/01/2015 04:02 PM, Gavin Shan wrote:
>>Currently, the PEs and their associated resources are assigned
>>in ppc_md.pcibios_fixup(). The function is called for once after
>>PCI probing and resources assignment are finished. O
On 05/10/2015 04:45 AM, Rafael J. Wysocki wrote:
> On Saturday, May 09, 2015 10:33:05 PM Rafael J. Wysocki wrote:
>> On Saturday, May 09, 2015 10:11:41 PM Rafael J. Wysocki wrote:
>>> On Saturday, May 09, 2015 11:19:16 AM Preeti U Murthy wrote:
Hi Rafael,
On 05/08/2015 07:48 PM, Rafa
On Mon, May 11, 2015 at 12:21:04PM +1000, Gavin Shan wrote:
>On Mon, May 04, 2015 at 03:07:31PM +0800, Wei Yang wrote:
>>This patch caches the index of a VF in its PF in pci_dn.
>>
>
>At least you can mention the purpose of vf_index to make the commit log
>complete. The following message looks bett
On Mon, May 11, 2015 at 12:37:07PM +1000, Gavin Shan wrote:
>On Mon, May 04, 2015 at 03:07:34PM +0800, Wei Yang wrote:
>
>Please reorder PATCH[6] with this one because the EEH device is expected
>to be created before EEH PE.
That's a good idea.
>
>>On powernv platform, VF PE is a special PE which
On Sat, May 09, 2015 at 10:43:23PM +1000, Alexey Kardashevskiy wrote:
>On 05/01/2015 04:02 PM, Gavin Shan wrote:
>>The original code doesn't support releasing PEs dynamically, meaning
>>that PE and the associated resources (IO, M32, M64 and DMA) can't
>>be released when unplugging a PCI adapter fro
Serialize against find_linux_pte_or_hugepte which does lock-less
lookup in page tables with local interrupts disabled. For huge pages
it casts pmd_t to pte_t. Since format of pte_t is different from
pmd_t we want to prevent transit from pmd pointing to page table
to pmd pointing to huge page (and b
We need to check whether pte is present in follow_huge_addr and
properly return NULL if mapping is not present. Also use READ_ONCE
when dereferencing pte_t address.
Without this patch, we may wrongly return a zero pfn page in follow_huge_addr.
Reviewed-by: David Gibson
Signed-off-by: Aneesh Kuma
Andrew Morton writes:
> On Thu, 7 May 2015 12:53:28 +0530 "Aneesh Kumar K.V"
> wrote:
>
>> Serialize against find_linux_pte_or_hugepte which does lock-less
>> lookup in page tables with local interrupts disabled. For huge pages
>> it casts pmd_t to pte_t. Since format of pte_t is different fro
Andrew Morton writes:
> On Thu, 7 May 2015 12:53:27 +0530 "Aneesh Kumar K.V"
> wrote:
>
>> After this patch pmdp_* functions operate only on hugepage pte,
>> and not on regular pmd_t values pointing to page table.
>>
>
> The patch looks like a pretty safe no-op for non-powerpc?
That is corre
Architectures like ppc64 [1] need to do special things while clearing
pmd before a collapse. For them this operation is largely different
from a normal hugepage pte clear. Hence add a separate function
to clear pmd before collapse. After this patch pmdp_* functions
operate only on hugepage pte, and
On Sat, May 09, 2015 at 11:41:05PM +1000, Alexey Kardashevskiy wrote:
>On 05/01/2015 04:02 PM, Gavin Shan wrote:
>>For PowerNV platform, running on top of skiboot, all PE level reset
>>should be routed to firmware if the bridge of the PE primary bus has
>>device-node property "ibm,reset-by-firmware
On Sun, May 10, 2015 at 12:12:18AM +1000, Alexey Kardashevskiy wrote:
>On 05/01/2015 04:02 PM, Gavin Shan wrote:
>>Function pnv_pci_reset_secondary_bus() is used to reset specified
>>PCI bus, which is leaded by root complex or PCI bridge. That means
>>the function shouldn't be called on PCI root bu
On Thu, 2015-05-07 at 15:00 +0530, Vipin K Parashar wrote:
> This patch adds support for FSP EPOW (Early Power Off Warning) and
> DPO (Delayed Power Off) events support for PowerNV platform. EPOW events
> are generated by SPCN/FSP due to various critical system conditions that
> need system shutdo
36 matches
Mail list logo
