Kernel 5.4

[Roland]

The memory issue with Dawicontrol DC 2976 UW is present also in Kernel 5.4 rc2.

[xeno74]

I noticed that Kernel 5.3 has created a problem which does not exist in 4.20 or earlier... If there is a Dawicontrol DC 2976 UW SCSI board (PCI) installed, the system does not boot unless the RAM is limited to 3500M. This happens now even when there is nothing connected to the controller!

Hi Roland,

Thanks a lot for reporting the issue with the Dawicontrol DC 2976 UW SCSI board (PCI).

Could you please test the RC2 of kernel 5.4 with this SCSI board? I would like to know if the problem still exists in the latest kernel.

Please post the results in the kernel 5.4 test thread.

Thanks in advance,

Christian

The memory issue with Dawicontrol DC 2976 UW is present also in Kernel 5.4 rc2.

Hi Roland,

Thanks for testing the RC2! OK, we know that this issue is still exists in the latest kernel. We have to figure out which code change is responsible for this issue. You told me that the stable kernel 4.20 doesn't have this issue. Could you please test the alpha1 of kernel 4.21/5.0?

Thanks,
Christian

[Roland]

Thanks for testing the RC2! OK, we know that this issue is still exists in the latest kernel. We have to figure out which code change is responsible for this issue. You told me that the stable kernel 4.20 doesn't have this issue. Could you please test the alpha1 of kernel 4.21/5.0?

4.21-alpha1 does not have that issue, I can use the full 8 Gb memory with it. I tested this with unitrd-4.19.3.

I tested also 5.1 (first stable version), and found out that if I use the uinitrd-4.19.3, I can use full RAM, but if unitrd-5.3, the issue is present.

4.20.17 seems to work ok both with unitrd-4.19.3 and unitrd-5.3.

[xeno74]

Hi Roland,

4.21-alpha1 does not have that issue, I can use the full 8 Gb memory with it.

Thanks for testing the alpha1. Please test the alpha2 of kernel 4.21/5.0. I would like to know when the code changed.

I tested this with unitrd-4.19.3.

I tested also 5.1 (first stable version), and found out that if I use the uinitrd-4.19.3, I can use full RAM, but if unitrd-5.3, the issue is present.

4.20.17 seems to work ok both with unitrd-4.19.3 and unitrd-5.3.

Strange. Please test the alphas without any initial ramdisks. The initrds falsify the results.

Thanks,
Christian

[xeno74]

FYI: PowerPC fixes 5.4-3

[Roland]

Thanks for testing the alpha1. Please test the alpha2 of kernel 4.21/5.0. I would like to know when the code changed.

I tested now the alphas... 4.21-alpha2 is last which works - the issue is present starting from alpha3.

[xeno74]

Hi Roland,

I tested now the alphas... 4.21-alpha2 is last which works - the issue is present starting from alpha3.

Thanks for testing! Both have the patch because of this issue.

Code: Select all

diff -rupN a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
--- a/arch/powerpc/sysdev/fsl_pci.c	2018-12-28 08:20:11.651183458 +0100
+++ b/arch/powerpc/sysdev/fsl_pci.c	2018-12-28 08:17:54.971034055 +0100
@@ -127,9 +127,6 @@ static inline void setup_swiotlb_ops(str
 
 static int fsl_pci_dma_set_mask(struct device *dev, u64 dma_mask)
 {
-	if (!dev->dma_mask || !dma_supported(dev, dma_mask))
-		return -EIO;
-
 	/*
 	 * Fix up PCI devices that are able to DMA to the large inbound
 	 * mapping that allows addressing any RAM address from across PCI.

OK, the alpha2 is from 28 December 2018 08:25 AM and the alpha3 with the PowerPC updates 4.21-1 is from 28 December 2018 08:52 AM.

I think the issue is somewhere in the PowerPC updates 4.21-1. Maybe the code change in the file arch/powerpc/kernel/dma-swiotlb.c or maybe the change in the file arch/powerpc/kernel/dma.c.

Cheers,
Christian

[xeno74]

Hi All,

I tried to revert the changes in the file arch/powerpc/kernel/dma.c. The problem is, this file doesn’t exist in the latest kernels anymore. That means we can’t fix anything which doesn’t exist anymore. I think the issue was in these files but today it is somewhere in the other files.

@Roland
Please create a bug report because the changes to the code are too long ago.

@All
It’s very important to test the alphas and release candidates because the sooner we notice an error, the higher is the chance of a fast solution.

Cheers,
Christian

[xeno74]

Hi All,

The RC3 of kernel 5.4 has been released for testing.

New:

• Linux 5.4-rc3 Released Ahead Of Official Kernel Debut In November -- phoronix.com
• PowerPC fixes 5.4-3
• Torvalds' release announcement
• Linux Git log
• Phoronix articles, reviews and news stories covering Linux 5.4

Download: linux-image-5.4-rc3-X1000_X5000_A1222.tar.gz

Please test the kernels.

Thanks,
Christian

[Roland]

I tried to revert the changes in the file arch/powerpc/kernel/dma.c. The problem is, this file doesn’t exist in the latest kernels anymore. That means we can’t fix anything which doesn’t exist anymore. I think the issue was in these files but today it is somewhere in the other files.

I think this problem with PCI boards should be solved in general level... It is stupid that some boards work, and others do not, without anyone really knowing why.

Please create a bug report because the changes to the code are too long ago.

That system seems to be for programmers etc., and you have to create an account.... Too complicated to my old, non-programmable brains .

It’s very important to test the alphas and release candidates because the sooner we notice an error, the higher is the chance of a fast solution.

Hmm... If I would test every rarely used piece of harware every time there is a new alfa/beta kernel, I would not have time for anything else in my life!-) BTW, when I have asked to test something, e.g. just a simple videostream...