====== Kernel Messages ======

This is a collection of trying to make sense of some output that can be seen by ''dmesg'' or looking at your system log.

Here's one I get when putting a DVD in the drive (and I only figured this out on accident, but it's been haunting me for years, so hurray!):

<code>
Apr  9 02:19:34 tux kernel: sr 1:0:0:0: [sr0] tag#15 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr  9 02:19:34 tux kernel: sr 1:0:0:0: [sr0] tag#15 Sense Key : Illegal Request [current]
Apr  9 02:19:34 tux kernel: sr 1:0:0:0: [sr0] tag#15 Add. Sense: Read of scrambled sector without authentication
Apr  9 02:19:34 tux kernel: sr 1:0:0:0: [sr0] tag#15 CDB: Read(10) 28 00 00 31 29 80 00 00 40 00
Apr  9 02:19:34 tux kernel: blk_update_request: I/O error, dev sr0, sector 12887552
Apr  9 02:19:34 tux kernel: sr 1:0:0:0: [sr0] tag#16 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr  9 02:19:34 tux kernel: sr 1:0:0:0: [sr0] tag#16 Sense Key : Illegal Request [current]
Apr  9 02:19:34 tux kernel: sr 1:0:0:0: [sr0] tag#16 Add. Sense: Read of scrambled sector without authentication
Apr  9 02:19:34 tux kernel: sr 1:0:0:0: [sr0] tag#16 CDB: Read(10) 28 00 00 31 29 80 00 00 02 00
Apr  9 02:19:34 tux kernel: blk_update_request: I/O error, dev sr0, sector 12887552
Apr  9 02:19:34 tux kernel: Buffer I/O error on dev sr0, logical block 1610944, async page read
Apr  9 02:19:36 tux kernel: sr 1:0:0:0: [sr0] tag#17 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr  9 02:19:36 tux kernel: sr 1:0:0:0: [sr0] tag#17 Sense Key : Illegal Request [current]
Apr  9 02:19:36 tux kernel: sr 1:0:0:0: [sr0] tag#17 Add. Sense: Read of scrambled sector without authentication
Apr  9 02:19:36 tux kernel: sr 1:0:0:0: [sr0] tag#17 CDB: Read(10) 28 00 00 31 29 80 00 00 40 00
Apr  9 02:19:36 tux kernel: blk_update_request: I/O error, dev sr0, sector 12887552
Apr  9 02:19:36 tux kernel: sr 1:0:0:0: [sr0] tag#18 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr  9 02:19:36 tux kernel: sr 1:0:0:0: [sr0] tag#18 Sense Key : Illegal Request [current]
Apr  9 02:19:36 tux kernel: sr 1:0:0:0: [sr0] tag#18 Add. Sense: Read of scrambled sector without authentication
Apr  9 02:19:36 tux kernel: sr 1:0:0:0: [sr0] tag#18 CDB: Read(10) 28 00 00 31 29 80 00 00 02 00
Apr  9 02:19:36 tux kernel: blk_update_request: I/O error, dev sr0, sector 12887552
Apr  9 02:19:36 tux kernel: Buffer I/O error on dev sr0, logical block 1610944, async page read
</code>

When you put a disc in the drive, there's a [[udev]] rule that runs [[cdrom_id]] to get the device variables (which is an ingenious program, I might add).

You can see what udev is doing at ''/lib64/udev/rules.d/60-cdrom_id.rules''

It's tiny and mostly self-explanatory, so I'll post the whole thing here:

<code>
# do not edit this file, it will be overwritten on update

ACTION=="remove", GOTO="cdrom_end"
SUBSYSTEM!="block", GOTO="cdrom_end"
KERNEL!="sr[0-9]*|xvd*", GOTO="cdrom_end"
ENV{DEVTYPE}!="disk", GOTO="cdrom_end"

# unconditionally tag device as CDROM
KERNEL=="sr[0-9]*", ENV{ID_CDROM}="1"

# media eject button pressed
ENV{DISK_EJECT_REQUEST}=="?*", RUN+="cdrom_id --eject-media $devnode", GOTO="cdrom_end"

# import device and media properties and lock tray to
# enable the receiving of media eject button events
IMPORT{program}="cdrom_id --lock-media $devnode"

# ejecting a CD does not remove the device node, so mark the systemd device
# unit as inactive while there is no medium; this automatically cleans up of
# stale mounts after ejecting
ENV{DISK_MEDIA_CHANGE}=="?*", ENV{ID_CDROM_MEDIA}!="?*", ENV{SYSTEMD_READY}="0"

KERNEL=="sr0", SYMLINK+="cdrom", OPTIONS+="link_priority=-100"

LABEL="cdrom_end"
</code>

It's the ''cdrom_id'' call to lock the media that is causing it.

The output is harmless. You can safely ignore it.