It's more complicated. Look at the top of the screen: FreeBSD recognizes the drive as being connected via (S)ATA, at ata2, using UDMA2, and protocol ATAPI. Now, what is ATAPI? It is a way to send SCSI-style commands over an ATA interfaces, and the de-facto standard for accessing CD-ROM drives in the last 10 or 15 years. Then FreeBSD correctly and sensibly sends a SCSI read command to the drive, namely a READ(10) command consisting of the bytes 28 00 00 04 8b 21 00 00 01 00. OK, so let's go decode that read command: Opcode=28 (correct), flags=00 (all flags, in particular DPO and FUA are off), logical block address = 00 04 8b 21 (which is decimal 29776, perfectly sensible for a CD), group number 00, transfer length 00 01 = 1 block, and no control at the end. A perfectly sensible read command. The drive responds with ASC/ASCQ=64/00, which means illegal request, illegal mode for this track. By the way, you can find the decoder rings for commands and ASC/ASCQ on the T10 web site (T10 is the committee that defines SCSI), for example
https://www.t10.org/lists/asc-num.htm.
So what is this telling us? That this is indeed an ATAPI drive, because in order to get here, we must have already gone through several command phases, for example sending an Inquiry command to find out what kind of device it is (which succeeded, because we got the complete SCSI-style vital parameter data, namely manufacturer, model and revision), but that reading a block is something that this track on the disk can not do.
I looked up the model, and the LiteOn LNT 486 S is a completely boring IDE / ATAPI CD ROM drive.
Here's my suspicion, which is along the lines of what Jose is saying: I think there might be a music CD in the drive, and on music tracks, you can't do block reads.