Pages

Sunday, June 14, 2015

What to do if ifconfig/ip link says "NO_CARRIER" in your Linux box even though the line is physically connected

There are times that make you into craziness. Your physical network connection is okay, the lamps on the interface card are flickering, and you see "NO_CARRIER" in your Linux box if you type ip link or ifconfig(deprecated). And guess what? In same machine, if you boot with Windows, you're actually connected to Internet!

Yes. That's what I experienced a few weeks ago. More precisely, the symptom was as follows:
  1. Cold boot to Linux: NO_CARRIER
  2. Cold boot to Windows and reboot to Linux: IT'S WORKING!(what?)
So, if I boot directly to Linux and I see NO_CARRIER message, but if I boot to Windows and reboot to Linux(warm boot) and my Linux can connect to the network as nothing happened.

Darn. Which curse did make my box as dull as possible like this? First I blamed my lovely bleeding-edge Arch Linux and built Gentoo stable, and later blamed dhcpcd and installed dhclient(in dhcp ebuild). I thought I got it with Gentoo+dhclient, but I was mistaken. Neither was the devil within.


I googled and in Arch Linux forum I found that there are several people with same issue, and it was NOT only atl1c module either. Some were using Marvel chipsets, some used the same Qualcomm Atheros, and so on. Their "collective intelligence" found out a solution, but it was of no effect to me(and some others in the forum), and I found yet the other cause for the issue.

So, here I leave things I found you can try(both googled ones and my own finding):
  1. (My own finding)
    Disable
    "power up from PCI device" feature from BIOS. Yes. From BIOS. And it's done. Other "power up from....." settings(e.g. keyboard, mouse) were actually not related to the issue in any way(still I enable "power up from USB keyboard" feature).
  2. (from https://bbs.archlinux.org/viewtopic.php?pid=994513#p994513)
    Send "on" message to the PCI system. e.g. echo on > /sys/bus/pci/devices/0000:00:XX.0/power/control

Simple, huh?

Hope this helps others with same symptom.

Tuesday, June 9, 2015

mingw-builds 5.1.0R0으로 Qt Creator 3.4.1을 빌드하기

mingw-builds 5.1.0 Release 0으로 Qt Creator 3.4.1을 빌드하는 동안 발견되는 문제들과 그 해결방안(이라기보단 우회방안)을 정리했습니다.

----------------------------------------
[QString::QString(const char *) is private]
문제가 되는 부분은 src/lib/corelib/tools/filetime_win.cpp의 108번째 줄입니다. QT_NO_CAST_FROM_ASCII이 선언되었을때 QString의 헤더 파일과 관련되어 있는 것 같긴 한데, 자세한건 잘 모르겠네요.

일단 보시면, 해당 부분은 이렇게 생겼습니다:
const QString result = QString("%1.%2.%3 %4:%5:%6")

이 부분을 이렇게 바꾸면 어쨌든 해결됩니다:
const QString result = QString(QLatin1String("%1.%2.%3 %4:%5:%6"))

뭐 일단 컴파일이 되는게 중요하죠. ;)

----------------------------------------
[Psapi.lib is not found]
이 건 역시 qbs 빌드시 발생하는 오류입니다. 경우에 따라 src/shared/qbs/src/lib/corelib디렉토리에 있는 Makefile.Debug 또는 Makefile.Release 파일을 수정해야 합니다. 텍스트 에디터로 파일을 연 뒤 Psapi.lib를 찾아보면 다음과 같은 내용을 발견할 수 있습니다:

LIBS        =        -lglu32 -lopengl32 -lgdi32 -luser32 Psapi.lib -LD:/Components/Qt-5.4.2-MinGW32-5.1.0R0/qtbase/lib -lQt5Script -lQt5Gui -lQt5Xml -lQt5Core release\qbscore_resource_res.o 

아래와 같이 Psapi.lib-lpsapi로 바꿔주기만 하면 문제가 해결됩니다:
LIBS        =        -lglu32 -lopengl32 -lgdi32 -luser32 -lpsapi -LD:/Components/Qt-5.4.2-MinGW32-5.1.0R0/qtbase/lib -lQt5Script -lQt5Gui -lQt5Xml -lQt5Core release\qbscore_resource_res.o

