kernel-packages team mailing list archive
-
kernel-packages team
-
Mailing list archive
-
Message #136602
[Bug 1499357] [NEW] 830 TI on Tuleta during IPL of Linux - bad xisr passed to PHYP
You have been subscribed to a public bug:
I looked at the dump and the assert is due to a bad xisr. From the VIO
trace the xisr was 0000000001000A00.
> ~d4a3/phypmacro/vio -globals -fr
+-----------------------------------------+
| HvVioGlobals (address=8000000807621100) |
+-----------------------------------------+
BitBucket: 0x07F000001A2D2000
AssertFr: 0x07F000080F394C80
AssertEnabled: True
VlanMap: 0x07F0000807621000
+------------------------------------+
| HvVioFr (address=07F000001A282800) |
+------------------------------------+
[ 0] HvVioInterruptAssertBadXisr [TB] 0000002C2067AB1A 0000000001000A00 0000000000000000 0000000000000000 0000000000000000
Here is the trace along with some Linux output that followed:
Token = 34, timebase = 0x24222848
h_hypervisor_esw_call(0x504c) rc = 0xfffffffc (-4)
175: b=
0100 0A00 0000 0000 0000 0000 0000 0001 [................]
105: get_parms_ptr=
0100 0A00 0000 0000 0000 0000 0000 0001 [................]
GET XIVE ERROR hcall rc=fffffffc buff_rc=1
[ 0.000517] irq: (null) didn't like hwirq-0x1000a00 to VIRQ16 mapping (rc=-22)
[ 0.000578] hvsi_console_init: couldn't create irq mapping for 0x1000a00
---------------------------------
I then dumped the device tree for interrupts that PFW communicates to Linux
via the device as follows:
1) Here are all the 'interrupt-ranges' properties found:
0 > showprops -i interrupt-ranges
/ibm,platform-facilities 00090400 00000400
/event-sources 00090000 00000008
/interrupt-controller@800000025000010 000037f8 00000004
/interrupt-controller@800000025000013 00003ff8 00000004
/interrupt-controller@800000025000014
/interrupt-controller@800000025000015
/interrupt-controller@800000025000018 000017f8 00000004
/interrupt-controller@80000002500001b
/interrupt-controller@80000002500001d 00001ff8 00000004
/interrupt-controller@80000002500001e
/interrupt-controller@80000002500001f
/interrupt-controller@800000025000021 00000ff8 00000004
/interrupt-controller@800000025000028 00002ff8 00000004
/interrupt-controller@800000025000029 000027f8 00000004
/vdevice 000a0000 000000c7 000b0000 0000007f
2) Here are all the 'ibm,msi-ranges' properties found:
0 > showprops -i ibm,msi-ranges
/pci@800000020000014/ethernet@0 00003be0 00000001
/pci@800000020000014/ethernet@0,1 00003be1 00000001
/pci@800000020000014/ethernet@0,2 00003be2 00000001
/pci@800000020000014/ethernet@0,3 00003be3 00000001
/pci@800000020000015/pci1014,034A@0 00003820 00000001
/pci@800000020000018/pci@0/pci@2/fibre-channel@0 00001000 00000001
/pci@800000020000018/pci@0/pci@2/fibre-channel@0,1 00001001 00000001
/pci@800000020000018/pci@0/pci@3/fibre-channel@0 00001002 00000001
/pci@800000020000018/pci@0/pci@3/fibre-channel@0,1 00001003 00000001
/pci@80000002000001b/usb@0 00001fa0 00000001
/pci@80000002000001e/ethernet@0 00001ce0 00000001
/pci@80000002000001e/ethernet@0,1 00001ce1 00000001
/pci@80000002000001e/ethernet@0,2 00001ce2 00000001
/pci@80000002000001e/ethernet@0,3 00001ce3 00000001
/pci@800000020000029/pci@0/pci@2/fibre-channel@0 00002000 00000001
/pci@800000020000029/pci@0/pci@2/fibre-channel@0,1 00002001 00000001
/pci@800000020000029/pci@0/pci@3/fibre-channel@0 00002002 00000001
/pci@800000020000029/pci@0/pci@3/fibre-channel@0,1 00002003 00000001
3) Here are all the 'interrupts' properties found:
0 > showprops -i interrupts
/event-sources/epow-events 00090001 00000000
/vdevice/vty@30000000 000a0000 00000000
/vdevice/vty@30000001 000a0001 00000000
/vdevice/ibm,vmc@30000002 000a0002 00000000
----------------------------------
PFW did not provide interrupt 01000A00 to the OS, so I don't think either PFW or
PHYP (who provides PFW with the int values) is at fault here. This needs to go
to Linux to determine where the 01000A00 comes from.
My guess is the interrupt 000A0001 provided for virtual console device /vdevice/vty@30000001
may be the source of the issue. Perhaps Linux is passing RTAS the little endian version of
the /vdevice/vty@30000001 interrupt since BE value 01000A00 is LE value 000A0001.
I think there is an endianess issue in hvsi_console_init where irq, as
well as vtermno, are not byte swapped when fetched from the DT.
However, I tried to get it fixed on my LPAR but I can't reach that code since there is no such a device configured.
How could I get this device (serial hvterm-protocol) set up ?
I confirm that hvsi_console_init() assumes big endian, which is wrong.
That explains the swapped irq value.
This patch is fixing all the endianness issues I found by reading the
HVSI driver's code.
When booting the system, there is no more error messages displayed and
the tty driver sounds configured correctly. However, I can't tell that
the driver is fully functional since I don't know how to access the
other side of the configured TTY.
The patch has been accpeted upstream in the powerpc/next branch:
https://git.kernel.org/powerpc/c/480798044eb268a31f6b
Hi,
This patch should be applied to Ubuntu 15.04 and 15.10.
Thanks,
Laurent.
** Affects: linux (Ubuntu)
Importance: Undecided
Assignee: Taco Screen team (taco-screen-team)
Status: New
** Tags: architecture-ppc64le bugnameltc-121364 severity-high targetmilestone-inin1504
--
830 TI on Tuleta during IPL of Linux - bad xisr passed to PHYP
https://bugs.launchpad.net/bugs/1499357
You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu.
