I was making some modifications in the linux kernel, and something has broken due to my changes, I have lots of printk's inside the code, which do show up only in the tty console (Ctrl+Alt+F1) .
The problem is that it quickly keeps moving down and reaches the kernel crash info and I cannot determine anything from the crash info as everything is lost after a reset.
Is it somehow possible to make the tty scrollable or even static . By static I mean that it should not scroll down and stay on the original screen even when new messages pop up. (So that I can see my printk's)
Press CTRL+s to freeze scrolling, and in fact any updating of the TTY.
Press CTRL+q to resume.
You can scroll with SHIFT+page up/page down
There is no way to stop it from scrolling at boot time (as far as I know).
You can use the command
sudo dmesg -n 1
to suppress all messages from the kernel (and its drivers) except panic messages from appearing on the console.
To fix at each boot, add the command to:
/etc/rc.local
Related
On modern Fedora Linux installations, pressing the computer's "power off" button does not actually shut it down, but rather hibernates it, which is very convenient.
However, this is only true if I run the default Gnome window manager. If I use a different window manager (my favorite is the old-school ctwm), this doesn't happen - the power-off button shuts down the system instead of hibernating.
My question is: How can I tell my system (I don't mind a little coding, and it doesn't need to be inside ctwm) to do something else - and not a shutdown - when the poweroff button is pressed. Without Gnome.
I did a little digging, and it appears that I have "upowerd" running. However, it is running just the same when ctwm and Gnome are the current window manager, so Gnome must somehow be telling upowerd not to power-off the computer and instead either do something else (like hibernate) or send Gnome that the event happened. But I couldn't find any documentation on how that's done, or how I can do something similar without Gnome.
When I am running firefox as my active application and do a [ctrl]+[shift]+T, firefox opens a new tab. Hoever when I do a [ctrl]+[alt]+T, linux opens a new terminal window. Just made me ponder over the possible internals of this operation.
I had assumed that the control over stdin lies with the active application and if it reads something that makes sense to it, it goes ahead and does it. Now I feel that before the input is even put into stdin, the kernel scans it for the shortcuts that are relevant to it, and only the ones leftover are passed onto stdin, and from there to the user space applications.
Is this view accurate?
You are correct about what is causing it, just not the details. It's not the kernel that is swallowing it in this case, it's the Window Manager.
Your keyboard shortcut for Ctrl+Alt+T is getting eaten by your window manager. If you go to your Window Manager keyboard shortcuts, find the one bound to Ctrl+Alt+T and un-define it, it will work in FF properly.
The WM is a "layer" if you will that receives all events and passes on the ones that it determines are relevant to the underlying application.
I'm running GNOME on Angstrom Linux on a Beagleboard, and have an issue when the device boots, i'm running the 2013-06-20 image from http://beagleboard.org/latest-images.
Power on, and the screen will display the Beagleboard logo, and continues to boot up. The screen goes black, but instead of loading onto the desktop, the screens (I've tried a few just to make sure) report no output from the device. If i move the mouse/press a key on the keyboard however it wakes up and displays the desktop.
Has anyone else experienced this? Is there a way to prevent this 'sleep mode' (I doubt that's what it is, its just the best phrase I can think of describe this problem) from happening and just to boot up & display the desktop?
Cheers.
This seems to have fixed the issue I was having, firstly I'd suggest updating any outdated packages by opening a terminal and typing
opkg update
this should only take ~1 minute, aftewards type
opkg upgrade
This can take anywhere from ~10minutes to ~6 hours maybe even more, so be patient, just leave the device alone until it has finished.
then open the following file
nano /etc/X11/xorg.conf
and add the following
Section "ServerFlags"
Option "BlankTime" "0"
Option "StandbyTime" "0"
Option "SuspendTime" "0"
Option "OffTime" "0"
EndSection
Section "Monitor"
Option "DPMS"
Identifier "Builtin Default Monitor"
EndSection
This should also disable any screensavers etc... which was also ideal for my requirements.
Reboot your device, and it should be good to go.
I'm trying to use the ocaml graphics module.
The line:
#Graphics.open_graph "";;
works fine in the interactive module, i.e. a small window pop up in X11 with white background.
However, when I try to use the script mode -- put this line in a file then compile it:
ocamlc -o a.out graphics.cma code.ml
only X11 starts but with no window popup.
Am using a mac. Anyone knows why? Thanks.
Followup:
It seems under script mode the popup window will closeup immediately after code execution. Because if I compile using XTerminal, I can see a small window popup but then closes.
I managed to keep the window open by adding an infinit loop at the bottom:
while true do () done;;
But still don't understand how things really work. Please help. Thanks.
All ressources are freed when the script terminates: memory, file descriptors, including the X window.
If you add an infinite loop, the script does not terminates, and the windows stays open.
Likewise, under the toplevel, the window stays open as long as you don't close the toplevel.
I would suggest to add two lines add the end of your script:
print "press enter to exit"
read one line from keyboard input
This way the script will not terminate until the user presses enter.
Indeed, as jrouquie explains you need to delay the termination of your program. The way I personally do that is by waiting on user input. At the end of the interactive program (or function being studied that opens the graphic mode), I put:
ignore (Graphics.read_key ())
This will wait until a key has been hit on the keyboard, and ignore the key value before returning.
I would really like to find a way to start gvim without the terminal losing focus.
I found a way to use gvim to display code when debugging in dbx.
Gvim as dbx frontend
This works great but it causes gvim to steal the focus every time it hits a breakpoint or changes line.
I am pretty sure I could adapt a terminal keeping focus to work inside dbx.
I am running solaris on a sparc processor.
How can I start gvim without it taking focus from the terminal that started it?
If you're a KDE user, you can start gvim with the kstart command. The kstart program has extensive options for controlling the behavior of the program you're starting. The --onbottom option might accomplish what you're trying to do.