Re: ext4 corruption on alpha with 4.20.0-09062-gd8372ba8ce28

[Meelis Roos]

First, I found out that both the problematic alphas had memory compaction and
page migration and bounce buffers turned on, and working alphas had them off.

Next, turing off these options makes the problematic alphas work.


OK, thanks for testing! Can you narrow down whether the problem is due to
CONFIG_BOUNCE or CONFIG_MIGRATION + CONFIG_COMPACTION? These are two
completely different things so knowing where to look will help. Thanks!


Tested both.

Just CONFIG_MIGRATION + CONFIG_COMPACTION breaks the alpha.
Just CONFIG_BOUNCE has no effect in 5 tries.

--
Meelis Roos

Re: ext4 corruption on alpha with 4.20.0-09062-gd8372ba8ce28

[Meelis Roos]

Could
https://lore.kernel.org/linux-mm/20190219123212.29838-1-lar...@axis.com/T/#u
be relevant?


Tried it, still broken.

I wrote:


But my kernel config had memory compaction (that turned on page migration) and
bounce buffers. I do not remember why I found them necessary but I will try
without them. 


First, I found out that both the problematic alphas had memory compaction and
page migration and bounce buffers turned on, and working alphas had them off.

Next, turing off these options makes the problematic alphas work.

--
Meelis Roos 

Re: ext4 corruption on alpha with 4.20.0-09062-gd8372ba8ce28

[Meelis Roos]

The result of the bisection is
[88dbcbb3a4847f5e6dfeae952d3105497700c128] blkdev: avoid migration stalls for 
blkdev pages

Is that result relevant for the problem or should I continue bisecting between 
4.20.0 and the so far first bad commit?


Can you try reverting the commit and see if it makes the problem go away?


Tried reverting it on top of 5.0.0-rc6-00153-g5ded5871030e and it seems
to make the kernel work - emerge --sync succeeded.

There is more to it.

After running 5.0.0-rc6-00153-g5ded5871030e-dirty (with the revert of that 
patch)
successfully for Gentoo update, I upgraded the kernel to
5.0.0-rc7-00011-gb5372fe5dc84-dirty (todays git + revert of this patch) and it 
broke on rsync again:

RepoStorageException: command exited with status -6: rsync -a --link-dest 
/usr/portage --exclude=/distfiles --exclude=/local --exclude=/lost+found 
--exclude=/packages --exclude /.tmp-unverified-download-quarantine 
/usr/portage/ /usr/portage/.tmp-unverified-download-quarantine/

Nothing in dmesg.

This means the real root reason is somewhere deeper and reverting this commit 
just made
it less likely to happen.

--
Meelis Roos 

Re: ext4 corruption on alpha with 4.20.0-09062-gd8372ba8ce28

[Meelis Roos]

Hum, weird. I have hard time understanding how that change could be causing
fs corruption on Aplha but OTOH it is not completely unthinkable. With this
commit we may migrate some block device pages we were not able to migrate
previously and that could be causing some unexpected issue. I'll look into
this.


To make things more interesting, it does not happen on any alpha but only one 
subarch
so far: 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1889207.html
is my original bug report.

--
Meelis Roos 

Re: ext4 corruption on alpha with 4.20.0-09062-gd8372ba8ce28

[Meelis Roos]

The result of the bisection is
[88dbcbb3a4847f5e6dfeae952d3105497700c128] blkdev: avoid migration stalls for 
blkdev pages

Is that result relevant for the problem or should I continue bisecting between 
4.20.0 and the so far first bad commit?


Can you try reverting the commit and see if it makes the problem go away?


Tried reverting it on top of 5.0.0-rc6-00153-g5ded5871030e and it seems to make 
the kernel work - emerge --sync succeeded.

Unfinished further bisection has also not yielded any other bad revisions so 
far.

--
Meelis Roos

Re: ext4 corruption on alpha with 4.20.0-09062-gd8372ba8ce28

[Meelis Roos]

I have noticed ext4 filesystem corruption on two of my test alphas with 
4.20.0-09062-gd8372ba8ce28.


Retried it, still happens with 5.0.0-rc5-00358-gdf3865f8f568 - rsync of emerge 
--sync just fail with nothing in dmesg.


Finished second round of bisecting, first round did not get me far enough so
I may still have false "goods" in my bisection history.

The command I used for bisecting was Gentoos
emerge --sync.
that sometimes failed from error -6 or -11 from rsync.
Usually the file system corruption did not happen and nothing was in dmesg, 
just file IO error from rsync.

The result of the bisection is
[88dbcbb3a4847f5e6dfeae952d3105497700c128] blkdev: avoid migration stalls for 
blkdev pages

Is that result relevant for the problem or should I continue bisecting between 
4.20.0 and the so far first bad commit?


On AlphaServer DS10:
[10749.664418] EXT4-fs error (device sda2): __ext4_iget:5052: inode #1853093: 
block 1: comm rsync: invalid block

On AlphaServer DS10L:
[ 5325.064656] EXT4-fs error (device sda2): htree_dirblock_to_tree:1007: inode 
#1191951: block 4731728: comm rm: bad entry in directory: directory entry 
overrun - offset=76, inode=417080, rec_len=61816, name_len=35, size=4096
[ 5325.069539] EXT4-fs error (device sda2): htree_dirblock_to_tree:1007: inode 
#1191951: block 4731728: comm rm: bad entry in directory: directory entry 
overrun - offset=76, inode=417080, rec_len=61816, name_len=35, size=4096
[ 5325.077351] EXT4-fs error (device sda2): ext4_empty_dir:2718: inode 
#1191951: block 4731728: comm rm: bad entry in directory: directory entry 
overrun - offset=76, inode=417080, rec_len=61816, name_len=35, size=4096

