Re: [Virtual ppce500] virtio_gpu virtio0: swiotlb buffer is full

2020-08-19 Thread Christian Zigotzky
On 19 August 2020 at 06:35 am, Gerd Hoffmann wrote: On Tue, Aug 18, 2020 at 04:41:38PM +0200, Christian Zigotzky wrote: Hello Gerd, I compiled a new kernel with the latest DRM misc updates today. The patch is included in these updates. This kernel works with the VirtIO-GPU in a virtual e5500

Re: [Virtual ppce500] virtio_gpu virtio0: swiotlb buffer is full

2020-08-18 Thread Christian Zigotzky
On 18 August 2020 at 10:18 am, Gerd Hoffmann wrote: On Mon, Aug 17, 2020 at 11:19:58AM +0200, Christian Zigotzky wrote: Hello I compiled the RC1 of kernel 5.9 today. Unfortunately the issue with the VirtIO-GPU (see below) still exists. Therefore we still need the patch (see below) for using

Re: [Virtual ppce500] virtio_gpu virtio0: swiotlb buffer is full

2020-08-18 Thread Christian Zigotzky
On 18 August 2020 at 10:18 am, Gerd Hoffmann wrote: On Mon, Aug 17, 2020 at 11:19:58AM +0200, Christian Zigotzky wrote: Hello I compiled the RC1 of kernel 5.9 today. Unfortunately the issue with the VirtIO-GPU (see below) still exists. Therefore we still need the patch (see below) for using

Re: [Virtual ppce500] virtio_gpu virtio0: swiotlb buffer is full

2020-08-17 Thread Christian Zigotzky
On 12 August 2020 at 3:09 pm, Christian Zigotzky wrote: Hello Daniel, The VirtIO-GPU doesn't work anymore with the latest Git kernel in a virtual e5500 PPC64 QEMU machine [1,2] after the commit "drm/virtio: Call the right shmem helpers". [3] The kernel 5.8 works with the

[Virtual ppce500] virtio_gpu virtio0: swiotlb buffer is full

2020-08-12 Thread Christian Zigotzky
Hello Daniel, The VirtIO-GPU doesn't work anymore with the latest Git kernel in a virtual e5500 PPC64 QEMU machine [1,2] after the commit "drm/virtio: Call the right shmem helpers". [3] The kernel 5.8 works with the VirtIO-GPU in this virtual machine. I bisected today [4]. Result:

[Virtual ppce500] virtio_gpu virtio0: swiotlb buffer is full

2020-08-10 Thread Christian Zigotzky
Hello, Just for info. The latest git kernel doesn't work with a virtio_gpu anymore. QEMU command: qemu-system-ppc64 -M ppce500 -cpu e5500 -enable-kvm -m 1024 -kernel uImage -drive format=raw,file=fienix-soar_3.0-2020608-net.img,index=0,if=virtio -nic user,model=e1000 -append "rw

Re: [PASEMI] Nemo board doesn't boot anymore after the commit "powerpc/book3s64/pkeys: Simplify pkey disable branch"

2020-08-10 Thread Christian Zigotzky
Am 10.08.20 um 10:58 schrieb Aneesh Kumar K.V: On 8/10/20 2:15 PM, Christian Zigotzky wrote: Hello Aneesh, I tested the new kernel today and unfortunately it doesn't run very well. I have only one core (1 physical processor; 1 core; 2 threads) instead of two cores (1 physical processor; 2

Re: [PASEMI] Nemo board doesn't boot anymore after the commit "powerpc/book3s64/pkeys: Simplify pkey disable branch"

2020-08-10 Thread Christian Zigotzky
/dmesg_nemo_board_kernel_5.9.txt Could you please check the updates? Thanks, Christian On 10 August 2020 at 09:56 am, Christian Zigotzky wrote: Hello Aneesh, The Nemo board boots with your patch but unfortunately I don't see any boot messages anymore. Please find attached the kernel config. Thanks, Christian

[PASEMI] Nemo board doesn't boot anymore after the commit "powerpc/book3s64/pkeys: Simplify pkey disable branch"

