isync
blr
Best regards
-Mike
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Hi all
Any comments about my patchset?
Thanks
Mike
在 2013-01-15二的 15:38 +0800，Mike Qiu写道：
> Currently, multiple MSI feature hasn't been enabled in pSeries,
> These patches try to enbale this feature.
>
> These patches have been tested by using ipr driver, and the driver patc
Hi all
Any comments? or any questions about my patchset?
Thanks
Mike
在 2013-01-15二的 15:38 +0800，Mike Qiu写道：
> Currently, multiple MSI feature hasn't been enabled in pSeries,
> These patches try to enbale this feature.
>
> These patches have been tested by using ipr driver, and
Hi all
Any comments? or any questions about my patchset?
Thanks
Mike
在 2013-01-15二的 15:38 +0800，Mike Qiu写道：
> Currently, multiple MSI feature hasn't been enabled in pSeries,
> These patches try to enbale this feature.
>
> These patches have been tested by using ipr driver, and
Building on ppc32
In file included from fs/proc/task_mmu.c:14:0:
include/linux/swapops.h: In function ‘pte_to_swp_entry’:
include/linux/swapops.h:69:6: error: implicit declaration of function
‘pte_swp_soft_dirty’ [-Werror=implicit-function-declaration]
if (pte_swp_soft_dirty(pte))
^
includ
Thanks!
Applied and it built this time, sadly i missed RC-2 and will just have to
test and see if the radeon r300 is un-broken and rebuild, doing dpkg kernel
build and was lazy with the .config so it takes a day building on this
single core g4!
Cheers
Mike
On 1 February 2016 at 01:05, Pranith
Agreed, raised an eyebrow initially when select ppc64 and 32 :D
I'll give a word on the trackpad issue later, cant remember seeing any
changes that ought effect it really. guess the compile is done in a good
hour or so, took the tiime to slim it down to someting reasonable
Thanks man
On 2 Feb 201
b 2 03:39:38 PowerBook-G4 kernel: [ 15.423289] usbcore:
registered new interface driver appletouch
Any clues? Worked in 4.3.3 at least . Anyone point me to where i could
begin to look? Any structures changed which could account for this?
On 2 February 2016 at 17:55, Mike wrote:
> Agre
would account for this ...
On 3 February 2016 at 00:05, Mike wrote:
> Normally as far as i can tell it should register it as input and that's
> not happening, verified the config entry CONFIG_MOUSE_APPLETOUCH is
> selected and compiled in both tests i've done for rc-1 and rc-
o point to serious issues had around the time of change to ums
to kms and a serious regression hitting the linux kernel? No?
Cheers
-Mike
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Put the info forth in an Amiga ppc related thread, agpmode=-1 is also
needed on the Pegasos 2, need do some research/googling but is it safe to
say its broken for all non x86 platforms?
Including those replies here:
Hi Christian and Mike,
for my personal experiences on Pegasos2 and MacMini
. <
herminio.hernande...@gmail.com> wrote:
> I have been experiencing the same thing with my iBook and PowerBook.
>
> Sent from my iPhone
>
> On Feb 4, 2016, at 8:47 PM, Mike wrote:
>
> Hi.
> Managed to get the Radeon R300 running on mesa 11.1.1 with an old 2013
&g
:
> I have already applied his patches on my PowerBook running Jessie to get
> accelerated graphics. However they are only a work around and not a real
> fix so they will be committed to mesa.
>
> On Fri, Feb 5, 2016 at 8:44 AM, Mike wrote:
>
>> Herminio,
>>
gt; Yeah the issue is with the driOpenDriver function at least that what I
> think from what I saw in gdb.
>
> On Fri, Feb 5, 2016 at 12:06 PM, Mike wrote:
>
>> True, a permanent patch was needed, but at least we are up and running
>> and can identify other issues.. In the thre
Excellent work!
On 5 February 2016 at 19:46, Herminio Hernandez, Jr. <
herminio.hernande...@gmail.com> wrote:
> Yeah that is the thread I am on
>
> On Fri, Feb 5, 2016 at 1:44 PM, Mike wrote:
>
>> Thanks, found this now -
>> https://www.mail-archive.com/search?l=me
, hardware
acceleration brings on a crash so hard a 5 sec power off is required if
agpmode is active...
On 8 February 2016 at 09:53, Michel Dänzer wrote:
> On 05.02.2016 11:47, Mike wrote:
> > Hi.
> > Managed to get the Radeon R300 running on mesa 11.1.1 with an old 2013
> >
ecate the
entire AGP system
On 8 February 2016 at 12:41, Boris Reinhard
wrote:
> Definitely would have made sense for years, but could someone possibly
> look into a proper solution?
>
> Michel Dänzer schrieb am Mo., 8. Feb. 2016 11:00:
>
>> On 05.02.2016 11:47, Mike wrote
shing 10 years , but it's the only alternative if
one wishes to remain mobile.
On 9 Feb 2016 02:41, "Michel Dänzer" wrote:
> On 08.02.2016 22:28, Mike wrote:
> > Certainly 750~800 fps in glxgears vs 3000+ in debian squeeze, i cant
> > bring myself to say that it'
Hey, so I originally sat down to compile the fast headers V2 patch, but
quickly discovered other things at play, and grabbed 5.16.0 a few hours
after it lifted off, arch/powerpc/mm/mmu_context.c I had to specifically
say had to include -maltivec or it barfed on a 'dssall', I'm fine with
that, I've
. I usually consider the kernel a
place of sane code, as long as it's not a hurried vendor or so.
-mr pink hand
On Tue, Jan 11, 2022, 10:51 Christophe Leroy
wrote:
>
>
> Le 11/01/2022 à 10:32, Mike a écrit :
> > I managed to fix it in the end, patch attached, though i should
It booted at least. I'll try your suggestions as soon as I can, I'm
progressing slower than ever, concentration is somewhat lapse still
Thanks.
Best regards
Michael
On Tue, Jan 11, 2022, 10:51 Christophe Leroy
wrote:
>
>
> Le 11/01/2022 à 10:32, Mike a écrit :
> &g
As some have probably noticed, we are seeing errors like ' Error:
unrecognized opcode: `ptesync'' 'dssall' and 'stbcix' as a result of
binutils changes, making compiling all that more fun again. The only
question on my mind still is this:
diff --git a/arch/powerpc/include/asm/io.h b/arch/power
;);
break;
+#endif
}
break;
-
On Sun, 23 Jan 2022 at 14:43, Mike wrote:
>
> As some have probably noticed, we are seeing errors like ' Error:
> unrecognized opcode: `ptesync'' 'dssall' and 'stbcix' as a result of
> binutils changes, making co
;);
+#endif
break;
#ifdef CONFIG_PPC64
case BARRIER_PTESYNC:
On Sun, 23 Jan 2022 at 15:18, Mike wrote:
>
> Maybe cite the correct parts of the patch where my questions arose for
> context.
> ---
> diff --git a/arch/powerpc/lib/sstep.c
I just made the huge mistake of hibernating and resuming, I'm going trough
the process of rescue and all, thankfully I had a 2016 cd in the drive.
I'll read up once the sheer panic settles.
-Michael
On Wed, Jan 26, 2022, 21:22 John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:
> Hi
We are seeing errors like ' Error: unrecognized opcode: `ptesync''
'dssall' and 'stbcix' as a result of binutils changes Unless 'stbcix'
and friends aren't as exclusively PPC6 as I've gathered from
binutils/opcode/ppc-opc.c there shouldn't be much of a problem, but i
suspect a lot more needs to be
interface.
On 5 Feb 2016 15:32, "Herminio Hernandez Jr." <
herminio.hernande...@gmail.com> wrote:
> I have been experiencing the same thing with my iBook and PowerBook.
>
> Sent from my iPhone
>
> On Feb 4, 2016, at 8:47 PM, Mike wrote:
>
> Hi.
> Manage
On Wed, Apr 29 2015 at 11:29pm -0400,
Joel Stanley wrote:
> Hello,
>
> I just booted 3d99e3fe13d473ac4578c37f477a59b829530764 (linus' tree as
> of this morning) on a Tuletta and got the following:
This is fixed with the following commit (which I just sent to Linus for
4.1-rc2 inclusion):
https:
lled the following fix into your 2/9 patch. No action is
necessary.
Regards,
Mike
diff --git a/include/asm-generic/clkdev.h b/include/asm-generic/clkdev.h
index 4320225..90a32a6 100644
--- a/include/asm-generic/clkdev.h
+++ b/include/asm-generic/clkdev.h
@@ -15,10 +15,10 @@
#include
-struct clk
feats
> > the
> > purpose of having a config option in the first place.
>
> Only if Kconfig CONFIG_DEBUG_KERNEL is enabled in the first place.
Which is likely enabled just about everywhere on the planet.
-Mike
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
r(&ppc_corenet_clk_driver);
> + return platform_driver_register(&qoriq_clk_driver);
> }
> -subsys_initcall(ppc_corenet_clk_init);
> +subsys_initcall(qoriq_clk_init);
> +
> +CLK_OF_DECLARE(qoriq_core_pll_v1, "fsl,qoriq-core-pll-1.0", core_pll_init);
> +CLK_OF_DECLARE(qoriq_core_pll_v2, "fsl,qoriq-core-pll-2.0", core_pll_init);
> +CLK_OF_DECLARE(qoriq_core_mux_v1, "fsl,qoriq-core-mux-1.0", core_mux_init);
> +CLK_OF_DECLARE(qoriq_core_mux_v2, "fsl,qoriq-core-mux-2.0", core_mux_init);
Is there binding documentation for these compatibles?
Regards,
Mike
> --
> 1.8.0
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
is essentially just renames (though the V1.0/V2.0
stuff seems weird).
Regards,
Mike
>
> -Scott
>
> On Thu, 2014-09-25 at 04:47 -0500, Lu Jingchang-B35083 wrote:
> > Hi, Scott and Mike,
> >
> > Could you please help review this patch and give an ACK if ok.
Quoting Scott Wood (2014-09-25 15:56:20)
> On Thu, 2014-09-25 at 15:54 -0700, Mike Turquette wrote:
> > Quoting Scott Wood (2014-09-25 13:08:00)
> > > Well, like I said, I'd rather see the CLK_OF_DECLARE stuff be made to
> > > work on PPC rather than have the
Quoting Scott Wood (2014-11-06 20:07:43)
> On Sun, 2014-10-19 at 14:11 +0800, Kevin Hao wrote:
> > Hi,
> >
> > I have done a boot test on p2014rdb and t4240qds boards. I don't have an
> > access
> > to mpc512x board, so only build test for that.
> >
> > v2:
> > - Revert the commit da788acb2838
to me. I've taken it into clk-next for now, but by
aware that I'll be rebasing that branch until at least -rc3 comes out,
so don't use it for a stable branch.
I did not take in patch #2, I guess you'll send that through a PPC tree?
Regards,
Mike
> ---
> v3:
>
于 2013/5/21 22:45, Alexander Gordeev 写道:
On Tue, Jan 15, 2013 at 03:38:53PM +0800, Mike Qiu wrote:
The test results is shown by 'cat /proc/interrups':
CPU0 CPU1 CPU2 CPU3
16: 240458 261601 226310 200425 XICS Level IPI
17:
于 2013/5/22 8:15, Benjamin Herrenschmidt 写道:
On Tue, 2013-05-21 at 16:45 +0200, Alexander Gordeev wrote:
On Tue, Jan 15, 2013 at 03:38:53PM +0800, Mike Qiu wrote:
The test results is shown by 'cat /proc/interrups':
CPU0 CPU1 CPU2 CPU3
16: 240458
>> (48 - 32)) << 4);
+ pci_write_config_dword(pdev, pos + PCI_MSI_ADDRESS_LO,
addr_lo);
+ pci_write_config_dword(pdev, pos + PCI_MSI_ADDRESS_HI,
0);
I think here you can use catched dev->msi_cap for better.
Thanks
Mike
+
Quoting yuantian.t...@freescale.com (2013-05-22 01:22:19)
> From: Tang Yuantian
>
> The compatible string of clock is changed from *-2 to *-2.0
> on chassis 2. So updated it accordingly.
>
> Signed-off-by: Tang Yuantian
Taken into clk-next.
Regards,
Mike
> ---
&
Quoting Mike Turquette (2013-05-30 11:57:32)
> Quoting yuantian.t...@freescale.com (2013-05-22 01:22:19)
> > From: Tang Yuantian
> >
> > The compatible string of clock is changed from *-2 to *-2.0
> > on chassis 2. So updated it accordingly.
> >
> > Signed
Quoting Kumar Gala (2013-05-30 12:26:38)
> On May 30, 2013, at 2:21 PM, Mike Turquette wrote:
>
> > Quoting Mike Turquette (2013-05-30 11:57:32)
> >> Quoting yuantian.t...@freescale.com (2013-05-22 01:22:19)
> >>> From: Tang Yuantian
> >>>
> &g
ot;, virq))
+ return -EINVAL;
Hi Grant,
I have a qestion here, assume that we have three hwirqs and alloc three
virqs, for first irq, it check irq_data
and irq_data->domain pass, but the second is failed, then this code do
nothing with failed( in
irq_domain_associate_many(
r a device pe ? the value is the
bus which edev belongs to.
so that we can make the code more efficient for device pe.
I have no idea of whether this will cause side effect
Thanks
Mike
+
/* Put the edev to PE */
list_add_tail(&edev->list, &pe->edev
Documentation/clk.txt with more verbosity. The document was
originally intended as a "porting guide" to help migrate from legacy
frameworks to the common struct clk implementation. However the scope of
the document should probably be generalized a bit more.
Regards,
Mike
>
>
> Nicolas
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
pport for other platforms
>
> Signed-off-by: Gerhard Sittig
I've taken this into clk-next for testing. regmap deserves investigation
but I don't think your series should be blocked on that. We can always
overhaul the basic clock primitives with regmap support later on if t
e an enum but
> + * needs to be a list of #define directives since when referenced from
> + * within DTS files they need to get resolved "at compile time".
Above comment is not really necessary. Otherwise,
Reviewed-by: Mike Turquette
> + */
> +
> +#ifndef _DT_
> the reference design (25MHz xtal, 80MHz IPS bus)
>
> Signed-off-by: Gerhard Sittig
Reviewed-by: Mike Turquette
> ---
> arch/powerpc/boot/dts/ac14xx.dts |7 +++
> arch/powerpc/boot/dts/mpc5121.dtsi | 15 ++-
> 2 files changed, 21 insertions(+), 1
on looks OK. It would be helpful if another
platform with shared gates could weigh in on whether the implementation
works for them.
Still, a shared gate solution is not a prerequisite for this series,
correct?
Regards,
Mike
>
> The clock subtrees which are involved in generating CAN bitra
gt;
> these specs map 'clock-names' encoded in drivers to their respective
> 'struct clk' items in the platform's clock driver
>
> Signed-off-by: Gerhard Sittig
Reviewed-by: Mike Turquette
> ---
> arch/powerpc/boot/dts/mpc5121.dtsi | 79
> +
et removed as these drivers get adjusted after
> device tree based clock lookup has become available
>
> Signed-off-by: Gerhard Sittig
Hi Gerhard,
This looks OK to me. Do you want me to take it or will you keep the
series together? Note that I took "clk: wrap I/O acces
Quoting Gerhard Sittig (2013-08-03 07:39:56)
> [ we are strictly talking about clocks and source code again,
> I have trimmed the CC: list to not spam the device tree ML or
> subsystem maintainers ]
>
> On Fri, Aug 02, 2013 at 16:30 -0700, Mike Turquette wrote:
> >
>
'pe_no' hasn't been defined, it should be an typo error,
it should be 'frozen_pe_no'.
Also '__func__' should be added to IODA_EEH_DBG(),
Signed-off-by: Mike Qiu
---
arch/powerpc/platforms/powernv/eeh-ioda.c | 3 ++-
1 file changed, 2 insertions(+), 1 del
The procfs entry for global statistics has been missed on PowerNV
platform and the patch is going to add that.
Signed-off-by: Mike Qiu
---
arch/powerpc/kernel/eeh.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index
于 2013/8/7 13:25, Gavin Shan 写道:
On Wed, Aug 07, 2013 at 03:11:24PM +1000, Michael Ellerman wrote:
On Tue, Aug 06, 2013 at 10:24:46PM -0400, Mike Qiu wrote:
'pe_no' hasn't been defined, it should be an typo error,
it should be 'frozen_pe_no'.
Also '__func__&#x
'pe_no' hasn't been defined, it should be an typo error,
it should be 'frozen_pe_no'.
Also '__func__' has missed in IODA_EEH_DBG(),
For safety reasons, use pr_info() directly, instead
of use IODA_EEH_DBG()
Signed-off-by: Mike Qiu
---
arch/powerp
'pe_no' hasn't been defined, it should be an typo error,
it should be 'frozen_pe_no'.
Also '__func__' has missed in IODA_EEH_DBG(),
For safety reasons, use pr_devel() directly, instead
of use IODA_EEH_DBG()
Signed-off-by: Mike Qiu
---
arch/powerp
pr_devel() directly, instead
of use IODA_EEH_DBG()
Signed-off-by: Mike Qiu
---
arch/powerpc/platforms/powernv/eeh-ioda.c | 22 --
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/eeh-ioda.c
b/arch/powerpc/platforms/powernv/eeh-ioda.c
y clock, then we might also want a generic way to
> > specify it.
>
> What do we actually mean by a "dummy clock"? We already have bindings
> for "fixed-clock" and co friends describe relatively simple
> preconfigured clocks.
Some platfor
Quoting Tomasz Figa (2013-08-21 14:34:55)
> On Wednesday 21 of August 2013 09:50:15 Mark Rutland wrote:
> > On Tue, Aug 20, 2013 at 01:06:25AM +0100, Mike Turquette wrote:
> > > Quoting Mark Rutland (2013-08-19 02:35:43)
> > >
> > > > On Sat, Aug 17, 2013
Quoting Sascha Hauer (2013-08-22 14:00:35)
> On Thu, Aug 22, 2013 at 01:09:31PM +0100, Mark Rutland wrote:
> > On Thu, Aug 22, 2013 at 08:19:10AM +0100, Mike Turquette wrote:
> > > Quoting Tomasz Figa (2013-08-21 14:34:55)
> > > > On Wednesday 21 of August 20
Quoting Sascha Hauer (2013-08-23 07:01:28)
> On Fri, Aug 23, 2013 at 01:58:15PM +0100, Mark Rutland wrote:
> > On Fri, Aug 23, 2013 at 07:34:21AM +0100, Sascha Hauer wrote:
> > > On Fri, Aug 23, 2013 at 12:49:19AM +0200, Tomasz Figa wrote:
> > > > On Thursday 2
Quoting Anatolij Gustschin (2013-08-23 15:05:39)
> On Fri, 02 Aug 2013 15:30:00 -0700
> Mike Turquette wrote:
>
> > Quoting Gerhard Sittig (2013-07-22 05:14:40)
> > > the common clock drivers were motivated/initiated by ARM development
> > > and apparently
0 Machine check exceptions
Mike Qiu (3):
irq: Set multiple MSI descriptor data for multiple IRQs
irq: Add hw continuous IRQs map to virtual continuous IRQs support
powerpc/pci: Enable pSeries multiple MSI feature
arch/powerpc/kernel/msi.c|4 --
arch/powerpc/platforms/pseri
Adding a function irq_create_mapping_many() which can associate
multiple MSIs to a continous irq mapping.
This is needed to enable multiple MSI support for pSeries.
Signed-off-by: Mike Qiu
---
include/linux/irq.h |2 +
include/linux/irqdomain.h |3 ++
kernel/irq/irqdomain.c
PCI devices support MSI, MSIX as well as multiple MSI.
But pSeries does not support multiple MSI yet.
This patch enable multiple MSI feature in pSeries.
Signed-off-by: Mike Qiu
---
arch/powerpc/kernel/msi.c|4 --
arch/powerpc/platforms/pseries/msi.c | 62
Multiple MSI only requires the IRQ in msi_desc entry to be set as
the value of irq_base.
This patch implements the above mentioned technique.
Signed-off-by: Mike Qiu
---
include/linux/irq.h |2 ++
kernel/irq/chip.c | 40 ++--
2 files changed, 32
With the fix, the machine can boot up successfully
Tested-by: Mike Qiu
于 2013/1/30 13:40, Aneesh Kumar K.V 写道:
> From: "Aneesh Kumar K.V"
>
> The ASM version of hash computation function was truncating the upper bit.
> Make the ASM version similar to hpt_hash function. Re
On Tue, 2013-01-15 at 15:38 +0800, Mike Qiu wrote:
Currently, multiple MSI feature hasn't been enabled in pSeries,
These patches try to enbale this feature.
Hi Mike,
These patches have been tested by using ipr driver, and the driver patch
has been made by Wen Xiong :
So who wrote
2013/2/4 13:56, Michael Ellerman:
On Mon, 2013-02-04 at 11:49 +0800, Mike Qiu wrote:
On Tue, 2013-01-15 at 15:38 +0800, Mike Qiu wrote:
Currently, multiple MSI feature hasn't been enabled in pSeries,
These patches try to enbale this feature.
Hi Mike,
These patches have been tested by
于 2013/3/1 11:54, Michael Ellerman 写道:
On Fri, Mar 01, 2013 at 11:08:45AM +0800, Mike wrote:
Hi all
Any comments? or any questions about my patchset?
You were going to get some performance numbers that show a definite
benefit for using more than one MSI.
Yes, but my patch just enable the
于 2013/3/5 10:23, Michael Ellerman 写道:
On Tue, Jan 15, 2013 at 03:38:55PM +0800, Mike Qiu wrote:
Adding a function irq_create_mapping_many() which can associate
multiple MSIs to a continous irq mapping.
This is needed to enable multiple MSI support for pSeries.
Signed-off-by: Mike Qiu
于 2013/3/5 10:41, Paul Mundt 写道:
On Tue, Jan 15, 2013 at 03:38:55PM +0800, Mike Qiu wrote:
Adding a function irq_create_mapping_many() which can associate
multiple MSIs to a continous irq mapping.
This is needed to enable multiple MSI support for pSeries.
+int irq_create_mapping_many(struct
于 2013/3/6 11:54, Michael Ellerman 写道:
On Tue, Mar 05, 2013 at 03:19:57PM +0800, Mike Qiu wrote:
于 2013/3/5 10:23, Michael Ellerman 写道:
On Tue, Jan 15, 2013 at 03:38:55PM +0800, Mike Qiu wrote:
Adding a function irq_create_mapping_many() which can associate
multiple MSIs to a continous irq
于 2013/3/6 13:42, Michael Ellerman 写道:
On Wed, Mar 06, 2013 at 01:34:58PM +0800, Mike Qiu wrote:
于 2013/3/6 11:54, Michael Ellerman 写道:
On Tue, Mar 05, 2013 at 03:19:57PM +0800, Mike Qiu wrote:
于 2013/3/5 10:23, Michael Ellerman 写道:
On Tue, Jan 15, 2013 at 03:38:55PM +0800, Mike Qiu wrote
Quoting Tang Yuantian-B29983 (2013-04-15 23:59:34)
> Hi Mike,
>
> I really appreciate if you can spend some times to review this patch.
>
Yauntian,
Thanks for submitting this patch. I have frozen the changes I plan to
submit for 3.10, with the exception of any last-minute fixes.
]#
Thant means I have done nothing with the kernel
Thanks
Mike
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
于 2013/4/24 16:31, Michael Ellerman 写道:
On Wed, Apr 24, 2013 at 04:22:53PM +0800, Mike Qiu wrote:
Hi all
I get an error message when I compile the source code in Power7 platform
use the newest upstream kernel.
Hi Mike,
It depends on what your .config is. What defconfig are you building?
I
于 2013/4/24 16:31, Michael Ellerman 写道:
On Wed, Apr 24, 2013 at 04:22:53PM +0800, Mike Qiu wrote:
Hi all
I get an error message when I compile the source code in Power7 platform
use the newest upstream kernel.
Hi Mike,
It depends on what your .config is. What defconfig are you building
于 2013/4/25 9:05, Chen Gang 写道:
On 2013年04月24日 20:47, Mike wrote:
在 2013-04-24三的 20:37 +1000，Michael Neuling写道：
Mike Qiu wrote:
于 2013/4/24 16:31, Michael Ellerman 写道:
On Wed, Apr 24, 2013 at 04:22:53PM +0800, Mike Qiu wrote:
Hi all
I get an error message when I compile the source code
于 2013/4/25 16:21, Chen Gang 写道:
Hello Mike:
Please try this patch, at least it can pass compiling with the config
file which you provided under my cross-compiling envrionments.
I do not give a running test now, so better to try to run the new kernel
with this patch.
OK, I will use your patch
于 2013/4/25 19:16, Chen Gang 写道:
On 2013年04月25日 14:25, Paul Mackerras wrote:
On Thu, Apr 25, 2013 at 12:05:54PM +0800, Mike Qiu wrote:
This has block my work now
So I hope you can take a look ASAP
Thanks
:)
Mike
As a quick fix, turn on CONFIG_KVM_BOOK3S_64_HV. That will eliminate
the
于 2013/4/26 9:36, Chen Gang 写道:
> On 2013年04月26日 09:18, Chen Gang wrote:
>> On 2013年04月26日 09:06, Chen Gang wrote:
CFAR is the Come From Register. It saves the location of the last
> branch and is hence overwritten by any branch.
>
>>> Do we process it just like others done (e.g. 0x30
于 2013/4/26 10:06, Chen Gang 写道:
On 2013年04月26日 10:03, Mike Qiu wrote:
�� 2013/4/26 9:36, Chen Gang �:
On 2013��04��26�� 09:18, Chen Gang wrote:
On 2013��04��26�� 09:06, Chen Gang wrote:
CFAR is the Come From Register. It saves the location of the last
branch and is hence overwritten by
于 2013/4/25 14:25, Paul Mackerras 写道:
On Thu, Apr 25, 2013 at 12:05:54PM +0800, Mike Qiu wrote:
This has block my work now
So I hope you can take a look ASAP
Thanks
:)
Mike
As a quick fix, turn on CONFIG_KVM_BOOK3S_64_HV. That will eliminate
the immediate problem.
Thanks
got it, I will have
于 2013/4/26 11:42, Chen Gang 写道:
On 2013年04月26日 11:25, Chen Gang wrote:
On 2013年04月26日 11:08, Mike Qiu wrote:
于 2013/4/26 10:06, Chen Gang 写道:
On 2013年04月26日 10:03, Mike Qiu wrote:
�� 2013/4/26 9:36, Chen Gang �:
On 2013��04��26�� 09:18, Chen Gang wrote:
On 2013��04��26�� 09:06, Chen
于 2013/4/27 17:28, Chen Gang F T 写道:
On 2013年04月26日 11:54, Mike Qiu wrote:
于 2013/4/26 11:42, Chen Gang 写道:
On 2013年04月26日 11:25, Chen Gang wrote:
On 2013年04月26日 11:08, Mike Qiu wrote:
于 2013/4/26 10:06, Chen Gang 写道:
On 2013年04月26日 10:03, Mike Qiu wrote:
�� 2013/4/26 9:36, Chen Gang д
0xa00, doorbell_super)
test-by: Mike Qiu
It's workable for me. but I just use this patch to compile and boot up
the machine. not do any performance test:)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinf
Hi Gavin,
Can error injection be done if EEH is not enbaled?
Thanks
Mike
On 05/14/2014 12:11 PM, Gavin Shan wrote:
The series of patches intends to support EEH for PCI devices, which are
passed through to PowerKVM based guest via VFIO. The implementation is
straightforward based on the issues
Hi all,
I face one build error in linux-next git tree, see below:
The platform is IBM P7.
[root@cena01 linux-next]# make -j60
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
CALLscripts/checksyscalls.sh
:1232
bdir of the source tree
Thanks
Mike
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Error 1
make: *** [zImage] Error 2
make: *** Waiting for unfinished jobs
Thanks
Mike
On 06/11/2014 08:22 PM, Michal Marek wrote:
Dne 11.6.2014 14:21, Michal Marek napsal(a):
On Wed, Jun 11, 2014 at 10:24:24AM +0200, Michal Marek wrote:
Dne 11.6.2014 08:02, Mike Qiu napsal(a):
make[1]: Cir
This v2 patch is good,
Tested-by: Mike Qiu
On 06/11/2014 11:40 PM, Michal Marek wrote:
The rule to create the final images uses a zImage.% pattern.
Unfortunately, this also matches the names of the zImage.*.lds linker
scripts, which appear as a dependency of the final images. This somehow
a1ce0 041b89f0 0003 0001
Special Regs:
%IV: 0700 %CR: 48002024%XER: %DSISR: 4000
%SRR0: 041a1c14 %SRR1: 00081002
%LR: 0369aafc%CTR:
%DAR: f821ff913d220035
Virtual PID = 0
ok
0 >
Tha
Anyone has a idea on this issue?
Thanks
Mike
On 06/17/2014 05:45 PM, Mike Qiu wrote:
Hi all,
I use newest linux-next( top commit:
5f295cdf5c5dbbb0c40f10f2ddae02ff46bbf773) to boot up my Power7
machine, PowerVM mode(HypMode 01), use defualt config file in /boot/,
it show error log below
On 06/18/2014 03:54 PM, Michael Ellerman wrote:
On Wed, 2014-06-18 at 11:27 +0800, Mike Qiu wrote:
Anyone has a idea on this issue?
Did it ever work? If so which kernel version?
It works for 3.15, but failed with linux version 3.16.0-rc1-next-20140617
The config file can be simply get from
On 06/19/2014 09:32 AM, Michael Ellerman wrote:
On Wed, 2014-06-18 at 17:02 +0800, Mike Qiu wrote:
On 06/18/2014 03:54 PM, Michael Ellerman wrote:
On Wed, 2014-06-18 at 11:27 +0800, Mike Qiu wrote:
Anyone has a idea on this issue?
Did it ever work? If so which kernel version?
It works for
On 06/19/2014 09:32 AM, Michael Ellerman wrote:
On Wed, 2014-06-18 at 17:02 +0800, Mike Qiu wrote:
On 06/18/2014 03:54 PM, Michael Ellerman wrote:
On Wed, 2014-06-18 at 11:27 +0800, Mike Qiu wrote:
Anyone has a idea on this issue?
Did it ever work? If so which kernel version?
It works for
On 06/19/2014 09:32 AM, Michael Ellerman wrote:
On Wed, 2014-06-18 at 17:02 +0800, Mike Qiu wrote:
On 06/18/2014 03:54 PM, Michael Ellerman wrote:
On Wed, 2014-06-18 at 11:27 +0800, Mike Qiu wrote:
Anyone has a idea on this issue?
Did it ever work? If so which kernel version?
It works for
On 06/19/2014 11:55 AM, Michael Ellerman wrote:
On Thu, 2014-06-19 at 10:18 +0800, Mike Qiu wrote:
On 06/19/2014 09:32 AM, Michael Ellerman wrote:
On Wed, 2014-06-18 at 17:02 +0800, Mike Qiu wrote:
On 06/18/2014 03:54 PM, Michael Ellerman wrote:
On Wed, 2014-06-18 at 11:27 +0800, Mike Qiu
ble to do error injection with "CONFIG_IOMMU_API" ?
That means if use default config(CONFIG_IOMMU_API = n), we can not do
error injection to pci devices?
Thanks
Mike
+ struct iommu_group *iommu_grp;
+ struct iommu_table *tbl;
+ struct pnv_ioda_pe *pe;
+
+ iomm
1 - 100 of 1756 matches
Mail list logo