Two other alphas, PC-164 and Eiger, worked fine with the same kernel version 
(different kernel configs according to hardware).

The details:
4.20 worked fine, with gentoo emerge package update after bootup.
Next, 4.20.0-06428-g00c569b567c7 worked fine, with gentoo emerge after bootup.
Next, 4.20.0-09062-gd8372ba8ce28 booted up fine but rsync and rm during start 
of gentoo emerge errored out like above.

So the corruption _might_ have happened during bootup of previous kernel but it 
looks more likely that only the latest kernel with blk-mq introduced the 
problems. mq-deadline is in use on all the alphas.

DS10 has Symbios 53C896 SCSI (sym2 driver), DS10L has QLogic ISP1040, so they 
are different. Working Eiger and PC164 have sym2 based scsi controllers too.




--
Meelis Roos 

Re: ext4 corruption on alpha with 4.20.0-09062-gd8372ba8ce28

[Meelis Roos]

02.01.19 17:52 I wrote:


I have noticed ext4 filesystem corruption on two of my test alphas with 
4.20.0-09062-gd8372ba8ce28.


Retried it, still happens with 5.0.0-rc5-00358-gdf3865f8f568 - rsync of emerge 
--sync just fail with nothing in dmesg.
 

On AlphaServer DS10:
[10749.664418] EXT4-fs error (device sda2): __ext4_iget:5052: inode #1853093: 
block 1: comm rsync: invalid block

On AlphaServer DS10L:
[ 5325.064656] EXT4-fs error (device sda2): htree_dirblock_to_tree:1007: inode 
#1191951: block 4731728: comm rm: bad entry in directory: directory entry 
overrun - offset=76, inode=417080, rec_len=61816, name_len=35, size=4096
[ 5325.069539] EXT4-fs error (device sda2): htree_dirblock_to_tree:1007: inode 
#1191951: block 4731728: comm rm: bad entry in directory: directory entry 
overrun - offset=76, inode=417080, rec_len=61816, name_len=35, size=4096
[ 5325.077351] EXT4-fs error (device sda2): ext4_empty_dir:2718: inode 
#1191951: block 4731728: comm rm: bad entry in directory: directory entry 
overrun - offset=76, inode=417080, rec_len=61816, name_len=35, size=4096

Two other alphas, PC-164 and Eiger, worked fine with the same kernel version 
(different kernel configs according to hardware).

The details:
4.20 worked fine, with gentoo emerge package update after bootup.
Next, 4.20.0-06428-g00c569b567c7 worked fine, with gentoo emerge after bootup.
Next, 4.20.0-09062-gd8372ba8ce28 booted up fine but rsync and rm during start 
of gentoo emerge errored out like above.

So the corruption _might_ have happened during bootup of previous kernel but it 
looks more likely that only the latest kernel with blk-mq introduced the 
problems. mq-deadline is in use on all the alphas.

DS10 has Symbios 53C896 SCSI (sym2 driver), DS10L has QLogic ISP1040, so they 
are different. Working Eiger and PC164 have sym2 based scsi controllers too.


--
Meelis Roos 

Re: PWS 433au (Miata) recovery update

[Meelis Roos]

I share my experience of fresh install of and embedded SBC Alpha
(Eiger with EV6 500 MHz).

Only an ancient Debian installer worked for me. The reason appeared to
be broken IRQ numbers for Eiger.

So I used 2 disks. I first installed the ancient Debian on disk 1.
That worked.

Next, I used that to bootstrap Gentoo on second disk, with ext3 as was
supported by Debian tooling.

Then I debugged the new kernel and fixed the IRQ problem. Now I had a
recent kernel. I sent the patch https://lkml.org/lkml/2018/10/12/379 to
linux-alpha but it seems to have been ignored - PING!

Next I emerged the newest filesystem tools (e2fsutils) to support latest
ext4 features and bootstrapped next Gentoo installation from second disk to
the first disk, with ext4 and the newest kernel.

The resulting Gentoo with Eiger and patched kernel is working fine -
I have to carry the kernel patch around until gets applied upstream.

Even btrfs seems to work on alpha - I have a btrfs volume with 5x4.5G disks :)

--
Meelis Roos 

Re: NO_BOOTMEM breaks alpha pc164

[Meelis Roos]

] futex hash table entries: 256 (order: -1, 6144 bytes)
[0.106445] NET: Registered protocol family 16
[0.108398] pci: passed tb register update test
[0.109374] pci: passed sg loopback i/o read test
[0.110351] pci: passed tbia test
[0.111328] pci: passed pte write cache snoop test

halted CPU 0

halt code = 7
machine check while in PAL mode
PC = 1814c
boot failure




--
Meelis Roos 

Re: NO_BOOTMEM breaks alpha pc164

[Meelis Roos]

ocess



You can try applying the below patch to enable debug printouts from
memblock, maybe it'll shed some more light.


Will try.

--
Meelis Roos 

NO_BOOTMEM breaks alpha pc164

[Meelis Roos]

