What's happening here? USB and SSD's connections disappeared suddenly

[betweendayandnight]

Install using CD (install58.iso, snapshot of install59.iso)

I was trying to install OpenBSD 5.8 (install58.iso) using a CD when during the installing process, weird things happened.

A message, white text against a blue background, popped up at various times after I typed the letter I (for "install"). It read as follows:

uhidev0 at uhub0 port 5 configuration 1 interface 0 "Logitech USB Optical Mouse" rev 2.00/63.00 addr 2
uhidev0 : iclass 3/1
uhidev at uhidev0 not configured
uhidev0 not configured

I pressed the ENTER key and was able to proceed to the next step with the same message appearing about 10 seconds later. (It behaved like malware which popped up from time to time to remind one to register or pay up or else....)

When it came to choosing which sets of software to install, I typed -game58.tgz to remove it from being installed. Next I pressed the ENTER key.

Immediately I was asked a second time to choose the software I wished to install. And again I typed -game58.tgz to deselect it.

The above repeated itself ad nauseum till I pressed Ctrl+C to abort the installation.

The same weird things happened when I tried to install a snapshot of OpenBSD 5.9 (install59.iso).

Install using USB 2.0, USB 3.0 thumb drives (install58.fs, snapshot of install59.fs)

In addition to the message "uhidev0 at uhub0 port 5 configuration 1 interface....." appearing, when it came for me to choose whether to (A)utoinstall, (I)nstall, (U)pgrade, sd0 disappeared while sd1 remained. (sd0 is the SSD drive while sd1 is the thumb drive).

I am beginning to wonder if my computer has been possessed, jinxed or worse tampered with by the 3-letter government agency.

The components of my computer are:

Intel Haswell CPU, i5-4570
Haswell motherboard with H87 chipset
8 GB RAM
4 USB 3.0 ports
2 USB 2.0 ports
1 Sata 6 GB/s SSD
1 Sata DVD drive
No dedicated graphics card

P.S.: Surprisingly the weird things described above did not occur when I installed a Linux distro such as Ubuntu, Gentoo or Arch Linux.

[e1-531g]

Maybe there is something wrong with mouse and cable?
I also have some messages, but fortunately they are not so frequent.
I have a laptop so I have also touchpad. If I unplug mouse and use only touchpad, messages are not displaying on screen/dmesg.
Unfortunately and often manufacturer doesn't make power saving features of mouse according to USB standard, rather than than just test against Windows.

[jggimi]

Originally Posted by betweendayandnight

Install using CD (install58.iso, snapshot of install59.iso)

Thank you for trying both.

A message, white text against a blue background, popped up at various times after I typed the letter I (for "install").

White text on blue background is a message from the OpenBSD kernel to the console on amd64/i386 architectures.

(It behaved like malware which popped up from time to time to remind one to register or pay up or else....)

No, it's not malware, it's the USB connecting and disconnecting. Probably after a timeout event.

When it came to choosing which sets of software to install, I typed -game58.tgz to remove it from being installed. Next I pressed the ENTER key....Immediately I was asked a second time to choose the software I wished to install. And again I typed -game58.tgz to deselect it.

I'll assume it was already deselected. You will continue to get this selection prompt until you inform the installer you aredone selecting/deselecting filesets.

The above repeated itself ad nauseum till I pressed Ctrl+C to abort the installation.

Perhaps, the keyboard (USB) keystroke is being lost by whatever is causing the mouse disconnections?

The same weird things happened when I tried to install a snapshot of OpenBSD 5.9 (install59.iso)...In addition to the message "uhidev0 at uhub0 port 5 configuration 1 interface....." appearing, when it came for me to choose whether to (A)utoinstall, (I)nstall, (U)pgrade, sd0 disappeared while sd1 remained. (sd0 is the SSD drive while sd1 is the thumb drive).