2020-08-09 Thread Christian Zigotzky
Hello, The Nemo board (A-EON AmigaOne X1000) [1] doesn't start with the latest Git kernel anymore after the commit "powerpc/book3s64/pkeys: Simplify pkey disable branch" [2]. I bisected today [3]. Result: powerpc/book3s64/pkeys: Simplify pkey disable branch

Re: [Latest Git kernel/Linux-next kernel] Xorg doesn't start after the seccomp updates v5.9-rc1

2020-08-07 Thread Christian Zigotzky
updates are responsible for the second issue. Because of this second issue I can’t test your patch. Please test the latest Git kernel. Thanks, Christian > On 7. Aug 2020, at 19:45, Kees Cook wrote: > > On Fri, Aug 07, 2020 at 04:45:14PM +0200, Christian Zigotzky wrote: >>

[Latest Git kernel/Linux-next kernel] Xorg doesn't start after the seccomp updates v5.9-rc1

2020-08-07 Thread Christian Zigotzky
Hello, Xorg doesn't start with the latest Git kernel anymore on some Linux distributions after the seccomp updates v5.9-rc1 [1]. For example on Fienix (Debian Sid PowerPC 32-bit) and on ubuntu MATE 16.04.6 (PowerPC 32-bit). I tested these distributions on the A-EON AmigaOne X1000 [2], A-EON

Re: FSL P5020/P5040: DPAA Ethernet issue with the latest Git kernel

2020-07-08 Thread Christian Zigotzky
On 08 July 2020 at 08:03 am, Madalin Bucur (OSS) wrote: From: Christian Zigotzky Sent: Tuesday, July 7, 2020 9:26 PM To: Madalin Bucur (OSS) Cc: mad skateman ; Camelia Alexandra Groza ; linuxppc-...@ozlabs.org; net...@vger.kernel.org; R.T.Dickinson ; Darren Stevens Subject: Re: FSL P5020

Re: FSL P5020/P5040: DPAA Ethernet issue with the latest Git kernel

2020-07-07 Thread Christian Zigotzky
> On 7. Jul 2020, at 17:53, Madalin Bucur (OSS) > wrote: > > Was DPAA functional before commit A? > How about after commit A and before commit B? The DPAA Ethernet works from the kernel 5.6-rc4 [1] till the Git kernel from the 11 of June [2]. It doesn’t work since the commit “fix

Re: FSL P5020/P5040: DPAA Ethernet issue with the latest Git kernel

2020-07-07 Thread Christian Zigotzky
On 25 June 2020 at 12:22 pm, Alexander Gordeev wrote: On Thu, Jun 25, 2020 at 01:01:52AM +0200, Christian Zigotzky wrote: [...] I compiled a test kernel with the option "CONFIG_TEST_BITMAP=y" yesterday. After that Skateman and I booted it and looked for the bitmap tests with "

Re: PowerPC KVM-PR issue

2020-06-25 Thread Christian Zigotzky
On 15 June 2020 at 01:39 pm, 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

FSL P5020/P5040: DPAA Ethernet issue with the latest Git kernel

2020-06-21 Thread Christian Zigotzky
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

Re: PowerPC KVM-PR issue

2020-06-15 Thread Christian Zigotzky
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

Re: PowerPC KVM-PR issue

2020-06-14 Thread Christian Zigotzky
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

Re: PowerPC KVM-PR issue

2020-06-14 Thread Christian Zigotzky
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

Re: PowerPC KVM-PR issue

2020-06-12 Thread Christian Zigotzky
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

Re: PowerPC KVM-PR issue

2020-06-11 Thread Christian Zigotzky
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

Re: PowerPC KVM-PR issue

2020-06-10 Thread Christian Zigotzky
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

Re: PowerPC KVM-PR issue

2020-06-10 Thread Christian Zigotzky
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

PowerPC KVM-PR issue

2020-06-09 Thread Christian Zigotzky
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

Re: Boot issue with the latest Git kernel

2020-06-07 Thread Christian Zigotzky
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

Re: Boot issue with the latest Git kernel

