A500 boot crash in 4.2.0-rc3-00246-g763e326

A500 boot crash in 4.2.0-rc3-00246-g763e326

[Meelis Roos]

Tried 4.2.0-rc3-00246-g763e326 on A500 but it crashes on boot. This is 
still present in todays 4.2.0-rc6+git. 4.1 was fine, I Will bisect but 
it takes time.

PDC Stable Storage facility v0.30
STI GSC/PCI core graphics driver Version 0.9b
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
serial 0000:00:04.0: enabling device (0146 -> 0147)
console [ttyS0] disabled
0000:00:04.0: ttyS0 at MMIO 0xfffffffff8000000 (irq = 21, base_baud = 115200) is a 16550A
console [ttyS0] enabled
console [ttyS0] enabled
bootconsole [ttyB0] disabled
bootconsole [ttyB0] disabled
0000:00:04.0: ttyS1 at MMIO 0xfffffffff8000008 (irq = 21, base_baud = 115200) is a 16550A
0000:00:04.0: ttyS2 at MMIO 0xfffffffff8000010 (irq = 21, base_baud = 115200) is a 16550A
serial 0000:00:05.0: enabling device (0000 -> 0003)
serial 0000:00:05.0: enabling SERR and PARITY (0003 -> 0143)
0000:00:05.0: ttyS3 at MMIO 0xfffffffff8003000 (irq = 22, base_baud = 115200) is a 16550A
serial 0000:00:05.0: Couldn't register serial port 0, irq 22, type 2, error -28
sym53c8xx 0000:00:01.0: enabling device (0000 -> 0003)
sym53c8xx 0000:00:01.0: enabling SERR and PARITY (0003 -> 0143)

************* SYSTEM ALERT **************
SYSTEM NAME: a500-m
DATE: 07/26/2015 TIME: 06:06:56
ALERT LEVEL: 7 = reserved

REASON FOR ALERT
SOURCE: 0 = unknown, no source stated
SOURCE DETAIL: 0 = unknown, no source stated   SOURCE ID: FF
PROBLEM DETAIL: 0 = no problem detail

LEDs:  RUN      ATTENTION     FAULT     REMOTE     POWER
       ON       FLASH         OFF       ON         ON
LED State: There was a system interruption that did not take the system 
down.
Check Chassis and Console Logs for error messages.

0x0000007000FF6292 00000000 00000000 - type  0 = Data Field Unused
0x5800087000FF6292 00007306 1A060638 - type 11 = Timestamp 07/26/2015 
06:06:56
A: ack read of this entry - X: Disable all future alert messages
Anything else skip redisplay the log entry
->Choice:a
*****************************************




-- 
Meelis Roos (mroos@linux.ee)

Re: A500 boot crash in 4.2.0-rc3-00246-g763e326

[John David Anglin]

On 2015-08-12, at 4:35 PM, Meelis Roos wrote:

> Tried 4.2.0-rc3-00246-g763e326 on A500 but it crashes on boot. This is 
> still present in todays 4.2.0-rc6+git. 4.1 was fine, I Will bisect but 
> it takes time.

This is probably a hpmc.  Could you look at SL event log?  It should show address of
the hpmc.  Then, look at kernel image with objdump and search for address.  This should
show where crash occurred and it might give a clue as to the cause.

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

Re: A500 boot crash in 4.2.0-rc3-00246-g763e326

[Meelis Roos]

> > Tried 4.2.0-rc3-00246-g763e326 on A500 but it crashes on boot. This is 
> > still present in todays 4.2.0-rc6+git. 4.1 was fine, I Will bisect but 
> > it takes time.
> 
> This is probably a hpmc.  Could you look at SL event log?  It should show address of
> the hpmc.  Then, look at kernel image with objdump and search for address.  This should
> show where crash occurred and it might give a clue as to the cause.

How do I set filters for SL?

-- 
Meelis Roos (mroos@linux.ee)

Re: A500 boot crash in 4.2.0-rc3-00246-g763e326

[John David Anglin]

On 2015-08-13 11:42 AM, Meelis Roos wrote:
>>> Tried 4.2.0-rc3-00246-g763e326 on A500 but it crashes on boot. This is
>>> still present in todays 4.2.0-rc6+git. 4.1 was fine, I Will bisect but
>>> it takes time.
>> This is probably a hpmc.  Could you look at SL event log?  It should show address of
>> the hpmc.  Then, look at kernel image with objdump and search for address.  This should
>> show where crash occurred and it might give a clue as to the cause.
> How do I set filters for SL?
>
I think you need to entry an "E" for event log and just select default 
for filters.

Dave

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

Re: A500 boot crash in 4.2.0-rc3-00246-g763e326

[Meelis Roos]

> > Tried 4.2.0-rc3-00246-g763e326 on A500 but it crashes on boot. This is 
> > still present in todays 4.2.0-rc6+git. 4.1 was fine, I Will bisect but 
> > it takes time.
> 
> This is probably a hpmc.  Could you look at SL event log?  It should show address of
> the hpmc.  Then, look at kernel image with objdump and search for address.  This should
> show where crash occurred and it might give a clue as to the cause.

SL errors from last boot that failed are below - how can I decode it 
further, I find no addresses here? All these errors only happen on 
problematic boot, none of these happen on 4.1.0 boot.

Log Entry #   0 :
SYSTEM NAME: a500-m
DATE: 08/14/2015 TIME: 05:36:18
ALERT LEVEL: 2 = Non-Urgent operator attention required

SOURCE: 8 = I/O 
SOURCE DETAIL: 6 = disk   SOURCE ID: 0
PROBLEM DETAIL: 3 = functional failure

CALLER ACTIVITY: 6 = machine check   STATUS: 0
CALLER SUBACTIVITY: 20 = implementation dependent
REPORTING ENTITY TYPE: 0 = system firmware   REPORTING ENTITY ID: 00

0x0000002386006200 00000000 00000000 type  0 = Data Field Unused
0x5800082386006200 00007307 0E052412 type 11 = Timestamp 08/14/2015 05:36:18


Log Entry #   1 :
SYSTEM NAME: a500-m
DATE: 08/14/2015 TIME: 05:36:18
ALERT LEVEL: 2 = Non-Urgent operator attention required

SOURCE: 8 = I/O 
SOURCE DETAIL: 9 = serial   SOURCE ID: 0
PROBLEM DETAIL: 3 = functional failure

CALLER ACTIVITY: 6 = machine check   STATUS: 0
CALLER SUBACTIVITY: 20 = implementation dependent
REPORTING ENTITY TYPE: 0 = system firmware   REPORTING ENTITY ID: 00

0x0000002389006200 00000000 00000000 type  0 = Data Field Unused
0x5800082389006200 00007307 0E052412 type 11 = Timestamp 08/14/2015 05:36:18

Log Entry #   2 :
SYSTEM NAME: a500-m
DATE: 08/14/2015 TIME: 05:36:17
ALERT LEVEL: 2 = Non-Urgent operator attention required

SOURCE: 8 = I/O 
SOURCE DETAIL: 2 = system bus adapter   SOURCE ID: 6
PROBLEM DETAIL: 3 = function failure

CALLER ACTIVITY: 6 = machine check   STATUS: 3
CALLER SUBACTIVITY: 34 = implementation dependent
REPORTING ENTITY TYPE: 0 = system firmware   REPORTING ENTITY ID: 00

0x7000002382066343 00000000 00070200 type 14 = Problem Detail
0x5800082382066343 00007307 0E052411 type 11 = Timestamp 08/14/2015 05:36:17


Log Entry #   3 :
SYSTEM NAME: a500-m
DATE: 08/14/2015 TIME: 05:36:17
ALERT LEVEL: 2 = Non-Urgent operator attention required

SOURCE: 8 = I/O 
SOURCE DETAIL: 2 = system bus adapter   SOURCE ID: 4
PROBLEM DETAIL: 3 = function failure

CALLER ACTIVITY: 6 = machine check   STATUS: 3
CALLER SUBACTIVITY: 34 = implementation dependent
REPORTING ENTITY TYPE: 0 = system firmware   REPORTING ENTITY ID: 00

0x7000002382046343 00000000 00070200 type 14 = Problem Detail
0x5800082382046343 00007307 0E052411 type 11 = Timestamp 08/14/2015 05:36:17


Log Entry #   4 :
SYSTEM NAME: a500-m
DATE: 08/14/2015 TIME: 05:36:17
ALERT LEVEL: 2 = Non-Urgent operator attention required

SOURCE: 8 = I/O 
SOURCE DETAIL: 2 = system bus adapter   SOURCE ID: 2
PROBLEM DETAIL: 3 = function failure

CALLER ACTIVITY: 6 = machine check   STATUS: 3
CALLER SUBACTIVITY: 34 = implementation dependent
REPORTING ENTITY TYPE: 0 = system firmware   REPORTING ENTITY ID: 00

0x7000002382026343 00000000 00070200 type 14 = Problem Detail
0x5800082382026343 00007307 0E052411 type 11 = Timestamp 08/14/2015 05:36:17


Log Entry #   5 :
SYSTEM NAME: a500-m
DATE: 08/14/2015 TIME: 05:36:17
ALERT LEVEL: 2 = Non-Urgent operator attention required

SOURCE: 8 = I/O 
SOURCE DETAIL: 2 = system bus adapter   SOURCE ID: 0
PROBLEM DETAIL: 3 = function failure

CALLER ACTIVITY: 6 = machine check   STATUS: 3
CALLER SUBACTIVITY: 34 = implementation dependent
REPORTING ENTITY TYPE: 0 = system firmware   REPORTING ENTITY ID: 00

0x7000002382006343 00000000 00070200 type 14 = Problem Detail
0x5800082382006343 00007307 0E052411 type 11 = Timestamp 08/14/2015 05:36:17



Log Entry #   6 :
SYSTEM NAME: a500-m
DATE: 08/14/2015 TIME: 05:36:17
ALERT LEVEL: 2 = Non-Urgent operator attention required

SOURCE: 0 = unknown, no source stated
SOURCE DETAIL: 0 = unknown, no source stated   SOURCE ID: FF
PROBLEM DETAIL: 0 = no problem detail

CALLER ACTIVITY: 6 = machine check   STATUS: 2
CALLER SUBACTIVITY: 40 = implementation dependent
REPORTING ENTITY TYPE: 0 = system firmware   REPORTING ENTITY ID: 00

0x0000002000FF6402 00000000 00000000 type  0 = Data Field Unused
0x5800082000FF6402 00007307 0E052411 type 11 = Timestamp 08/14/2015 05:36:17


Log Entry #   7 :
SYSTEM NAME: a500-m
DATE: 08/14/2015 TIME: 05:36:17
ALERT LEVEL: 2 = Non-Urgent operator attention required

SOURCE: 0 = unknown, no source stated
SOURCE DETAIL: 0 = unknown, no source stated   SOURCE ID: FF
PROBLEM DETAIL: 0 = no problem detail

CALLER ACTIVITY: 6 = machine check   STATUS: 2
CALLER SUBACTIVITY: 45 = implementation dependent
REPORTING ENTITY TYPE: 0 = system firmware   REPORTING ENTITY ID: 00

