Hello Alexander,
The DPAA Ethernet doesn’t work anymore on our FSL P5020/P5040 boards [1] since
the RC1 of kernel 5.8 [2].
We bisected last days [3] and found the problematic commit [4]. I was able to
revert it [5]. After that the DPAA Ethernet works again. I created a patch for
reverting the
On 15 June 2020 at 01:39 am, Christian Zigotzky wrote:
On 14 June 2020 at 04:52 pm, Christian Zigotzky wrote:
On 14 June 2020 at 02:53 pm, Nicholas Piggin wrote:
Excerpts from Christian Zigotzky's message of June 12, 2020 11:01 pm:
On 11 June 2020 at 04:47 pm, Christian Zigotzky wrote:
On 10
On 14 June 2020 at 04:52 pm, Christian Zigotzky wrote:
On 14 June 2020 at 02:53 pm, Nicholas Piggin wrote:
Excerpts from Christian Zigotzky's message of June 12, 2020 11:01 pm:
On 11 June 2020 at 04:47 pm, Christian Zigotzky wrote:
On 10 June 2020 at 01:23 pm, Christian Zigotzky wrote:
On 10
On 14 June 2020 at 02:53 pm, Nicholas Piggin wrote:
Excerpts from Christian Zigotzky's message of June 12, 2020 11:01 pm:
On 11 June 2020 at 04:47 pm, Christian Zigotzky wrote:
On 10 June 2020 at 01:23 pm, Christian Zigotzky wrote:
On 10 June 2020 at 11:06 am, Christian Zigotzky wrote:
On 10
On 11 June 2020 at 04:47 pm, Christian Zigotzky wrote:
On 10 June 2020 at 01:23 pm, Christian Zigotzky wrote:
On 10 June 2020 at 11:06 am, Christian Zigotzky wrote:
On 10 June 2020 at 00:18 am, Christian Zigotzky wrote:
Hello,
KVM-PR doesn't work anymore on my Nemo board [1]. I figured out
On 10 June 2020 at 01:23 pm, Christian Zigotzky wrote:
On 10 June 2020 at 11:06 am, Christian Zigotzky wrote:
On 10 June 2020 at 00:18 am, Christian Zigotzky wrote:
Hello,
KVM-PR doesn't work anymore on my Nemo board [1]. I figured out that
the Git kernels and the kernel 5.7 are affected
On 10 June 2020 at 11:06 am, Christian Zigotzky wrote:
On 10 June 2020 at 00:18 am, Christian Zigotzky wrote:
Hello,
KVM-PR doesn't work anymore on my Nemo board [1]. I figured out that
the Git kernels and the kernel 5.7 are affected.
Error message: Fienix kernel: kvmppc_exit_pr_progint
On 10 June 2020 at 00:18 am, Christian Zigotzky wrote:
Hello,
KVM-PR doesn't work anymore on my Nemo board [1]. I figured out that
the Git kernels and the kernel 5.7 are affected.
Error message: Fienix kernel: kvmppc_exit_pr_progint: emulation at 700
failed ()
I can boot virtual
Hello,
KVM-PR doesn't work anymore on my Nemo board [1]. I figured out that the
Git kernels and the kernel 5.7 are affected.
Error message: Fienix kernel: kvmppc_exit_pr_progint: emulation at 700
failed ()
I can boot virtual QEMU PowerPC machines with KVM-PR with the kernel 5.6
Hi All,
It seems, someone has fixed the boot issue. The latest Git kernel boots
on my PowerPC machines.
Thanks,
Christian
On 05 June 2020 at 6:23 pm, Christian Zigotzky wrote:
On 04 June 2020 at 7:15 pm, Christophe Leroy wrote:
Yes today's linux-next boots on my powerpc 8xx board
On 04 June 2020 at 7:15 pm, Christophe Leroy wrote:
Yes today's linux-next boots on my powerpc 8xx board.
Christophe
Hello Christophe,
Thanks for testing.
I was able to perform a 'git bisect' [1] and identified the bad commit.
[2] I reverted this commit and after that the kernel boots and
Cheers,
Christian
[1] https://en.m.wikipedia.org/wiki/AmigaOne_X1000
[2] https://www.amigaos.net/hardware/133/amigaone-x5000
> On 4. Jun 2020, at 16:29, Christophe Leroy
> wrote:
>
>
>
>> Le 04/06/2020 à 16:26, Christophe Leroy a écrit :
>> Hi,
>>> Le 04
> On 4. Jun 2020, at 16:29, Christophe Leroy
> wrote:
>
> And are you able to perform a 'git bisect' to identify the guilty commit ?
>
> Thanks
> Christophe
Hello Christophe,
Unfortunately I haven’t had time to bisect the latest Git kernel. Does it boot
on your PowerPC machine?
Thanks,
Hi All,
I tested the latest Git kernel today. [1]. Unfortunately it doesn't boot
on my PowerPC machines.
Could you please test the latest Git kernel with your PowerPC machine?
BTW, it doesn't boot in a virtual QEMU PowerPC machine either.
Thanks,
Christian
[1]
OK, thanks.
> On 18. May 2020, at 04:40, Michael Ellerman wrote:
>
> Christian Zigotzky writes:
>> Hi All,
>>
>> This patch wasn't included in the PowerPC fixes 5.7-4. Please add it.
>
> It's not an important bug. I'll take the patch for v5.8
>
>
.early_init_mmu lacks a __init
annotation or the annotation of .hash__early_init_mmu is wrong.
The compiler is uninlining early_init_mmu and not putting it in an init
section because there is no annotation. Add it.
Reported-by: Christian Zigotzky
Tested-by: Christian Zigotzky
Signed-off-by: Nicholas
Hi All,
AGP mode/support is deactivated on PowerPC and it doesn't work reliable
And what does these lines mean:
PowerMac G5 Dual:
OpenGL vendor string: DRI R300 Project
OpenGL renderer string: Mesa DRI R300 (RV350 4152) 20090101 AGP 8x
PowerPC 64/Altivec TCL
OpenGL version string: 1.5
Hi All,
AGP mode/support is deactivated on PowerPC and it doesn't work reliable
And what does these lines mean:
PowerMac G5 Dual:
OpenGL vendor string: DRI R300 Project
OpenGL renderer string: Mesa DRI R300 (RV350 4152) 20090101 AGP 8x
PowerPC 64/Altivec TCL
OpenGL version string: 1.5
> On 30. Apr 2020, at 23:36, Darren Stevens wrote:
>
> Hello Christian
>
>> On 29/04/2020, Christian Zigotzky wrote:
>>
>>
>>>> On 29. Apr 2020, at 17:22, Andrew Lunn wrote:
>>>
>>> ?On Wed, Apr 29, 2020 at 03:55:28PM +0200,
Hi Andrew,
You can find some dtb and source files in our kernel package.
Download: http://www.xenosoft.de/linux-image-5.7-rc3-X1000_X5000.tar.gz
Thanks,
Christian
> On 29. Apr 2020, at 15:13, Andrew Lunn wrote:
>
>
>>
>> Maybe we have to modify the dtb file.
>
> Hi Christian
>
> Could
> On 29. Apr 2020, at 17:22, Andrew Lunn wrote:
>
> On Wed, Apr 29, 2020 at 03:55:28PM +0200, Christian Zigotzky wrote:
>> Hi Andrew,
>>
>> You can find some dtb and source files in our kernel package.
>>
>> Download: http://www.xenosoft.de/linux-
Hi Darren,
Thanks a lot for your patch!
I tested it with the RC3 today.
Unfortunately it doesn't compile because a bracket is missing in the
following line:
+ if (prop && !strncmp(prop, "disabled", 8) {
And a semicolon is missing in the following line:
+ goto _return
I added
On 29 April 2020 at 07:13 am, Nicholas Piggin wrote:
Excerpts from Christian Zigotzky's message of April 29, 2020 2:53 pm:
Hi All,
The issue still exists in the RC3. (kernel config attached)
Please help me to fix this issue.
Huh, looks like maybe early_init_mmu() got uninlined because the
Hello,
The issue still exists after the new PowerPC updates 5.7-2.
Please check the PowerPC updates 5.7-1.
Thanks,
Christian
On 08 April 2020 at 6:32 pm, Christian Zigotzky wrote:
Hello,
Since the PowerPC updates 5.7-1 we have the following issue during the
linking of vmlinux:
MODPOST
Hello,
Since the PowerPC updates 5.7-1 we have the following issue during the
linking of vmlinux:
MODPOST vmlinux.o
WARNING: modpost: vmlinux.o(.text.unlikely+0x1a0): Section mismatch in
reference from the function .early_init_mmu() to the function
.init.text:.radix__early_init_mmu()
The
Hi All,
The DMA mapping works great on our PowerPC machines currently. It was a
long way to get the new DMA mapping code to work successfully on our
PowerPC machines.
P L E A S E don't modify the good working DMA mapping code. There are
many other topics which needs improvements. For us
Hello,
We would like to add poweroff and restart support for the Cyrus+ board
[1] [2] to the mainline vanilla kernel.
There is a patch for adding poweroff and restart support. (attached)
It works but I am not sure if it is good enough for the mainline vanilla
kernel.
Please post some
On 08 February 2020 at 07:59 am, Christian Zigotzky wrote:
On 7. Feb 2020, at 18:08, Arnd Bergmann wrote:
On Fri, Feb 7, 2020 at 3:34 PM Christian Zigotzky
wrote:
Hello Arnd,
We regularly compile and test Linux kernels every day during the merge
window. Since Thursday last week we have
> On 7. Feb 2020, at 18:08, Arnd Bergmann wrote:
>
> On Fri, Feb 7, 2020 at 3:34 PM Christian Zigotzky
> wrote:
>>
>> Hello Arnd,
>>
>> We regularly compile and test Linux kernels every day during the merge
>> window. Since Thursday las
Hello Arnd,
We regularly compile and test Linux kernels every day during the merge
window. Since Thursday last week we have very high CPU usage because of
the avahi daemon on our desktop Linux systems (Ubuntu, Debian etc). The
avahi daemon produces a lot of the following log message. This
On 06 February 2020 at 05:35 am, Michael Ellerman wrote:
Christian Zigotzky writes:
Kernel 5.5 PowerPC is also affected.
I don't know what you mean by that. What sha are you talking about?
I have a system with avahi running and everything's fine.
# grep use- /etc/avahi/avahi-daemon.conf
Kernel 5.5 PowerPC is also affected.
— Christian
Christian Zigotzky wrote:
Hi All,
The issue with the avahi-daemon still exist in the latest Git kernel. It's a
PowerPC issue. I compiled the latest Git kernel on a PC today and there aren't
any issues with the avahi daemon. Another Power Mac
On 03 February 2020 at 6:53 pm, Jakub Kicinski wrote:
On Sun, 2 Feb 2020 16:02:18 +0100, Christian Zigotzky wrote:
On 02 February 2020 at 09:19 am, Christophe Leroy wrote:
Hello,
Le 02/02/2020 à 01:08, Christian Zigotzky a écrit :
Hello,
We regularly compile and test Linux kernels every day
On 02 February 2020 at 09:19 am, Christophe Leroy wrote:
Hello,
Le 02/02/2020 à 01:08, Christian Zigotzky a écrit :
Hello,
We regularly compile and test Linux kernels every day during the
merge window. Since Thuesday we have very high CPU loads because of
the avahi daemon on our desktop
Hello,
We regularly compile and test Linux kernels every day during the merge
window. Since Thuesday we have very high CPU loads because of the avahi
daemon on our desktop Linux systems (Ubuntu, Debian etc).
Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device
Could
On 28 January 2020 at 3:16 pm, Rob Herring wrote:
On Tue, Jan 28, 2020 at 2:01 AM Christian Zigotzky
wrote:
Hi All,
Which mailing list is responsible for the pata_pcmcia driver? We are
using new SanDisk High (>8G) CF cards with this driver [1] and we need
the following line in the f
Hi All,
Which mailing list is responsible for the pata_pcmcia driver? We are
using new SanDisk High (>8G) CF cards with this driver [1] and we need
the following line in the file "drivers/ata/pata_pcmcia.c".
+ PCMCIA_DEVICE_MANF_CARD(0x00f1, 0x0101), /* SanDisk High
(>8G) CFA */
On 24 January 2020 at 12:42 pm, Michael Ellerman wrote:
Ulf Hansson writes:
On Thu, 16 Jan 2020 at 12:18, Christian Zigotzky wrote:
Hi All,
We still need the attached patch for our onboard SD card interface
[1,2]. Could you please add this patch to the tree?
No, because according
Am 16.01.20 um 16:46 schrieb Ulf Hansson:
On Thu, 16 Jan 2020 at 12:18, Christian Zigotzky wrote:
Hi All,
We still need the attached patch for our onboard SD card interface
[1,2]. Could you please add this patch to the tree?
No, because according to previous discussion that isn't the correct
Hi All,
We still need the attached patch for our onboard SD card interface
[1,2]. Could you please add this patch to the tree?
Thanks,
Christian
[1] https://www.spinics.net/lists/linux-mmc/msg56211.html
[2]
http://forum.hyperion-entertainment.com/viewtopic.php?f=58=4349=20#p49012
diff
Hi All,
The SCSI cards work again. [1, 2]
Sorry for bothering you.
Thanks,
Christian
[1]
http://forum.hyperion-entertainment.com/viewtopic.php?f=58=49603=1adf9e6d558c136c1ad4ff15c44212ba#p49599
[2] https://bugzilla.kernel.org/show_bug.cgi?id=205201
Hi All,
The SCSI cards work again. [1, 2]
Sorry for bothering you.
Thanks,
Christian
[1]
http://forum.hyperion-entertainment.com/viewtopic.php?f=58=49603=1adf9e6d558c136c1ad4ff15c44212ba#p49599
[2] https://bugzilla.kernel.org/show_bug.cgi?id=205201
, Christian Zigotzky wrote:
On 28 November 2018 at 12:05PM, Michael Ellerman wrote:
Nothing specific yet.
I'm a bit worried it might break one of the many old obscure platforms
we have that aren't well tested.
Please don't apply the new DMA mapping code if you don't be sure if it
works on all
, Christian Zigotzky wrote:
On 28 November 2018 at 12:05PM, Michael Ellerman wrote:
Nothing specific yet.
I'm a bit worried it might break one of the many old obscure platforms
we have that aren't well tested.
Please don't apply the new DMA mapping code if you don't be sure if it
works on all
ristoph Hellwig wrote:
>>>> On Tue, Nov 26, 2019 at 12:26:38PM +0100, Christian Zigotzky wrote:
>>>> Hello Christoph,
>>>>
>>>> The PCI TV card works with your patch! I was able to patch your Git kernel
>>>> with the patch above
ristoph Hellwig wrote:
>>>> On Tue, Nov 26, 2019 at 12:26:38PM +0100, Christian Zigotzky wrote:
>>>> Hello Christoph,
>>>>
>>>> The PCI TV card works with your patch! I was able to patch your Git kernel
>>>> with the patch above
Hello Rasmus,
I have seen a lot of fsl soc patches from you.
Could you please post what you have modified? Did you test your patches on FSL
SoC machines?
Thanks,
Christian
Sent from my iPhone
> On 28. Nov 2019, at 16:00, linuxppc-dev-requ...@lists.ozlabs.org wrote:
>
> Send Linuxppc-dev
On 27 November 2019 at 07:56 am, Mike Rapoport wrote:
Maybe we'll simply force bottom up allocation before calling
swiotlb_init()? Anyway, it's the last memblock allocation.
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 62f74b1b33bd..771e6cf7e2b9 100644
---
On 27 November 2019 at 07:56 am, Mike Rapoport wrote:
Maybe we'll simply force bottom up allocation before calling
swiotlb_init()? Anyway, it's the last memblock allocation.
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 62f74b1b33bd..771e6cf7e2b9 100644
---
On 25 November 2019 at 10:32 am, Mike Rapoport wrote:
On Mon, Nov 25, 2019 at 08:39:23AM +0100, Christoph Hellwig wrote:
On Sat, Nov 23, 2019 at 12:42:27PM +0100, Christian Zigotzky wrote:
Hello Christoph,
Please find attached the dmesg of your Git kernel.
Thanks. It looks like on your
On 25 November 2019 at 08:39 am, Christoph Hellwig wrote:
On Sat, Nov 23, 2019 at 12:42:27PM +0100, Christian Zigotzky wrote:
Hello Christoph,
Please find attached the dmesg of your Git kernel.
Thanks. It looks like on your platform the swiotlb buffer isn't
actually addressable based
On 25 November 2019 at 08:39 am, Christoph Hellwig wrote:
On Sat, Nov 23, 2019 at 12:42:27PM +0100, Christian Zigotzky wrote:
Hello Christoph,
Please find attached the dmesg of your Git kernel.
Thanks. It looks like on your platform the swiotlb buffer isn't
actually addressable based
On 25 November 2019 at 10:32 am, Mike Rapoport wrote:
On Mon, Nov 25, 2019 at 08:39:23AM +0100, Christoph Hellwig wrote:
On Sat, Nov 23, 2019 at 12:42:27PM +0100, Christian Zigotzky wrote:
Hello Christoph,
Please find attached the dmesg of your Git kernel.
Thanks. It looks like on your
On 25 November 2019 at 10:32 am, Mike Rapoport wrote:
On Mon, Nov 25, 2019 at 08:39:23AM +0100, Christoph Hellwig wrote:
On Sat, Nov 23, 2019 at 12:42:27PM +0100, Christian Zigotzky wrote:
Hello Christoph,
Please find attached the dmesg of your Git kernel.
Thanks. It looks like on your
On 25 November 2019 at 08:39 am, Christoph Hellwig wrote:
On Sat, Nov 23, 2019 at 12:42:27PM +0100, Christian Zigotzky wrote:
Hello Christoph,
Please find attached the dmesg of your Git kernel.
Thanks. It looks like on your platform the swiotlb buffer isn't
actually addressable based
On 25 November 2019 at 08:39 am, Christoph Hellwig wrote:
On Sat, Nov 23, 2019 at 12:42:27PM +0100, Christian Zigotzky wrote:
Hello Christoph,
Please find attached the dmesg of your Git kernel.
Thanks. It looks like on your platform the swiotlb buffer isn't
actually addressable based
On 21 November 2019 at 07:02 pm, Christoph Hellwig wrote:
On Thu, Nov 21, 2019 at 05:34:48PM +0100, Christian Zigotzky wrote:
I modified the patch and compiled a new RC8 of kernel 5.4 today. (patch
attached)
We have to wait to Rolands test results with his SCSI PCI card. I tested it
today
On 21 November 2019 at 07:02 pm, Christoph Hellwig wrote:
On Thu, Nov 21, 2019 at 05:34:48PM +0100, Christian Zigotzky wrote:
I modified the patch and compiled a new RC8 of kernel 5.4 today. (patch
attached)
We have to wait to Rolands test results with his SCSI PCI card. I tested it
today
On 21. Nov 2019, at 19:02, Christoph Hellwig wrote:
On Thu, Nov 21, 2019 at 05:34:48PM +0100, Christian Zigotzky wrote:
I modified the patch and compiled a new RC8 of kernel 5.4 today. (patch
attached)
We have to wait to Rolands test results with his SCSI PCI card. I tested it
today but my TV
On 21. Nov 2019, at 19:02, Christoph Hellwig wrote:
On Thu, Nov 21, 2019 at 05:34:48PM +0100, Christian Zigotzky wrote:
I modified the patch and compiled a new RC8 of kernel 5.4 today. (patch
attached)
We have to wait to Rolands test results with his SCSI PCI card. I tested it
today but my TV
Am 21.11.19 um 14:33 schrieb Robin Murphy:
On 21/11/2019 12:21 pm, Christian Zigotzky wrote:
On 21 November 2019 at 01:16 pm, Christian Zigotzky wrote:
On 21 November 2019 at 08:29 am, Christoph Hellwig wrote:
On Sat, Nov 16, 2019 at 08:06:05AM +0100, Christian Zigotzky wrote:
/*
* DMA
Am 21.11.19 um 14:33 schrieb Robin Murphy:
On 21/11/2019 12:21 pm, Christian Zigotzky wrote:
On 21 November 2019 at 01:16 pm, Christian Zigotzky wrote:
On 21 November 2019 at 08:29 am, Christoph Hellwig wrote:
On Sat, Nov 16, 2019 at 08:06:05AM +0100, Christian Zigotzky wrote:
/*
* DMA
On 21 November 2019 at 01:16 pm, Christian Zigotzky wrote:
On 21 November 2019 at 08:29 am, Christoph Hellwig wrote:
On Sat, Nov 16, 2019 at 08:06:05AM +0100, Christian Zigotzky wrote:
/*
* DMA addressing mode.
*
* 0 : 32 bit addressing for all chips.
* 1 : 40 bit addressing when
On 21 November 2019 at 01:16 pm, Christian Zigotzky wrote:
On 21 November 2019 at 08:29 am, Christoph Hellwig wrote:
On Sat, Nov 16, 2019 at 08:06:05AM +0100, Christian Zigotzky wrote:
/*
* DMA addressing mode.
*
* 0 : 32 bit addressing for all chips.
* 1 : 40 bit addressing when
On 21 November 2019 at 08:29 am, Christoph Hellwig wrote:
On Sat, Nov 16, 2019 at 08:06:05AM +0100, Christian Zigotzky wrote:
/*
* DMA addressing mode.
*
* 0 : 32 bit addressing for all chips.
* 1 : 40 bit addressing when supported by chip.
* 2 : 64 bit addressing when supported
On 21 November 2019 at 08:29 am, Christoph Hellwig wrote:
On Sat, Nov 16, 2019 at 08:06:05AM +0100, Christian Zigotzky wrote:
/*
* DMA addressing mode.
*
* 0 : 32 bit addressing for all chips.
* 1 : 40 bit addressing when supported by chip.
* 2 : 64 bit addressing when supported
FYI: Source files of the Dawicontrol DC 2976 UW SCSI board (PCI):
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/sym53c8xx_2?h=v5.4-rc7
/*
* DMA addressing mode.
*
* 0 : 32 bit addressing for all chips.
* 1 : 40 bit addressing when supported by chip.
ot;. After compiling the RC7 of
kernel 5.4 my TV card works again.
Cheers,
Christian
On 12 November 2019 at 3:41 pm, Christoph Hellwig wrote:
On Mon, Nov 11, 2019 at 01:22:55PM +0100, Christian Zigotzky wrote:
Now, I can definitely say that this patch does not solve the issue.
Do you have ano
ot;. After compiling the RC7 of
kernel 5.4 my TV card works again.
Cheers,
Christian
On 12 November 2019 at 3:41 pm, Christoph Hellwig wrote:
On Mon, Nov 11, 2019 at 01:22:55PM +0100, Christian Zigotzky wrote:
Now, I can definitely say that this patch does not solve the issue.
Do you have ano
On 12 November 2019 at 3:41 pm, Christoph Hellwig wrote:
On Mon, Nov 11, 2019 at 01:22:55PM +0100, Christian Zigotzky wrote:
Now, I can definitely say that this patch does not solve the issue.
Do you have another patch for testing or shall I bisect?
I'm still interested in the .config
On 12 November 2019 at 3:41 pm, Christoph Hellwig wrote:
On Mon, Nov 11, 2019 at 01:22:55PM +0100, Christian Zigotzky wrote:
Now, I can definitely say that this patch does not solve the issue.
Do you have another patch for testing or shall I bisect?
I'm still interested in the .config
On 11 November 2019 at 09:16 am, Christian Zigotzky wrote:
On 11 November 2019 at 09:12 am, Christian Zigotzky wrote:
On 10 November 2019 at 08:27 am, Christian Zigotzky wrote:
On 07 November 2019 at 10:53 am, Christian Zigotzky wrote:
On 05 November 2019 at 05:28 pm, Christoph Hellwig wrote
On 11 November 2019 at 09:16 am, Christian Zigotzky wrote:
On 11 November 2019 at 09:12 am, Christian Zigotzky wrote:
On 10 November 2019 at 08:27 am, Christian Zigotzky wrote:
On 07 November 2019 at 10:53 am, Christian Zigotzky wrote:
On 05 November 2019 at 05:28 pm, Christoph Hellwig wrote
On 11 November 2019 at 09:12 am, Christian Zigotzky wrote:
On 10 November 2019 at 08:27 am, Christian Zigotzky wrote:
On 07 November 2019 at 10:53 am, Christian Zigotzky wrote:
On 05 November 2019 at 05:28 pm, Christoph Hellwig wrote:
On Tue, Nov 05, 2019 at 08:56:27AM +0100, Christian
On 11 November 2019 at 09:12 am, Christian Zigotzky wrote:
On 10 November 2019 at 08:27 am, Christian Zigotzky wrote:
On 07 November 2019 at 10:53 am, Christian Zigotzky wrote:
On 05 November 2019 at 05:28 pm, Christoph Hellwig wrote:
On Tue, Nov 05, 2019 at 08:56:27AM +0100, Christian
On 10 November 2019 at 08:27 am, Christian Zigotzky wrote:
On 07 November 2019 at 10:53 am, Christian Zigotzky wrote:
On 05 November 2019 at 05:28 pm, Christoph Hellwig wrote:
On Tue, Nov 05, 2019 at 08:56:27AM +0100, Christian Zigotzky wrote:
Hi All,
We still have DMA problems with some PCI
On 10 November 2019 at 08:27 am, Christian Zigotzky wrote:
On 07 November 2019 at 10:53 am, Christian Zigotzky wrote:
On 05 November 2019 at 05:28 pm, Christoph Hellwig wrote:
On Tue, Nov 05, 2019 at 08:56:27AM +0100, Christian Zigotzky wrote:
Hi All,
We still have DMA problems with some PCI
On 07 November 2019 at 10:53 am, Christian Zigotzky wrote:
On 05 November 2019 at 5:28 pm, Christoph Hellwig wrote:
On Tue, Nov 05, 2019 at 08:56:27AM +0100, Christian Zigotzky wrote:
Hi All,
We still have DMA problems with some PCI devices. Since the PowerPC
updates
4.21-1 [1] we need
On 07 November 2019 at 10:53 am, Christian Zigotzky wrote:
On 05 November 2019 at 5:28 pm, Christoph Hellwig wrote:
On Tue, Nov 05, 2019 at 08:56:27AM +0100, Christian Zigotzky wrote:
Hi All,
We still have DMA problems with some PCI devices. Since the PowerPC
updates
4.21-1 [1] we need
On 05 November 2019 at 5:28 pm, Christoph Hellwig wrote:
On Tue, Nov 05, 2019 at 08:56:27AM +0100, Christian Zigotzky wrote:
Hi All,
We still have DMA problems with some PCI devices. Since the PowerPC updates
4.21-1 [1] we need to decrease the RAM to 3500MB (mem=3500M) if we want to
work
On 05 November 2019 at 5:28 pm, Christoph Hellwig wrote:
On Tue, Nov 05, 2019 at 08:56:27AM +0100, Christian Zigotzky wrote:
Hi All,
We still have DMA problems with some PCI devices. Since the PowerPC updates
4.21-1 [1] we need to decrease the RAM to 3500MB (mem=3500M) if we want to
work
Hi All,
We still have DMA problems with some PCI devices. Since the PowerPC
updates 4.21-1 [1] we need to decrease the RAM to 3500MB (mem=3500M) if
we want to work with our PCI devices. The FSL P5020 and P5040 have these
problems currently.
Error message:
[ 25.654852] bttv 1000:04:05.0:
Hi All,
We still have DMA problems with some PCI devices. Since the PowerPC
updates 4.21-1 [1] we need to decrease the RAM to 3500MB (mem=3500M) if
we want to work with our PCI devices. The FSL P5020 and P5040 have these
problems currently.
Error message:
[ 25.654852] bttv 1000:04:05.0:
FYI: The onboard SD card works also with the RC6 of kernel 5.4 with the
patch below.
-- Christian
On 23 October 2019 at 4:20pm, Christian Zigotzky wrote:
Hello,
The patch below works. I compiled the RC4 of kernel 5.4 with this patch today
and the onboard SD card works without any problems
> On 29. Oct 2019, at 05:49, Christian Zigotzky wrote:
>
> Hello,
>
> The bug with some PCI devices if you have more than 3.5G installed still
> exist in the RC5. Could you please look in the following bug report.
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=205201
>
> Thanks,
> Christian
Hello,
The bug with some PCI devices if you have more than 3.5G installed still exist
in the RC5. Could you please look in the following bug report.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=205201
Thanks,
Christian
2019 at 03:12:49PM +0200, Christian Zigotzky wrote:
>>> Hello Russell,
>>>
>>> You asked me about "dma-coherent" in the Cyrus device tree. Unfortunately I
>>> don't find the property "dma-coherent" in the dtb source files.
>>>
>
Hello,
I compiled a Git kernel with the latest DRM updates
(drm-next-2019-09-18) [1] today. Unfortunately it doesn't boot with my
Radeon Northern Islands graphics cards anymore.
I tested it with a Radeon HD6870 and with a Radeon HD4870.
The kernel boots with a Radeon SI graphics card. (R7
compiled without any errors.
Afterwards I successfully tested the new Git kernel with some cpufreq
governors on openSUSE Tumbleweed 20190521 PowerPC64 [4] and on ubuntu
MATE 16.04.6 LTS PowerPC32.
Thanks a lot for your work!
Tested-by: Christian Zigotzky
Cheers,
Christian
[1] https
Is a final patch available for testing? Please do not release it without
testing.
- Christian
On 09-07-19, 16:04, Wen Yang wrote:
> The cpu variable is still being used in the of_get_property() call
> after the of_node_put() call, which may result in use-after-free.
>
> Fixes: a9acc26b75f
Hello Wen,
Thanks for your patch!
Did you test your patch with a P.A. Semi board?
Cheers,
Christian
On 22 June 2019 at 11:51am, Michael Cree wrote:
See https://salsa.debian.org/multimedia-team/x265/commits/master
for the top two commits but one, one to disable altivec (which I am
not sure is necessary on ppc64,
It's necessary because we use a PPC64 CPU without AltiVec (e5500).
-- Christian
Hello Christophe,
Could you please add this patch to the GIT kernel because the issue still
exists.
Thanks,
Christian
On 15. May 2019, at 12:15, Christophe Leroy wrote:
Hi,
Le 15/05/2019 à 12:09, Christian Zigotzky a écrit :
Hi All,
I got the following error messages with the latest Git
On 14 May 2019 at 07:25AM, John Paul Adrian Glaubitz wrote:
Hello!
With the upcoming version 9 of gcc, support for the powerpcspe target has
been removed from the compiler. Since it makes no sense to keep the buildds
running in the long time given that perspective, I would to remove the
Hi All,
Shall I activate FLATMEM or SPARSEMEM for the Nemo board with the PA6T-1682M
SoC?
Thanks,
Christian
On 04 April 2019 at 1:23PM, Christian Zigotzky wrote:
On 04 April 2019 at 11:07AM, Christophe Leroy wrote:
On 04/04/2019 08:44 AM, Christian Zigotzky wrote:
On 04 April 2019 at 06:00AM, Christophe Leroy wrote:
Le 04/04/2019 à 02:58, Christian Zigotzky a écrit :
On 03 April 2019 at 07
On 04 April 2019 at 11:07AM, Christophe Leroy wrote:
On 04/04/2019 08:44 AM, Christian Zigotzky wrote:
On 04 April 2019 at 06:00AM, Christophe Leroy wrote:
Le 04/04/2019 à 02:58, Christian Zigotzky a écrit :
On 03 April 2019 at 07:05AM, Christophe Leroy wrote:
Le 03/04/2019 à 05:52
On 04 April 2019 at 06:00AM, Christophe Leroy wrote:
Le 04/04/2019 à 02:58, Christian Zigotzky a écrit :
On 03 April 2019 at 07:05AM, Christophe Leroy wrote:
Le 03/04/2019 à 05:52, Christian Zigotzky a écrit :
Please test VLC with the RC3 of kernel 5.1.
The removing of the PowerPC fixes
On 03 April 2019 at 07:05AM, Christophe Leroy wrote:
Le 03/04/2019 à 05:52, Christian Zigotzky a écrit :
Please test VLC with the RC3 of kernel 5.1.
The removing of the PowerPC fixes 5.1-3 has solved the VLC issue.
Another user has already confirmed that [1]. This isn’t an April
Fool‘s
Please test VLC with the RC3 of kernel 5.1.
The removing of the PowerPC fixes 5.1-3 has solved the VLC issue. Another user
has already confirmed that [1]. This isn’t an April Fool‘s. ;-)
Thanks
[1]
http://forum.hyperion-entertainment.com/viewtopic.php?f=58=4256=20#p47561
201 - 300 of 1071 matches
Mail list logo
