Re: port-amd64/52493: NetBSD boot freezes on xhci_init on Mac Mini (MGEN2AE/A)

[Andrius V <vezhlys%gmail.com@localhost>]

The following reply was made to PR port-amd64/52493; it has been noted by GNATS.

From: Andrius V <vezhlys%gmail.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: skrll%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: port-amd64/52493: NetBSD boot freezes on xhci_init on Mac Mini (MGEN2AE/A)
Date: Mon, 11 Sep 2017 17:50:31 +0300

 Hello again,
 
 I had a chance to continue my testing efforts and I think I came up
 with quite a clear reason for this bug and it puts a partial doubt if
 it can/needs to be fixed. Long story short that code probably would
 work on EFI boot but it fails on BIOS emulation (more details later).
 Indirectly I could confirm that with OpenBSD (it has both boot options
 in the installation image and it freezes on BIOS boot but successfully
 initialize controller attaches USB devices on EFI boot). When I was
 trying FreeBSD I was having EFI boot as well. The problem is that
 NetBSD EFI boot fails before any log messages appear on the screen
 (after loading the kernel system shows cursor in the upper edge of the
 screen for some time and then just reboots). I would like to submit a
 bug regarding this issue as well but it's hard to do it without having
 any details on the failure itself...
 
 To describe my findings in more details I probably should start from
 the note that I have a laptop with the same controller I had a chance
 to compare boot messages between Mac Mini and the laptop. The main
 finding which pointed me to the problem that one of ECR values was
 0x00000801 in mac mini instead of 0x00010801 in laptop (in xhci_ecp
 function in xhci.c) which in turn makes bios_sem value 0, xHCI
 controller never becomes owned by OS. Eventually xhci_op_write_4(sc,
 XHCI_USBCMD, XHCI_CMD_INTE|XHCI_CMD_RS) execution freezes at the boot
 process (some hardware specifics not to return error/timeout?). I even
 tried to do set value to 1 on purpose when I have this ECR value and
 NetBSD actually didn't freeze anymore on boot. uhub* devices still
 ended up with "device problem, disabling port " messages but I
 wouldn't be surprised if it is related. So I am not sure what can be a
 solution here. It would be great to either detect this situation
 somehow or at least timeout the operation and show warning instead.
 Just hope this info will help to come up with some solution. Thank
 you.
 
 Regards,
 Andrius V
 
 On Fri, Sep 1, 2017 at 3:55 PM, Andrius V <vezhlys%gmail.com@localhost> wrote:
 > The following reply was made to PR port-amd64/52493; it has been noted by GNATS.
 >
 > From: Andrius V <vezhlys%gmail.com@localhost>
 > To: gnats-bugs%netbsd.org@localhost
 > Cc: netbsd-bugs%netbsd.org@localhost
 > Subject: Re: port-amd64/52493: NetBSD boot freezes on xhci_init on Mac Mini (MGEN2AE/A)
 > Date: Fri, 1 Sep 2017 15:52:22 +0300
 >
 >  Hello NetBSD team,
 >
 >  I performed additional testing the get more information regarding this
 >  issue. I tried to boot different BSDs and compare drivers
 >  (unfortunately all BSDs seem to have their own take on xhci driver).
 >  OpenBSD shares exactly the same issue with the freezing system on
 >  their counterpart of xhci_op_write_4(sc, XHCI_USBCMD,
 >  XHCI_CMD_INTE|XHCI_CMD_RS); call (XOWRITE4(sc, XHCI_USBCMD,
 >  XHCI_CMD_INTE|XHCI_CMD_RS);). FreeBSD boots and identifies USB devices
 >  properly on the other hand. So it can be some kind of reference to
 >  investigate the cause (but I am not sure yet where to look). They
 >  execute it a bit differently (XWRITE4(sc, oper, XHCI_USBCMD,
 >  XHCI_CMD_RS | XHCI_CMD_INTE | XHCI_CMD_HSEE);) but it's not the cause
 >  of the problem. Coincidentally I have same usb3 controller on one
 >  lenovo laptop (or at least identification message is the same up to
 >  revision) but it boots NetBSD and identifies USB devices properly. So
 >  in the end it seems the problem is caused by something before
 >  initialization of the controller (device information/memory?). Any
 >  clues where can I look or what information can I provide? Thank you.
 >
 >  Regards,
 >  Andrius V
 >
 >  On Sun, Aug 20, 2017 at 9:35 PM,  <vezhlys%gmail.com@localhost> wrote:
 >  >>Number:         52493
 >  >>Category:       port-amd64
 >  >>Synopsis:       NetBSD boot freezes on xhci_init on Mac Mini (MGEN2AE/A)
 >  >>Confidential:   no
 >  >>Severity:       serious
 >  >>Priority:       medium
 >  >>Responsible:    port-amd64-maintainer
 >  >>State:          open
 >  >>Class:          sw-bug
 >  >>Submitter-Id:   net
 >  >>Arrival-Date:   Sun Aug 20 18:35:00 +0000 2017
 >  >>Originator:     Andrius V
 >  >>Release:        NetBSD 8.0_BETA
 >  >>Organization:
 >  >>Environment:
 >  >>Description:
 >  > Recently I performed some NetBSD 8 testing on various hardware including =
 >  Mac Mini (MGEN2AE/A). The problem I encountered in booting it on this syste=
 >  m was that it just freezes without any error message. After some trial and =
 >  error I found that the freeze occurs on xhci_init, specifically on this lin=
 >  e (xhci.c line 1180):
 >  >
 >  > xhci_op_write_4(sc, XHCI_USBCMD, XHCI_CMD_INTE|XHCI_CMD_RS); /* Go! */
 >  >
 >  > Commenting out the line and rebuilding the kernel actually allows system =
 >  to boot (of course, USB3 fails to work but at least system boot doesn't fre=
 >  eze). Unfortunately my knowledge stops here though I can try to get more in=
 >  fo if needed.
 >  >
 >  > Ideally it would be nice to make USB3 work (as mac mini is quite useless =
 >  without USB) but I believe at least the freeze shouldn't occur on the boot.
 >  >
 >  > Debug messages from boot for xhci (with commented out line above):
 >  >
 >  > ...
 >  > xhci0 at pci0 dev 20 function 0: vendor 8086 product 9c31 (rev. 0x04)
 >  > xhci0: interrupting at msi2 vec 0
 >  > xhci0: xHCI version 1.0
 >  > xhci0: hcs1=3Dd000820 hcs2=3D84000054 hcs3=3D200000a
 >  > xhci0: hcc=3D0x200077c1<XECP=3D0x2000,MAXPSA=3D0x7,SEC,SPC,PAE,NSS,LTC,AC=
 >  64>
 >  > xhci0: xECP 8000
 >  > xhci0: ECR: 0x02000802
 >  > xhci0:  SP: 02000802 20425355 30180901 00000000
 >  > xhci0:  hs ports 1 - 9
 >  > xhci0: ECR: 0x03000802
 >  > xhci0:  SP: 03000802 20425355 1000040a 00000000
 >  > xhci0:  ss ports 10 - 13
 >  > xhci0: ECR: 0x00010cc1
 >  > xhci0: ECR: 0x0000fcc0
 >  > xhci0: ECR: 0x00000801
 >  > xhci0: ECR: 0x0005000a
 >  > xhci0: PAGESIZE 0x00000001
 >  > xhci0: sc_pgsz 0x00001000
 >  > xhci0: sc_maxslots 0x00000020
 >  > xhci0: sc_maxports 13
 >  > xhci0: sc_maxspbuf 16
 >  > xhci0: eventst: 000000010f414fc0 0xffff80008e5c7fc0 1000
 >  > xhci0: dcbaa: 000000010f415000 0xffff80008e5c8000 1000
 >  > xhci0: current IMOD 1000
 >  > xhci0: USBCMD 00000000
 >  > xhci0: USB3PRM / USB3.0 configurable ports: 0x0000000f
 >  > xhci0: USB3_PSSEN / Enabled USB3.0 ports under xHCI: 0x0000000f
 >  > xhci0: XUSB2PRM / USB2.0 ports can switch from EHCI to xHCI:0x000001ff
 >  > xhci0: XUSB2PR / USB2.0 ports under xHCI: 0x000001ff
 >  > usb0 at xhci0: USB revision 3.0
 >  > usb0: WARNING: power management not supported
 >  > usb1 at xhci0: USB revision 2.0
 >  > usb1: WARNING: power management not supported
 >  > ...
 >  > uhub0 at usb0: vendor 8086 (0x8086) xHCI Root Hub (0000), class 9/0, rev =
 >  1.00/1.00, addr 0
 >  > uhub0: 4 ports with 4 removable, self powered
 >  > uhub1 at usb1: vendor 8086 (0x8086) xHCI Root Hub (0000), class 9/0, rev =
 >  2.00/1.00, addr 0
 >  > uhub1: 9 ports with 9 removable, self powered
 >  > ...
 >  > uhub1: device problem, disabling port 1
 >  > uhub1: device problem, disabling port 2
 >  > uhub1: device problem, disabling port 3
 >  > uhub1: device problem, disabling port 4
 >  >>How-To-Repeat:
 >  >
 >  >>Fix:
 >  >
 >