반응형

OS: Ubuntu 16.04 (amd64)

GPU: AMD Radeon HD 7850



우분투 16.04에서 그래픽 카드로 AMD 것을 썼더니, 그다지 매끄럽게 잘 작동하는 것 같지가 않다. 몇 년 전에 비하면 점점 좋아지고는 있지만, Nvidia 그래픽 카드에 비하면 여전히 오류가 많이 발생하는 것이 체감된다.


나는 업무 특성상 우분투 PC에 연결된 모니터 2개를 다 쓰다가 가끔 출력을 모니터 1개로만 내보내는 등의 디스플레이 설정을 자주 변경하는 편인데, 그러는 과정에서 열에 한 번 정도는 화면을 재구성하는 과정에서 화면 전체가 멈추는(freezing) 문제가 발생한다.


(Ubuntu 16.04에 있는 디스플레이 설정)


증상을 보면, 마우스는 마음대로 움직일 수 있는데, 화면 전체가 고정된 이미지처럼 꼼짝도 하지 않고 아무 것도 클릭할 수 없다. 키보드로 몇몇 단축키(창 닫기, Super 키를 눌러서 Unity 메뉴 보이기 등의 시도)를 눌러 봐도 화면 상에는 아무 변화가 일어나지 않는다.


하지만 정작 시스템은 멀쩡하게 돌고 있는 상황이다. 다른 컴퓨터에서 SSH로 접속해도 잘 되고, 웹 서버도 잘 돌고 있고, 데스크탑 화면에서 돌리는 모든 프로그램이 다 켜져 있는 것으로 잡히기 때문이다. 즉, 유일하게 화면을 '그리는(?)' 부분만 고장이 났다고 볼 수 있다.


가장 쉬운 해결 방법은 물론 그냥 전원 버튼을 직접 눌러서 강제로 재부팅하거나, 쉘이 작동한다면 sudo reboot 명령으로 재부팅하는 방법이겠지만, 기왕이면 이미 돌아가고 있는 서비스들을 유지하고 화면만 복구하는 것이 좋을 것이다.


Unity의 디스플레이 설정이 모니터 2개를 제어하는 과정에서 문제를 일으키거나, Unity (lightdm 서비스) 자체가 오류가 나서 다운되는 경우이므로 이 두 가지를 해결하는 것이 핵심이다.

내가 시도해 본 해결 방법은 다음과 같다.



1. Ctrl + Alt + F1 키를 눌러서 tty1 쉘 화면에 진입한다.

만약 이것이 뜨지 않는다면, 다른 컴퓨터에서 SSH를 통해 접속이 되는지 확인한다. SSH로도 접속이 안 되면 정말로 시스템이나 커널이 다운된 것이므로 강제로 재부팅을 해야 한다.



2. 쉘에 로그인한 뒤, 문제의 원인이 되는 디스플레이 설정 프로세스를 검색한다.


$ ps -ef | grep unity-control-center


만약 프로세스가 실행 중인 것으로 검색이 되면, 해당하는 프로세스의 PID를 가지고 kill 한다.

$ sudo kill -9 [PID of unity-control-center]



3. Ctrl + Alt + F7 키를 눌러서 다시 우분투 Unity 화면으로 돌아온다.

만약 화면이 정상적으로 반응을 한다면 고쳐진 것이다.



4. 3번까지 했는데도 여전히 화면이 아무 반응이 없으면, Ctrl + Alt + F1 키를 눌러서 다시 tty1 쉘 화면에 진입하고, 아래 명령으로 lightdm 서비스를 재시작한다.


$ sudo service lightdm restart



그러면 곧바로 우분투 데스크탑 로그인 화면이 뜰 것이다.

아쉽지만, lightdm 서비스를 재시작하게 되면 그 전에 화면에 띄워져 있던 어플리케이션은 모두 강제 종료된다.



사족)

잠깐... 이러면 재부팅과 거의 다를 바가 없잖아? ㅠㅠ

그래도 재부팅보다는 빨리 복귀할 수는 있으니 조금 더 좋은 걸로?

그리고 백그라운드 서비스 몇 개는 살아 있으니까 완전 재부팅은 아님..





반응형
블로그 이미지

Bryan_

,
반응형

테스트 대상 기기: 삼성 갤럭시 노트3 네오, LGU+ (SM-N750L)

Android 버전: 4.4.2


스마트폰을 통한 네트워크 실험을 하는 과정에서, 여러 차례 와이파이에 연결된 스마트폰에 ping을 날려야 하는 경우가 있었다. 화면이 꺼져 있더라도 옵션을 통해서 와이파이에 항상 연결되어 있게 할 수는 있는데, 유독 화면이 꺼져 있을 때에 ping 속도가 느린 것 같다는 느낌이 들어서 실제로 테스트를 해 보았다.

샘플 수가 20개라서 사실 많지는 않지만, 그래도 동일한 환경에서 주변에 다른 방해하는 기기가 거의 없는 새벽 시간대에 해 본 것이라서 어느 정도 의미는 있을 것으로 생각한다.


테스트 환경으로, 라즈베리파이 2B에 hostapd를 돌려서 가상 AP로 만들고, 스마트폰이 그 AP에 연결되도록 했다.

라즈베리파이는 Raspbian Jessie 운영체제에 Atheros ath9k-htc 기반의 USB 무선랜카드를 달고 있고, IEEE 802.11n 모드로 AP를 돌렸다.

테스트용 스마트폰 외에 무선으로 연결된 다른 연결된 기기는 없었다.


아래는 화면이 꺼져 있을 때, 의 ping 결과이다.

pi@raspberrypi ~/exp $ ping 10.0.5.10

PING 10.0.5.10 (10.0.5.10) 56(84) bytes of data.

64 bytes from 10.0.5.10: icmp_seq=1 ttl=64 time=289 ms

64 bytes from 10.0.5.10: icmp_seq=2 ttl=64 time=113 ms

64 bytes from 10.0.5.10: icmp_seq=3 ttl=64 time=344 ms

64 bytes from 10.0.5.10: icmp_seq=4 ttl=64 time=157 ms

64 bytes from 10.0.5.10: icmp_seq=5 ttl=64 time=204 ms

64 bytes from 10.0.5.10: icmp_seq=6 ttl=64 time=164 ms

64 bytes from 10.0.5.10: icmp_seq=7 ttl=64 time=188 ms

64 bytes from 10.0.5.10: icmp_seq=8 ttl=64 time=9.65 ms

64 bytes from 10.0.5.10: icmp_seq=9 ttl=64 time=237 ms

64 bytes from 10.0.5.10: icmp_seq=10 ttl=64 time=276 ms

64 bytes from 10.0.5.10: icmp_seq=11 ttl=64 time=80.7 ms

64 bytes from 10.0.5.10: icmp_seq=12 ttl=64 time=105 ms

64 bytes from 10.0.5.10: icmp_seq=13 ttl=64 time=126 ms

64 bytes from 10.0.5.10: icmp_seq=14 ttl=64 time=205 ms

64 bytes from 10.0.5.10: icmp_seq=15 ttl=64 time=220 ms

64 bytes from 10.0.5.10: icmp_seq=16 ttl=64 time=258 ms

64 bytes from 10.0.5.10: icmp_seq=17 ttl=64 time=254 ms

64 bytes from 10.0.5.10: icmp_seq=18 ttl=64 time=290 ms

64 bytes from 10.0.5.10: icmp_seq=19 ttl=64 time=312 ms

64 bytes from 10.0.5.10: icmp_seq=20 ttl=64 time=135 ms

^C

--- 10.0.5.10 ping statistics ---

20 packets transmitted, 20 received, 0% packet loss, time 19025ms

rtt min/avg/max/mdev = 9.658/198.845/344.289/84.791 ms



아래는 스마트폰 화면을 켜고, 바탕화면을 전환하거나 카카오톡 앱을 한번 켜 보는 등 화면을 켜져 있도록 유지했을 때의 ping 결과이다. 카카오톡을 켤 때 잠시 서버에 접속하는 경우를 제외하고는 스마트폰에서 별도로 트래픽을 발생시키지 않았다.


pi@raspberrypi ~/exp $ ping 10.0.5.10

PING 10.0.5.10 (10.0.5.10) 56(84) bytes of data.

64 bytes from 10.0.5.10: icmp_seq=1 ttl=64 time=146 ms

64 bytes from 10.0.5.10: icmp_seq=2 ttl=64 time=67.5 ms

64 bytes from 10.0.5.10: icmp_seq=3 ttl=64 time=81.2 ms

64 bytes from 10.0.5.10: icmp_seq=4 ttl=64 time=133 ms

64 bytes from 10.0.5.10: icmp_seq=5 ttl=64 time=128 ms

64 bytes from 10.0.5.10: icmp_seq=6 ttl=64 time=147 ms

64 bytes from 10.0.5.10: icmp_seq=7 ttl=64 time=175 ms

64 bytes from 10.0.5.10: icmp_seq=8 ttl=64 time=98.5 ms

64 bytes from 10.0.5.10: icmp_seq=9 ttl=64 time=109 ms

64 bytes from 10.0.5.10: icmp_seq=10 ttl=64 time=9.62 ms

64 bytes from 10.0.5.10: icmp_seq=11 ttl=64 time=66.1 ms

64 bytes from 10.0.5.10: icmp_seq=12 ttl=64 time=81.9 ms

64 bytes from 10.0.5.10: icmp_seq=13 ttl=64 time=108 ms

64 bytes from 10.0.5.10: icmp_seq=14 ttl=64 time=139 ms

64 bytes from 10.0.5.10: icmp_seq=15 ttl=64 time=146 ms

64 bytes from 10.0.5.10: icmp_seq=16 ttl=64 time=75.2 ms

64 bytes from 10.0.5.10: icmp_seq=17 ttl=64 time=5.52 ms

64 bytes from 10.0.5.10: icmp_seq=18 ttl=64 time=4.06 ms

64 bytes from 10.0.5.10: icmp_seq=19 ttl=64 time=4.30 ms

64 bytes from 10.0.5.10: icmp_seq=20 ttl=64 time=188 ms

64 bytes from 10.0.5.10: icmp_seq=21 ttl=64 time=78.3 ms

^C

--- 10.0.5.10 ping statistics ---

21 packets transmitted, 21 received, 0% packet loss, time 20028ms

rtt min/avg/max/mdev = 4.062/95.085/188.859/54.672 ms



최소값, 최대값, 평균 모두 차이가 남을 알 수 있다.

평균을 기준으로 대략 2배 가량 전송시간(round trip time)의 차이가 발생했다.

참고로 같은 증상이 삼성 갤럭시 넥서스(버전 4.1.1)에서도 나타났다.


무슨 연유로 어디에서 이러한 지연이 발생하는지는 정확하게 알 수 없다. 하지만 아마도 스마트폰에서 의도적으로 지연을 발생시켰을 것으로 예상되며, 그 이유는 여러가지가 있겠지만 에너지 절약 차원의 목표가 있을 것이라고 추측만 하고 있다.

네트워크 실험을 할 때에는 (물론 화면을 끄고서 실험할 일은 거의 없겠지만) 스마트폰 화면의 꺼짐 유무도 잘 확인하는 것이 좋겠다.



반응형
블로그 이미지

Bryan_

,