0x0000002000FF6452 00000000 00000000 type  0 = Data Field Unused
0x5800082000FF6452 00007307 0E052411 type 11 = Timestamp 08/14/2015 05:36:17


Log Entry #   8 :
SYSTEM NAME: a500-m
DATE: 08/14/2015 TIME: 05:36:15
ALERT LEVEL: 2 = Non-Urgent operator attention required

SOURCE: 7 = memory
SOURCE DETAIL: 9 = unexpected   SOURCE ID: 0
PROBLEM DETAIL: 3 = unexpected

CALLER ACTIVITY: 6 = machine check   STATUS: 3
CALLER SUBACTIVITY: 13 = implementation dependent
REPORTING ENTITY TYPE: 0 = system firmware   REPORTING ENTITY ID: 00

0x7000002379006133 C1BFF0FF FED08040 type 14 = Problem Detail
0x5800082379006133 00007307 0E05240F type 11 = Timestamp 08/14/2015 05:36:15


Log Entry #   9 :
SYSTEM NAME: a500-m
DATE: 08/14/2015 TIME: 05:36:15
ALERT LEVEL: 2 = Non-Urgent operator attention required

SOURCE: 7 = memory
SOURCE DETAIL: 0 = unknown, no source stated   SOURCE ID: 0
PROBLEM DETAIL: 0 = no problem detail

CALLER ACTIVITY: 6 = machine check   STATUS: 2
CALLER SUBACTIVITY: 08 = implementation dependent
REPORTING ENTITY TYPE: 0 = system firmware   REPORTING ENTITY ID: 00

0x7000002070006082 00000000 00B92400 type 14 = Problem Detail
0x5800082070006082 00007307 0E05240F type 11 = Timestamp 08/14/2015 05:36:15


Log Entry #  10 :
SYSTEM NAME: a500-m
DATE: 08/14/2015 TIME: 05:36:15
ALERT LEVEL: 2 = Non-Urgent operator attention required

SOURCE: 7 = memory
SOURCE DETAIL: 0 = unknown, no source stated   SOURCE ID: 0
PROBLEM DETAIL: 0 = no problem detail

CALLER ACTIVITY: 6 = machine check   STATUS: 2
CALLER SUBACTIVITY: 06 = implementation dependent
REPORTING ENTITY TYPE: 0 = system firmware   REPORTING ENTITY ID: 00

0x6000002070006062 00000000 00100010 type 12 = Device Status
0x5800082070006062 00007307 0E05240F type 11 = Timestamp 08/14/2015 05:36:15


Log Entry #  11 :
SYSTEM NAME: a500-m
DATE: 08/14/2015 TIME: 05:36:14
ALERT LEVEL: 7 = reserved

SOURCE: 0 = unknown, no source stated
SOURCE DETAIL: 0 = unknown, no source stated   SOURCE ID: FF
PROBLEM DETAIL: 0 = no problem detail

CALLER ACTIVITY: 6 = machine check   STATUS: 2
CALLER SUBACTIVITY: 29 = implementation dependent
REPORTING ENTITY TYPE: 0 = system firmware   REPORTING ENTITY ID: 00

0x0000007000FF6292 00000000 00000000 type  0 = Data Field Unused
0x5800087000FF6292 00007307 0E05240E type 11 = Timestamp 08/14/2015 05:36:14


Log Entry #  12 :
SYSTEM NAME: a500-m
DATE: 08/14/2015 TIME: 05:36:14
ALERT LEVEL: 2 = Non-Urgent operator attention required

SOURCE: 1 = processor
SOURCE DETAIL: 1 = processor general   SOURCE ID: 0
PROBLEM DETAIL: 0 = no problem detail

CALLER ACTIVITY: 6 = machine check   STATUS: 2
CALLER SUBACTIVITY: 31 = implementation dependent
REPORTING ENTITY TYPE: 0 = system firmware   REPORTING ENTITY ID: 00

0x1800002011006312 CB810000 00000000 type  3 = Actual Data
0x5800082011006312 00007307 0E05240E type 11 = Timestamp 08/14/2015 05:36:14


Log Entry #  13 :
SYSTEM NAME: a500-m
DATE: 08/14/2015 TIME: 05:36:14
ALERT LEVEL: 2 = Non-Urgent operator attention required

SOURCE: 0 = unknown, no source stated
SOURCE DETAIL: 0 = unknown, no source stated   SOURCE ID: FF
PROBLEM DETAIL: 0 = no problem detail

CALLER ACTIVITY: 6 = machine check   STATUS: 2
CALLER SUBACTIVITY: 24 = implementation dependent
REPORTING ENTITY TYPE: 0 = system firmware   REPORTING ENTITY ID: 00

0x0000002000FF6242 00000000 00000000 type  0 = Data Field Unused
0x5800082000FF6242 00007307 0E05240E type 11 = Timestamp 08/14/2015 05:36:14




-- 
Meelis Roos (mroos@linux.ee)

Re: A500 boot crash in 4.2.0-rc3-00246-g763e326

[John David Anglin]

On 2015-08-14, at 2:35 AM, Meelis Roos wrote:

> SL errors from last boot that failed are below - how can I decode it 
> further, I find no addresses here? All these errors only happen on 
> problematic boot, none of these happen on 4.1.0 boot.

It's some time since I looked at an A500 long.  On rp3440, there is a text, "T', mode that's
easier for humans.  I usually go to the end of the long with 'L' first.

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

Re: A500 boot crash in 4.2.0-rc3-00246-g763e326

[John David Anglin]

On 2015-08-12, at 4:35 PM, Meelis Roos wrote:

> serial 0000:00:05.0: Couldn't register serial port 0, irq 22, type 2, error -28

There's something wrong here.

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

Re: A500 boot crash in 4.2.0-rc3-00246-g763e326

[Meelis Roos]

> > serial 0000:00:05.0: Couldn't register serial port 0, irq 22, type 2, error -28
> 
> There's something wrong here.

Yes, but this is the same for a working kernel.

-- 
Meelis Roos (mroos@linux.ee)

Aw: A500 boot crash in 4.2.0-rc3-00246-g763e326

[Helge Deller]

> Tried 4.2.0-rc3-00246-g763e326 on A500 but it crashes on boot. This is 
> still present in todays 4.2.0-rc6+git. 4.1 was fine, I Will bisect but 
> it takes time.
> 
> PDC Stable Storage facility v0.30
> STI GSC/PCI core graphics driver Version 0.9b
> Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
> serial 0000:00:04.0: enabling device (0146 -> 0147)
> console [ttyS0] disabled
> 0000:00:04.0: ttyS0 at MMIO 0xfffffffff8000000 (irq = 21, base_baud = 115200) is a 16550A
> console [ttyS0] enabled
> console [ttyS0] enabled
> bootconsole [ttyB0] disabled
> bootconsole [ttyB0] disabled
> 0000:00:04.0: ttyS1 at MMIO 0xfffffffff8000008 (irq = 21, base_baud = 115200) is a 16550A
> 0000:00:04.0: ttyS2 at MMIO 0xfffffffff8000010 (irq = 21, base_baud = 115200) is a 16550A
> serial 0000:00:05.0: enabling device (0000 -> 0003)
> serial 0000:00:05.0: enabling SERR and PARITY (0003 -> 0143)
> 0000:00:05.0: ttyS3 at MMIO 0xfffffffff8003000 (irq = 22, base_baud = 115200) is a 16550A
> serial 0000:00:05.0: Couldn't register serial port 0, irq 22, type 2, error -28
> sym53c8xx 0000:00:01.0: enabling device (0000 -> 0003)
> sym53c8xx 0000:00:01.0: enabling SERR and PARITY (0003 -> 0143)

I'm seeing the same problem on my rp5470 with Kernel 4.2-rc7. My machine just hangs though and doesn't crash.
The same kernel runs fine on a J5000:

[   14.100000] sym0: <896> rev 0x4 at pci 0000:00:0f.0 irq 69
[   14.168000] sym0: PA-RISC Firmware, ID 7, Fast-40, SE, parity checking
[   14.248000] sym0: SCSI BUS has been reset.
[   14.304000] sym0: SCSI BUS mode change from SE to SE.
[   14.304000] sym0: SCSI BUS has been reset.
[   14.416000] scsi host0: sym-2.2.3
[   20.056000] sym1: <896> rev 0x4 at pci 0000:00:0f.1 irq 69
[   20.124000] sym1: PA-RISC Firmware, ID 7, Fast-40, LVD, parity checking
[   20.204000] sym1: SCSI BUS has been reset.
[   20.260000] sym1: SCSI BUS mode change from SE to SE.
[   20.260000] sym1: SCSI BUS has been reset.
[   20.372000] scsi host1: sym-2.2.3
[   22.420000] random: nonblocking pool is initialized
[   24.600000] scsi 1:0:3:0: Direct-Access     SEAGATE  ST118273WC       HP14 PQ: 0 ANSI: 2

Since the J5000 has another SCSI driver, I assume the problem is in changes in the SCSI layer or the sym53c8xx driver.

Helge

Aw: A500 boot crash in 4.2.0-rc3-00246-g763e326

[Helge Deller]

> > Tried 4.2.0-rc3-00246-g763e326 on A500 but it crashes on boot. This is 
> > still present in todays 4.2.0-rc6+git. 4.1 was fine, I Will bisect but 
> > it takes time.
> > 
> > PDC Stable Storage facility v0.30
> > STI GSC/PCI core graphics driver Version 0.9b
> > Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
> > serial 0000:00:04.0: enabling device (0146 -> 0147)
> > console [ttyS0] disabled
> > 0000:00:04.0: ttyS0 at MMIO 0xfffffffff8000000 (irq = 21, base_baud = 115200) is a 16550A
> > console [ttyS0] enabled
> > console [ttyS0] enabled
> > bootconsole [ttyB0] disabled
> > bootconsole [ttyB0] disabled
> > 0000:00:04.0: ttyS1 at MMIO 0xfffffffff8000008 (irq = 21, base_baud = 115200) is a 16550A
> > 0000:00:04.0: ttyS2 at MMIO 0xfffffffff8000010 (irq = 21, base_baud = 115200) is a 16550A
> > serial 0000:00:05.0: enabling device (0000 -> 0003)
> > serial 0000:00:05.0: enabling SERR and PARITY (0003 -> 0143)
> > 0000:00:05.0: ttyS3 at MMIO 0xfffffffff8003000 (irq = 22, base_baud = 115200) is a 16550A
> > serial 0000:00:05.0: Couldn't register serial port 0, irq 22, type 2, error -28
> > sym53c8xx 0000:00:01.0: enabling device (0000 -> 0003)
> > sym53c8xx 0000:00:01.0: enabling SERR and PARITY (0003 -> 0143)
> 
> I'm seeing the same problem on my rp5470 with Kernel 4.2-rc7. My machine just hangs though and doesn't crash.

