Linux – Why do kernel oopses taint and prohibit reporting with ABRT

Well I don't believe a standard Fedora kernel package will include any modules which would trigger this taint so the question is, what other kernel modules have you installed?

Common candidates would be graphics drivers (though I think those will mostly set the "proprietary" bit) and wireless drivers.

If you can find anything in the lsmod output that you think may be a candidate then run modinfo <module-name> and see if the output includes intree: Y as any module without that will trigger the taint you are seeing.

UPDATE: The rts5139 module that you're seeing in lsmod but which doesn't seem to be on your system is probably in the initrd and is being loaded from there early in the boot process before the main filesystem is mounted.

That also explains why blacklisting won't work as you would have to rebuild the initrd with the updated blacklist. Rebuilding the initrd with dracut will cause the module to go away anyway though.

1) Why would all the rescheduled sectors be exactly 8 apart?

Such gaps in the sector numbers are to be expected, the question is more how large those gaps would be (4k or larger). 8x 512 bytes are 4k which is the sector size most filesystems work with. So the filesystem probably requested to read 4k from the RAID, the RAID asks the /dev/sdb for that data. The first sector of that read fails (that's the sector number you see in your logs), the RAID switches to /dev/sda and serves the 4k from there. Then the filesystem requests to read the next 4k, back to /dev/sdb with sector number +8 which fails again which is again what you see in your logs ...

2) Why would the kernel become unresponsive and require a reboot?

Shouldn't happen normally. The problem is that the reallocation situation is about the most expensive you can get. Each read that fails, has to be redirected to the other disk, has to be rewritten on the original disk, etc. If it fills your log file at the same time, causing in turn new write requests, which in turn have to be reallocated again, etc. It would be cheaper to just kick the disk out entirely in this case.

It's also a question of how the rest of the hardware (such as the SATA controller) handles failing drives. If the controller itself gets a hiccup from it, it will hurt performance even more.

It's hard to tell what happened exactly if there is no log entry; it's a weak point of the Linux kernel, there is no straightforward solution to preserve those last messages when things really go south.

3) Why would the unreadable and offline uncorrectable counts reset only 23 hours after the raid resync was complete?

Some values are updated only when you do offline data collection (UPDATED Offline column), that may take some time. If the disk is set to do this automatically, it depends on the disk, e.g. every four hours. If you don't want to rely on the disk, you should set it up using smartmontools.