parisc late boot crash in 4.4-rc, scsi-related

(Try 2, spelling linux-block correctly - please ignore the previous one)

I noticed on RP3440 and A500 that recent 4.4-rc* crashes on boot. The 
following is dmesg that was copied piecewise by hand from ILO console 
log (so it can contain some whitespace damage), from 
4.4.0-rc7-00028-gc616920 on RP3440:

SCSI subsystem initialized
NET: Registered protocol family 2
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
UDP hash table entries: 8192 (order: 6, 262144 bytes)
UDP-Lite hash table entries: 8192 (order: 6, 262144 bytes)
NET: Registered protocol family 1
Chassis warnings not supported.
Performance monitoring counters enabled for Storm Peak Slow
futex hash table entries: 1024 (order: 3, 32768 bytes)
HugeTLB registered 2 MB page size, pre-allocated 0 pages
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
PDC Stable Storage facility v0.30
STI GSC/PCI core graphics driver Version 0.9b
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
0000:e0:01.0: ttyS0 at MMIO 0xfffffffff4051000 (irq = 27, base_baud = 115200) is a 16450
0000:e0:01.1: ttyS1 at MMIO 0xfffffffff4050000 (irq = 27, base_baud = 115200) is a 16550A
console [ttyS1] enabled
console [ttyS1] enabled
bootconsole [ttyB0] disabled
bootconsole [ttyB0] disabled
0000:e0:01.1: ttyS2 at MMIO 0xfffffffff4050010 (irq = 27, base_baud = 115200) is a 16550A
0000:e0:01.1: ttyS3 at MMIO 0xfffffffff4050038 (irq = 27, base_baud = 115200) is a 16550A
sym0: <1010-66> rev 0x1 at pci 0000:20:01.0 irq 22
sym0: No NVRAM, ID 7, Fast-80, LVD, parity checking
sym0: SCSI BUS has been reset.
scsi host0: sym-2.2.3
scsi 0:0:0:0: Direct-Access     COMPAQ   BF07285A36       HPB7 PQ: 0 ANSI: 3
scsi target0:0:0: tagged command queuing enabled, command queue depth 16.

124 more lines

On 08.01.2016 22:30, Meelis Roos wrote:

(Try 2, spelling linux-block correctly - please ignore the previous one)

I noticed on RP3440 and A500 that recent 4.4-rc* crashes on boot.

I've not seen it with 4.4-rc yet, but I've seen it on debian kernel 4.3.3:

[   25.516000] scsi_id(112): unaligned access to 0x00000000facdf009 at ip=0x000000004100390b
[   25.628000] sd 3:0:6:0: [sdb] Attached SCSI disk
[   25.716000] scsi_id(113): unaligned access to 0x00000000fada7009 at ip=0x000000004100390b
[   25.864000] random: nonblocking pool is initialized
[   25.928000] Backtrace:
[   25.928000]  [<000000000046feb8>] scsi_init_sgtable+0x70/0x168 [scsi_mod]
[   25.928000]  [<000000000047001c>] scsi_init_io+0x6c/0x258 [scsi_mod]
[   25.928000]  [<0000000000828f28>] sd_init_command+0x70/0xec8 [sd_mod]
[   25.928000] 
[   25.928000] 
[   25.928000] Bad Address (null pointer deref?): Code=15 regs=00000000bbe69100 (Addr=c00002613ce9de94)
[   25.928000] CPU: 0 PID: 67 Comm: systemd-udevd Not tainted 4.3.0-1-parisc64-smp #1 Debian 4.3.3-4
[   25.928000] task: 00000000bbe67548 ti: 00000000bbe68000 task.ti: 00000000bbe68000
[   25.928000] 
[   25.928000]      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
[   25.928000] PSW: 00001000000001001111111100001110 Not tainted
[   25.928000] r00-03  000000ff0804ff0e 00000000bbe68fd0 000000004043abd8 00000000bbe68fd0
[   25.928000] r04-07  00000000408eea40 0000000000014000 0000000000000000 000000000000001c
[   25.928000] r08-11  0000000000000001 0000000000000000 f4b3d2613ce9de94 00000000bbd94100
[   25.928000] r12-15  00000000000001c0 000000000000000a 0000000000001000 000000007f8c3148
[   25.928000] r16-19  0000000000000000 0000000000001000 0000000041dfa600 0000000000001000
[   25.928000] r20-23  0000000000000000 000000007fabac00 0000000000011000 0000000040987a40
[   25.928000] r24-27  0000000000000000 0000000040e18000 000000007fac1d30 00000000408eea40
[   25.928000] r28-31  f4b3d2613ce9de94 00000000bbe690d0 00000000bbe69100 0000000000000001
[   25.928000] sr00-03  0000000000014000 0000000000000000 0000000000000000 0000000000014000
[   25.928000] sr04-07  0000000000000000 0000000000000000 0000000000000000 0000000000000000
[   25.928000] 
[   25.928000] IASQ: 0000000000000000 0000000000000000 IAOQ: 000000004043abe0 000000004043abe4
[   25.928000]  IIR: 0d4010dc    ISR: 0000000034b3d000  IOR: c00002613ce9de94
[   25.928000]  CPU:        0   CR30: 00000000bbe68000 CR31: 00000000d20345e0
[   25.928000]  ORIG_R28: 0000000000000000
[   25.928000]  IAOQ[0]: blk_rq_map_sg+0x2a0/0x568
[   25.928000]  IAOQ[1]: blk_rq_map_sg+0x2a4/0x568
[   25.928000]  RP(r2): blk_rq_map_sg+0x298/0x568
[   25.928000] Backtrace:
[   25.928000]  [<000000000046feb8>] scsi_init_sgtable+0x70/0x168 [scsi_mod]
[   25.928000]  [<000000000047001c>] scsi_init_io+0x6c/0x258 [scsi_mod]