dia control info
[0.464843] tulip0: EEPROM default media type Autosense
[0.465820] tulip0: Index #0 - Media 10base2 (#1) described by a 21140 
non-MII (0) block
[0.466796] tulip0: Index #1 - Media 10baseT (#0) described by a 21140 
non-MII (0) block
[0.467773] tulip0: Index #2 - Media 10baseT-FDX (#4) described by a 21140 
non-MII (0) block
[0.468749] tulip0: Index #3 - Media 100baseTx (#3) described by a 21140 
non-MII (0) block
[0.469726] tulip0: Index #4 - Media 100baseTx-FDX (#5) described by a 21140 
non-MII (0) block
[0.472656] net eth0: Digital DS21140 Tulip rev 34 at MMIO 0x2276000, 
00:00:e8:3c:4e:c2, IRQ 19
[0.480468] serio: i8042 KBD port at 0x60,0x64 irq 1
[0.482421] serio: i8042 AUX port at 0x60,0x64 irq 12
[0.487304] NET: Registered protocol family 10
[0.491210] FDC 0 is a post-1991 82077
[0.502929] atkbd serio0: keyboard reset failed on isa0060/serio0
[0.503905] Segment Routing with IPv6
[0.504882] NET: Registered protocol family 17
[0.508788] platform rtc-alpha: setting system clock to 2018-11-22 14:26:16 
UTC (1542896776)
[0.552734] atkbd serio1: keyboard reset failed on isa0060/serio1
[0.628905] atkbd serio0: keyboard reset failed on isa0060/serio0
[0.693359] atkbd serio1: keyboard reset failed on isa0060/serio1
[3.828123] scsi 0:0:0:0: Direct-Access COMPAQ   BF0369A4BC   HPB7 
PQ: 0 ANSI: 3
[3.829099] scsi target0:0:0: tagged command queuing enabled, command queue 
depth 16.
[3.830076] scsi target0:0:0: Beginning Domain Validation
[3.836912] scsi target0:0:0: FAST-20 WIDE SCSI 40.0 MB/s ST (50 ns, offset 
15)
[3.840818] scsi target0:0:0: Domain Validation skipping write tests
[3.841794] scsi target0:0:0: Ending Domain Validation
[3.843748] scsi 0:0:0:0: Power-on or device reset occurred
[7.989253] sd 0:0:0:0: Attached scsi generic sg0 type 0
[7.991206] sd 0:0:0:0: [sda] 71132000 512-byte logical blocks: (36.4 
GB/33.9 GiB)
[7.993159] sd 0:0:0:0: [sda] Write Protect is off
[7.994136] sd 0:0:0:0: [sda] Mode Sense: cf 00 10 08
[7.995113] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, 
supports DPO and FUA
[8.009761]  sda: sda1 sda2 sda4
[8.017574] sd 0:0:0:0: [sda] Attached SCSI disk
[8.041988] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: 
(null)
[8.042964] VFS: Mounted root (ext4 filesystem) readonly on device 8:2.
[8.059566] devtmpfs: mounted
[8.061519] Freeing unused kernel memory: 208K
[8.062495] This architecture does not have kernel memory protection.
[8.063472] Run /sbin/init as init process
[8.319331] random: crng init done
[   21.777332] udevd[477]: starting version 3.2.5
[   21.949207] udevd[478]: starting eudev-3.2.5
[   23.199206] tulip :00:09.0 enp0s9: renamed from eth0
[   23.864245] libata version 3.00 loaded.
[   24.037097] scsi host1: pata_cmd64x
[   24.055651] scsi host2: pata_cmd64x
[   24.055651] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0x8480 irq 14
[   24.055651] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0x8488 irq 15
[   24.056628] pata_cmd64x: active 10 recovery 10 setup 3.
[   24.056628] pata_cmd64x: active 10 recovery 10 setup 3.
[   24.232409] ata1.00: ATAPI: SONYCD-RW  CRX140E, 1.2a, max UDMA/33
[   24.232409] pata_cmd64x: active 3 recovery 1 setup 1.
[   24.232409] pata_cmd64x: active 3 recovery 1 setup 1.
[   24.262682] scsi 1:0:0:0: CD-ROMSONY CD-RW  CRX140E   1.2a 
PQ: 0 ANSI: 5
[   24.281237] sr 1:0:0:0: [sr0] scsi3-mmc drive: 32x/32x writer cd/rw xa/form2 
cdda tray
[   24.281237] cdrom: Uniform CD-ROM driver Revision: 3.20
[   24.282214] sr 1:0:0:0: Attached scsi CD-ROM sr0
[   24.284167] sr 1:0:0:0: Attached scsi generic sg1 type 5
[   24.285143] pata_cmd64x: active 10 recovery 10 setup 3.
[   24.285143] pata_cmd64x: active 10 recovery 10 setup 3.
[   29.485336] EXT4-fs (sda2): re-mounted. Opts: errors=remount-ro
[   31.106429] Adding 1697208k swap on /dev/sda4.  Priority:-2 extents:1 
across:1697208k
[   31.825179] EXT4-fs (sda1): mounting ext2 file system using the ext4 
subsystem
[   31.846663] EXT4-fs (sda1): mounted filesystem without journal. Opts: (null)

--
Meelis Roos 

Relocation (type 4) overflow on alpha for big module

[Meelis Roos]

I decided to try btrfs on one of my alphas and got a surprise - btrfs module 
does not load:

modprobe: ERROR: could not insert 'btrfs': Exec format error

dmesg has

module btrfs: Relocation (type 4) overflow vs btrfs_attach_transaction_barrier

