UART4 at high speed cause crash

Hello everyone,
I set up the following jig to evaluate BBB UART performances:

PC (Win7) <-> USB <-> FTDI <-> 3.3V-RS232 <-> BBB UART4 <-> BBB ETH0 <-> PC

Using Teraterm on my PC, running Minicom on the BBB and monitoring the BBB with Putty SSH.
Serial commuication works fine. I am able to exchange binary and ASCII files in both direction up to a 57600 serial communication speed.
btw I am using HW flow control, but the speed is so low data flow is never paused.
Now when I raise the speed to 115200, try sending a large (600k) file from Teraterm almost invariably crash the BBB dead: leds stop blinking, no console response, and I need to reset the board.

kern.log and message.log, examined after the subsequent reset, do not report anything suspicious happening after the UART overlays:

Jan 3 01:42:31 BBBK2513292915 kernel: [ 17.301956] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Jan 3 17:35:21 BBBK2513292915 kernel: [57187.743075] bone-capemgr bone_capemgr.9: part_number ‘BB-UART4’, version ‘N/A’
Jan 3 17:35:21 BBBK2513292915 kernel: [57187.753304] bone-capemgr bone_capemgr.9: slot #7: generic override
Jan 3 17:35:21 BBBK2513292915 kernel: [57187.760015] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 7
Jan 3 17:35:21 BBBK2513292915 kernel: [57187.768339] bone-capemgr bone_capemgr.9: slot #7: ‘Override Board Name,00A0,Override Manuf,BB-UART4’
Jan 3 17:35:21 BBBK2513292915 kernel: [57187.778730] bone-capemgr bone_capemgr.9: slot #7: Requesting part number/version based 'BB-UART4-00A0.dtbo
Jan 3 17:35:21 BBBK2513292915 kernel: [57187.789089] bone-capemgr bone_capemgr.9: slot #7: Requesting firmware ‘BB-UART4-00A0.dtbo’ for board-name ‘Override Board Name’, version ‘00A0’
Jan 3 17:35:21 BBBK2513292915 kernel: [57187.806841] bone-capemgr bone_capemgr.9: slot #7: dtbo ‘BB-UART4-00A0.dtbo’ loaded; converting to live tree
Jan 3 17:35:21 BBBK2513292915 kernel: [57187.818898] bone-capemgr bone_capemgr.9: slot #7: #2 overlays
Jan 3 17:35:22 BBBK2513292915 kernel: [57187.835403] 481a8000.serial: ttyO4 at MMIO 0x481a8000 (irq = 45) is a OMAP UART4
Jan 3 17:35:22 BBBK2513292915 kernel: [57187.854892] bone-capemgr bone_capemgr.9: slot #7: Applied #2 overlays.
Jan 3 17:35:30 BBBK2513292915 kernel: [57196.811335] bone-capemgr bone_capemgr.9: part_number ‘BB-UART4-RTSCTS’, version ‘N/A’
Jan 3 17:35:31 BBBK2513292915 kernel: [57196.821155] bone-capemgr bone_capemgr.9: slot #8: generic override
Jan 3 17:35:31 BBBK2513292915 kernel: [57196.827873] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 8
Jan 3 17:35:31 BBBK2513292915 kernel: [57196.836043] bone-capemgr bone_capemgr.9: slot #8: ‘Override Board Name,00A0,Override Manuf,BB-UART4-RTSCTS’
Jan 3 17:35:31 BBBK2513292915 kernel: [57196.847050] bone-capemgr bone_capemgr.9: slot #8: Requesting part number/version based 'BB-UART4-RTSCTS-00A0.dtbo
Jan 3 17:35:31 BBBK2513292915 kernel: [57196.857992] bone-capemgr bone_capemgr.9: slot #8: Requesting firmware ‘BB-UART4-RTSCTS-00A0.dtbo’ for board-name ‘Override Board Name’, version ‘00A0’
Jan 3 17:35:31 BBBK2513292915 kernel: [57196.876202] bone-capemgr bone_capemgr.9: slot #8: dtbo ‘BB-UART4-RTSCTS-00A0.dtbo’ loaded; converting to live tree
Jan 3 17:35:31 BBBK2513292915 kernel: [57196.888618] bone-capemgr bone_capemgr.9: slot #8: #2 overlays
Jan 3 17:35:31 BBBK2513292915 kernel: [57196.902380] bone-capemgr bone_capemgr.9: slot #8: Applied #2 overlays.

The same happens at 230400 and 460800, but oddly at 921600, apart from getting sometimes a spare char wrong, the BBB does not crash and ascii file transfers are succesfull ( I didn’t try binary because bit errors will provoke CRC error and resending )
Given that the serial communication link works and that data flow is controlled perfectly at very high speed I ruled out any hardware problem, and using minicom I think I ruled out any user software application mistake, so I suspect the problem is in the BBB linux, I am using the provided debian image, interaction with ttyO4 causing the crash.
Does anyone have an clue for what’s happening, a suggestion or at least an investigational route to propose?
Thanks for helping