Bug 1548425

Summary: bad char encoding on pty with ppc64le
Product: [Fedora] Fedora Reporter: Menanteau Guy <menantea>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: airlied, ajax, bskeggs, dan, ewk, hdegoede, ichavero, itamar, jarodwilson, jglisse, john.j5live, jonathan, josef, kernel-maint, linville, mchehab, mjg59, steved
Target Milestone: ---   
Target Release: ---   
Hardware: ppc64le   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-03-13 09:57:31 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1071880    

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.