Please provide exact package release including that patch to be tested. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1499357
Title: 830 TI on Tuleta during IPL of Linux - bad xisr passed to PHYP Status in linux package in Ubuntu: Fix Released Status in linux source package in Vivid: Fix Committed Status in linux source package in Wily: Fix Released Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1499357/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp