according to SMART hard disk is not broken, but I have errors in dmesg

First, keep in mind that SMART saying that your drive is healthy doesn't necessarily mean that the drive is healthy. SMART reports are an aid, not an absolute truth.

If all you are interested in is what to do, rather than why, then feel free to scroll down to the last few paragraphs; however, the interim text will tell you why I think what I propose is the correct course of action, and how to derive that from what you posted.

With that said, let's look at what one of those errors are telling us.

[ 1670.547805] ata3.00: exception Emask 0x50 SAct 0x7f SErr 0x280900 action 0x6 frozen
[ 1670.547812] ata3.00: irq_stat 0x08000000, interface fatal error
[ 1670.547820] ata3: SError: { UnrecovData HostInt 10B8B BadCRC }
[ 1670.547826] ata3.00: failed command: READ FPDMA QUEUED
[ 1670.547839] ata3.00: cmd 60/80:00:00:1f:2e/01:00:0c:00:00/40 tag 0 ncq 196608 in
           res 40/00:2c:00:26:2e/00:00:0c:00:00/40 Emask 0x50 (ATA bus error)
[ 1670.547846] ata3.00: status: { DRDY }
[ 1670.547852] ata3.00: failed command: READ FPDMA QUEUED

(I hope I got the parts that should go together, but you were getting a bundle of those so it should be okay either way.)

The Linux ata Wiki has a page explaining how to read these errors. Particularly,

• A status value of DRDY means "Device ready. Normally 1, when all is OK." Seeing a status value of DRDY is perfectly normal and expected.
• SError has multiple component values, of which you are seeing (in this particular snippet):
  • UnrecovData "Data integrity error occurred, interface did not recover"
  • HostInt "Host bus adapter internal error"
  • 10B8B "10b to 8b decoding error occurred"
  • BadCRC "Link layer CRC error occurred"

10b8b coding, which encodes 8 bits as 10 bits to aid with both signal synchronization and error detection, is used on the physical cabling, not necessarily on the drive itself. The drive most likely uses other forms of FEC or ECC coding, and an error there would normally show up as some form of I/O error, likely with an error value of UNC ("uncorrectable error - often due to bad sectors on the disk"), likely with "media error" ("software detected a media error") in parenthesis at the end of the res line. This latter is not what you are seeing, so while we can't completely rule it out, it seems unlikely.

The "link layer" is the physical cables and circuit board traces between the drive's own controller, and the disk drive interface chip (likely part of the southbridge on your computer's motherboard, but could be located at an offboard HBA).

A host bus adapter, also known as a HBA, is the circuitry that connects to storage equipment. Also colloquially known as a "disk controller", a term which is a bit of a misnomer with modern systems. The most visible part of the HBA is generally the connection ports, most often these days either SATA or some SAS form factor.

The UnrecovData and HostInt flags basically tell us that "something just went horribly wrong, and there was no way to recover or no attempt at recovery was made". The opposite would likely be RecovData, which indicates that a "data integrity error occurred, but the interface recovered". (As an aside, I probably would have used HBAInt instead of HostInt, as the "host" refers to the HBA, not the whole system.)

The combination of 10B8B and BadCRC, which both point to the physical link layer, makes me suspect a cabling issue.

This suspicion is also supported by the fact that the SMART self-tests, which are completely internal to the drive except for status reporting, are finding no errors that the manufacturer feels are serious enough to warrant reporting in the results. If the drive was having problems storing or reading data, the long SMART self-test in particular should have reported that.

TL;DR:

The first thing I would do is thus simply to unplug and re-plug the SATA cable at both ends; it may be slightly loose, causing it to lose electrical contact intermittently. See if that resolves the problem. It might even be worth doing this to all SATA cabling in your computer, not just the affected disk. If you are using an off-board HBA, I would also remove and re-seat that card, mainly because it's an easy thing to try while you are already messing around with the cabling.

Failing that, try throwing away and replacing the SATA cable, preferably with a high-quality cable. A high-quality cable will be slightly more expensive, but I find that it's usually well worth the small extra expense if it helps avoid headaches like this. Nobody likes seeing their storage spewing errors!