Wyse D10D KDLs at boot

[mounty]

This machine used to work but a few months ago started to hang at the fourth of the seven icons at boot. Just lately it's been kind enough to drop into KDL, so here is the screen-shot in the hope that it might identify a fixable problem. The photograph is reduced to monochrome in order to minimise its size.

As this only affects this one machine, I've given the priority as normal, although, of course, for this particular hardware it's a blocker.

It's also possible that the bug is in a driver rather than the kernel.

[mounty]

screen grab/shot

[mounty]

Link to product WWW page:

​http://accessories.us.dell.com/sna/productdetail.aspx?c=us&l=en&s=fed&cs=16&sku=a6999776

[luroh]

What revision of Haiku is this? What image type? USB stick, hard disk...?

[mounty]

commit 19ce061e0bf560bab63b4178473e380a5d852013 Date: Fri Jan 16 14:24:32 2015 -0500

Built in Gentoo Linux and installed onto /dev/sda3 of the SSD of the device.

fdisk output (via Linux):

Disk /dev/sda: 1.9 GiB, 2048385024 bytes, 4000752 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0xbf92031a

Device Boot Start End Sectors Size Id Type /dev/sda1 * 8 29303 29296 14.3M 83 Linux /dev/sda2 * 30720 1853439 1822720 890M 83 Linux /dev/sda3 * 1853440 4000751 2147312 1G 83 Linux

[luroh]

What does install onto /dev/sda3 entail in this case, are you building Haiku directly to /dev/sda3, dd'ing an image and running makebootable, or something else? Is it repeatable using an official nightly image? Please also attach the output of lspci -vv from Linux.

[mounty]

output of lspci -vv

[mounty]

1. Building directly to /dev/sda3.
2. I'll try when I have the time, and report back.

[pulkomandy]

It would be nice if you could "binary search" which commit exactly made things break. This would make identifying the problem easier. https://dev.haiku-os.org/wiki/BinarySearch

[mounty]

Well, git bisect automates that a little and that's what I'm doing but I'm still trying to find a `good' starting-point, since builds for me were broken in around Feb. to July 2014 owing to stddef.h being in an unexpected place --- source had #include <stddef.h> but it is in /usr/include/linux/stddef.h. Obviously that could be trivially hacked but I'd rather find the build that I do remember successfully booting.

Even if I find the delta that triggers the hang, it could still be a red herring. But I'll keep looking anyway. It's slow because the machine is my main work machine currently AND certain downloads are not available from ​http://packages.haiku-os.org/

[pulkomandy]

You are not supposed to download things directly from ​http://packages.haiku-os.org/ (this is used by the package repositories). Nightly builds are hosted at ​http://download.haiku-os.org , and older versions are at ​http://haiku-files.org . I don't think we have deleted anything.

Maybe you can start your search using the nightly builds, and once you have located a starting point, switch to git bissect (depends if downloads are faster than building an image yourself or not).

[mounty]

I wasn't downloading directly from ​http://packages.haiku-os.org/ --- the build process was doing it, and failing, and outputting the name of the file it failed to download.

The nightlies are referenced by version, not date, so I can't tell which one to download.

The lockup still occurs with a build from the source as at 15 August 2014 and the source dated around 1 August 2014 fails to obtain its downloads (so cannot be built), so I don't know what else I can do with this. Maybe it's just not worth the trouble and the ticket should be closed.

[pulkomandy]

​http://cgit.haiku-os.org/haiku/log/ allows to map revision numbers to dates (and back).

Which are the files failing to download? This should be fixed if it prevents building old versions of Haiku.

And your boot failure should be investigated as well, we don't want such problems in Haiku.

[mounty]

I'm now thinking that I was mistaken in my memory that the machine once booted, as I went right back to September 2014 and still couldn't get a boot out of it. To move on, I booted with all options (ACPI, APM etc.) disabled, stepped boot, and got this (transcribed character for character including blanks from a screen shot which I consider too big to attach):