8 more lines

The 
following is dmesg that was copied piecewise by hand from ILO console 
log (so it can contain some whitespace damage), from 
4.4.0-rc7-00028-gc616920 on RP3440:

SCSI subsystem initialized
NET: Registered protocol family 2
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
UDP hash table entries: 8192 (order: 6, 262144 bytes)
UDP-Lite hash table entries: 8192 (order: 6, 262144 bytes)
NET: Registered protocol family 1
Chassis warnings not supported.
Performance monitoring counters enabled for Storm Peak Slow
futex hash table entries: 1024 (order: 3, 32768 bytes)
HugeTLB registered 2 MB page size, pre-allocated 0 pages
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
PDC Stable Storage facility v0.30
STI GSC/PCI core graphics driver Version 0.9b
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
0000:e0:01.0: ttyS0 at MMIO 0xfffffffff4051000 (irq = 27, base_baud = 115200) is a 16450
0000:e0:01.1: ttyS1 at MMIO 0xfffffffff4050000 (irq = 27, base_baud = 115200) is a 16550A
console [ttyS1] enabled
console [ttyS1] enabled
bootconsole [ttyB0] disabled
bootconsole [ttyB0] disabled
0000:e0:01.1: ttyS2 at MMIO 0xfffffffff4050010 (irq = 27, base_baud = 115200) is a 16550A
0000:e0:01.1: ttyS3 at MMIO 0xfffffffff4050038 (irq = 27, base_baud = 115200) is a 16550A
sym0: <1010-66> rev 0x1 at pci 0000:20:01.0 irq 22
sym0: No NVRAM, ID 7, Fast-80, LVD, parity checking
sym0: SCSI BUS has been reset.
scsi host0: sym-2.2.3
scsi 0:0:0:0: Direct-Access     COMPAQ   BF07285A36       HPB7 PQ: 0 ANSI: 3
scsi target0:0:0: tagged command queuing enabled, command queue depth 16.
scsi target0:0:0: Beginning Domain Validation
scsi target0:0:0: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 31)

120 more quoted lines

quoted

I noticed on RP3440 and A500 that recent 4.4-rc* crashes on boot.

I've not seen it with 4.4-rc yet, but I've seen it on debian kernel 4.3.3:

This is still present in 4.6, just tested. All my pariscs are broken  
- A500, RP3410, RP3440. 4.3 is the latest working release for me. If 
4.3.3 is broken, it might be possible to bisect more easily.