That's very odd. However, you have a Haswell platform, which is very new technology for OpenBSD, and USB 3.0, which is relatively new for OpenBSD. If it is possible, try to connect your devices to USB 2.0 ports rather than USB 3.0. If it is USB 3.0 related, the problems may dissipate.

[betweendayandnight]

Originally Posted by e1-531g

Maybe there is something wrong with mouse and cable?

How is it that when I was installing a Linux distro such as Ubuntu, Gentoo or Arch Linux, no such problems occurred?

Originally Posted by e1-531g

Unfortunately and often manufacturer doesn't make power saving features of mouse according to USB standard, rather than than just test against Windows.

I didn't test it against Microsoft Windows. I tested it against some flavors of Linux.

[betweendayandnight]

Originally Posted by jggimi

You will continue to get this selection prompt until you inform the installer you are done selecting/deselecting filesets.

I'm sorry I didn't provide more details in my original post.

I did inform the installer that I was done selecting/deselecting filesets by pressing the relevant keys. Like you said the "signals" from the key presses were somehow lost by one of the USB ports disconnection.

Originally Posted by jggimi

That's very odd.

Indeed it is. What's weirder is that the problems as described in my original post--USB port disconnecting, keyboard inputs not registering with the installer, sd0 lost while sd1 was still connected--suggest that the Haswell motherboard has been tampered with. But then again, if it had been messed with, the exact same problems should've appeared when I was installing Ubuntu, Gentoo and Arch Linux, no?

Originally Posted by jggimi

However, you have a Haswell platform, which is very new technology for OpenBSD,

Are you serious? Haswell is like two generations old, about 3 years old. The current generation of Intel CPUs is called Skylake.

Originally Posted by jggimi

If it is possible, try to connect your devices to USB 2.0 ports rather than USB 3.0. If it is USB 3.0 related, the problems may dissipate.

I'm sorry for not having been clear enough in my original post. I tested various scenarios using a USB 2.0 thumb drive inserted into a USB 2.0 port too. The exact same problems reared their ugly heads as well.

[jggimi]

Sorry for confusing myself, and you. I was indeed confusing Haswell and Skylake.

It might be possible to obtain a dmesg(8) from that platform. The RAMDISK kernel you have booted from a thumb drive contains a small kernel and a self-contained, but minimal userland filesystem with some tools -- in RAM -- hence the name. Select the shell after boot, instead of the install script.

The USB stick you booted from wouldn't be useful for this purpose, because you'd need a working OpenBSD system to read any files written there. A second stick, if you have one, formatted with a FAT filesytem could be used to transfer a dmesg(). It's possible, but less easy to transfer over a network, because the tools available on the RAMDISK system are limited.

If you have a second stick available, formatted with a FAT filesystem, it can be mounted and a dmesg() copied to it. Foreign filesystems like FAT are given virtual disklabel letters beginning with "i". So, if the blue/while kernel messages tell you that a USB stick has been inserted and assigned to device sd3, then sd3i would be its FAT filesystem.

# mount /dev/sd3i /mnt
# dmesg > /mnt/my.dmesg
# umount /mnt

With a dmesg, a problem report can be submitted to the OpenBSD Project team for review. Doing this from the snapshot, rather than 5.8, would be recommended, since you have it available.

[betweendayandnight]

Originally Posted by jggimi

It might be possible to obtain a dmesg(8) from that platform. The RAMDISK kernel you have booted from a thumb drive contains a small kernel and a self-contained, but minimal userland filesystem with some tools -- in RAM -- hence the name.

Only the thumb drive containing install5*.fs has the small kernel with self-contained, but minimal userland filesystem? What about a CD containing install5*.iso? The reason for asking is I've a USB 2.0 stick and two USB 3.0 sticks. IMHO to troubleshoot, I'd prefer to use USB 2.0 sticks as support for USB 3.0 in OpenBSD is relatively new.

Originally Posted by jggimi

Select the shell after boot, instead of the install script.

Select what shell please? Could you provide more detailed steps?