2020-06-05 Thread Christian Zigotzky
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

Re: Boot issue with the latest Git kernel

2020-06-04 Thread Christian Zigotzky
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

Re: Boot issue with the latest Git kernel

2020-06-04 Thread Christian Zigotzky
> 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,

Boot issue with the latest Git kernel

2020-06-04 Thread Christian Zigotzky
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]

Re: [PATCH] powerpc/64s: Fix early_init_mmu section mismatch

2020-05-18 Thread Christian Zigotzky
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 > >

Re: [PATCH] powerpc/64s: Fix early_init_mmu section mismatch

2020-05-17 Thread Christian Zigotzky
.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

Re: Don't initialise ports with no PHY

2020-04-30 Thread Christian Zigotzky
> 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,

Re: [RFC PATCH dpss_eth] Don't initialise ports with no PHY

2020-04-29 Thread Christian Zigotzky
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

Re: [RFC PATCH dpss_eth] Don't initialise ports with no PHY

2020-04-29 Thread Christian Zigotzky
> 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-

Re: [RFC PATCH dpss_eth] Don't initialise ports with no PHY

2020-04-29 Thread Christian Zigotzky
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

Re: Section mismatch in reference from the function .early_init_mmu() to the function .init.text:.radix__early_init_mmu() after PowerPC updates 5.7-1

2020-04-29 Thread Christian Zigotzky
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

Section mismatch in reference from the function .early_init_mmu() to the function .init.text:.radix__early_init_mmu() after PowerPC updates 5.7-1

2020-04-10 Thread Christian Zigotzky
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

Section mismatch in reference from the function .early_init_mmu() to the function .init.text:.radix__early_init_mmu() after PowerPC updates 5.7-1

2020-04-08 Thread Christian Zigotzky
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

Re: [PATCH 1/2] dma-mapping: add a dma_ops_bypass flag to, struct device

2020-03-24 Thread Christian Zigotzky
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

FSL P5020/Cyrus+ Board: Poweroff and Restart Support

2020-03-21 Thread Christian Zigotzky
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

Re: Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device

2020-02-08 Thread Christian Zigotzky
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

Re: Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device

2020-02-07 Thread Christian Zigotzky
> 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

Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device

2020-02-07 Thread Christian Zigotzky
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

Re: Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device

2020-02-06 Thread Christian Zigotzky
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

Re: Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device

2020-02-05 Thread Christian Zigotzky
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

Re: Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device

2020-02-05 Thread Christian Zigotzky
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

Re: Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device

2020-02-02 Thread Christian Zigotzky
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

Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device

2020-02-01 Thread Christian Zigotzky
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

Re: [PASEMI PA6T PPC] Onboard CF card device with new SanDisk High (>8G) CF cards

2020-01-28 Thread Christian Zigotzky
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

[PASEMI PA6T PPC] Onboard CF card device with new SanDisk High (>8G) CF cards

2020-01-28 Thread Christian Zigotzky
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 */

Re: [FSL P5020 P5040 PPC] Onboard SD card doesn't work anymore after the 'mmc-v5.4-2' updates

2020-01-25 Thread Christian Zigotzky
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

[FSL P5020 P5040 PPC] Onboard SD card doesn't work anymore after the 'mmc-v5.4-2' updates

2020-01-20 Thread Christian Zigotzky
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

[FSL P5020 P5040 PPC] Onboard SD card doesn't work anymore after the 'mmc-v5.4-2' updates

2020-01-16 Thread Christian Zigotzky
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

Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M

2020-01-09 Thread Christian Zigotzky
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

Re: use generic DMA mapping code in powerpc V4

2019-12-19 Thread Christian Zigotzky
, 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

Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M

2019-12-04 Thread Christian Zigotzky
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

soc: fsl patches

2019-11-28 Thread Christian Zigotzky
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

Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M

2019-11-27 Thread Christian Zigotzky
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 ---

Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M

2019-11-26 Thread Christian Zigotzky
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

Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M

2019-11-26 Thread Christian Zigotzky
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

Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M

2019-11-25 Thread Christian Zigotzky
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

Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M