Happens both natively on alpha:
binutils 2.30.0 (Gentoo 2.30 p2) and gcc version 7.3.0 (Gentoo 7.3.0-r3 p1.4)
or in cross-compiling:
binutils (GNU Binutils for Debian) 2.31.1 and gcc version 8.1.0 (Debian 
8.1.0-12)

btrfs.ko has size 2939856. Build-in btrfs initializes and tests itself just 
fine.

This seems to have happened in the distant past:
https://www.redhat.com/archives/axp-list/2005-March/msg00060.html

Do we have a similar binutils problem again with big modules?

--
Meelis Roos 

[PATCH] [alpha] Fix Eiger NR_IRQS to 128

[Meelis Roos]

Eiger machine vector definition has nr_irqs 128, and working 2.6.26
boot shows SCSI getting IRQ-s 64 and 65. Current kernel boot fails
because Symbios SCSI fails to request IRQ-s and does not find the disks.
It has been broken at least since 3.18 - the earliest I could test with
my gcc-5.

The headers have moved around and possibly another order of defines has
worked in the past - but since 128 seems to be correct and used, fix
arch/alpha/include/asm/irq.h to have NR_IRQS=128 for Eiger.

This fixes 4.19-rc7 boot on my Force Flexor A264 (Eiger subarch).

Signed-off-by: Meelis Roos 

---
 arch/alpha/include/asm/irq.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/alpha/include/asm/irq.h b/arch/alpha/include/asm/irq.h
index 4d17cacd1462..5681ccc3cf63 100644
--- a/arch/alpha/include/asm/irq.h
+++ b/arch/alpha/include/asm/irq.h
@@ -56,15 +56,15 @@
 
 #elif defined(CONFIG_ALPHA_DP264) || \

   defined(CONFIG_ALPHA_LYNX)  || \
-  defined(CONFIG_ALPHA_SHARK) || \
-  defined(CONFIG_ALPHA_EIGER)
+  defined(CONFIG_ALPHA_SHARK)
 # define NR_IRQS   64
 
 #elif defined(CONFIG_ALPHA_TITAN)

 #define NR_IRQS80
 
 #elif defined(CONFIG_ALPHA_RAWHIDE) || \

-   defined(CONFIG_ALPHA_TAKARA)
+   defined(CONFIG_ALPHA_TAKARA) || \
+   defined(CONFIG_ALPHA_EIGER)
 # define NR_IRQS   128
 
 #elif defined(CONFIG_ALPHA_WILDFIRE)

--
2.19.1

bpfilter compile failure on alpha

[Meelis Roos]

ONFIG_CRYPTO_NULL is not set
CONFIG_CRYPTO_NULL2=y
CONFIG_CRYPTO_WORKQUEUE=y
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_MCRYPTD is not set
# CONFIG_CRYPTO_AUTHENC is not set
# CONFIG_CRYPTO_TEST is not set

#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_CHACHA20POLY1305 is not set
# CONFIG_CRYPTO_AEGIS128 is not set
# CONFIG_CRYPTO_AEGIS128L is not set
# CONFIG_CRYPTO_AEGIS256 is not set
# CONFIG_CRYPTO_MORUS640 is not set
# CONFIG_CRYPTO_MORUS1280 is not set
# CONFIG_CRYPTO_SEQIV is not set
# CONFIG_CRYPTO_ECHAINIV is not set

#
# Block modes
#
# CONFIG_CRYPTO_CBC is not set
# CONFIG_CRYPTO_CFB is not set
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
# CONFIG_CRYPTO_ECB is not set
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set
# CONFIG_CRYPTO_KEYWRAP is not set

#
# Hash modes
#
# CONFIG_CRYPTO_CMAC is not set
CONFIG_CRYPTO_HMAC=y
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_VMAC is not set

#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_CRC32 is not set
# CONFIG_CRYPTO_CRCT10DIF is not set
# CONFIG_CRYPTO_GHASH is not set
# CONFIG_CRYPTO_POLY1305 is not set
# CONFIG_CRYPTO_MD4 is not set
# CONFIG_CRYPTO_MD5 is not set
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=y
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_SHA3 is not set
# CONFIG_CRYPTO_SM3 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set

#
# Ciphers
#
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_AES_TI is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_CHACHA20 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_SM4 is not set
# CONFIG_CRYPTO_SPECK is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set

#
# Compression
#
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_LZO is not set
# CONFIG_CRYPTO_842 is not set
# CONFIG_CRYPTO_LZ4 is not set
# CONFIG_CRYPTO_LZ4HC is not set
# CONFIG_CRYPTO_ZSTD is not set

#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
# CONFIG_CRYPTO_DRBG_MENU is not set
# CONFIG_CRYPTO_JITTERENTROPY is not set
# CONFIG_CRYPTO_USER_API_HASH is not set
# CONFIG_CRYPTO_USER_API_SKCIPHER is not set
# CONFIG_CRYPTO_USER_API_RNG is not set
# CONFIG_CRYPTO_USER_API_AEAD is not set
# CONFIG_CRYPTO_HW is not set