I did a bisect and commit 3a9ad0b4fdcd57f775d3615004c8c64c021a9e7d ("PCI: Add pci_bus_addr_t") seems to be the culprit:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3a9ad0b4fdcd57f775d3615004c8c64c021a9e7d

Since the patch has "CC: stable@vger.kernel.org  # v3.19+", it might be the reason why you see kernel 3.19 failing too...

Helge

[deller@ls3530 linux-2.6]$ git bisect good v4.1
[deller@ls3530 linux-2.6]$ git bisect bad v4.2-rc3
Bisecting: 6909 revisions left to test after this (roughly 13 steps)
[0db9723cacf4d62bc3685fb15179b39ee4e17679] Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux
[deller@ls3530 linux-2.6]$ git bisect bad 
Bisecting: 3289 revisions left to test after this (roughly 12 steps)
[e3d8238d7f5c3f539a29f5ac596cd342d847e099] Merge tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
[deller@ls3530 linux-2.6]$ git bisect bad 
Bisecting: 1662 revisions left to test after this (roughly 11 steps)
[c70c5fb2b96dae0996fb0877d996458d3ca57eda] Merge tag 'pwm/for-4.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm
[deller@ls3530 linux-2.6]$ git bisect good
Bisecting: 824 revisions left to test after this (roughly 10 steps)
[acd53127c4adbd34570b221e7ea1f7fc94aea923] Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
[deller@ls3530 linux-2.6]$ git bisect bad 
Bisecting: 482 revisions left to test after this (roughly 9 steps)
[cb8a4deaf9b2778653c4391d8ccb24c5ab159f9d] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial
[deller@ls3530 linux-2.6]$ git bisect bad 
Bisecting: 172 revisions left to test after this (roughly 8 steps)
[234a56c80a6aa7a05fec05d8b7184354d8765b48] Merge tag 'hwmon-for-linus-v4.2' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging
[deller@ls3530 linux-2.6]$ git bisect good
Bisecting: 96 revisions left to test after this (roughly 7 steps)
[a394c6a0b361fe7b6ffec0e33e9100db5e777b24] Merge git://git.kernel.org/pub/scm/linux/kernel/git/brodo/pcmcia
[deller@ls3530 linux-2.6]$ git bisect bad 
Bisecting: 42 revisions left to test after this (roughly 5 steps)
[0ff9b9bad66730e8347cb3350c8d3d1b88a21f13] Merge branches 'pci/aspm', 'pci/enumeration', 'pci/hotplug', 'pci/misc', 'pci/msi', 'pci/resource' and 'pci/virtualization' into next
[deller@ls3530 linux-2.6]$ git bisect bad 
Bisecting: 25 revisions left to test after this (roughly 4 steps)
[c6201cd8513db2db54b248a862672849ed9ccb82] PCI/MSI: Remove unused pci_msi_off()
[deller@ls3530 linux-2.6]$ git bisect good
Bisecting: 19 revisions left to test after this (roughly 4 steps)
[0c0cbb6c5a04a169320df1812e58b10362865e95] PCI/ASPM: Simplify Clock Power Management setting
[deller@ls3530 linux-2.6]$ git bisect good
Bisecting: 14 revisions left to test after this (roughly 3 steps)
[a5dd4b4b0570b3bf880d563969b245dfbd170c1e] PCI: pciehp: Wait for hotplug command completion where necessary
[deller@ls3530 linux-2.6]$ git bisect good
Bisecting: 9 revisions left to test after this (roughly 3 steps)
[c0300089fd2dbeebef5ab9b6d66b4e6cedf8500a] PCI: Remove unused pci_scan_bus_parented()
[deller@ls3530 linux-2.6]$ git bisect good
Bisecting: 5 revisions left to test after this (roughly 2 steps)
[917bfd93d3c9c644743940deaf8fe0cff77947eb] ACPI / PCI: Account for ARI in _PRT lookups
[deller@ls3530 linux-2.6]$ git bisect good
Bisecting: 2 revisions left to test after this (roughly 2 steps)
[d59d36a7fce6707acae644621320a75ab93f1856] PCI: Remove unused pcibios_select_root() (again)
[deller@ls3530 linux-2.6]$ git bisect good
Bisecting: 1 revision left to test after this (roughly 1 step)
[3a9ad0b4fdcd57f775d3615004c8c64c021a9e7d] PCI: Add pci_bus_addr_t
[deller@ls3530 linux-2.6]$ git bisect bad 
3a9ad0b4fdcd57f775d3615004c8c64c021a9e7d is the first bad commit
commit 3a9ad0b4fdcd57f775d3615004c8c64c021a9e7d
Author: Yinghai Lu <yinghai@kernel.org>
Date:   Wed May 27 17:23:51 2015 -0700

    PCI: Add pci_bus_addr_t
    
    David Ahern reported that d63e2e1f3df9 ("sparc/PCI: Clip bridge windows
    to fit in upstream windows") fails to boot on sparc/T5-8:
    
      pci 0000:06:00.0: reg 0x184: can't handle BAR above 4GB (bus address 0x110204000)
    
    The problem is that sparc64 assumed that dma_addr_t only needed to hold DMA
    addresses, i.e., bus addresses returned via the DMA API (dma_map_single(),
    etc.), while the PCI core assumed dma_addr_t could hold *any* bus address,
    including raw BAR values.  On sparc64, all DMA addresses fit in 32 bits, so
    dma_addr_t is a 32-bit type.  However, BAR values can be 64 bits wide, so
    they don't fit in a dma_addr_t.  d63e2e1f3df9 added new checking that
    tripped over this mismatch.
    
    Add pci_bus_addr_t, which is wide enough to hold any PCI bus address,
    including both raw BAR values and DMA addresses.  This will be 64 bits
    on 64-bit platforms and on platforms with a 64-bit dma_addr_t.  Then
    dma_addr_t only needs to be wide enough to hold addresses from the DMA API.
    
    [bhelgaas: changelog, bugzilla, Kconfig to ensure pci_bus_addr_t is at
    least as wide as dma_addr_t, documentation]
    Fixes: d63e2e1f3df9 ("sparc/PCI: Clip bridge windows to fit in upstream windows")
    Fixes: 23b13bc76f35 ("PCI: Fail safely if we can't handle BARs larger than 4GB")
    Link: http://lkml.kernel.org/r/CAE9FiQU1gJY1LYrxs+ma5LCTEEe4xmtjRG0aXJ9K_Tsu+m9Wuw@mail.gmail.com
    Link: http://lkml.kernel.org/r/1427857069-6789-1-git-send-email-yinghai@kernel.org
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=96231
    Reported-by: David Ahern <david.ahern@oracle.com>
    Tested-by: David Ahern <david.ahern@oracle.com>
    Signed-off-by: Yinghai Lu <yinghai@kernel.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: David S. Miller <davem@davemloft.net>
    CC: stable@vger.kernel.org  # v3.19+

:040000 040000 ce493c3ad8e7b3e9b1f48f53588880827a48a082 76798494194e545219eb18dbb9f5209e02796820 M      Documentation
:040000 040000 19b4d25aa55534c88947c00c5862baf292f836dd 7adaff85e1fd7b27f053bdbf52d3bf6184a9fa54 M      drivers
:040000 040000 37493ef5238ad154ccad6a184617975e8502730e 93e417046cd848c639c9c4364009224bd4fa0500 M      include

Re: Aw: A500 boot crash in 4.2.0-rc3-00246-g763e326

[Meelis Roos]

(CC-s added)

> > > Tried 4.2.0-rc3-00246-g763e326 on A500 but it crashes on boot. This is 
> > > still present in todays 4.2.0-rc6+git. 4.1 was fine, I Will bisect but 
> > > it takes time.
> > > 
> > > PDC Stable Storage facility v0.30
> > > STI GSC/PCI core graphics driver Version 0.9b
> > > Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
> > > serial 0000:00:04.0: enabling device (0146 -> 0147)
> > > console [ttyS0] disabled
> > > 0000:00:04.0: ttyS0 at MMIO 0xfffffffff8000000 (irq = 21, base_baud = 115200) is a 16550A
> > > console [ttyS0] enabled
> > > console [ttyS0] enabled
> > > bootconsole [ttyB0] disabled
> > > bootconsole [ttyB0] disabled
> > > 0000:00:04.0: ttyS1 at MMIO 0xfffffffff8000008 (irq = 21, base_baud = 115200) is a 16550A
> > > 0000:00:04.0: ttyS2 at MMIO 0xfffffffff8000010 (irq = 21, base_baud = 115200) is a 16550A
> > > serial 0000:00:05.0: enabling device (0000 -> 0003)
> > > serial 0000:00:05.0: enabling SERR and PARITY (0003 -> 0143)
> > > 0000:00:05.0: ttyS3 at MMIO 0xfffffffff8003000 (irq = 22, base_baud = 115200) is a 16550A
> > > serial 0000:00:05.0: Couldn't register serial port 0, irq 22, type 2, error -28
> > > sym53c8xx 0000:00:01.0: enabling device (0000 -> 0003)
> > > sym53c8xx 0000:00:01.0: enabling SERR and PARITY (0003 -> 0143)
> > 
> > I'm seeing the same problem on my rp5470 with Kernel 4.2-rc7. My machine just hangs though and doesn't crash.
> 
> I did a bisect and commit 3a9ad0b4fdcd57f775d3615004c8c64c021a9e7d ("PCI: Add pci_bus_addr_t") seems to be the culprit:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3a9ad0b4fdcd57f775d3615004c8c64c021a9e7d
> 
> Since the patch has "CC: stable@vger.kernel.org  # v3.19+", it might be the reason why you see kernel 3.19 failing too...

I just found the same commit breaking my A500 parisc machine by 
bisecting.

CC: patch author and linux-pci.

-- 
Meelis Roos (mroos@linux.ee)

Re: Aw: A500 boot crash in 4.2.0-rc3-00246-g763e326

[Meelis Roos]

(CC-s added)

> > > Tried 4.2.0-rc3-00246-g763e326 on A500 but it crashes on boot. This is 
> > > still present in todays 4.2.0-rc6+git. 4.1 was fine, I Will bisect but 
> > > it takes time.
> > > 
> > > PDC Stable Storage facility v0.30
> > > STI GSC/PCI core graphics driver Version 0.9b
> > > Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
> > > serial 0000:00:04.0: enabling device (0146 -> 0147)
> > > console [ttyS0] disabled
> > > 0000:00:04.0: ttyS0 at MMIO 0xfffffffff8000000 (irq = 21, base_baud = 115200) is a 16550A
> > > console [ttyS0] enabled
> > > console [ttyS0] enabled
> > > bootconsole [ttyB0] disabled
> > > bootconsole [ttyB0] disabled
> > > 0000:00:04.0: ttyS1 at MMIO 0xfffffffff8000008 (irq = 21, base_baud = 115200) is a 16550A
> > > 0000:00:04.0: ttyS2 at MMIO 0xfffffffff8000010 (irq = 21, base_baud = 115200) is a 16550A
> > > serial 0000:00:05.0: enabling device (0000 -> 0003)
> > > serial 0000:00:05.0: enabling SERR and PARITY (0003 -> 0143)
> > > 0000:00:05.0: ttyS3 at MMIO 0xfffffffff8003000 (irq = 22, base_baud = 115200) is a 16550A
> > > serial 0000:00:05.0: Couldn't register serial port 0, irq 22, type 2, error -28
> > > sym53c8xx 0000:00:01.0: enabling device (0000 -> 0003)
> > > sym53c8xx 0000:00:01.0: enabling SERR and PARITY (0003 -> 0143)
> > 
> > I'm seeing the same problem on my rp5470 with Kernel 4.2-rc7. My machine just hangs though and doesn't crash.
> 
> I did a bisect and commit 3a9ad0b4fdcd57f775d3615004c8c64c021a9e7d ("PCI: Add pci_bus_addr_t") seems to be the culprit:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id:9ad0b4fdcd57f775d3615004c8c64c021a9e7d
> 
> Since the patch has "CC: stable@vger.kernel.org  # v3.19+", it might be the reason why you see kernel 3.19 failing too...

I just found the same commit breaking my A500 parisc machine by 
bisecting.

CC: patch author and linux-pci.

-- 
Meelis Roos (mroos@linux.ee)

Re: Aw: A500 boot crash in 4.2.0-rc3-00246-g763e326

[Helge Deller]

On 18.08.2015 20:44, Meelis Roos wrote:
> (CC-s added)
>
>>>> Tried 4.2.0-rc3-00246-g763e326 on A500 but it crashes on boot. This is
>>>> still present in todays 4.2.0-rc6+git. 4.1 was fine, I Will bisect but
>>>> it takes time.
>>>>
>>>> PDC Stable Storage facility v0.30
>>>> STI GSC/PCI core graphics driver Version 0.9b
>>>> Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
>>>> serial 0000:00:04.0: enabling device (0146 -> 0147)
>>>> console [ttyS0] disabled
>>>> 0000:00:04.0: ttyS0 at MMIO 0xfffffffff8000000 (irq = 21, base_baud = 115200) is a 16550A
>>>> console [ttyS0] enabled
>>>> console [ttyS0] enabled
>>>> bootconsole [ttyB0] disabled
>>>> bootconsole [ttyB0] disabled
>>>> 0000:00:04.0: ttyS1 at MMIO 0xfffffffff8000008 (irq = 21, base_baud = 115200) is a 16550A
>>>> 0000:00:04.0: ttyS2 at MMIO 0xfffffffff8000010 (irq = 21, base_baud = 115200) is a 16550A
>>>> serial 0000:00:05.0: enabling device (0000 -> 0003)
>>>> serial 0000:00:05.0: enabling SERR and PARITY (0003 -> 0143)
>>>> 0000:00:05.0: ttyS3 at MMIO 0xfffffffff8003000 (irq = 22, base_baud = 115200) is a 16550A
>>>> serial 0000:00:05.0: Couldn't register serial port 0, irq 22, type 2, error -28
>>>> sym53c8xx 0000:00:01.0: enabling device (0000 -> 0003)
>>>> sym53c8xx 0000:00:01.0: enabling SERR and PARITY (0003 -> 0143)
>>>
>>> I'm seeing the same problem on my rp5470 with Kernel 4.2-rc7. My machine just hangs though and doesn't crash.
>>
>> I did a bisect and commit 3a9ad0b4fdcd57f775d3615004c8c64c021a9e7d ("PCI: Add pci_bus_addr_t") seems to be the culprit:
>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3a9ad0b4fdcd57f775d3615004c8c64c021a9e7d
>>
>> Since the patch has "CC: stable@vger.kernel.org  # v3.19+", it might be the reason why you see kernel 3.19 failing too...
>
> I just found the same commit breaking my A500 parisc machine by
> bisecting.
>
> CC: patch author and linux-pci.

I think this is the problem:

--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -1,6 +1,10 @@
  #
  # PCI configuration
  #
+config PCI_BUS_ADDR_T_64BIT
+       def_bool y if (ARCH_DMA_ADDR_T_64BIT || 64BIT)
+       depends on PCI


CONFIG_PCI_BUS_ADDR_T_64BIT gets now defined on all 64bit arches.
Then if CONFIG_PCI_BUS_ADDR_T_64BIT is set, in pci_bus_alloc_resource()
64bit address spaces (IORESOURCE_MEM_64) will be enabled which weren't enabled before.

This trivial/temporary hack fixes the problem:

--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -200,7 +200,7 @@ int pci_bus_alloc_resource(struct pci_bus *bus, struct resource *res,
                                           resource_size_t),
                 void *alignf_data)
  {
-#ifdef CONFIG_PCI_BUS_ADDR_T_64BIT
+#if defined(CONFIG_PCI_BUS_ADDR_T_64BIT) && !defined(CONFIG_PARISC)
         int rc;
  
         if (res->flags & IORESOURCE_MEM_64) {


but the real problem is probably, that the sym53c8xx driver or maybe the parisc PCI core code isn't 64bit clean?

I did some more debugging, and on parisc the first hang happens in function sym_check_raid() [called from sym2_probe()]
indrivers/scsi/sym53c8xx_2/sym_glue.c while trying to call readl():
   ram_val = readl(device->s.ramaddr + ram_size - 16);

Helge

Re: Aw: A500 boot crash in 4.2.0-rc3-00246-g763e326

[Helge Deller]

On 18.08.2015 20:44, Meelis Roos wrote:
> (CC-s added)
>
>>>> Tried 4.2.0-rc3-00246-g763e326 on A500 but it crashes on boot. This is
>>>> still present in todays 4.2.0-rc6+git. 4.1 was fine, I Will bisect but
>>>> it takes time.
>>>>
>>>> PDC Stable Storage facility v0.30
>>>> STI GSC/PCI core graphics driver Version 0.9b
>>>> Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
>>>> serial 0000:00:04.0: enabling device (0146 -> 0147)
>>>> console [ttyS0] disabled
>>>> 0000:00:04.0: ttyS0 at MMIO 0xfffffffff8000000 (irq = 21, base_baud = 115200) is a 16550A
>>>> console [ttyS0] enabled
>>>> console [ttyS0] enabled
>>>> bootconsole [ttyB0] disabled
>>>> bootconsole [ttyB0] disabled
>>>> 0000:00:04.0: ttyS1 at MMIO 0xfffffffff8000008 (irq = 21, base_baud = 115200) is a 16550A
>>>> 0000:00:04.0: ttyS2 at MMIO 0xfffffffff8000010 (irq = 21, base_baud = 115200) is a 16550A
>>>> serial 0000:00:05.0: enabling device (0000 -> 0003)
>>>> serial 0000:00:05.0: enabling SERR and PARITY (0003 -> 0143)
>>>> 0000:00:05.0: ttyS3 at MMIO 0xfffffffff8003000 (irq = 22, base_baud = 115200) is a 16550A
>>>> serial 0000:00:05.0: Couldn't register serial port 0, irq 22, type 2, error -28
>>>> sym53c8xx 0000:00:01.0: enabling device (0000 -> 0003)
>>>> sym53c8xx 0000:00:01.0: enabling SERR and PARITY (0003 -> 0143)
>>>
>>> I'm seeing the same problem on my rp5470 with Kernel 4.2-rc7. My machine just hangs though and doesn't crash.
>>
>> I did a bisect and commit 3a9ad0b4fdcd57f775d3615004c8c64c021a9e7d ("PCI: Add pci_bus_addr_t") seems to be the culprit:
>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id:9ad0b4fdcd57f775d3615004c8c64c021a9e7d
>>
>> Since the patch has "CC: stable@vger.kernel.org  # v3.19+", it might be the reason why you see kernel 3.19 failing too...
>
> I just found the same commit breaking my A500 parisc machine by
> bisecting.
>
> CC: patch author and linux-pci.

I think this is the problem:

--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -1,6 +1,10 @@
  #
  # PCI configuration
  #
+config PCI_BUS_ADDR_T_64BIT
+       def_bool y if (ARCH_DMA_ADDR_T_64BIT || 64BIT)
+       depends on PCI


CONFIG_PCI_BUS_ADDR_T_64BIT gets now defined on all 64bit arches.
Then if CONFIG_PCI_BUS_ADDR_T_64BIT is set, in pci_bus_alloc_resource()
64bit address spaces (IORESOURCE_MEM_64) will be enabled which weren't enabled before.

This trivial/temporary hack fixes the problem:

--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -200,7 +200,7 @@ int pci_bus_alloc_resource(struct pci_bus *bus, struct resource *res,
                                           resource_size_t),
                 void *alignf_data)
  {
-#ifdef CONFIG_PCI_BUS_ADDR_T_64BIT
+#if defined(CONFIG_PCI_BUS_ADDR_T_64BIT) && !defined(CONFIG_PARISC)
         int rc;
  
         if (res->flags & IORESOURCE_MEM_64) {


but the real problem is probably, that the sym53c8xx driver or maybe the parisc PCI core code isn't 64bit clean?

I did some more debugging, and on parisc the first hang happens in function sym_check_raid() [called from sym2_probe()]
indrivers/scsi/sym53c8xx_2/sym_glue.c while trying to call readl():
   ram_val = readl(device->s.ramaddr + ram_size - 16);

Helge

Re: Aw: A500 boot crash in 4.2.0-rc3-00246-g763e326

[Yinghai Lu]

On Tue, Aug 18, 2015 at 12:47 PM, Helge Deller <deller@gmx.de> wrote:
> On 18.08.2015 20:44, Meelis Roos wrote:
>>> I did a bisect and commit 3a9ad0b4fdcd57f775d3615004c8c64c021a9e7d ("PCI:
>>> Add pci_bus_addr_t") seems to be the culprit:
>>>
>>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3a9ad0b4fdcd57f775d3615004c8c64c021a9e7d
>>
>> CC: patch author and linux-pci.
>
>
> I think this is the problem:
>
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -1,6 +1,10 @@
>  #
>  # PCI configuration
>  #
> +config PCI_BUS_ADDR_T_64BIT
> +       def_bool y if (ARCH_DMA_ADDR_T_64BIT || 64BIT)
> +       depends on PCI

Thanks for bisecting.

Then we should change to

config PCI_BUS_ADDR_T_64BIT
       def_bool y if (ARCH_DMA_ADDR_T_64BIT || SPARC64)
       depends on PCI

Re: Aw: A500 boot crash in 4.2.0-rc3-00246-g763e326

[Yinghai Lu]

On Tue, Aug 18, 2015 at 12:47 PM, Helge Deller <deller@gmx.de> wrote:
> On 18.08.2015 20:44, Meelis Roos wrote:
>>> I did a bisect and commit 3a9ad0b4fdcd57f775d3615004c8c64c021a9e7d ("PCI:
>>> Add pci_bus_addr_t") seems to be the culprit:
>>>
>>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id:9ad0b4fdcd57f775d3615004c8c64c021a9e7d
>>
>> CC: patch author and linux-pci.
>
>
> I think this is the problem:
>
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -1,6 +1,10 @@
>  #
>  # PCI configuration
>  #
> +config PCI_BUS_ADDR_T_64BIT
> +       def_bool y if (ARCH_DMA_ADDR_T_64BIT || 64BIT)
> +       depends on PCI

Thanks for bisecting.

Then we should change to

config PCI_BUS_ADDR_T_64BIT
       def_bool y if (ARCH_DMA_ADDR_T_64BIT || SPARC64)
       depends on PCI

Re: Aw: A500 boot crash in 4.2.0-rc3-00246-g763e326

[Meelis Roos]

> On Tue, Aug 18, 2015 at 12:47 PM, Helge Deller <deller@gmx.de> wrote:
> > On 18.08.2015 20:44, Meelis Roos wrote:
> >>> I did a bisect and commit 3a9ad0b4fdcd57f775d3615004c8c64c021a9e7d ("PCI:
> >>> Add pci_bus_addr_t") seems to be the culprit:
> >>>
> >>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3a9ad0b4fdcd57f775d3615004c8c64c021a9e7d
> >>
> >> CC: patch author and linux-pci.
> >
> >
> > I think this is the problem:
> >
> > --- a/drivers/pci/Kconfig
> > +++ b/drivers/pci/Kconfig
> > @@ -1,6 +1,10 @@
> >  #
> >  # PCI configuration
> >  #
> > +config PCI_BUS_ADDR_T_64BIT
> > +       def_bool y if (ARCH_DMA_ADDR_T_64BIT || 64BIT)
> > +       depends on PCI
> 
> Thanks for bisecting.
> 
> Then we should change to
> 
> config PCI_BUS_ADDR_T_64BIT
>        def_bool y if (ARCH_DMA_ADDR_T_64BIT || SPARC64)
>        depends on PCI

Why SPARC64? The problem happened on parisc.

-- 
Meelis Roos (mroos@linux.ee)

Re: Aw: A500 boot crash in 4.2.0-rc3-00246-g763e326

[Meelis Roos]

> On Tue, Aug 18, 2015 at 12:47 PM, Helge Deller <deller@gmx.de> wrote:
> > On 18.08.2015 20:44, Meelis Roos wrote:
> >>> I did a bisect and commit 3a9ad0b4fdcd57f775d3615004c8c64c021a9e7d ("PCI:
> >>> Add pci_bus_addr_t") seems to be the culprit:
> >>>
> >>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id:9ad0b4fdcd57f775d3615004c8c64c021a9e7d
> >>
> >> CC: patch author and linux-pci.
> >
> >
> > I think this is the problem:
> >
> > --- a/drivers/pci/Kconfig
> > +++ b/drivers/pci/Kconfig
> > @@ -1,6 +1,10 @@
> >  #
> >  # PCI configuration
> >  #
> > +config PCI_BUS_ADDR_T_64BIT
> > +       def_bool y if (ARCH_DMA_ADDR_T_64BIT || 64BIT)
> > +       depends on PCI
> 
> Thanks for bisecting.
> 
> Then we should change to
> 
> config PCI_BUS_ADDR_T_64BIT
>        def_bool y if (ARCH_DMA_ADDR_T_64BIT || SPARC64)
>        depends on PCI

Why SPARC64? The problem happened on parisc.

-- 
Meelis Roos (mroos@linux.ee)

Re: Aw: A500 boot crash in 4.2.0-rc3-00246-g763e326

[Yinghai Lu]

On Tue, Aug 18, 2015 at 9:48 PM, Meelis Roos <mroos@linux.ee> wrote:
>> On Tue, Aug 18, 2015 at 12:47 PM, Helge Deller <deller@gmx.de> wrote:
>>
>> Then we should change to
>>
>> config PCI_BUS_ADDR_T_64BIT
>>        def_bool y if (ARCH_DMA_ADDR_T_64BIT || SPARC64)
>>        depends on PCI
>
> Why SPARC64? The problem happened on parisc.
>

so will not set PCI_BUS_ADDR_T_64BIT for parisc.

Re: Aw: A500 boot crash in 4.2.0-rc3-00246-g763e326

[Yinghai Lu]

On Tue, Aug 18, 2015 at 9:48 PM, Meelis Roos <mroos@linux.ee> wrote:
>> On Tue, Aug 18, 2015 at 12:47 PM, Helge Deller <deller@gmx.de> wrote:
>>
>> Then we should change to
>>
>> config PCI_BUS_ADDR_T_64BIT
>>        def_bool y if (ARCH_DMA_ADDR_T_64BIT || SPARC64)
>>        depends on PCI
>
> Why SPARC64? The problem happened on parisc.
>

so will not set PCI_BUS_ADDR_T_64BIT for parisc.

Re: Aw: A500 boot crash in 4.2.0-rc3-00246-g763e326

[John David Anglin]

On 2015-08-19, at 1:30 AM, Yinghai Lu wrote:

> On Tue, Aug 18, 2015 at 9:48 PM, Meelis Roos <mroos@linux.ee> wrote:
>>> On Tue, Aug 18, 2015 at 12:47 PM, Helge Deller <deller@gmx.de> wrote:
>>> 
>>> Then we should change to
>>> 
>>> config PCI_BUS_ADDR_T_64BIT
>>>       def_bool y if (ARCH_DMA_ADDR_T_64BIT || SPARC64)
>>>       depends on PCI
>> 
>> Why SPARC64? The problem happened on parisc.
>> 
> 
> so will not set PCI_BUS_ADDR_T_64BIT for parisc.

I'm not sure this is optimal.  While the A500 may only have 32-bit PCI, c8000 appears to have a mix
of 32 and 64-bit, and rp34XX is all 64-bit.

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

Re: Aw: A500 boot crash in 4.2.0-rc3-00246-g763e326

[John David Anglin]

On 2015-08-19, at 1:30 AM, Yinghai Lu wrote:

> On Tue, Aug 18, 2015 at 9:48 PM, Meelis Roos <mroos@linux.ee> wrote:
>>> On Tue, Aug 18, 2015 at 12:47 PM, Helge Deller <deller@gmx.de> wrote:
>>> 
>>> Then we should change to
>>> 
>>> config PCI_BUS_ADDR_T_64BIT
>>>       def_bool y if (ARCH_DMA_ADDR_T_64BIT || SPARC64)
>>>       depends on PCI
>> 
>> Why SPARC64? The problem happened on parisc.
>> 
> 
> so will not set PCI_BUS_ADDR_T_64BIT for parisc.

I'm not sure this is optimal.  While the A500 may only have 32-bit PCI, c8000 appears to have a mix
of 32 and 64-bit, and rp34XX is all 64-bit.

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

Aw: Re: A500 boot crash in 4.2.0-rc3-00246-g763e326

[Helge Deller]

> On 2015-08-19, at 1:30 AM, Yinghai Lu wrote:
> > On Tue, Aug 18, 2015 at 9:48 PM, Meelis Roos <mroos@linux.ee> wrote:
> >>> On Tue, Aug 18, 2015 at 12:47 PM, Helge Deller <deller@gmx.de> wrote:
> >>> 
> >>> Then we should change to
> >>> 
> >>> config PCI_BUS_ADDR_T_64BIT
> >>>       def_bool y if (ARCH_DMA_ADDR_T_64BIT || SPARC64)
> >>>       depends on PCI
> >> 
> >> Why SPARC64? The problem happened on parisc.
> > so will not set PCI_BUS_ADDR_T_64BIT for parisc.

I think given the current time frame it's probably the best approach to fix this problem for kernel 4.2.
It reverts the behaviour back to how it was before (for all arches beside SPARC64).
I'm still wondering if/why parisc is the only arch (in the sym53c8xx driver only!) which broke by this change...

> I'm not sure this is optimal.  While the A500 may only have 32-bit PCI, c8000 appears to have a mix
> of 32 and 64-bit, and rp34XX is all 64-bit.

True, but probably nobody of us noticed that we only used the 32-bit PCI interface even with 64bit kernel on parisc up to now?
pci_bus_alloc_resource() in drivers/pci/bus.c just disabled (flag=0) all 64bit resources for us.
But I agree, I think we need to fix drivers/parisc/lba_pci.c to correctly cope with 64bit pci addresses.

In the meantime I did some more debugging on sym_iomap_device() in drivers/scsi/sym53c8xx_2/sym_glue.c:
   pcibios_resource_to_bus(pdev->bus, &bus_addr,
                          &pdev->resource[i]);
   ram_base = bus_addr.start;

with (working) 32bit PCI addresses I get:
ressource = [mem 0xffffffff80002000-0xffffffff80003fff 64bit]
and pcibios_resource_to_bus() returning: ram_base = 0x80002000 

and with (failing) 64bit PCI addresses I get:
ressource = [mem 0xfffffff004000000-0xfffffff004001fff 64bit]
and pcibios_resource_to_bus() returning: ram_base = 0xfffffff004000000 

It seems the resource window doesn't get initialized correctly for 64bit...

Helge

Aw: Re: A500 boot crash in 4.2.0-rc3-00246-g763e326

[Helge Deller]

> On 2015-08-19, at 1:30 AM, Yinghai Lu wrote:
> > On Tue, Aug 18, 2015 at 9:48 PM, Meelis Roos <mroos@linux.ee> wrote:
> >>> On Tue, Aug 18, 2015 at 12:47 PM, Helge Deller <deller@gmx.de> wrote:
> >>> 
> >>> Then we should change to
> >>> 
> >>> config PCI_BUS_ADDR_T_64BIT
> >>>       def_bool y if (ARCH_DMA_ADDR_T_64BIT || SPARC64)
> >>>       depends on PCI
> >> 
> >> Why SPARC64? The problem happened on parisc.
> > so will not set PCI_BUS_ADDR_T_64BIT for parisc.

I think given the current time frame it's probably the best approach to fix this problem for kernel 4.2.
It reverts the behaviour back to how it was before (for all arches beside SPARC64).
I'm still wondering if/why parisc is the only arch (in the sym53c8xx driver only!) which broke by this change...

> I'm not sure this is optimal.  While the A500 may only have 32-bit PCI, c8000 appears to have a mix
> of 32 and 64-bit, and rp34XX is all 64-bit.

True, but probably nobody of us noticed that we only used the 32-bit PCI interface even with 64bit kernel on parisc up to now?
pci_bus_alloc_resource() in drivers/pci/bus.c just disabled (flag=0) all 64bit resources for us.
But I agree, I think we need to fix drivers/parisc/lba_pci.c to correctly cope with 64bit pci addresses.

In the meantime I did some more debugging on sym_iomap_device() in drivers/scsi/sym53c8xx_2/sym_glue.c:
   pcibios_resource_to_bus(pdev->bus, &bus_addr,
                          &pdev->resource[i]);
   ram_base = bus_addr.start;

with (working) 32bit PCI addresses I get:
ressource = [mem 0xffffffff80002000-0xffffffff80003fff 64bit]
and pcibios_resource_to_bus() returning: ram_base = 0x80002000 

and with (failing) 64bit PCI addresses I get:
ressource = [mem 0xfffffff004000000-0xfffffff004001fff 64bit]
and pcibios_resource_to_bus() returning: ram_base = 0xfffffff004000000 

It seems the resource window doesn't get initialized correctly for 64bit...

Helge

Re: Re: A500 boot crash in 4.2.0-rc3-00246-g763e326

[Bjorn Helgaas]

On Wed, Aug 19, 2015 at 04:06:38PM +0200, Helge Deller wrote:
> > On 2015-08-19, at 1:30 AM, Yinghai Lu wrote:
> > > On Tue, Aug 18, 2015 at 9:48 PM, Meelis Roos <mroos@linux.ee> wrote:
> > >>> On Tue, Aug 18, 2015 at 12:47 PM, Helge Deller <deller@gmx.de> wrote:
> > >>> 
> > >>> Then we should change to
> > >>> 
> > >>> config PCI_BUS_ADDR_T_64BIT
> > >>>       def_bool y if (ARCH_DMA_ADDR_T_64BIT || SPARC64)
> > >>>       depends on PCI
> > >> 
> > >> Why SPARC64? The problem happened on parisc.
> > > so will not set PCI_BUS_ADDR_T_64BIT for parisc.
> 
> I think given the current time frame it's probably the best approach to fix this problem for kernel 4.2.
> It reverts the behaviour back to how it was before (for all arches beside SPARC64).
> I'm still wondering if/why parisc is the only arch (in the sym53c8xx driver only!) which broke by this change...
> 
> > I'm not sure this is optimal.  While the A500 may only have 32-bit PCI, c8000 appears to have a mix
> > of 32 and 64-bit, and rp34XX is all 64-bit.
> 
> True, but probably nobody of us noticed that we only used the 32-bit PCI interface even with 64bit kernel on parisc up to now?
> pci_bus_alloc_resource() in drivers/pci/bus.c just disabled (flag=0) all 64bit resources for us.
> But I agree, I think we need to fix drivers/parisc/lba_pci.c to correctly cope with 64bit pci addresses.

I doubt we can fix the underlying issue before v4.2, but I'd at least
like to avoid it.  I applied the patch below to for-linus.

Yinghai proposed this:

> > >>>       def_bool y if (ARCH_DMA_ADDR_T_64BIT || SPARC64)

I did this instead:

+	def_bool y if (ARCH_DMA_ADDR_T_64BIT || (64BIT && !PARISC))

because (a) Yinghai's proposal suggests this change is related to
SPARC64, which is misleading, and (b) I want to keep 64-bit bus
addresses for all 64-bit kernels *except* PA-RISC.

I didn't mark it as Tested-by Meelis because I think he tested
Yinghai's proposal.  But I can add that back, given confirmation.


commit 51a660a2732c
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Thu Aug 20 00:08:15 2015 -0500

    PCI: Don't use 64-bit bus addresses on PA-RISC
    
    Meelis and Helge reported that 3a9ad0b4fdcd ("PCI: Add pci_bus_addr_t")
    caused HPMCs on A500 and hangs on rp5470.
    
    PA-RISC does not set ARCH_DMA_ADDR_T_64BIT, even for 64-bit kernels, so
    prior to 3a9ad0b4fdcd, we always used 32-bit PCI addresses.  After
    3a9ad0b4fdcd, we do use 64-bit PCI addresses in 64-bit kernels, and
    apparently there's some PA-RISC problem related to them.
    
    Fixes: 3a9ad0b4fdcd ("PCI: Add pci_bus_addr_t")
    Link: http://lkml.kernel.org/r/alpine.LRH.2.11.1507260929000.30065@math.ut.ee
    Reported-by: Meelis Roos <mroos@linux.ee>
    Reported-by: Helge Deller <deller@gmx.de>
    Based-on-idea-by: Yinghai Lu <yinghai@kernel.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 73de4ef..944f500 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -2,7 +2,7 @@
 # PCI configuration
 #
 config PCI_BUS_ADDR_T_64BIT
-	def_bool y if (ARCH_DMA_ADDR_T_64BIT || 64BIT)
+	def_bool y if (ARCH_DMA_ADDR_T_64BIT || (64BIT && !PARISC))
 	depends on PCI
 
 config PCI_MSI

Re: Re: A500 boot crash in 4.2.0-rc3-00246-g763e326

[Bjorn Helgaas]

On Wed, Aug 19, 2015 at 04:06:38PM +0200, Helge Deller wrote:
> > On 2015-08-19, at 1:30 AM, Yinghai Lu wrote:
> > > On Tue, Aug 18, 2015 at 9:48 PM, Meelis Roos <mroos@linux.ee> wrote:
> > >>> On Tue, Aug 18, 2015 at 12:47 PM, Helge Deller <deller@gmx.de> wrote:
> > >>> 
> > >>> Then we should change to
> > >>> 
> > >>> config PCI_BUS_ADDR_T_64BIT
> > >>>       def_bool y if (ARCH_DMA_ADDR_T_64BIT || SPARC64)
> > >>>       depends on PCI
> > >> 
> > >> Why SPARC64? The problem happened on parisc.
> > > so will not set PCI_BUS_ADDR_T_64BIT for parisc.
> 
> I think given the current time frame it's probably the best approach to fix this problem for kernel 4.2.
> It reverts the behaviour back to how it was before (for all arches beside SPARC64).
> I'm still wondering if/why parisc is the only arch (in the sym53c8xx driver only!) which broke by this change...
> 
> > I'm not sure this is optimal.  While the A500 may only have 32-bit PCI, c8000 appears to have a mix
> > of 32 and 64-bit, and rp34XX is all 64-bit.
> 
> True, but probably nobody of us noticed that we only used the 32-bit PCI interface even with 64bit kernel on parisc up to now?
> pci_bus_alloc_resource() in drivers/pci/bus.c just disabled (flag=0) all 64bit resources for us.
> But I agree, I think we need to fix drivers/parisc/lba_pci.c to correctly cope with 64bit pci addresses.

I doubt we can fix the underlying issue before v4.2, but I'd at least
like to avoid it.  I applied the patch below to for-linus.

Yinghai proposed this:

> > >>>       def_bool y if (ARCH_DMA_ADDR_T_64BIT || SPARC64)

I did this instead:

+	def_bool y if (ARCH_DMA_ADDR_T_64BIT || (64BIT && !PARISC))

because (a) Yinghai's proposal suggests this change is related to
SPARC64, which is misleading, and (b) I want to keep 64-bit bus
addresses for all 64-bit kernels *except* PA-RISC.

I didn't mark it as Tested-by Meelis because I think he tested
Yinghai's proposal.  But I can add that back, given confirmation.


commit 51a660a2732c
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Thu Aug 20 00:08:15 2015 -0500

    PCI: Don't use 64-bit bus addresses on PA-RISC
    
    Meelis and Helge reported that 3a9ad0b4fdcd ("PCI: Add pci_bus_addr_t")
    caused HPMCs on A500 and hangs on rp5470.
    
    PA-RISC does not set ARCH_DMA_ADDR_T_64BIT, even for 64-bit kernels, so
    prior to 3a9ad0b4fdcd, we always used 32-bit PCI addresses.  After
    3a9ad0b4fdcd, we do use 64-bit PCI addresses in 64-bit kernels, and
    apparently there's some PA-RISC problem related to them.
    
    Fixes: 3a9ad0b4fdcd ("PCI: Add pci_bus_addr_t")
    Link: http://lkml.kernel.org/r/alpine.LRH.2.11.1507260929000.30065@math.ut.ee
    Reported-by: Meelis Roos <mroos@linux.ee>
    Reported-by: Helge Deller <deller@gmx.de>
    Based-on-idea-by: Yinghai Lu <yinghai@kernel.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 73de4ef..944f500 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -2,7 +2,7 @@
 # PCI configuration
 #
 config PCI_BUS_ADDR_T_64BIT
-	def_bool y if (ARCH_DMA_ADDR_T_64BIT || 64BIT)
+	def_bool y if (ARCH_DMA_ADDR_T_64BIT || (64BIT && !PARISC))
 	depends on PCI
 
 config PCI_MSI

Re: A500 boot crash in 4.2.0-rc3-00246-g763e326

[Helge Deller]

On 20.08.2015 07:42, Bjorn Helgaas wrote:
> On Wed, Aug 19, 2015 at 04:06:38PM +0200, Helge Deller wrote:
>>> On 2015-08-19, at 1:30 AM, Yinghai Lu wrote:
>>>> On Tue, Aug 18, 2015 at 9:48 PM, Meelis Roos <mroos@linux.ee> wrote:
>>>>>> On Tue, Aug 18, 2015 at 12:47 PM, Helge Deller <deller@gmx.de> wrote:
>>>>>>
>>>>>> Then we should change to
>>>>>>
>>>>>> config PCI_BUS_ADDR_T_64BIT
>>>>>>        def_bool y if (ARCH_DMA_ADDR_T_64BIT || SPARC64)
>>>>>>        depends on PCI
>>>>>
>>>>> Why SPARC64? The problem happened on parisc.
>>>> so will not set PCI_BUS_ADDR_T_64BIT for parisc.
>>
>> I think given the current time frame it's probably the best approach to fix this problem for kernel 4.2.
>> It reverts the behaviour back to how it was before (for all arches beside SPARC64).
>> I'm still wondering if/why parisc is the only arch (in the sym53c8xx driver only!) which broke by this change...
>>
>>> I'm not sure this is optimal.  While the A500 may only have 32-bit PCI, c8000 appears to have a mix
>>> of 32 and 64-bit, and rp34XX is all 64-bit.
>>
>> True, but probably nobody of us noticed that we only used the 32-bit PCI interface even with 64bit kernel on parisc up to now?
>> pci_bus_alloc_resource() in drivers/pci/bus.c just disabled (flag=0) all 64bit resources for us.
>> But I agree, I think we need to fix drivers/parisc/lba_pci.c to correctly cope with 64bit pci addresses.
>
> I doubt we can fix the underlying issue before v4.2,

Agreed.

> but I'd at least like to avoid it.  I applied the patch below to
> for-linus.
>
> Yinghai proposed this:
>
>>>>>>        def_bool y if (ARCH_DMA_ADDR_T_64BIT || SPARC64)
>
> I did this instead:
>
> +	def_bool y if (ARCH_DMA_ADDR_T_64BIT || (64BIT && !PARISC))
>
> because (a) Yinghai's proposal suggests this change is related to
> SPARC64, which is misleading, and (b) I want to keep 64-bit bus
> addresses for all 64-bit kernels *except* PA-RISC.

Ok.
  
> I didn't mark it as Tested-by Meelis because I think he tested
> Yinghai's proposal.  But I can add that back, given confirmation.
>
>
> commit 51a660a2732c
> Author: Bjorn Helgaas <bhelgaas@google.com>
> Date:   Thu Aug 20 00:08:15 2015 -0500
>
>      PCI: Don't use 64-bit bus addresses on PA-RISC
>
>      Meelis and Helge reported that 3a9ad0b4fdcd ("PCI: Add pci_bus_addr_t")
>      caused HPMCs on A500 and hangs on rp5470.
>
>      PA-RISC does not set ARCH_DMA_ADDR_T_64BIT, even for 64-bit kernels, so
>      prior to 3a9ad0b4fdcd, we always used 32-bit PCI addresses.  After
>      3a9ad0b4fdcd, we do use 64-bit PCI addresses in 64-bit kernels, and
>      apparently there's some PA-RISC problem related to them.
>
>      Fixes: 3a9ad0b4fdcd ("PCI: Add pci_bus_addr_t")
>      Link: http://lkml.kernel.org/r/alpine.LRH.2.11.1507260929000.30065@math.ut.ee
>      Reported-by: Meelis Roos <mroos@linux.ee>
>      Reported-by: Helge Deller <deller@gmx.de>
>      Based-on-idea-by: Yinghai Lu <yinghai@kernel.org>
>      Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Looks OK. I will test later today.

Can you please add
  CC: stable@vger.kernel.org  # v3.19+
since commit 3a9ad0b4fdcd had that too and now all kernels down to 3.19+ are
broken on parisc...

Thanks!
Helge  
  
> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> index 73de4ef..944f500 100644
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -2,7 +2,7 @@
>   # PCI configuration
>   #
>   config PCI_BUS_ADDR_T_64BIT
> -	def_bool y if (ARCH_DMA_ADDR_T_64BIT || 64BIT)
> +	def_bool y if (ARCH_DMA_ADDR_T_64BIT || (64BIT && !PARISC))
>   	depends on PCI
>
>   config PCI_MSI

Re: A500 boot crash in 4.2.0-rc3-00246-g763e326

[Helge Deller]

On 20.08.2015 07:42, Bjorn Helgaas wrote:
> On Wed, Aug 19, 2015 at 04:06:38PM +0200, Helge Deller wrote:
>>> On 2015-08-19, at 1:30 AM, Yinghai Lu wrote:
>>>> On Tue, Aug 18, 2015 at 9:48 PM, Meelis Roos <mroos@linux.ee> wrote:
>>>>>> On Tue, Aug 18, 2015 at 12:47 PM, Helge Deller <deller@gmx.de> wrote:
>>>>>>
>>>>>> Then we should change to
>>>>>>
>>>>>> config PCI_BUS_ADDR_T_64BIT
>>>>>>        def_bool y if (ARCH_DMA_ADDR_T_64BIT || SPARC64)
>>>>>>        depends on PCI
>>>>>
>>>>> Why SPARC64? The problem happened on parisc.
>>>> so will not set PCI_BUS_ADDR_T_64BIT for parisc.
>>
>> I think given the current time frame it's probably the best approach to fix this problem for kernel 4.2.
>> It reverts the behaviour back to how it was before (for all arches beside SPARC64).
>> I'm still wondering if/why parisc is the only arch (in the sym53c8xx driver only!) which broke by this change...
>>
>>> I'm not sure this is optimal.  While the A500 may only have 32-bit PCI, c8000 appears to have a mix
>>> of 32 and 64-bit, and rp34XX is all 64-bit.
>>
>> True, but probably nobody of us noticed that we only used the 32-bit PCI interface even with 64bit kernel on parisc up to now?
>> pci_bus_alloc_resource() in drivers/pci/bus.c just disabled (flag=0) all 64bit resources for us.
>> But I agree, I think we need to fix drivers/parisc/lba_pci.c to correctly cope with 64bit pci addresses.
>
> I doubt we can fix the underlying issue before v4.2,

Agreed.

> but I'd at least like to avoid it.  I applied the patch below to
> for-linus.
>
> Yinghai proposed this:
>
>>>>>>        def_bool y if (ARCH_DMA_ADDR_T_64BIT || SPARC64)
>
> I did this instead:
>
> +	def_bool y if (ARCH_DMA_ADDR_T_64BIT || (64BIT && !PARISC))
>
> because (a) Yinghai's proposal suggests this change is related to
> SPARC64, which is misleading, and (b) I want to keep 64-bit bus
> addresses for all 64-bit kernels *except* PA-RISC.

Ok.
  
> I didn't mark it as Tested-by Meelis because I think he tested
> Yinghai's proposal.  But I can add that back, given confirmation.
>
>
> commit 51a660a2732c
> Author: Bjorn Helgaas <bhelgaas@google.com>
> Date:   Thu Aug 20 00:08:15 2015 -0500
>
>      PCI: Don't use 64-bit bus addresses on PA-RISC
>
>      Meelis and Helge reported that 3a9ad0b4fdcd ("PCI: Add pci_bus_addr_t")
>      caused HPMCs on A500 and hangs on rp5470.
>
>      PA-RISC does not set ARCH_DMA_ADDR_T_64BIT, even for 64-bit kernels, so
>      prior to 3a9ad0b4fdcd, we always used 32-bit PCI addresses.  After
>      3a9ad0b4fdcd, we do use 64-bit PCI addresses in 64-bit kernels, and
>      apparently there's some PA-RISC problem related to them.
>
>      Fixes: 3a9ad0b4fdcd ("PCI: Add pci_bus_addr_t")
>      Link: http://lkml.kernel.org/r/alpine.LRH.2.11.1507260929000.30065@math.ut.ee
>      Reported-by: Meelis Roos <mroos@linux.ee>
>      Reported-by: Helge Deller <deller@gmx.de>
>      Based-on-idea-by: Yinghai Lu <yinghai@kernel.org>
>      Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Looks OK. I will test later today.

Can you please add
  CC: stable@vger.kernel.org  # v3.19+
since commit 3a9ad0b4fdcd had that too and now all kernels down to 3.19+ are
broken on parisc...

Thanks!
Helge  
  
> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> index 73de4ef..944f500 100644
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -2,7 +2,7 @@
>   # PCI configuration
>   #
>   config PCI_BUS_ADDR_T_64BIT
> -	def_bool y if (ARCH_DMA_ADDR_T_64BIT || 64BIT)
> +	def_bool y if (ARCH_DMA_ADDR_T_64BIT || (64BIT && !PARISC))
>   	depends on PCI
>
>   config PCI_MSI

Re: Re: A500 boot crash in 4.2.0-rc3-00246-g763e326

[Yinghai Lu]

On Wed, Aug 19, 2015 at 10:42 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:

> commit 51a660a2732c
> Author: Bjorn Helgaas <bhelgaas@google.com>
> Date:   Thu Aug 20 00:08:15 2015 -0500
>
>     PCI: Don't use 64-bit bus addresses on PA-RISC
>
>     Meelis and Helge reported that 3a9ad0b4fdcd ("PCI: Add pci_bus_addr_t")
>     caused HPMCs on A500 and hangs on rp5470.
>
>     PA-RISC does not set ARCH_DMA_ADDR_T_64BIT, even for 64-bit kernels, so
>     prior to 3a9ad0b4fdcd, we always used 32-bit PCI addresses.  After
>     3a9ad0b4fdcd, we do use 64-bit PCI addresses in 64-bit kernels, and
>     apparently there's some PA-RISC problem related to them.
>
>     Fixes: 3a9ad0b4fdcd ("PCI: Add pci_bus_addr_t")
>     Link: http://lkml.kernel.org/r/alpine.LRH.2.11.1507260929000.30065@math.ut.ee
>     Reported-by: Meelis Roos <mroos@linux.ee>
>     Reported-by: Helge Deller <deller@gmx.de>
>     Based-on-idea-by: Yinghai Lu <yinghai@kernel.org>
>     Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>
> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> index 73de4ef..944f500 100644
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -2,7 +2,7 @@
>  # PCI configuration
>  #
>  config PCI_BUS_ADDR_T_64BIT
> -       def_bool y if (ARCH_DMA_ADDR_T_64BIT || 64BIT)
> +       def_bool y if (ARCH_DMA_ADDR_T_64BIT || (64BIT && !PARISC))
>         depends on PCI
>
>  config PCI_MSI

Yes, that is better.

Acked-by: Yinghai Lu <yinghai@kernel.org>

Re: Re: A500 boot crash in 4.2.0-rc3-00246-g763e326

[Yinghai Lu]

On Wed, Aug 19, 2015 at 10:42 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:

> commit 51a660a2732c
> Author: Bjorn Helgaas <bhelgaas@google.com>
> Date:   Thu Aug 20 00:08:15 2015 -0500
>
>     PCI: Don't use 64-bit bus addresses on PA-RISC
>
>     Meelis and Helge reported that 3a9ad0b4fdcd ("PCI: Add pci_bus_addr_t")
>     caused HPMCs on A500 and hangs on rp5470.
>
>     PA-RISC does not set ARCH_DMA_ADDR_T_64BIT, even for 64-bit kernels, so
>     prior to 3a9ad0b4fdcd, we always used 32-bit PCI addresses.  After
>     3a9ad0b4fdcd, we do use 64-bit PCI addresses in 64-bit kernels, and
>     apparently there's some PA-RISC problem related to them.
>
>     Fixes: 3a9ad0b4fdcd ("PCI: Add pci_bus_addr_t")
>     Link: http://lkml.kernel.org/r/alpine.LRH.2.11.1507260929000.30065@math.ut.ee
>     Reported-by: Meelis Roos <mroos@linux.ee>
>     Reported-by: Helge Deller <deller@gmx.de>
>     Based-on-idea-by: Yinghai Lu <yinghai@kernel.org>
>     Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>
> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> index 73de4ef..944f500 100644
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -2,7 +2,7 @@
>  # PCI configuration
>  #
>  config PCI_BUS_ADDR_T_64BIT
> -       def_bool y if (ARCH_DMA_ADDR_T_64BIT || 64BIT)
> +       def_bool y if (ARCH_DMA_ADDR_T_64BIT || (64BIT && !PARISC))
>         depends on PCI
>
>  config PCI_MSI

Yes, that is better.

Acked-by: Yinghai Lu <yinghai@kernel.org>

Re: A500 boot crash in 4.2.0-rc3-00246-g763e326

[Helge Deller]

On 20.08.2015 21:31, Yinghai Lu wrote:
> On Wed, Aug 19, 2015 at 10:42 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
>
>> commit 51a660a2732c
>> Author: Bjorn Helgaas <bhelgaas@google.com>
>> Date:   Thu Aug 20 00:08:15 2015 -0500
>>
>>      PCI: Don't use 64-bit bus addresses on PA-RISC
>>
>>      Meelis and Helge reported that 3a9ad0b4fdcd ("PCI: Add pci_bus_addr_t")
>>      caused HPMCs on A500 and hangs on rp5470.
>>
>>      PA-RISC does not set ARCH_DMA_ADDR_T_64BIT, even for 64-bit kernels, so
>>      prior to 3a9ad0b4fdcd, we always used 32-bit PCI addresses.  After
>>      3a9ad0b4fdcd, we do use 64-bit PCI addresses in 64-bit kernels, and
>>      apparently there's some PA-RISC problem related to them.
>>
>>      Fixes: 3a9ad0b4fdcd ("PCI: Add pci_bus_addr_t")
>>      Link: http://lkml.kernel.org/r/alpine.LRH.2.11.1507260929000.30065@math.ut.ee
>>      Reported-by: Meelis Roos <mroos@linux.ee>
>>      Reported-by: Helge Deller <deller@gmx.de>
>>      Based-on-idea-by: Yinghai Lu <yinghai@kernel.org>
>>      Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>>
>> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
>> index 73de4ef..944f500 100644
>> --- a/drivers/pci/Kconfig
>> +++ b/drivers/pci/Kconfig
>> @@ -2,7 +2,7 @@
>>   # PCI configuration
>>   #
>>   config PCI_BUS_ADDR_T_64BIT
>> -       def_bool y if (ARCH_DMA_ADDR_T_64BIT || 64BIT)
>> +       def_bool y if (ARCH_DMA_ADDR_T_64BIT || (64BIT && !PARISC))
>>          depends on PCI
>>
>>   config PCI_MSI
>
> Yes, that is better.
>
> Acked-by: Yinghai Lu <yinghai@kernel.org>


Tested-by: Helge Deller <deller@gmx.de>
   and please add:
CC: stable@vger.kernel.org  # v3.19+

Helge

Re: A500 boot crash in 4.2.0-rc3-00246-g763e326

[Helge Deller]

On 20.08.2015 21:31, Yinghai Lu wrote:
> On Wed, Aug 19, 2015 at 10:42 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
>
>> commit 51a660a2732c
>> Author: Bjorn Helgaas <bhelgaas@google.com>
>> Date:   Thu Aug 20 00:08:15 2015 -0500
>>
>>      PCI: Don't use 64-bit bus addresses on PA-RISC
>>
>>      Meelis and Helge reported that 3a9ad0b4fdcd ("PCI: Add pci_bus_addr_t")
>>      caused HPMCs on A500 and hangs on rp5470.
>>
>>      PA-RISC does not set ARCH_DMA_ADDR_T_64BIT, even for 64-bit kernels, so
>>      prior to 3a9ad0b4fdcd, we always used 32-bit PCI addresses.  After
>>      3a9ad0b4fdcd, we do use 64-bit PCI addresses in 64-bit kernels, and
>>      apparently there's some PA-RISC problem related to them.
>>
>>      Fixes: 3a9ad0b4fdcd ("PCI: Add pci_bus_addr_t")
>>      Link: http://lkml.kernel.org/r/alpine.LRH.2.11.1507260929000.30065@math.ut.ee
>>      Reported-by: Meelis Roos <mroos@linux.ee>
>>      Reported-by: Helge Deller <deller@gmx.de>
>>      Based-on-idea-by: Yinghai Lu <yinghai@kernel.org>
>>      Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>>
>> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
>> index 73de4ef..944f500 100644
>> --- a/drivers/pci/Kconfig
>> +++ b/drivers/pci/Kconfig
>> @@ -2,7 +2,7 @@
>>   # PCI configuration
>>   #
>>   config PCI_BUS_ADDR_T_64BIT
>> -       def_bool y if (ARCH_DMA_ADDR_T_64BIT || 64BIT)
>> +       def_bool y if (ARCH_DMA_ADDR_T_64BIT || (64BIT && !PARISC))
>>          depends on PCI
>>
>>   config PCI_MSI
>
> Yes, that is better.
>
> Acked-by: Yinghai Lu <yinghai@kernel.org>


Tested-by: Helge Deller <deller@gmx.de>
   and please add:
CC: stable@vger.kernel.org  # v3.19+

Helge

Re: A500 boot crash in 4.2.0-rc3-00246-g763e326

[Bjorn Helgaas]

On Thu, Aug 20, 2015 at 2:15 PM, Helge Deller <deller@gmx.de> wrote:
> On 20.08.2015 21:31, Yinghai Lu wrote:
>>
>> On Wed, Aug 19, 2015 at 10:42 PM, Bjorn Helgaas <bhelgaas@google.com>
>> wrote:
>>
>>> commit 51a660a2732c
>>> Author: Bjorn Helgaas <bhelgaas@google.com>
>>> Date:   Thu Aug 20 00:08:15 2015 -0500
>>>
>>>      PCI: Don't use 64-bit bus addresses on PA-RISC
>>>
>>>      Meelis and Helge reported that 3a9ad0b4fdcd ("PCI: Add
>>> pci_bus_addr_t")
>>>      caused HPMCs on A500 and hangs on rp5470.
>>>
>>>      PA-RISC does not set ARCH_DMA_ADDR_T_64BIT, even for 64-bit kernels,
>>> so
>>>      prior to 3a9ad0b4fdcd, we always used 32-bit PCI addresses.  After
>>>      3a9ad0b4fdcd, we do use 64-bit PCI addresses in 64-bit kernels, and
>>>      apparently there's some PA-RISC problem related to them.
>>>
>>>      Fixes: 3a9ad0b4fdcd ("PCI: Add pci_bus_addr_t")
>>>      Link:
>>> http://lkml.kernel.org/r/alpine.LRH.2.11.1507260929000.30065@math.ut.ee
>>>      Reported-by: Meelis Roos <mroos@linux.ee>
>>>      Reported-by: Helge Deller <deller@gmx.de>
>>>      Based-on-idea-by: Yinghai Lu <yinghai@kernel.org>
>>>      Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>>>
>>> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
>>> index 73de4ef..944f500 100644
>>> --- a/drivers/pci/Kconfig
>>> +++ b/drivers/pci/Kconfig
>>> @@ -2,7 +2,7 @@
>>>   # PCI configuration
>>>   #
>>>   config PCI_BUS_ADDR_T_64BIT
>>> -       def_bool y if (ARCH_DMA_ADDR_T_64BIT || 64BIT)
>>> +       def_bool y if (ARCH_DMA_ADDR_T_64BIT || (64BIT && !PARISC))
>>>          depends on PCI
>>>
>>>   config PCI_MSI
>>
>>
>> Yes, that is better.
>>
>> Acked-by: Yinghai Lu <yinghai@kernel.org>
>
>
>
> Tested-by: Helge Deller <deller@gmx.de>
>   and please add:
> CC: stable@vger.kernel.org  # v3.19+

Done, thanks for testing this!

Re: A500 boot crash in 4.2.0-rc3-00246-g763e326

[Bjorn Helgaas]

On Thu, Aug 20, 2015 at 2:15 PM, Helge Deller <deller@gmx.de> wrote:
> On 20.08.2015 21:31, Yinghai Lu wrote:
>>
>> On Wed, Aug 19, 2015 at 10:42 PM, Bjorn Helgaas <bhelgaas@google.com>
>> wrote:
>>
>>> commit 51a660a2732c
>>> Author: Bjorn Helgaas <bhelgaas@google.com>
>>> Date:   Thu Aug 20 00:08:15 2015 -0500
>>>
>>>      PCI: Don't use 64-bit bus addresses on PA-RISC
>>>
>>>      Meelis and Helge reported that 3a9ad0b4fdcd ("PCI: Add
>>> pci_bus_addr_t")
>>>      caused HPMCs on A500 and hangs on rp5470.
>>>
>>>      PA-RISC does not set ARCH_DMA_ADDR_T_64BIT, even for 64-bit kernels,
>>> so
>>>      prior to 3a9ad0b4fdcd, we always used 32-bit PCI addresses.  After
>>>      3a9ad0b4fdcd, we do use 64-bit PCI addresses in 64-bit kernels, and
>>>      apparently there's some PA-RISC problem related to them.
>>>
>>>      Fixes: 3a9ad0b4fdcd ("PCI: Add pci_bus_addr_t")
>>>      Link:
>>> http://lkml.kernel.org/r/alpine.LRH.2.11.1507260929000.30065@math.ut.ee
>>>      Reported-by: Meelis Roos <mroos@linux.ee>
>>>      Reported-by: Helge Deller <deller@gmx.de>
>>>      Based-on-idea-by: Yinghai Lu <yinghai@kernel.org>
>>>      Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>>>
>>> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
>>> index 73de4ef..944f500 100644
>>> --- a/drivers/pci/Kconfig
>>> +++ b/drivers/pci/Kconfig
>>> @@ -2,7 +2,7 @@
>>>   # PCI configuration
>>>   #
>>>   config PCI_BUS_ADDR_T_64BIT
>>> -       def_bool y if (ARCH_DMA_ADDR_T_64BIT || 64BIT)
>>> +       def_bool y if (ARCH_DMA_ADDR_T_64BIT || (64BIT && !PARISC))
>>>          depends on PCI
>>>
>>>   config PCI_MSI
>>
>>
>> Yes, that is better.
>>
>> Acked-by: Yinghai Lu <yinghai@kernel.org>
>
>
>
> Tested-by: Helge Deller <deller@gmx.de>
>   and please add:
> CC: stable@vger.kernel.org  # v3.19+

Done, thanks for testing this!

Re: Aw: A500 boot crash in 4.2.0-rc3-00246-g763e326

[Meelis Roos]

> >>> I did a bisect and commit 3a9ad0b4fdcd57f775d3615004c8c64c021a9e7d ("PCI:
> >>> Add pci_bus_addr_t") seems to be the culprit:
> >>>
> >>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3a9ad0b4fdcd57f775d3615004c8c64c021a9e7d
> >>
> >> CC: patch author and linux-pci.
> >
> >
> > I think this is the problem:
> >
> > --- a/drivers/pci/Kconfig
> > +++ b/drivers/pci/Kconfig
> > @@ -1,6 +1,10 @@
> >  #
> >  # PCI configuration
> >  #
> > +config PCI_BUS_ADDR_T_64BIT
> > +       def_bool y if (ARCH_DMA_ADDR_T_64BIT || 64BIT)
> > +       depends on PCI
> 
> Thanks for bisecting.
> 
> Then we should change to
> 
> config PCI_BUS_ADDR_T_64BIT
>        def_bool y if (ARCH_DMA_ADDR_T_64BIT || SPARC64)
>        depends on PCI

This works for my A500.

-- 
Meelis Roos (mroos@linux.ee)

Re: Aw: A500 boot crash in 4.2.0-rc3-00246-g763e326

[Meelis Roos]

> >>> I did a bisect and commit 3a9ad0b4fdcd57f775d3615004c8c64c021a9e7d ("PCI:
> >>> Add pci_bus_addr_t") seems to be the culprit:
> >>>
> >>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id:9ad0b4fdcd57f775d3615004c8c64c021a9e7d
> >>
> >> CC: patch author and linux-pci.
> >
> >
> > I think this is the problem:
> >
> > --- a/drivers/pci/Kconfig
> > +++ b/drivers/pci/Kconfig
> > @@ -1,6 +1,10 @@
> >  #
> >  # PCI configuration
> >  #
> > +config PCI_BUS_ADDR_T_64BIT
> > +       def_bool y if (ARCH_DMA_ADDR_T_64BIT || 64BIT)
> > +       depends on PCI
> 
> Thanks for bisecting.
> 
> Then we should change to
> 
> config PCI_BUS_ADDR_T_64BIT
>        def_bool y if (ARCH_DMA_ADDR_T_64BIT || SPARC64)
>        depends on PCI

This works for my A500.

-- 
Meelis Roos (mroos@linux.ee)