war story: read you kernel log (dmesg) once in a while
[One reason for this message is to test if the mailing list is working. I haven't seen a new message in a 10 days.] dmseg command ============= The dmesg command shows you the kernel log. It takes the log from the kernel itself. It is stored in a circular RAM buffer, so you can still read it if the normal logging system isn't working. This buffer is a fixed size so older messages can get pushed out by newer ones if there is enough logging going on. You can get more info on Fedora by journalctl -b but it isn't limited to kernel messages. It does colour-code messages based on severity, so that's a nice plus. Since this log typically goes to disk, it tends to be complete. Oh: the -b flag means: start from the most recent boot -- logs can go back months and years. As an old timer, my first instinct is to use dmesg. looking at kernel messages ========================== dmesg | less -i dmesg pours out a lot of lines. less is a good way of navigating this log. The -i makes searches within less case-insensitive. The Linux kernel is meant to log problems and move on. This means that there can be problems that you don't even know about because all looks well. I think it pays to once in a while look for problems reported in the log. A lot of messages will be inscrutable. If they intrigue you, investigate them. Here's one I noticed recently on one of my systems. It's been there for the whole life of the system, but I never noticed. [ 2.545003] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 2.545482] ata1.00: supports DRM functions and may not be fully accessible [ 2.545554] ata1.00: READ LOG DMA EXT failed, trying unqueued [ 2.548363] ata1.00: disabling queued TRIM support [ 2.548370] ata1.00: ATA-9: Crucial_CT240M500SSD1, MU05, max UDMA/133 [ 2.548376] ata1.00: 468862128 sectors, multi 16: LBA48 NCQ (depth 31/32), AA [ 2.551973] ata1.00: supports DRM functions and may not be fully accessible [ 2.554812] ata1.00: disabling queued TRIM support [ 2.558006] ata1.00: configured for UDMA/133 Look at "disabling queued TRIM support". What's that about? - TRIM is a useful feature in SSDs. It allows the OS to advise the SSD that chunks of the filesystem are no longer needed (eg. deleted files). This helps the SSD's wear-levelling firmware's garbage collector. It should help speed up the SSD and add to its lifetime. - Even without queued TRIM, TRIM can still be accomplished. Queued TRIM is some higher-performance variant (I haven't investigate). But what's up with this message? Googling got me to <https://bugzilla.kernel.org/show_bug.cgi?id=71371> Very useful. - apparently my SSD (a Crucial M500) had buggy firmware, leading to corruption in some cases. Including queue TRIM - Crucial released new firmware (in 2015) <https://www.crucial.com/support/ssd-support/m500-support> - my SSD has this firmware (MU05), as reported in the dmesg output - even after the update, M500's screw up queued TRIM - the Linux kernel embeds all this wisdom and it blacklists queued TRIM on my box I spent an hour investigating this. There was no effect, except that I learned a few things. Linux just does the right thing. I do recommend also looking at journalctl output because it highlights things that it thinks are of particular interest.
Hi, Thank you for your war story, for me it was very useful as it relates to SSD :) On Fri, 19 Mar 2021 11:24:11 -0400 (EDT) "D. Hugh Redelmeier via talk" <talk@gtalug.org> wrote:
[One reason for this message is to test if the mailing list is working. I haven't seen a new message in a 10 days.]
dmseg command =============
The dmesg command shows you the kernel log. It takes the log from the kernel itself. It is stored in a circular RAM buffer, so you can still read it if the normal logging system isn't working. This buffer is a fixed size so older messages can get pushed out by newer ones if there is enough logging going on.
You can get more info on Fedora by journalctl -b but it isn't limited to kernel messages. It does colour-code messages based on severity, so that's a nice plus. Since this log typically goes to disk, it tends to be complete. Oh: the -b flag means: start from the most recent boot -- logs can go back months and years.
As an old timer, my first instinct is to use dmesg.
looking at kernel messages ==========================
dmesg | less -i
dmesg pours out a lot of lines. less is a good way of navigating this log. The -i makes searches within less case-insensitive.
The Linux kernel is meant to log problems and move on. This means that there can be problems that you don't even know about because all looks well. I think it pays to once in a while look for problems reported in the log.
A lot of messages will be inscrutable. If they intrigue you, investigate them.
Here's one I noticed recently on one of my systems. It's been there for the whole life of the system, but I never noticed.
[ 2.545003] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 2.545482] ata1.00: supports DRM functions and may not be fully accessible [ 2.545554] ata1.00: READ LOG DMA EXT failed, trying unqueued [ 2.548363] ata1.00: disabling queued TRIM support [ 2.548370] ata1.00: ATA-9: Crucial_CT240M500SSD1, MU05, max UDMA/133 [ 2.548376] ata1.00: 468862128 sectors, multi 16: LBA48 NCQ (depth 31/32), AA [ 2.551973] ata1.00: supports DRM functions and may not be fully accessible [ 2.554812] ata1.00: disabling queued TRIM support [ 2.558006] ata1.00: configured for UDMA/133
Look at "disabling queued TRIM support". What's that about?
- TRIM is a useful feature in SSDs. It allows the OS to advise the SSD that chunks of the filesystem are no longer needed (eg. deleted files). This helps the SSD's wear-levelling firmware's garbage collector. It should help speed up the SSD and add to its lifetime.
- Even without queued TRIM, TRIM can still be accomplished. Queued TRIM is some higher-performance variant (I haven't investigate).
But what's up with this message? Googling got me to <https://bugzilla.kernel.org/show_bug.cgi?id=71371> Very useful.
- apparently my SSD (a Crucial M500) had buggy firmware, leading to corruption in some cases. Including queue TRIM
- Crucial released new firmware (in 2015) <https://www.crucial.com/support/ssd-support/m500-support>
- my SSD has this firmware (MU05), as reported in the dmesg output
- even after the update, M500's screw up queued TRIM
- the Linux kernel embeds all this wisdom and it blacklists queued TRIM on my box
I spent an hour investigating this. There was no effect, except that I learned a few things. Linux just does the right thing.
I do recommend also looking at journalctl output because it highlights things that it thinks are of particular interest. --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
On 2021-03-19 11:24, D. Hugh Redelmeier via talk wrote:
[One reason for this message is to test if the mailing list is working. I haven't seen a new message in a 10 days.]
dmseg command =============
The dmesg command shows you the kernel log. It takes the log from the kernel itself. It is stored in a circular RAM buffer, so you can still read it if the normal logging system isn't working. This buffer is a fixed size so older messages can get pushed out by newer ones if there is enough logging going on.
You can get more info on Fedora by journalctl -b but it isn't limited to kernel messages. It does colour-code messages based on severity, so that's a nice plus. Since this log typically goes to disk, it tends to be complete. Oh: the -b flag means: start from the most recent boot -- logs can go back months and years.
As an old timer, my first instinct is to use dmesg.
looking at kernel messages ==========================
dmesg | less -i
dmesg pours out a lot of lines. less is a good way of navigating this log. The -i makes searches within less case-insensitive.
A good read. Thanks for sharing! Small note: On Debian (and other distros?) if a non-root user runs dmesg to read the contents of the kernel message buffer they will see ... dmesg: read kernel buffer failed: Operation not permitted Turns out it is a security feature - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842226#15 To allow users to read the kernel log without being prompted for a password, modify /etc/sysctl.conf by adding ... kernel.dmesg_restrict = 0 ... and reload the configuration ... $ sudo sysctl -p
participants (3)
-
ac -
D. Hugh Redelmeier -
Daniel Wayne Armstrong