#
# Certificates for signature checking
#

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
CONFIG_GENERIC_NET_UTILS=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y
# CONFIG_CRC_CCITT is not set
CONFIG_CRC16=y
# CONFIG_CRC_T10DIF is not set
CONFIG_CRC_ITU_T=m
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
# CONFIG_CRC4 is not set
# CONFIG_CRC7 is not set
# CONFIG_LIBCRC32C is not set
# CONFIG_CRC8 is not set
# CONFIG_RANDOM32_SELFTEST is not set
CONFIG_ZLIB_INFLATE=y
# CONFIG_XZ_DEC is not set
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT_MAP=y
CONFIG_HAS_DMA=y
CONFIG_SGL_ALLOC=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
CONFIG_DQL=y
CONFIG_GLOB=y
# CONFIG_GLOB_SELFTEST is not set
CONFIG_NLATTR=y
# CONFIG_CORDIC is not set
# CONFIG_DDR is not set
# CONFIG_IRQ_POLL is not set
CONFIG_SG_POOL=y
CONFIG_SBITMAP=y
# CONFIG_STRING_SELFTEST is not set

-- 
Meelis Roos (mr...@linux.ee)
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: the patch "alpha/PCI: Replace pci_fixup_irqs()" breaks networking

[Meelis Roos]

> The patch 0e4c2eeb758a91e68b9eaf7a4bee9bd5ed97ff2b ("alpha/PCI: Replace 
> pci_fixup_irqs() call with host bridge IRQ mapping hooks") breaks 
> networking on Alpha for me. I have an Alpha Avanti server with tulip 
> network card.

Matbe the map is wrong for Avanti? Is there some way to check that?
> 
> The patch 0e4c2eeb breaks it so that I get MCE when the network card 
> driver is loaded. The patch 814eae59 fixes the MCE, the system boot 
> completes, but the network card doesn't receive any interrupts (and soon 
> it reports warning about timeout on tx queue). All kernels in the 4.14 
> branch have this bug.

Does some other IRQ icrease instead?

> Mikulas
> 
> 
> # cat /proc/interrupts
>CPU0
>   1:  3XT-PIC  i8042
>   2:  0XT-PIC  cascade
>   4:752XT-PIC  ttyS0
>   8:  58118 dummy-RTC   timer
>  10:   1613XT-PIC  ide0, ide1
>  11:739XT-PIC  sym53c8xx
>  12:  5XT-PIC  i8042
>  15:  0XT-PIC  eth0   <--- note that the counter is zero
> PMI:  0   Performance Monitoring
> ERR:  0
> 
> # lspci -vv
> 00:06.0 SCSI storage controller: LSI Logic / Symbios Logic 53c810 (rev 01)
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ 
> Stepping- SERR- FastB2B- DisINTx-
> Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
> SERR-  Latency: 255
> Interrupt: pin A routed to IRQ 11
> Region 0: I/O ports at 8000 [size=256]
> Region 1: Memory at 0130 (32-bit, non-prefetchable) [size=256]
> Kernel driver in use: sym53c8xx
> Kernel modules: sym53c8xx
> 
> 00:07.0 ISA bridge: Intel Corporation 82378ZB/IB, 82379AB (SIO, SIO.A) PCI to 
> ISA Bridge (rev 43)
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx-
> Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
> SERR-  Latency: 0
> 
> 00:0b.0 Ethernet controller: Digital Equipment Corporation DECchip 21140 
> [FasterNet] (rev 22)
> Subsystem: Digital Equipment Corporation DECchip 21140 [FasterNet]
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+ 
> Stepping- SERR- FastB2B- DisINTx-
> Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
> SERR-  Latency: 255 (5000ns min, 1ns max), Cache Line Size: 64 bytes
> Interrupt: pin A routed to IRQ 15
> Region 0: I/O ports at 8400 [size=128]
> Region 1: Memory at 01302000 (32-bit, non-prefetchable) [size=128]
> Expansion ROM at 0128 [disabled] [size=256K]
> Kernel driver in use: tulip
> Kernel modules: tulip
> 
> 00:0c.0 Display controller: Digital Equipment Corporation DECchip 21030 [TGA] 
> (rev 02)
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping+ SERR- FastB2B- DisINTx-
> Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
> SERR-  Latency: 255
> Interrupt: pin A routed to IRQ 5
> Region 0: Memory at 0200 (32-bit, prefetchable) [size=32M]
> Expansion ROM at 012c [disabled] [size=256K]
> Kernel driver in use: tgafb
> 
> 00:0d.0 RAID bus controller: Silicon Image, Inc. PCI0680 Ultra ATA-133 Host 
> Controller (rev 02)
> Subsystem: Silicon Image, Inc. Winic W-680 (Silicon Image 680 based)
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ 
> Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
> SERR-  Latency: 240, Cache Line Size: 4 bytes
> Interrupt: pin A routed to IRQ 10
> Region 0: I/O ports at 8490 [size=8]
> Region 1: I/O ports at 84a0 [size=4]
> Region 2: I/O ports at 8498 [size=8]
> Region 3: I/O ports at 84a4 [size=4]
> Region 4: I/O ports at 8480 [size=16]
> Region 5: Memory at 01301000 (32-bit, non-prefetchable) [size=256]
> Expansion ROM at 0120 [disabled] [size=512K]
> Capabilities: [60] Power Management version 2
> Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA 
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=2 PME-
> Kernel driver in use: SiI_IDE
> 

-- 
Meelis Roos (mr...@ut.ee)  http://www.cs.ut.ee/~mroos/
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: alpha boot hang - 4.14-rc* regression

[Meelis Roos]