PCI: [dom 0, bus  0] bus   0, device 24, function  7: vendor 1022, device 1719, revision 00
PCI:   class_base 06, class_function 00, class_api 00
PCI:   vendor 1022: Advanced Micro Devices, Inc. [AMD]
PCI:   device 1719: Family 12h/14h Processor Function 7
PCI:   info: Bridge (Host bridge)
PCI:   line_size 00, latency 00, header_type 80, BIST 00
PCI:   ROM base host 00000000, pci 00000000, size 00000000
PCI:   cardbus_CIS 00000000, subsystem_id 0000, subsystem_vendor_id 0000
PCI:   interrupt_line 00, interrupt_pin 00, min_grant 00, max_latency 00
PCI:   base reg 0: host 00000000, pci 00000000, size 00000000, flags 00
PCI:   base reg 1: host 00000000, pci 00000000, size 00000000, flags 00
PCI:   base reg 2: host 00000000, pci 00000000, size 00000000, flags 00
PCI:   base reg 3: host 00000000, pci 00000000, size 00000000, flags 00
PCI:   base reg 4: host 00000000, pci 00000000, size 00000000, flags 00
PCI:   base reg 5: host 00000000, pci 00000000, size 00000000, flags 00
PCI:   Capabilities: (not supported)
acpi: ACPI disabled
module: Search for busses/usb/xhci failed.
usb uhci: no devices found
usb ohci -1: iospace offset: 0x9114b000
add_memory_type_range(142, 0x9114b000, 0x1000, 0)
usb ohci -1: smm is in control of the host controller
usb ohci -1: ownership change successful
usb ohci -1: successfully started the controller
usb ohci -1: iospace offset: 0x9114a000
add_memory_type_range(145, 0x9114a000, 0x1000, 0)
usb ohci -1: smm is in control of the host controller
usb ohci -1: ownership change successful
usb ohci -1: successfully started the controller
usb ohci -1: iospace offset: 0x91149000
add_memory_type_range(148, 0x91149000, 0x1000, 0)
usb ohci -1: smm is in control of the host controller
usb ohci -1: ownership change successful
usb ohci -1: successfully started the controller
usb ohci -1: iospace offset: 0x91148000
add_memory_type_range(151, 0x91148000, 0x1000, 0)
usb ohci -1: smm is in control of the host controller
usb ohci -1: ownership change successful
usb ohci -1: successfully started the controller
add_memory_type_range(154, 0x9114c000, 0x1000, 0)
usb ehci -1: the host controller is bios owned, claiming ownership
usb ehci -1: controller is still bios owned, waiting
usb ehci -1: successfully took ownership of the host controller
sitd entry size 64, itd entry size 128
usb ehci -1: successfully started the controller
add_memory_type_range(159, 0x9114c000, 0x1000, 0)
usb ehci -1: the host controller is bios owned, claiming ownership
usb ehci -1: controller is still bios owned, waiting
usb ehci -1: successfully took ownership of the host controller
sitd entry size 64, itd entry size 128                   Press key to continue, S to skip output

and at that point I pressed a key and nothing further happened. That might indicate that the problem lies in the USB subsystem, or it might be in whatever comes after the USB.

This may or may not be relevant but I recently switched from having the keyboard and mouse connected via a hub, to having them plugged directly into the computer. That didn't work on Gentoo Linux until I rebuilt the kernel with CONFIG_USB_OHCI_HCD_PCI and CONFIG_USB_OHCI_HCD_PLATFORM -- OHCI support for PCI-bus USB controllers. Maybe that indicates something unusual about the hardware. It was something to do with connecting a low-speed device to a controller that was expecting high-speed, or something like that. As this braindump indicates, I'm not knowledgeable in this area.

[mounty]

I tried booting Haiku again with the keyboard and mouse plugged in directly, but no difference.

[pulkomandy]

You can disable the "paging" in the on-screen debug output from the boot menu. This will not wait for you to press keys, and boot as far as it can.

OHCI is a bit unusual, it is the USB1 controller design from Nec, competing with UHCI, which is the one supported by Intel and Via (and more common on most PC machines). EHCI is the unified controller for USB2, but when an USB1 device is used, EHCI still requires one of the USB1 controllers to handle it (this changed again with the introduction of USB3, however).

We do have an OHCI driver, however it doesn't get as much testing as the UHCI one. OHCI is usually found on PCI USB extension boards, while UHCI is present on most motherboards.

[mounty]

This bug no longer occurs. I presume the recent work on xHCI fixed it. The ticket should be closed.

[pulkomandy]

Ok, thanks fo reporting.