2019-11-25 Thread Christian Zigotzky
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

Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M

2019-11-23 Thread Christian Zigotzky
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

Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M

2019-11-21 Thread Christian Zigotzky
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

Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M

2019-11-21 Thread Christian Zigotzky
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

Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M

2019-11-21 Thread Christian Zigotzky
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

Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M

2019-11-21 Thread Christian Zigotzky
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

Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M

2019-11-15 Thread Christian Zigotzky
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.

Re: Bug 205201 - overflow of DMA mask and bus mask

2019-11-13 Thread Christian Zigotzky
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

Re: Bug 205201 - overflow of DMA mask and bus mask

2019-11-12 Thread Christian Zigotzky
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

Re: Bug 205201 - overflow of DMA mask and bus mask

2019-11-11 Thread Christian Zigotzky
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

Re: Bug 205201 - overflow of DMA mask and bus mask

2019-11-11 Thread Christian Zigotzky
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

Re: Bug 205201 - overflow of DMA mask and bus mask

2019-11-11 Thread Christian Zigotzky
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

Re: Bug 205201 - overflow of DMA mask and bus mask

2019-11-09 Thread Christian Zigotzky
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

Re: Bug 205201 - overflow of DMA mask and bus mask

2019-11-07 Thread Christian Zigotzky
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

Bug 205201 - overflow of DMA mask and bus mask

2019-11-04 Thread Christian Zigotzky
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:

Re: Onboard SD card doesn't work anymore after the 'mmc-v5.4-2' updates

2019-11-04 Thread Christian Zigotzky
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

Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M

2019-10-29 Thread Christian Zigotzky
> 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

Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M

2019-10-28 Thread Christian Zigotzky
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

Re: Onboard SD card doesn't work anymore after the 'mmc-v5.4-2' updates

2019-10-23 Thread Christian Zigotzky
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. >>> >

[PATCH v7] cpufreq/pasemi: fix an use-after-free inpas_cpufreq_cpu_init()

2019-07-18 Thread Christian Zigotzky
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

[PATCH v3] cpufreq/pasemi: fix an use-after-free inpas_cpufreq_cpu_init()

2019-07-10 Thread Christian Zigotzky
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

[PATCH v3] cpufreq/pasemi: fix an use-after-free in pas_cpufreq_cpu_init()

2019-07-08 Thread Christian Zigotzky
Hello Wen, Thanks for your patch! Did you test your patch with a P.A. Semi board? Cheers, Christian

Re: Latest Git kernel: Section mismatch in reference from the variable start_here_multiplatform to the function .init.text:.early_setup()

2019-06-10 Thread Christian Zigotzky
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

[PATCH] powerpc/mm: Define MAX_PHYSMEM_BITS for all 64-bit configs

2019-04-09 Thread Christian Zigotzky
Hi All, Shall I activate FLATMEM or SPARSEMEM for the Nemo board with the PA6T-1682M SoC? Thanks, Christian

VLC doesn't play videos anymore since the PowerPC fixes 5.1-3

2019-04-04 Thread Christian Zigotzky
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

VLC doesn't play videos anymore since the PowerPC fixes 5.1-3

2019-04-04 Thread Christian Zigotzky
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

VLC doesn't play videos anymore since the PowerPC fixes 5.1-3

2019-04-04 Thread Christian Zigotzky
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

VLC doesn't play videos anymore since the PowerPC fixes 5.1-3

2019-04-03 Thread Christian Zigotzky
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

VLC doesn't play videos anymore since the PowerPC fixes 5.1-3

2019-04-02 Thread Christian Zigotzky
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

VLC doesn't play videos anymore since the PowerPC fixes 5.1-3

2019-04-02 Thread Christian Zigotzky
Hi All, I figured out, that the VLC player doesn't play videos anymore since the PowerPC fixes 5.1-3 [1]. VLC plays videos with the RC1 of kernel 5.1 without any problems. VLC error messages: [100ea580] ts demux warning: first packet for pid=1104 cc=0xe [100ea580] ts demux warning: first