아무래도 VC nmake에서 GNU makefile로 설정을 갖다붙이다가 실수한 것 같습니다. 어째 개발진 양반들이 파일 만들면서 딴생각을 한 것 같네요. :P

----------------------------------------
[MIB_TCP_STATE is not declared]
만일 Visual Studio를 쓴다면 단지 iphlpapi.h를 인클루드하는 것으로 모든게 해결됩니다만, MinGW에서는 이걸 손수 선언해줘야 합니다. src/lib/utils에 있는 tcpportsgatherer.cpp파일을 보시면 이런 내용을 보실 수 있습니다:
// Missing declarations for MinGW 32.
#if __GNUC__ == 4 && (!defined(__MINGW64_VERSION_MAJOR) || __MINGW64_VERSION_MAJOR < 2)
typedef enum { } MIB_TCP_STATE;
#endif

아무래도 GCC 버전이 4.X일때만 동작하는 것 같죠? #if 부분을 comment out하는 걸로 해결할 수 있습니다.
// Missing declarations for MinGW 32. 
//#if __GNUC__ == 4 && (!defined(__MINGW64_VERSION_MAJOR) || __MINGW64_VERSION_MAJOR < 2)
typedef enum { } MIB_TCP_STATE;
//#endif

이걸로 끝입니다. Qt Creator 3.4.1로 오신 여러분을 환영합니다!

Building Qt Creator 3.4.1 with mingw-builds 5.1.0R0

There are some issues in building Qt Creator with mingw-builds 5.1.0 Release 0. Here are compile errors and workarounds:

----------------------------------------
[QString::QString(const char *) is private]

The issue occurs in building qbs and on line 108 of file src/lib/corelib/tools/filetime_win.cpp. It seems to be related to QString header file when QT_NO_CAST_FROM_ASCII is defined, but I have no idea on details.

You can see the line looks like this:
const QString result = QString("%1.%2.%3 %4:%5:%6")


And you can change the line like this to workaround:
const QString result = QString(QLatin1String("%1.%2.%3 %4:%5:%6"))

Now it's resolved anyway. ;)

----------------------------------------
[Psapi.lib is not found]
One more build error when building qbs. You've got to manually edit either Makefile.Debug or Makefile.Release in src/shared/qbs/src/lib/corelib directory. Search for Psapi.lib with your favorite text editor, and you'll see this:
LIBS        =        -lglu32 -lopengl32 -lgdi32 -luser32 Psapi.lib -LD:/Components/Qt-5.4.2-MinGW32-5.1.0R0/qtbase/lib -lQt5Script -lQt5Gui -lQt5Xml -lQt5Core release\qbscore_resource_res.o 

Just change Psapi.lib to -lpsapi as shown below and it's done:
LIBS        =        -lglu32 -lopengl32 -lgdi32 -luser32 -lpsapi -LD:/Components/Qt-5.4.2-MinGW32-5.1.0R0/qtbase/lib -lQt5Script -lQt5Gui -lQt5Xml -lQt5Core release\qbscore_resource_res.o

It seems to be human error when copy-and-pasting VC nmake file to GNU makefile. Hey Trolls, WAKE UP!

----------------------------------------
[MIB_TCP_STATE is not declared]
If you're using Visual Studio, it's okay by just including iphlpapi.h in your source code, yet with MinGW you have to declare yourself. If you read the file tcpportsgatherer.cpp in src/lib/utils you'll see something like this:
// Missing declarations for MinGW 32.
#if __GNUC__ == 4 && (!defined(__MINGW64_VERSION_MAJOR) || __MINGW64_VERSION_MAJOR < 2)
typedef enum { } MIB_TCP_STATE;
#endif

Well, this seems to work only if you're using GCC version 4.X, not with 5.1.0. Just comment #if like this and you're done.
// Missing declarations for MinGW 32.
//#if __GNUC__ == 4 && (!defined(__MINGW64_VERSION_MAJOR) || __MINGW64_VERSION_MAJOR < 2)
typedef enum { } MIB_TCP_STATE;
//#endif

