I’ve installed hrev57774 x64 on a bare metal system for the first time. So far apart from installing software I’ve configured it to run VESA graphics, otherwise it boots to a black screen (no signal).
Anyway after using it for a few minutes the screen stops updating. Just a static picture. I tried ssh’ing into the box and that works. From the ssh prompt I tried ‘shutdown -r’ which normally works fine. This time it just hangs indefinitely. I’m guessing something in the kernal is locked up… but not enough to break ssh.
So how do I get feedback on what’s gone wrong with the kernel? Are there logs somewhere? Do I have to turn them on? Ie what things can I do from the ssh prompt to figure out what’s wrong?
Hardware:
Intel i7, ga-z77-d3h mobo, hd4000 gfx, on board ethernet.
You can use top,which should be preinstalled,or htop from the htop_rivoreo package to get an overview over cpu load and memory usage of all processes.
Maybe you can see something that isn’t normal here.
And you can have a look at the file /var/log/syslog ,maybe there are errors reported here.
Actually any HiD device that has buttons is reported as a keyboard. For example, an USB headset with few multimedia keys will be seen as such but some integrated devices may be as well.
In same spirit, depending how they are wired, trackpads can be seen as mice.
Some input filters are also appearing here, so there’s probably nothing wrong.
I wonder if it really has anything to do with the kernel,if the rest of the system is still responsive and works as expected.
Maybe it’s the graphics card or the graphics driver that hangs,so that only the screen isn’t updated while everything,including the desktop environment itself,continues to run without you noticing it.
Can you try playing a audio file before it hangs?
Then,I’m interested if it continues to play when the screen is hanging (I guess it will).
And I’m interested if you can pause and resume it using hotkeys (space bar while the player window is focussed,usually) when the screen is hanging (I guess it will work).
If both is true,then only the graphics is your problem.
Can you drop to KDL via the keyboard shortcut (Alt+SysRq+D)? You can also use the kernel_debugger command, but if you don’t have a PS/2 keyboard this likely will just drop you to a kernel debugger prompt that you can’t type at. (If you use the keyboard shortcut on a USB keyboard, it tries to configure the kernel debugger to operate with USB keyboard support to the keyboard you pressed the shortcut on.)
With kernel debug logging on I’m getting a lot of this:
KERN: usb error control pipe 14: timeout waiting for queued request to complete
KERN: usb error hub 13: KERN: error updating port status
KERN: usb error control pipe 14: timeout waiting for queued request to complete
KERN: usb error hub 13: KERN: error updating port status
KERN: usb error control pipe 14: timeout waiting for queued request to complete
KERN: usb error hub 13: KERN: error updating port status
KERN: usb error control pipe 14: timeout waiting for queued request to complete
KERN: usb error hub 13: KERN: error updating port status
The system seems very laggy too. Like a single ls command at the ssh prompt can take 5-7 seconds in an empty folder. Hmmm.
Ok so the screen is frozen again. I can’t break into KDL with a keypress. My keyboard doesn’t have ‘SysRq’ but from what I understand the ‘PrnScn’ button is the same thing? Maybe?
Also I can run vncserver and vnc into the machine still… and THAT still updates as per normal. So whatever is drawing to the screen buffer is still working. Just not updating the HDMI output.
I’m currently configuring the haiku source so when that finishes I’ll try disabling ACPI. Most likely tonight as I have to go to work now.
One possible problem is the VESA driver tried and failed to put the display in powersaving mode. You can try disabling that from the screensaver preferences.
Also please give us the pci id of your videocard, if the native driver for it results in a black screen, we should remove it from the list of supported hardware for that driver, sothat vesa is used automatically
Disabling acpi is done using the boot menu (press space repeatedly at boot just before the splash screen shows) or the kernel configuration file. There is no need to recompile anything from sources.
I’ve also disabled the screensaver and we’ll see what happens. However I’ve had it freeze while actively using the computer so, IDK man… might be something else.
Btw in the kernel settings I currently have customized:
fail_safe_video_mode true
acpi false
So I noticed something interesting today. When the system switches to the “don’t update the screen” mode it also seems to insert a delay into every single command at the terminal, be it a local shell or an ssh session. A simple ‘ls’ now takes 6 seconds. Where as it’s instant normally. In fact all fairly instant commands now take 5-6 seconds. Hmmm.
For example, try to run ls inside strace, and you can see in more details at which step it gets stuck during 5 seconds.
Your syslog has a lot of USB errors. Can you try unplugging as much USB devices as possible? Maybe one of them is causing the problems, or, if not, at least we will have a cleaner syslog to look at and we can try to see if there is another problem.
Also, this should probably be tracked in the bugtracker instead of a forum topic.
The USB errors may be related to any executable taking a long time to start; until recently all application startups needed to go through the device manager lock in order to access /dev/random for the stack protector, which would be held for a long time if the USB explore thread got stuck. Now they don’t go through the device manager lock and the USB explore thread doesn’t hold that lock for so long either, so that problem at least may be fixed.
I’ve updated to hrev57921 and the USB errors in the log have disappeared. But so has my USB devices. Haiku no longer detects the mouse and keyboard attached to a USB hub. If I plug them directly into the machine they work, just not through the hub.
Is there a command like lsusb to list all the USB devices? Or anything really to debug USB related issues?
As for the screen freezing, I haven’t seen that happen since updating today. So fingers crossed it’s ok now? Maybe? Hopefully?
The next biggest issue I’m facing is that the Debugger can’t parse the dwarf debug data in my executables and I have no symbols for my code. Which is just so frustrating. It was working 6 months back. But something broke in the meantime.
But neither the keyboard or the mouse actually work. The screen is still updating ok, so that seems to be fixed. I can see the cursor in the terminal flashing and the clock is correct.