Originally Posted by jggimi

A second stick, if you have one, formatted with a FAT filesytem could be used to transfer a dmesg().

How long is this dmesg() going to be? I can jot down its entirety by hand, you know, because I've patience when it comes to learning new stuff.

If I'm plan to write it down by hand, you'll need to show me how to pause the dmesg() from scrolling.

Originally Posted by jggimi

If you have a second stick available, formatted with a FAT filesystem, it can be mounted and a dmesg() copied to it.

Well, I only have one USB 2.0 stick and two USB 3.0 sticks. As stated earlier in my reply I prefer to use USB 2.0 stick in a USB 2.0 port (which I've) for troubleshooting purposes.

P.S.: In your opinion, does my motherboard have hardware problems such as faulty USB ports, Sata ports (because sd0 also was disconnected), faulty keyboard ports?

[jggimi]

Originally Posted by betweendayandnight

What about a CD containing install5*.iso?

It contains the same system, just with CD boot blocks instead of an MBR with boot blocks, and a CD99600 fillesystem instead of an FFS filesystem.

Select what shell please? Could you provide more detailed steps?

Sure. When you boot the RAMDISK kernel, from any medium, you receive a prompt:

(I)nstall, (U)pgrade, (A)utoinstall or (S)hell?

Type s and press the Enter key. If your keyboard is working, you'll get a shell prompt #.

How long is this dmesg() going to be? I can jot down its entirety by hand, you know, because I've patience when it comes to learning new stuff.

They are fairly long -- its all that blue and white stuff that appears when you boot. It shows everything the kernel knows about your hardware, from probing it.

If I'm plan to write it down by hand, you'll need to show me how to pause the dmesg() from scrolling.

You're far better off taking photographs of the screen. You're less likely to introduce errors, and less likely to go insane.

You can stop the output with a pager program. The less(1) pager is available in that RAMDISK system. The more(1) pager might also be available, but I don't use it and haven't ever checked. (They're effectively the same program anyway.)

# dmesg | less

You don't need to set a terminal type. less() will warn you that it doesn't know what kind of terminal you have, but you'll still get paged output that will pause until you press the space bar.

P.S.: In your opinion, does my motherboard have hardware problems such as faulty USB ports, Sata ports (because sd0 also was disconnected), faulty keyboard ports?

From the information you've presented, this appears to be a software problem. But it could be something as simple as a BIOS setting for your motherboard.

A dmesg has a lot of information about your hardware as the kernel sees it, which is why one is so valuable to developers. Sometimes, they're even helpful to us users.

[betweendayandnight]

Here's the latest update on what I've done:

1. Downloaded the latest snapshot of install59.iso and burned it to a CD

2. Booted the RAMDISK kernel and when I came to the prompt

(I)nstall, (U)pgrade, (A)utoinstall or (S)hell?

I typed s and pressed ENTER

3. I typed

mount /dev/sd1i /mnt

and an error message appeared on the monitor. It read as follows:

mount_ffs: /dev/sd1i on /mnt: No such file or directory

I removed the USB 2.0 stick from the USB 2.0 port and reinserted it. A chunk of white text on blue background appeared and I noticed that the USB 2.0 stick was recognized as sd1

At the shell prompt, I re-typed

mount /dev/sd1i /mnt

and the same error message appeared.

What shall I do next, boss?

[jggimi]

I'm sorry you were having trouble. The example commands in post #7 above are predicated on your use of a USB stick already formatted with with a FAT filesystem.

In those cases, there is an MBR in sector 0, and an MBR partition table entry for the FAT filesystem.

OpenBSD will recognize the MBR and the partition table entry, and create a virtual disklabel for it, using the letter "i", which is the first partition letter used for foreign filesystems that it recognizes in an MBR partition table.

[betweendayandnight]

Originally Posted by jggimi

I'm sorry you were having trouble. The example commands in post #7 above are predicated on your use of a USB stick already formatted with with a FAT filesystem.

I should've provided more details when I was writing post #10.

As I don't have a computer with an installed OpenBSD to format a USB stick, I'd to use Microsoft Windows to do the job.

It appears that OpenBSD doesn't recognize filesystems created by Microsoft Windows as the same error message appeared, viz.

mount_ffs: /dev/sd1i on /mnt: No such file or directory

No sweat, I told myself and I reformatted the same stick using gparted in Ubuntu. Again OpenBSD couldn't recognize filesystems created by a program of a Linux distro.

Do you've suggestions for a workaround?

[jggimi]

My apologies, *again*. The RAMDISK kernel is a tiny thing, with limited resources, and doesn't have device nodes created in advance the same way a full system would. I had forgotten this. Among the sd(4) devices, only sd0 is pre-populated with device nodes in /dev.

To correct this, before the mount of /dev/sd1i will work, you must first create the device node (a special file in /dev).

# cd /dev
# sh MAKEDEV sd1

That will create the special files in the /dev directory needed to successfully mount.

(My apologies, again, for missing this critical step.)

[betweendayandnight]

Originally Posted by jggimi

My apologies, *again*.

No need to apologize as you're providing tech support for free and you've been a great help. Moreover according to OpenBSD's philosophy, I'm just here for the "ride".

Originally Posted by jggimi

Among the sd(4) devices, only sd0 is pre-populated with device nodes in /dev.

I assume the above statement is valid in the case in which I use a CD to install. If I use a USB stick with install59.fs on it to install, the device node for sd1 will be created automatically, right?

Originally Posted by jggimi

(My apologies, again, for missing this critical step.)

No sweat, no harm done. I'm learning new stuff for free each time I post here.

[jggimi]

The disk images and the cd images are identical, except for boot blocks and filesystem structure, per my first reply in post #8.

[betweendayandnight]

Good news: I was able to mount of the USB 2.0 stick on a device node.

Thanks in advancing for reviewing the attached dmesg in plain text format.

[betweendayandnight]

While waiting for the analysis of my first dmesg report 20160307-1.txt attached to my post #15, I ventured to test to see if the same error(s) would occur if I changed my Logitech mouse (USB).

I got myself a cheap 50-cent generic USB mouse and plugged it into a USB 3.0 port (I've only two USB 2.0 ports, one of which is reserved for the Logitech K200 keyboard (USB) while the other is reserved for the USB 2.0 thumb drive into which dmesg messages will be dumped as and when the installation routine throws up errors.)

I booted into the RAMDISK kernel using a CD (latest snapshot of install59.iso). No errors about the USB mouse being disconnected popped up on the screen. So far so good.

I managed to reach the step which stated:

Directory does not contain SHA256.sig. Continue without verification? [no] yes

And so the installation routine started with installing the necessary filesets until it stalled at

Installing comp59.tgz

And the white text on blue background appeared on the monitor with the following message:

cd0 (ahci0:1:0): Check Condition (error 0x70) on opcode 0x28
SENSE KEY: Media Error

The above was followed by white text against a black background with the below message:

ftp: Reading from file: Input/output error
gzip: stdin: unrecognized file format
tar: End of archive volume 1 reached
tar: Sorry, unable to determine archive format

I pressed Ctrl+C and a shell was presented to me.

I plugged a USB 2.0 stick into the only free USB 2.0 port. White text on a blue background appeared on my monitor telling me that the USB 2.0 stick had been mounted successfully.

At the shell prompt, I typed the following commands:

cd /dev
sh MAKEDEV sd1
mount /dev/sd1i /mnt
dmesg > /mnt/20160307-2.txt
umount /mnt

I rebooted my machine into a Linux distro.

I attach 20160307-2.txt for your analysis and report.

Thanks in advance.

[jggimi]

Originally Posted by betweendayandnight

Good news: I was able to mount of the USB 2.0 stick on a device node.

Great!

Thanks in advancing for reviewing the attached dmesg in plain text format.

I can see the repeated disconnects of the mouse. It's occurring on uhub0, which is an xhci(4) usb 3.0 hub, and your dmesg shows no USB 2.0 controllers, which I find unusual. I expected to see both uhci(4) USB 2.0 and ohci(4) USB 1.0/1.1 controllers attached as well as xhci().

I will guess you have a BIOS setting which may enable "legacy" USB connectivity, and if so, that may solve your USB-related troubles.

Originally Posted by betweendayandnight

I booted into the RAMDISK kernel using a CD....until it stalled at

Installing comp59.tgz

And the white text on blue background appeared on the monitor with the following message:

cd0 (ahci0:1:0): Check Condition (error 0x70) on opcode 0x28
SENSE KEY: Media Error

I'll repeat an earlier comment. White text on blue background on your console is a kernel message.

In this case, a 2048-byte sector on your CD could not be read from your CD drive by the kernel, and it reported this to you. And as your second dmesg shows, it tried repeatedly to do so.

[betweendayandnight]

Originally Posted by jggimi

Great!I can see the repeated disconnects of the mouse. It's occurring on uhub0, which is an xhci(4) usb 3.0 hub, and your dmesg shows no USB 2.0 controllers, which I find unusual. I expected to see both uhci(4) USB 2.0 and ohci(4) USB 1.0/1.1 controllers attached as well as xhci().

Well, I don't know about xhci(4) USB 3.0 hubs and such but what I do know is that on the motherboard there are pins for USB 2.0 and USB 1.0/1.1. There is a cable coming out from my computer tower case with the word USB 2.0 engraved on it. I just plugged it into the pins corresponding to USB 2.0 on the motherboard.

Originally Posted by jggimi

I will guess you have a BIOS setting which may enable "legacy" USB connectivity, and if so, that may solve your USB-related troubles.

Thanks for the tip. I accessed the BIOS and set it first to ENABLED, saved the BIOS setting and tried to install OpenBSD. Still the same error message appeared. I aborted the installation, accessed the BIOS again and set it to AUTO. Again the same error message was shown on the screen.

Originally Posted by jggimi

In this case, a 2048-byte sector on your CD could not be read from your CD drive by the kernel, and it reported this to you. And as your second dmesg shows, it tried repeatedly to do so.

Thanks for your diagnosis. I burned install59.iso a second time onto the same CD, this time using Nero on Microsoft Windows to do the job. Nero is good at verifying data that has just been burned onto CDs or DVDs.

This time round I was able to install the OS successfully, this in spite of repetitive kernel messages about disconnects of my Logitech mouse.

I am now able to boot into OpenBSD, all this because of your unfaltering tech support.

[jggimi]

Originally Posted by betweendayandnight

Well, I don't know about xhci(4) USB 3.0 hubs and such...

Now that you have successfully installed OpenBSD, you might want to.

These references to xhci(4) and ehci(4) and ohci(4) and sd(4) are man page references. The numbers in parentheses are the section numbers. Sometimes, there are multiple man pages with the same name in different sections. $ man printf will produce different results than $ man 3 printf.

but what I do know is that on the motherboard there are pins for USB 2.0 and USB 1.0/1.1....

Right, but the RAMDISK kernel wasn't seeing USB 2.0 or USB 1.x controllers. Which may have been the problem. However, now that you have a GENERIC kernel, and if OpenBSD seems to be running without further USB issues, check your your dmesg(8) again. Your GENERIC dmesg output might show them.

[betweendayandnight]

Originally Posted by jggimi

However, now that you have a GENERIC kernel, and if OpenBSD seems to be running without further USB issues, check your your dmesg(8) again. Your GENERIC dmesg output might show them.

It may be a bit premature for me to state that there are no disconnection issues with my Logitech mouse as my installed OpenBSD is less than a day old.

Please find attached the GENERIC dmesg output for your expert diagnosis. Thanks in advance.