Now everything's done. Welcome to the world of Qt Creator 3.4.1! :)

Saturday, May 2, 2015

Windows에서 Qt Widget 프로그램을 cold start하면 시간이 얼마나 오래 걸릴까?

아마 다들 아시겠지만, Qt는 시스템 위젯을 사용하는 대신 전용 위젯을 따로 사용합니다. 덕분에 DLL들 크기가 꽤 큰 편입니다(Qt Core와 Qt GUI, 그리고 기본 플러그인 몇 개만 합쳐도 20MB를 넘어습니다). 뒤집어서 말하자면 프로그램이 cold start를 하면 디스크 읽기 때문에 상대적으로 시작이 느릴 수밖에 없습니다.
그런데, 느리다면 얼마나 느리려나요? 스톱워치로 재보니 한 4초쯤 되는 것 같긴 하던데, 프로그램 동작을 사람 눈대중으로 측정하는건 프로그래머가 할 짓은 아닌 것 같더군요. 해서 Qt Creator가 기본으로 제공하는 Qt Widget application 소스코드를 살짝 수정해봤습니다:

#include “widget.h”
#include <QApplication>
#include <QDateTime>
#include <QMessageBox>
int main(int argc, char *argv[])
{
  QDateTime start=QDateTime::currentDateTime();
  QApplication a(argc, argv);
  Widget w;
  w.show();
  QMessageBox::information(NULL, “Time”, QString::number(start.secsTo(QDateTime::currentDateTime())));
  return 0;
}

간단하죠?
이 프로그램을 2012년쯤에 산 펜티엄에서 돌려보니 한 2초 정도가 걸리더군요. Warm start(재시작)시에 걸린 시간은 1초 미만이라 별 의미는 없어 보입니다.
그런데 이런 쓸데없는 결과에 관심있으신 분이 있으시긴 하려나(……).

How slow is it to cold start a Qt Widget application on Windows?

As you know, Qt uses its own widgets rather than using one system provides. So its DLLs are large(at least 20MB or so for just Qt Core + Qt GUI + some default plugins) so that it takes a bit relatively long to cold start the application.

But how long? I took my stopwatch application on my phone and it says it’s about 4 seconds for just showing blank window, but it’s not fair to rely on human sensory as a programmer myself.

So I tweaked the default Qt Widget application provided by Qt Creator as follows:


#include “widget.h”
#include <QApplication>
#include <QDateTime>
#include <QMessageBox>

int main(int argc, char *argv[])
{
   QDateTime start=QDateTime::currentDateTime();
   QApplication a(argc, argv);
   Widget w;
   w.show();

   QMessageBox::information(NULL, “Time”, QString::number(start.secsTo(QDateTime::currentDateTime())));
   return 0;
}


SImple, huh?

I ran the application on my Pentium which I bought at 2012 or so and found out that it takes 2 seconds to create the widget and show. For warm start(restart), it takes less than 1 second so it’s meaningless.

Anyone interested in this result?

Thursday, April 16, 2015

One Year after Sinking of the MV Sewol

I’m sorry.I’m ashamed.I cannot raise my face.

The crybaby became father of a child, and soon becomes father of two children, but now he turns to the crybaby again.

My deepest apologies and regrets to the souls sacrificed in the sinking; children, fathers, mothers, brothers and sisters.

The present of the living is really a shame for those in heaven, yet I’ll step forward, however slow and hard it is.

Rest in peace.

세월호 참사 1주기입니다

미안합니다.
부끄럽습니다.
고개를 들 수가 없습니다.
어렸을 적 울보였던 아이는 이제 한 아이의 아버지이자 곧 두 아이의 아버지가 될 사람이 되었지만 오늘 또다시 울보 아이가 되어 눈물을 흘립니다.

세월호 참사로 희생된 영혼들. 아이들. 아버지들. 엄마들. 그리고 형과 누나와 동생들. 그 모든 분들께 그저 죄송스러울 따름입니다.

삶이 남은 자의 현재는 걸음을 멈추신 그대들이 하늘 위에서 내려다보기에 부끄러울 뿐입니다만, 아무리 느리더라도 어떻게든 한 발 한 발 앞으로 나가보겠습니다.