> It is probably because I patched the wrong map_irq() function,
> I am trying to detect which one you are _actually_ using, if
> the patch below fails I will patch them all (which is what I
> have to do anyway).
> 
> Please give this a go - this _has_ to make a difference, it is not
> correct to leave map_irq() pointers as __init memory, IRQ routing
> for modules can't work.

This works for mainline git too.

If you have another round that fixes all subarches, I will try it on a 
PC164 too.

-- 
Meelis Roos (mr...@linux.ee)
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: alpha boot hang - 4.14-rc* regression

[Meelis Roos]

> > > > > > removing libata modules and rebooting fixes it - so it seems to be 
> > > > > > loading of libata.
> > > > > 
> > > > > Can you please cherry-pick:
> > > > > 
> > > > > commit b1f9e5e355e9 ("ide: fix IRQ assignment for PCI bus order 
> > > > > probing")
> > > > > 
> > > > > from mainline and let us know if that solves the issue ?
> > > > 
> > > > No, still breaks the same way (b1f9e5e355e9 patched on top of 
> > > > 0e4c2eeb758a).
> > > > 
> > > > 4.14.0-rc5-00095-g1c9fec470b81 was also still broken the same way 
> > > > (tried 
> > > > on Sunday).
> > > 
> > > I am not sure I patched the right sys file but if I did, does the patch
> > > below help ?
> > > 
> > > I think that at sata driver binding time the kernel finds a freed
> > > pointer in the host bridge map_irq() hook and that's where things
> > > go wrong.
> > > 
> > > Please let me know if that's the right sys file, it is a mechanical
> > > change and making it for other sys file should be reasonably simple.
> > > 
> > > Lorenzo
> > > 
> > > -- >8 --
> > > diff --git a/arch/alpha/kernel/sys_dp264.c b/arch/alpha/kernel/sys_dp264.c
> > 
> > "Booting GENERIC on Tsunami variation Webbrick using machine vector 
> > Webbrick from SRM"
> > 
> > Seems to be the correct file - tsunami is referenced from this file and 
> > the IRQ-s are DP264.
> > 
> > But the patch does not make a difference :(
> 
> It is probably because I patched the wrong map_irq() function,
> I am trying to detect which one you are _actually_ using, if
> the patch below fails I will patch them all (which is what I
> have to do anyway).
> 
> Please give this a go - this _has_ to make a difference, it is not
> correct to leave map_irq() pointers as __init memory, IRQ routing
> for modules can't work.

Yes, webrick entry seems to be the correct one fro DS10L. It works fine 
on top of the cherry-picked ATA IRQ patch.

Will try it on top of current mainline git.

-- 
Meelis Roos (mr...@linux.ee)
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: alpha boot hang - 4.14-rc* regression

[Meelis Roos]

> > > > removing libata modules and rebooting fixes it - so it seems to be 
> > > > loading of libata.
> > > 
> > > Can you please cherry-pick:
> > > 
> > > commit b1f9e5e355e9 ("ide: fix IRQ assignment for PCI bus order probing")
> > > 
> > > from mainline and let us know if that solves the issue ?
> > 
> > No, still breaks the same way (b1f9e5e355e9 patched on top of 
> > 0e4c2eeb758a).
> > 
> > 4.14.0-rc5-00095-g1c9fec470b81 was also still broken the same way (tried 
> > on Sunday).
> 
> I am not sure I patched the right sys file but if I did, does the patch
> below help ?
> 
> I think that at sata driver binding time the kernel finds a freed
> pointer in the host bridge map_irq() hook and that's where things
> go wrong.
> 
> Please let me know if that's the right sys file, it is a mechanical
> change and making it for other sys file should be reasonably simple.
> 
> Lorenzo
> 
> -- >8 --
> diff --git a/arch/alpha/kernel/sys_dp264.c b/arch/alpha/kernel/sys_dp264.c

"Booting GENERIC on Tsunami variation Webbrick using machine vector 
Webbrick from SRM"

Seems to be the correct file - tsunami is referenced from this file and 
the IRQ-s are DP264.

But the patch does not make a difference :(

-- 
Meelis Roos (mr...@linux.ee)
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: alpha boot hang - 4.14-rc* regression

[Meelis Roos]

> > (Added linux-pci to CC)
> > 
> > > > I run Gentoo Linux on my alphas, with latest git kernels for test. 
> > > > 4.13.0 worked well on 3 alphas but 4.13.0-09217-g5969d1bb3082 hangs on 
> > > > boot on all 3 of them. Tried bisecting on PC164, got into unrelated 
> > > > stuff, so probably it does not trigger always. Retried bisecting on 
> > > > DS10L. On the first try I got that the same keel where I first saw bad 
> > > > was the culprit, another bisect led me to 
> > > > 0e4c2eeb758a91e68b9eaf7a4bee9bd5ed97ff2b which looks more related.
> > > > 
> > > > This is how the crash looks on console:
> > > > 
> > > >  * Starting udev ...
> > > > starting version 225
> > > >  [ ok ]
> > > >  * Generating a rule to create a /dev/root symlink ...
> > > >  [ ok ]
> > > >  * Populating /dev with existing devices through uevents ...
> > > >  [ ok ]
> > > > 
> > > > halted CPU 0
> > > > 
> > > > halt code = 5
> > > > HALT instruction executed
> > > > PC = fc9bf914
> > > > boot failure
> > > > >>>
> > > > 
> > > > What else can I do to debug this?
> > > 
> > > Booting with debug ignore_loglevel I get also this:
> > [...]
> > > So maybe it is related pcspkr loading, or the just loaded libata or 
> > > floppy...
> > 
> > removing libata modules and rebooting fixes it - so it seems to be 
> > loading of libata.
> 
> Can you please cherry-pick:
> 
> commit b1f9e5e355e9 ("ide: fix IRQ assignment for PCI bus order probing")
> 
> from mainline and let us know if that solves the issue ?

No, still breaks the same way (b1f9e5e355e9 patched on top of 
0e4c2eeb758a).

4.14.0-rc5-00095-g1c9fec470b81 was also still broken the same way (tried 
on Sunday).

-- 
Meelis Roos (mr...@linux.ee)
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: alpha boot hang - 4.14-rc* regression

[Meelis Roos]

(Added linux-pci to CC)

> > I run Gentoo Linux on my alphas, with latest git kernels for test. 
> > 4.13.0 worked well on 3 alphas but 4.13.0-09217-g5969d1bb3082 hangs on 
> > boot on all 3 of them. Tried bisecting on PC164, got into unrelated 
> > stuff, so probably it does not trigger always. Retried bisecting on 
> > DS10L. On the first try I got that the same keel where I first saw bad 
> > was the culprit, another bisect led me to 
> > 0e4c2eeb758a91e68b9eaf7a4bee9bd5ed97ff2b which looks more related.
> > 
> > This is how the crash looks on console:
> > 
> >  * Starting udev ...
> > starting version 225
> >  [ ok ]
> >  * Generating a rule to create a /dev/root symlink ...
> >  [ ok ]
> >  * Populating /dev with existing devices through uevents ...
> >  [ ok ]
> > 
> > halted CPU 0
> > 
> > halt code = 5
> > HALT instruction executed
> > PC = fc9bf914
> > boot failure
> > >>>
> > 
> > What else can I do to debug this?
> 
> Booting with debug ignore_loglevel I get also this:
[...]
> So maybe it is related pcspkr loading, or the just loaded libata or 
> floppy...

removing libata modules and rebooting fixes it - so it seems to be 
loading of libata.

lspci -vvv from broken kernel with no libata loaded:

00:07.0 ISA bridge: ULi Electronics Inc. M1533/M1535/M1543 PCI to ISA Bridge 
[Aladdin IV/V/V+] (rev c3)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- http://www.cs.ut.ee/~mroos/
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

alpha boot hang - 4.14-rc* regression

[Meelis Roos]

I run Gentoo Linux on my alphas, with latest git kernels for test. 
4.13.0 worked well on 3 alphas but 4.13.0-09217-g5969d1bb3082 hangs on 
boot on all 3 of them. Tried bisecting on PC164, got into unrelated 
stuff, so probably it does not trigger always. Retried bisecting on 
DS10L. On the first try I got that the same keel where I first saw bad 
was the culprit, another bisect led me to 
0e4c2eeb758a91e68b9eaf7a4bee9bd5ed97ff2b which looks more related.

This is how the crash looks on console:

 * Starting udev ...
starting version 225
 [ ok ]
 * Generating a rule to create a /dev/root symlink ...
 [ ok ]
 * Populating /dev with existing devices through uevents ...
 [ ok ]

halted CPU 0

halt code = 5
HALT instruction executed
PC = fc9bf914
boot failure
>>>

What else can I do to debug this?


0e4c2eeb758a91e68b9eaf7a4bee9bd5ed97ff2b is the first bad commit
commit 0e4c2eeb758a91e68b9eaf7a4bee9bd5ed97ff2b
Author: Lorenzo Pieralisi <lorenzo.pieral...@arm.com>
Date:   Mon Jul 31 17:37:51 2017 +0100

alpha/PCI: Replace pci_fixup_irqs() call with host bridge IRQ mapping hooks

The pci_fixup_irqs() function allocates IRQs for all PCI devices present in
a system; those PCI devices possibly belong to different PCI bus trees (and
possibly rooted at different host bridges) and may well be enabled (ie
probed and bound to a driver) by the time pci_fixup_irqs() is called when
probing a given host bridge driver.

Furthermore, current kernel code relying on pci_fixup_irqs() to assign
legacy PCI IRQs to devices does not work at all for hotplugged devices in
that the code carrying out the IRQ fixup is called at host bridge driver
probe time, which just cannot take into account devices hotplugged after
the system has booted.

The introduction of map/swizzle function hooks in struct pci_host_bridge
allows us to define per-bridge map/swizzle functions that can be used at
device probe time in PCI core code to allocate IRQs for a given device
(through pci_assign_irq()).

Convert PCI host bridge initialization code to the
pci_scan_root_bus_bridge() API (that allows to pass a struct
pci_host_bridge with initialized map/swizzle pointers) and remove the
pci_fixup_irqs() call from arch code.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieral...@arm.com>
Signed-off-by: Bjorn Helgaas <bhelg...@google.com>
Cc: Richard Henderson <r...@twiddle.net>
Cc: Ivan Kokshaysky <i...@jurassic.park.msu.ru>

:04 04 18f71e214185d05a58284efd4e97927f48e217ac 
327e88f6df911f58be520ae99a02022dab6a8f5e M  arch

In case this does not look related, here are all the known bad kernels 
from all my bisect logs:

# bad: [0e4c2eeb758a91e68b9eaf7a4bee9bd5ed97ff2b] alpha/PCI: Replace 
pci_fixup_irqs() call with host bridge IRQ mapping hooks
# bad: [19cc4c843f40c6110dd07270414586e7fe4121b2] m68k/PCI: Replace 
pci_fixup_irqs() call with host bridge IRQ mapping hooks
# bad: [1c9fec470b81ca5e89391c20a11ead31a1e9314b] waitid(): Avoid unbalanced 
user_access_end() on access_ok() error
# bad: [572c01ba19ef150e98aea0b45ca17d43356521b5] Merge tag 'scsi-misc' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
# bad: [5969d1bb3082b41eba8fd2c826559abe38ccb6df] Merge branch 'gperf-removal'
# bad: [7f1b9be13a7dbe8e51ea541bbcd6c47adae39c71] Merge tag 'armsoc-platforms' 
of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
# bad: [98611dd735b472c23cc1e8cca90a997393a3a955] tile/PCI: Replace 
pci_fixup_irqs() call with host bridge IRQ mapping hooks
# bad: [c054be10ffdbd5507a1fd738067d76acfb4808fd] remove gperf left-overs from 
build system
# bad: [d4fdf844c9c3debc080aea1be8b71d9d0aaa01dc] Merge branch 'pci/irq-fixups' 
into next
# bad: [d872694bac212f76ca13fd20a85e5c1bdb53a945] Merge branch 'pci/pm' into 
next



-- 
Meelis Roos (mr...@linux.ee)
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: alpha boot hang - 4.14-rc* regression

[Meelis Roos]

> I run Gentoo Linux on my alphas, with latest git kernels for test. 
> 4.13.0 worked well on 3 alphas but 4.13.0-09217-g5969d1bb3082 hangs on 
> boot on all 3 of them. Tried bisecting on PC164, got into unrelated 
> stuff, so probably it does not trigger always. Retried bisecting on 
> DS10L. On the first try I got that the same keel where I first saw bad 
> was the culprit, another bisect led me to 
> 0e4c2eeb758a91e68b9eaf7a4bee9bd5ed97ff2b which looks more related.
> 
> This is how the crash looks on console:
> 
>  * Starting udev ...
> starting version 225
>  [ ok ]
>  * Generating a rule to create a /dev/root symlink ...
>  [ ok ]
>  * Populating /dev with existing devices through uevents ...
>  [ ok ]
> 
> halted CPU 0
> 
> halt code = 5
> HALT instruction executed
> PC = fc9bf914
> boot failure
> >>>
> 
> What else can I do to debug this?

Booting with debug ignore_loglevel I get also this:

seq 421 queued, 'add' 'platform'
seq 417 running
passed device to netlink monitor 0x200010c7820
seq 417 processed
seq 418 running
IMPORT builtin 'hwdb' /lib/udev/rules.d/50-udev-default.rules:15
IMPORT builtin 'hwdb' returned non-zero
RUN 'kmod load $env{MODALIAS}' /lib/udev/rules.d/80-drivers.rules:5
Execute 'load' 'platform:alarmtimer'
seq 419 running
IMPORT builtin 'hwdb' /lib/udev/rules.d/50-udev-default.rules:15
IMPORT builtin 'hwdb' returned non-zero
RUN 'kmod load $env{MODALIAS}' /lib/udev/rules.d/80-drivers.rules:5
Execute 'load' 'platform:floppy'
No module matches 'platform:floppy'
passed device to netlink monitor 0x200010ca0c0
seq 419 processed
seq 421 forked new worker [453]
seq 422 queued, 'add' 'serio'
seq 420 running
GROUP 11 /lib/udev/rules.d/40-gentoo.rules:2
GROUP 6 /lib/udev/rules.d/50-udev-default.rules:55
handling device node '/dev/fd0', devnum=b2:0, mode=0660, uid=0, gid=6
set permissions /dev/fd0, 060660, uid=0, gid=6
creating symlink '/dev/block/2:0' to '../fd0'
created empty file '/run/udev/data/b2:0' for 
'/devices/platform/floppy.0/block/fd0'
passed device to netlink monitor 0x200010c7820
seq 420 processed
No module matches 'platform:alarmtimer'
passed device to netlink monitor 0x200010c8c50
seq 418 processed
passed 208 byte device to netlink monitor 0x2000109ffa0
seq 423 queued, 'add' 'serio'
seq 424 queued, 'add' 'platform'
passed 178 byte device to netlink monitor 0x2000109ffa0
seq 425 queued, 'add' 'platform'
seq 425 running
IMPORT builtin 'hwdb' /lib/udev/rules.d/50-udev-default.rules:15
IMPORT builtin 'hwdb' returned non-zero
RUN 'kmod load $env{MODALIAS}' /lib/udev/rules.d/80-drivers.rules:5
Execute 'load' 'platform:rtc-alpha'
No module matches 'platform:rtc-alpha'
passed device to netlink monitor 0x200010c7820
seq 425 processed
seq 424 running
IMPORT builtin 'hwdb' /lib/udev/rules.d/50-udev-default.rules:15
IMPORT builtin 'hwdb' returned non-zero
RUN 'kmod load $env{MODALIAS}' /lib/udev/rules.d/80-drivers.rules:5
Execute 'load' 'platform:pcspkr'
[   29.890609] libata version 3.00 loaded.

passed device to netlink monitor 0x200010c8c50
halted CPU 0

halt code = 5
HALT instruction executed
PC = fc9bf914
boot failure


So maybe it is related pcspkr loading, or the just loaded libata or 
floppy...

-- 
Meelis Roos (mr...@linux.ee)
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html