I'm trying to debug why a change I made isn't working as it should. It's quite strange because there's two different builds of this driver running simultaneously (mpt2sas and mpt3sas) and the change is such that it's identical for both. The change works in mpt2sas but not in mpt3sas. I've got to figure out why. My first thought: print out what is actually being inspected by the driver.
To that end, I've read stuff from here and have referenced a few links from Stack Overflow about similar problems (e.g. this answer and this question). My current printk levels:
[root#dmandylnx64 ~]# cat /proc/sys/kernel/printk
8 4 1 7
Yet, I see no output when I do something like this:
dmesg | less # and search around for my strings
I found another link stating that the kernel buffers are made available through /proc/kmsg. So, I did
cat /proc/kmsg
... still not dice. I run my program and see no printks. One of the links I provided above stated something like, "... changing printk to pr_info did the trick ...". Well, I tried that too.
printk(KERN_DEBUG "MPT3SAS: 0x%08x\n", someIntegerData);
// became
pr_dbg("MPT3SAS: 0x%08x\n", someIntegerData);
Nope, that didn't work either. I upped the priority by changing them from DEBUG level to INFO level. Nope, that didn't work.
The question is really simple: what am I missing?
edit I forgot to mention, not even sure it is relevant, but this is CentOS 6.5.
Thanks,
Andy
Related
I have udev rule with the following content:
DRIVERS=="adt7310", RUN+="/bin/ln -s /sys//devices/platform/soc/fff00000.spi/spi_master/spi0/spi0.0/temp1_input /dev/temperature_adt"
The problem is that this rule is applied twice and in the log appears annoying line:
localhost systemd-udevd[1104]: Process '/bin/ln -s /sys//devices/platform/soc/fff00000.spi/spi_master/spi0/spi0.0/temp1_input /dev/temperature_adt' failed with exit code 1.
I have seen a lot of similar issues over the internet and many of them still unresolved. But most of them were about PC's and quite complicated rules.
Here it is an embedded system, the link is created, nothing wrong happens but I simply don't know what to tell to QA people...
Thanks
Please be very careful when writing rules and especially when you are taking someone else rules. Always run
udevadm info -a /sys/...device
and read very carefully the information.
In my case the solution is
DRIVER=="adt7310" instead of DRIVERS=="adt7310"
My apologies
I have a plugin in nagios "check_icmp" who return 4 values if the command can ping the demanded host however i got only 1 values if the ping failed so i used the following command :
'/usr/lib64/nagios/plugins/check_icmp -w 1000.0,20% -c 1400.0,60% -H 8.8.4.5 -m 5 | sed 's/pl=100%;20;60;0;100/rta=nan;;;; rtmax=nan;;;; rtmin=nan;;;; pl=100%;20;60;0;100/g'
and it returns
CRITICAL - 8.8.4.5: rta nan, lost 100%|rta=nan;;;; rtmax=nan;;;; rtmin=nan;;;; pl=100%;20;60;0;100
instead of
CRITICAL - 8.8.4.5: rta nan, lost 100%|pl=100%;20;60;0;100
so it works great on the host but if i put this command in nagiosql the current status stay in green "OK" even if the ping failed :
https://ibb.co/LCzvXrV
I would guess that the reason that you're getting an OK despite the fact that the result is "CRITICAL" is because the only thing Nagios cares about is the return code of the command you ran (also called an exit code). I would guess that sed has the last word, exits with return code 0 which means "everything went fine", and it did obviously: for sed.
Since you don't explain why you're doing any of this, I can't comment on whether this is a good idea or not, but it seems very odd in my mind to include a pipe to sed in your check command. I understand that you are sanitizing the performance data that is returned by the plugin, but why?
Nagios is built to interpret return codes as the status of your check, that's just the way it is. Whatever issues you are seeing because of this plugins behavior specifically surely can be resolved in another way without running sed magic on your checks that you may or may not get intended results from. It's also worth noting that if you're inserting this into RRD files, messing with the order or amount of values may create headaches, so I really wouldn't recommend it.
As a constructive suggestion in the future, please include what brought you to your current solution when asking these questions, as you can never know whether it's actually the best way to resolve your original issue. This is often called an XY Problem.
Relative Emacs newbie here, just trying to adapt my programming workflow to fit with emacs. So far I've discovered shell-pop and I'm quite enjoying on-demand terminals that pop up when needed for banging out the odd commands.
What I understand so far about Emacs is that shell is a "dumb" terminal that doesn't support any ansi control codes, and that makes it incompatible with things like ncurses that attempt to draw complex UI's on a terminal emulator. This is why you can't use less or top or similar in shell-mode.
However, I seem to be having trouble with ansi-term, it's not the be-all, end-all that it's cracked up to be. Sure, it has no problems running less or git log or even nano, but there are a few things that can't quite seem to display properly when they're running in an ansi-term, such as apt-get and nosetests. I'm not sure quite what the name is for it, but apt-get's output is characterised by live-updating what is displayed on the very last line, and then having unchanging lines of text scroll out above that line. It seems to be halfway between something like less and something dumber, like cat. Somehow ansi-term doesn't like this at all, and I get very garbled output, where it seems to output everything on one line only or just generally lose it's place and output things all over, randomly. In the case of nosetests, it starts off ok, but if any libraries spew out any STDERR, the output all goes to hell in a similar way.
With some fiddling it seems possible to fix this by mashing C-l and RET, but it's not always reliable.
Does anybody know what's going on here? Is there some way to fix ansi-term so that it can display everything properly? Or is there perhaps some other mode that I don't know about that is way better? Ideally I'd like something that "just works" as effortlessly as, eg, Gnome Terminal, which can run all of the above mentioned programs without a single hiccup.
Thanks!
I resolved this issue by commenting out my entire .emacs.el and then uncommenting and restarting emacs for every single line in the file. I discovered that the following line alone was responsible for the issue:
'(fringe-mode 0 nil (fringe))
(this line disables the fringes from inside custom-set-variables).
I guess this is a bug in Emacs, that disabling the fringe causes term-mode to garble it's output really badly whenever any output line exceeds $COLUMN columns.
Anyway, I don't really like the fringes much at all, and it seems I was able to at least disable the left fringe without triggering this issue:
(set-fringe-mode (cons 0 8))
Maybe apt-get does different things based on the $TERM environment variable. What happens if you set TERM=dumb? If that makes things work, then you can experiment with different values until you find one that supports enough features but still works.
Note that git 2.0.1 (June 25th, 2014) now better detects dumb terminal when displaying verbose messages.
That might help Emacs better display some of the messages received from git, but the fringe-mode bug reported above is certainly the main cause.
See commit 38de156 by Michael Naumov (mnaoumov)
sideband.c: do not use ANSI control sequence on non-terminal
Diagnostic messages received on the sideband #2 from the server side are sent to the standard error with ANSI terminal control sequence "\033[K" that erases to the end of line appended at the end of each line.
However, some programs (e.g. GitExtensions for Windows) read and interpret and/or show the message without understanding the terminal control sequences, resulting them to be shown to their end users.
To help these programs, squelch the control sequence when the standard error stream is not being sent to a tty.
I'm pretty new to linux, and I have a few questions about kernel module programming. I'm using ubuntu and C to make my .ko files. I'm trying to make a module that will execute program /b instead of /a whenever program /a is called. any tips?
also, even with printk (KERN_EMERG...), it won't print to the terminal. is there a setting i'm missing, or does ubuntu not do that?
Thanks a lot!
You may need to fiddle with the settings in /proc/sys/kernel/printk, which controls which levels are printed to the console. From proc(5):
/proc/sys/kernel/printk
The four values in this file are console_loglevel,
default_message_loglevel, minimum_console_level, and
default_console_loglevel. These values influence
printk() behavior when printing or logging error
messages. See syslog(2) for more info on the
different loglevels. Messages with a higher priority
than console_loglevel will be printed to the console.
Messages without an explicit priority will be printed
with priority default_message_level.
minimum_console_loglevel is the minimum (highest)
value to which console_loglevel can be set.
default_console_loglevel is the default value for
console_loglevel.
Note that, like nice(2) values, the lower values have higher priorities.
The easiest way to make an execve() for path /foo/a to execute /foo/b is to bind-mount /foo/b on top of /foo/a:
mount -obind /foo/b /foo/a
No kernel module is required.
Doing this same task with a kernel module would be significantly more work; the LSM interface may provide you with some assistance in figuring out when exactly your target is being executed. If you're looking for a starting point, do_execve() in fs/exec.c is where to start reading. Be sure to have ctags installed, run, and know how to use your editor's ctags integration, to make reading the code significantly easier.
Answer about printk:
It prints to the console, not the terminal. But what's the console?
You can find its TTY in /proc/cmdline. Normally it's tty0, which means the screen connected to the computer.
If you connect via SSH/TELNET, surely you won't see this.
If you're working in a graphical environment (Gnome/KDE), you may need something like alt-F1/F2 to switch to a text mode TTY.
You can also use the dmesg command to see the messages.
I have an application that traces program execution through memory. I tried to use readelf --debug-dump=decodedline to get memory address / line # information, but the memory addresses I see don't match up often with the ones given by that dump. I wrote something to match up each address with the "most recent" one appearing in the DWARF data -- this seemed to clean some things up but I'm not sure if that's the "official" way to interpret this data.
Can someone explain the exact process to map a program address to line number using DWARF?
Have a look at the program addr2line. It can probably give you some guidance on how to do this, if not solving your problem entirely (e.g. by shelling out to it, or linking its functionality in).
Indeed, as mentioned by Phil Miller's answer, addr2line is your friend. I have a gist where I show how I get the line number in the (C++) application source code from an address obtained from a backtrace.
Following this process will not show you the process you mention, but can give you an idea of how the code gets mapped into the object code (in an executable or a library/archive). Hope it helps.