← Back to team overview

kernel-packages team mailing list archive

[Bug 1499357] Re: 830 TI on Tuleta during IPL of Linux - bad xisr passed to PHYP

 

Patch submitted for Vivid SRU: https://lists.ubuntu.com/archives/kernel-
team/2015-September/063141.html

** Also affects: linux (Ubuntu Wily)
   Importance: High
     Assignee: Canonical Kernel Team (canonical-kernel-team)
       Status: Triaged

** Also affects: linux (Ubuntu Vivid)
   Importance: Undecided
       Status: New

** Changed in: linux (Ubuntu Wily)
       Status: Triaged => Fix Committed

** Changed in: linux (Ubuntu Wily)
     Assignee: Canonical Kernel Team (canonical-kernel-team) => Tim Gardner (timg-tpi)

** Changed in: linux (Ubuntu Vivid)
       Status: New => In Progress

** Changed in: linux (Ubuntu Vivid)
     Assignee: (unassigned) => Tim Gardner (timg-tpi)

-- 
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 Committed
Status in linux source package in Vivid:
  In Progress
Status in linux source package in Wily:
  Fix Committed

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