PowerPC fixes 5.1-3: CONFIG_SPARSEMEM doesn't exist in the kernel source code

2019-03-25 Thread Christian Zigotzky
I was able to activate CONFIG_SPARSEMEM in the kernel configuration. But does the P.A. Semi Nemo board need this option? -- Christian On 25 March 2019 at 12:00PM, Christian Zigotzky wrote: Hi All, I wasn't able to compile the RC2 today because of the following error messages:   CC

PowerPC fixes 5.1-3: CONFIG_SPARSEMEM doesn't exist in the kernel source code

2019-03-25 Thread Christian Zigotzky
Hi All, I wasn't able to compile the RC2 today because of the following error messages:   CC  arch/powerpc/mm/slb.o In file included from ./arch/powerpc/include/asm/book3s/64/mmu.h:39:0, from ./arch/powerpc/include/asm/mmu.h:360, from

Re: use generic DMA mapping code in powerpc V4

2019-02-12 Thread Christian Zigotzky
On 12 February 2019 at 8:31PM, Christian Zigotzky wrote: On 12 February 2019 at 4:25PM, Christoph Hellwig wrote: On Tue, Feb 12, 2019 at 01:42:56PM +0100, Christian Zigotzky wrote: On 11 February 2019 at 08:38AM, Christoph Hellwig wrote: On Sun, Feb 10, 2019 at 01:00:20PM +0100, Christian

Re: use generic DMA mapping code in powerpc V4

2019-02-12 Thread Christian Zigotzky
On 12 February 2019 at 4:25PM, Christoph Hellwig wrote: On Tue, Feb 12, 2019 at 01:42:56PM +0100, Christian Zigotzky wrote: On 11 February 2019 at 08:38AM, Christoph Hellwig wrote: On Sun, Feb 10, 2019 at 01:00:20PM +0100, Christian Zigotzky wrote: I tested the whole series today. The kernels

Re: use generic DMA mapping code in powerpc V4

2019-02-12 Thread Christian Zigotzky
On 11 February 2019 at 08:38AM, Christoph Hellwig wrote: On Sun, Feb 10, 2019 at 01:00:20PM +0100, Christian Zigotzky wrote: I tested the whole series today. The kernels boot and the P.A. Semi Ethernet works! :-) Thanks a lot! I also tested it in a virtual e5500 QEMU machine today

Re: use generic DMA mapping code in powerpc V4

2019-02-10 Thread Christian Zigotzky
Hi Christoph, Mario successfully tested a kernel from your Git [1] on his T2080rdb today. Link to the log: https://gitlab.com/oshw-powerpc-notebook/T2080customizations/blob/master/kernel/dma_fix/kernel_dma_fix_log.txt He wrote: Please, note that all of the above kernel runs just fine with the

Re: use generic DMA mapping code in powerpc V4

2019-02-10 Thread Christian Zigotzky
Hi Christoph, On 08 February 2019 at 10:18AM, Christoph Hellwig wrote: On Fri, Feb 08, 2019 at 10:01:46AM +0100, Christian Zigotzky wrote: Hi Christoph, Your new patch fixes the problems with the P.A. Semi Ethernet! :-) Thanks a lot once again for testing! Now can you test with this patch

Re: use generic DMA mapping code in powerpc V4

2019-02-08 Thread Christian Zigotzky
OK, I will test it. — Christian Sent from my iPhone > On 8. Feb 2019, at 10:18, Christoph Hellwig wrote: > >> On Fri, Feb 08, 2019 at 10:01:46AM +0100, Christian Zigotzky wrote: >> Hi Christoph, >> >> Your new patch fixes the problems with the P.A. Semi Ethern

Re: use generic DMA mapping code in powerpc V4

2019-02-08 Thread Christian Zigotzky
Hi Christoph, Your new patch fixes the problems with the P.A. Semi Ethernet! :-) Thanks, Christian On 07 February 2019 at 05:34AM, Christian Zigotzky wrote: Hi Christoph, I also didn’t notice the 32-bit DMA mask in your patch. I have to read your patches and descriptions carefully

  1   2   3   4   >