{"action":"opened","issue":{"url":"https://api.github.com/repos/openbmc/linux/issues/136","repository_url":"https://api.github.com/repos/openbmc/linux","labels_url":"https://api.github.com/repos/openbmc/linux/issues/136/labels{/name}","comments_url":"https://api.github.com/repos/openbmc/linux/issues/136/comments","events_url":"https://api.github.com/repos/openbmc/linux/issues/136/events","html_url":"https://github.com/openbmc/linux/issues/136","id":244590295,"number":136,"title":"VUART drops blocks of data on large host-side TX","user":{"login":"jk-ozlabs","id":8000933,"avatar_url":"https://avatars3.githubusercontent.com/u/8000933?v=4","gravatar_id":"","url":"https://api.github.com/users/jk-ozlabs","html_url":"https://github.com/jk-ozlabs","followers_url":"https://api.github.com/users/jk-ozlabs/followers","following_url":"https://api.github.com/users/jk-ozlabs/following{/other_user}","gists_url":"https://api.github.com/users/jk-ozlabs/gists{/gist_id}","starred_url":"https://api.github.com/users/jk-ozlabs/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jk-ozlabs/subscriptions","organizations_url":"https://api.github.com/users/jk-ozlabs/orgs","repos_url":"https://api.github.com/users/jk-ozlabs/repos","events_url":"https://api.github.com/users/jk-ozlabs/events{/privacy}","received_events_url":"https://api.github.com/users/jk-ozlabs/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2017-07-21T07:47:56Z","updated_at":"2017-07-21T07:47:56Z","closed_at":null,"body":"[I'm not yet convinced that this is specifically a BMC kernel issue, but tracking under openbmc/linux for now]\r\n\r\nIf I write 132kB of data to the host-side of the VUART, the BMC side only receives around 69-75kB of the written data. \r\n\r\non the host:\r\n\r\n```\r\n[jk@spoon2 ~]$ cat data | sudo dd of=/dev/hvc0\r\n256+0 records in\r\n256+0 records out\r\n131072 bytes (131 kB, 128 KiB) copied, 0.172273 s, 761 kB/s\r\n```\r\n\r\non the BMC:\r\n\r\n```\r\nroot@spoon2-bmc:~# hexdump -v -C /dev/ttyVUART0\r\n00000000  00 00 02 03 04 05 06 07  08 09 0a 0b 0c 0d 0e 0f  |................|\r\n00000010  10 11 12 13 14 15 16 17  18 19 1a 1b 1c 1d 1e 1f  |................|\r\n00000020  20 21 22 23 24 25 26 27  28 29 2a 2b 2c 2d 2e 2f  | !\"#$%&'()*+,-./|\r\n[…]\r\n000115c0  c0 c1 c2 c3 c4 c5 c6 c7  c8 c9 ca cb cc cd ce cf  |................|\r\n000115d0  d0 d1 d2 d3 d4 d5 d6 d7  d8 d9 da db dc dd de df  |................|\r\n000115e0  e0 e1 e2 e3 e4 e5 e6 e7  e8 e9 ea eb ec ed ee ef  |................|\r\n```\r\n\r\n\\- with `hexdump` waiting there for further data.\r\n\r\n[For those reproducing elsewhere, you'll need to first:\r\n * on the BMC: `systemctl stop obmc-console@ttyVUART0`\r\n * on the BMC: `stty -F /dev/ttyVUART0 raw`\r\n * on the host: `stty -F /dev/hvc0 raw`\r\n\r\n]\r\n\r\nGiven that we should be seeing 0x20000 bytes output, we're about 0xea10 bytes short there. This delta is a little variable (more detail below) but always seems to end on an 0xf0 boundary. With the specific data pattern that I'm using, the data always seems to be truncated (no missing data occurs before that point).\r\n\r\nOver 20 runs, here are the lengths that I see:\r\n\r\n0x115f0\r\n0x114f0\r\n0x116f0\r\n0x115f0\r\n0x115f0\r\n0x114f0\r\n0x116f0\r\n0x115f0\r\n0x114f0\r\n0x115f0\r\n0x115f0\r\n0x118f0\r\n0x114f0\r\n0x114f0\r\n0x113f0\r\n0x124f0\r\n0x114f0\r\n0x114f0\r\n0x115f0\r\n0x115f0\r\n"}}
{"actor":{"display_login":"jk-ozlabs"}}