Bug 1548425 - bad char encoding on pty with ppc64le
Summary: bad char encoding on pty with ppc64le
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: ppc64le
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: PPCTracker
TreeView+ depends on / blocked
 
Reported: 2018-02-23 13:27 UTC by Menanteau Guy
Modified: 2018-03-13 09:57 UTC (History)
18 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2018-03-13 09:57:31 UTC


Attachments (Terms of Use)

Description Menanteau Guy 2018-02-23 13:27:14 UTC
Description of problem:
After creating a VM with rawhide iso Fedora-Server-dvd-ppc64le-Rawhide-20180218.n.0.iso, I got curious behaviour on pty (bad char encoding) when I do some commands.

let's see a sample:
I do a simple command like this one below several time
[root@vm55 ~]# ls | grep sample
[root@vm55 ~]#

some time the command is not working correctly
[root@vm55 ~]# ls | grep sample
-bash:  grep: command not found

if a do a copy paste of each command behind in a file and look at it in hexa, I got the following:
[root@vm55 ~]# echo 'ls | grep sample' > sample.ko                              [root@vm55 ~]# echo 'ls | grep sample' > sample.ok
[root@vm55 ~]# hexdump -C sample.ok
00000000  6c 73 20 7c 20 67 72 65  70 20 73 61 6d 70 6c 65  |ls | grep sample|
00000010  0a                                                |.|
00000011
[root@vm55 ~]# hexdump -C sample.ko
00000000  6c 73 20 7c c2 a0 67 72  65 70 20 73 61 6d 70 6c  |ls |..grep sampl|
00000010  65 0a                                             |e.|
00000012

The command having the problem have a bad blank coding char just after the pipe
ok: blank is 20
ko: blank is c2 a0 (note that we can still the 2 and 0 but on different bytes)

This is always reproductible. I tried it with different english languages (gb, us ...) installations with different qemu versions.
[root@vm55 ~]# localectl
   System Locale: LANG=en_US.UTF-8
       VC Keymap: us
      X11 Layout: us
[root@vm55 ~]# uname -r
4.16.0-0.rc1.git4.1.fc28.ppc64le

Comment 1 Dan Horák 2018-03-02 11:17:56 UTC
Guy, do you see this behaviour in a ssh session or in the graphical console in eg. PowerKVM/Kimchi or RHEV?

Comment 2 Menanteau Guy 2018-03-02 14:19:34 UTC
Problem is on ssh and screen sessions of a VM qemu machine (as for openqa).
We did not see the problem on PowerKVM so far (even thru ssh).

I run this kind of command to create the VM machine. 
/usr/bin/qemu-system-ppc64 -name f28_55 -enable-kvm -M pseries -smp 4 -m 8G -nographic -nodefaults -monitor stdio -serial pty -device virtio-net-pci,netdev=net10095,mac=c0:ff:ee:00:00:01 -netdev bridge,br=br0,id=net10095 -cdrom isole -drive file=hd1.qcow2 -drive file=hd2.qcow2 -S

then, ssh on the IP address or a screen command on the char device redirected by qemu (ex: screen /dev/pts/1) and the problem appears after running several time the same command.

Comment 3 Menanteau Guy 2018-03-13 09:57:31 UTC
This problem is no more present on last f28 and rawhide isos
I checked on Fedora-Server-dvd-ppc64le-28-20180312.n.0.iso and Fedora-Server-dvd-ppc64le-Rawhide-20180312.n.0.iso
openqa is working again without char problem too.


Note You need to log in before you can comment on or make changes to this bug.