Antw: 3.0.101: "blk_rq_check_limits: over max size limit."

Hi once more! I managed to get the call traces of involved processes: 1) The process doing read(): Dec 7 13:51:16 h10 kernel: [183809.594434] SysRq : Show Blocked State Dec 7 13:51:16 h10 kernel: [183809.594447] taskPC stack pid father Dec 7 13:51:16 h10 kernel: [1

Antw: 3.0.101: "blk_rq_check_limits: over max size limit."

Hi again! An addition: Processes doing such I/O seem to be unkillable, and I also cannot change the queue parameters while this problem occurs (the process trying to write (e.g.: to queue/scheduler) is also blocked. The process status of the process doing I/O looks like this: # cat /proc/2762/s

Antw: 3.0.101: "blk_rq_check_limits: over max size limit."

Hi again! Maybe someone can confirm this: If you have a device (e.g. multipath map) that limits max_sectors_kb to maybe 64, and then define an LVM LV using that multipath map as PV, the LV still has a larger max_sectors_kb. If you send a big request (read in my case), the kernel will complain:

3.0.101: "blk_rq_check_limits: over max size limit."

Hello! While performance-testing a 3PARdata StorServ 8400 with SLES11SP4, I noticed that I/Os dropped, until everything stood still more or less. Looking into the syslog I found that multipath's TUR-checker considered the paths (FC, BTW) as dead. Amazingly I did not have this problem when I did