sym0: <1010-66> rev 0x1 at pci 0000:20:01.0 irq 22
sym0: No NVRAM, ID 7, Fast-80, LVD, parity checking
sym0: SCSI BUS has been reset.
scsi host0: sym-2.2.3
scsi 0:0:0:0: Direct-Access     COMPAQ   BF07285A36       HPB7 PQ: 0 ANSI: 3
scsi target0:0:0: tagged command queuing enabled, command queue depth 16.
scsi target0:0:0: Beginning Domain Validation
scsi target0:0:0: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 31)
scsi target0:0:0: Ending Domain Validation
random: nonblocking pool is initialized
sym1: <1010-66> rev 0x1 at pci 0000:20:01.1 irq 23
sym1: No NVRAM, ID 7, Fast-80, LVD, parity checking
sym1: SCSI BUS has been reset.
scsi host1: sym-2.2.3
bioset (67) used greatest stack depth: 13864 bytes left
bioset (82) used greatest stack depth: 13608 bytes left
mousedev: PS/2 mouse device common for all mice
sd 0:0:0:0: [sda] 142264000 512-byte logical blocks: (72.8 GB/67.8 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, supports DPO and FUA
rtc-generic rtc-generic: rtc core: registered rtc-generic as rtc0
NET: Registered protocol family 17
rtc-generic rtc-generic: setting system clock to 2016-05-16 20:41:06 UTC (1463431266)
 sda: sda1 sda2 sda3 sda4
sd 0:0:0:0: [sda] Attached SCSI disk
EXT4-fs (sda3): couldn't mount as ext3 due to feature incompatibilities
EXT4-fs (sda3): couldn't mount as ext2 due to feature incompatibilities
EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: (null)
VFS: Mounted root (ext4 filesystem) readonly on device 8:3.
devtmpfs: mounted
Freeing unused kernel memory: 1024K (0000000040100000 - 0000000040200000)
This architecture does not have kernel memory protection.
------------[ cut here ]------------
WARNING: CPU: 2 PID: 1 at block/blk-merge.c:462 blk_rq_map_sg+0x5d8/0x610
Modules linked in:

97 more lines

On 2016-05-16 4:40 PM, Meelis Roos wrote:

quoted

quoted

I noticed on RP3440 and A500 that recent 4.4-rc* crashes on boot.

I've not seen it with 4.4-rc yet, but I've seen it on debian kernel 4.3.3:

This is still present in 4.6, just tested. All my pariscs are broken
- A500, RP3410, RP3440. 4.3 is the latest working release for me. If
4.3.3 is broken, it might be possible to bisect more easily.

I believe this is fixed in current gcc versions (4.9 and latter). It was exposed by a blk-merge
change.  It was fixed by this change:

2016-03-17  John David Anglin  [off-list ref]

        PR target/70188
        * config/pa/constraints.md: Revert 2015-02-13 change.  Use
        define_constraint for "Q" and "T" constraints.

However, this caused a different problem fixed here:

2016-04-05  John David Anglin  [off-list ref]

        * config/pa/predicates.md (integer_store_memory_operand): Accept
        REG+D operands with a large offset when reload_in_progress is true.
        (floating_point_store_memory_operand): Likewise.

Dave

-- 
John David Anglin  dave.anglin@bell.net

quoted

quoted

quoted

I noticed on RP3440 and A500 that recent 4.4-rc* crashes on boot.

I've not seen it with 4.4-rc yet, but I've seen it on debian kernel
4.3.3:

This is still present in 4.6, just tested. All my pariscs are broken
- A500, RP3410, RP3440. 4.3 is the latest working release for me. If
4.3.3 is broken, it might be possible to bisect more easily.

I believe this is fixed in current gcc versions (4.9 and latter). It was
exposed by a blk-merge
change.  It was fixed by this change:

Out of interest, how do other parisc users get the new compiler?

What distro are you using?

My pariscs are gentoo and still only the old versions are available on 
hppa.

-- 
Meelis Roos (mroos@linux.ee)

On 2016-06-22, at 7:52 AM, Meelis Roos wrote:

quoted

quoted

quoted

quoted

I noticed on RP3440 and A500 that recent 4.4-rc* crashes on boot.

I've not seen it with 4.4-rc yet, but I've seen it on debian kernel
4.3.3:

This is still present in 4.6, just tested. All my pariscs are broken
- A500, RP3410, RP3440. 4.3 is the latest working release for me. If
4.3.3 is broken, it might be possible to bisect more easily.

I believe this is fixed in current gcc versions (4.9 and latter). It was
exposed by a blk-merge
change.  It was fixed by this change:

Out of interest, how do other parisc users get the new compiler?

The Debian binaries have the change.

For development, I get gcc with svn from <https://gcc.gnu.org/>.  It is also possible to
use git to access the sources.

gcc -v should show how your current compiler was built.

What distro are you using?

We are using Debian unstable.  Helge and myself have setup an automated build system
with several buildds.  We are getting reasonable support from package maintainers.

Approximately, 11100 packages are available using apt-get:
https://buildd.debian.org/status/architecture.php?a=hppa&suite=sid
In terms of package counts, we are about equal to alpha, ppc64 and sparc64.

Helge has setup a Debian install disk.  Info on this is here:
https://parisc.wiki.kernel.org/index.php/Main_Page

My pariscs are gentoo and still only the old versions are available on 
hppa.

Hope this helps,
Dave
--
John David Anglin	dave.anglin@bell.net

Am Mittwoch, 22. Juni 2016, 14:52:40 schrieb Meelis Roos:

quoted

quoted

quoted

quoted

I noticed on RP3440 and A500 that recent 4.4-rc* crashes on boot.

I've not seen it with 4.4-rc yet, but I've seen it on debian kernel

quoted

quoted

4.3.3:

This is still present in 4.6, just tested. All my pariscs are broken
- A500, RP3410, RP3440. 4.3 is the latest working release for me. If
4.3.3 is broken, it might be possible to bisect more easily.

I believe this is fixed in current gcc versions (4.9 and latter). It was
exposed by a blk-merge

quoted

change.  It was fixed by this change:

Out of interest, how do other parisc users get the new compiler?

What distro are you using?

My pariscs are gentoo and still only the old versions are available on
hppa.

Several newer versions (4.9, 5.3) are in portage, maybe they just need to be 
unmasked.

Greetings,

Eike

Hi,

On Wed, Jun 22, 2016 at 02:52:40PM +0300, Meelis Roos wrote:

quoted

quoted

quoted

quoted

I noticed on RP3440 and A500 that recent 4.4-rc* crashes on boot.

I've not seen it with 4.4-rc yet, but I've seen it on debian kernel
4.3.3:

This is still present in 4.6, just tested. All my pariscs are broken
- A500, RP3410, RP3440. 4.3 is the latest working release for me. If
4.3.3 is broken, it might be possible to bisect more easily.

I believe this is fixed in current gcc versions (4.9 and latter). It was
exposed by a blk-merge
change.  It was fixed by this change:

Out of interest, how do other parisc users get the new compiler?

What distro are you using?

My pariscs are gentoo and still only the old versions are available on 
hppa.

I compile everything from scratch. Currently using GCC 6.1.

A.

quoted

What distro are you using?

My pariscs are gentoo and still only the old versions are available on
hppa.

Several newer versions (4.9, 5.3) are in portage, maybe they just need to be 
unmasked.

4.9.3 and 5.3.0 were too old.

However, at the end of June, 5.4.0 appeared masked. Unmasking kgcc64 
5.4.0 and building it made my pariscs work again, with 4.7-rc6 running 
fine on all of them.

-- 
Meelis Roos (mroos@linux.ee)

On 2016-07-06 2:59 AM, Meelis Roos wrote:

quoted

quoted

What distro are you using?

My pariscs are gentoo and still only the old versions are available on
hppa.

Several newer versions (4.9, 5.3) are in portage, maybe they just need to be
unmasked.

4.9.3 and 5.3.0 were too old.

Correct.  4.9.4 will include fix if it is released.

However, at the end of June, 5.4.0 appeared masked. Unmasking kgcc64
5.4.0 and building it made my pariscs work again, with 4.7-rc6 running
fine on all of them.

Great!  Thanks for report.

Dave

-- 
John David Anglin  dave.anglin@bell.net