Just to be sure, I tried out

$ ps aux --sort -rss | less

(list processes sorted by resident memory) and as expected, no memory hog to be seen.

So what does the kernel (a home cooked 2.6.35.4) say for itself?

$ cat /proc/meminfo
MemTotal:       16463436 kB
MemFree:          130568 kB
Buffers:         2818532 kB
Cached:          1387344 kB
SwapCached:            0 kB
Active:          3368176 kB
Inactive:        2246912 kB
Active(anon):    1407872 kB
Inactive(anon):   339276 kB
Active(file):    1960304 kB
Inactive(file):  1907636 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:               368 kB
Writeback:             0 kB
AnonPages:       1409264 kB
Mapped:           174032 kB
Shmem:            337932 kB
Slab:           10246976 kB
SReclaimable:    9526744 kB
SUnreclaim:       720232 kB
KernelStack:        5112 kB
PageTables:        47880 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     8231716 kB
Committed_AS:    4241756 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      122564 kB
VmallocChunk:   34359572612 kB
HardwareCorrupted:     0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:      350080 kB
DirectMap2M:    16422912 kB

Hmmm… That’s the kernel eating up ~10 GB, most of which is reclaimable. This page seems to explain the issue: As the disk was scanned, directory and inode metadata was probably cached. So what if that takes nearly 10 GB?

The thing is that it gives a somewhat misleading picture of the computer’s state.

So let’s just tell the kernel to drop all those caches, as suggested in that page:

As root, just go

# echo 3 > /proc/sys/vm/drop_caches

and watch how the memory meter drops. This problem is supposed to be solved in kernel not as ancient as mine.

ionice -c 3 -p 18898

And you have your computer back. “-c 3″ means class 3, which is idle class. In other words, take the disk when nobody else asks for it.

I love it. More here.

It all starts with a short conversation like this one:

[root@short Downloads]# rpm -i VirtualBox-3.1-3.1.2_56127_fedora12-1.x86_64.rpm
error: Failed dependencies:
    libQtGui.so.4()(64bit) is needed by VirtualBox-3.1-3.1.2_56127_fedora12-1.x86_64
    libQtOpenGL.so.4()(64bit) is needed by VirtualBox-3.1-3.1.2_56127_fedora12-1.x86_64

THE WRONG THING TO DO IS:

[root@short Downloads]# yum install libQtGui.so.4

because it will install the right library, but for 32 bit (note the i686 suffix). There must be an elegant way to come around this. Until I find it out, I’ll go:

[root@short Downloads]# yum whatprovides libQtGui.so.4
Loaded plugins: presto, refresh-packagekit
1:qt-x11-4.5.3-7.fc12.i686 : Qt GUI-related libraries
Repo        : fedora
Matched from:
Other       : libQtGui.so.4

(this entry possibly duplicated for each repository)

Now we have the name of the 32-bit package, qt-x11-4.5.3-7.fc12.i686 in our case. Just replace i686 with x86_64, and off we go:

[root@short Downloads]# yum install qt-x11-4.5.3-9.fc12.x86_64

It is left as an exercise to explain why yum would load i686 files when running on a x86_64 machine. Tell me if you get the logic.

Another thing is that one can match against file names:

[root@short eli]# yum whatprovides "*libXm.so.*"
Loaded plugins: presto, refresh-packagekit
lesstif-0.95.2-1.fc12.i686 : OSF/Motif library clone
Repo        : fedora
Matched from:
Filename    : /usr/lib/libXm.so.2
Filename    : /usr/lib/libXm.so.2.0.1
Other       : libXm.so.2

CONFIG STEPPING = "2";

to the UCF file. It must have been one of those moments where I believed that the tools do what is best for me.

It wasn’t long before the mapper told me it’s rewarding me with some autocalibration logic for the DCM. Sounded pretty OK. Some logic that will get the DCM back on its feet if the clock stops and returns. Not that I have any such plans. As a matter of fact, I’ve made sure that the DCM will get a reset after any possible messing with the DCM’s clock input.

Both the mapping warning and the docs mention that it’s possible to disable the autocalibration feature in order to save some logic. They never mentioned that the logic can kill the DCM.

And then one of the DCMs started losing lock. I had changed several other things at the same time, so it wasn’t easy to track down why. But it looked so weird: The DCM’s lock flag would go high, and then go down again. The timescale was tens of milliseconds, which is way beyond the response times  for a DCM.

My first thought was that it must have something to do with the clock’s signal quality. Maybe some crosstalk. The clock was around 200 MHz. But then I decided to look a bit closer on what this autocalibration was about.

That led me to Answer Record #21435, which was pretty explicit about the reset:

When the input clock returns, the user must manually assert the DCM reset for at least 200 ms to resume proper DCM functionality.

200 ms? So there is was. I did mess with the input clock, but then I sent a brief reset signal to the DCM to get it back to normal. It worked in the past. Not with the extra logic. So all I needed to do, was to add

defparam   thedcm.DCM_AUTOCALIBRATION = “FALSE”;

(in the Verilog definition of the DCM) and the problem (which shouldn’t have occured in the first place) was solved.

To make things slightly more annoying, I also had to upgrade the old “DCM” primitives to “DCM_BASE”, because when the “DCM” primitives are upgraded automatically to DCM_ADV’s (by XST),  the DCM_AUTOCALIBRATION parameter set to the default, which is “TRUE”. The same parameter simply doesn’t exist for the backward-compatible “DCM” primitive.

Note to self: Remember to disable the autocalibration on all DCMs from now on.

The truth is that without really paying attention to it, my Linux box approached 500 days. I noticed that, because I wanted to upgrade my kernel (it’s about time…). But first I wanted to know what I’m breaking. 493 days, uptime told me. So I decided to wait a week. Childish, but it’s 500 days after all.

Today is the day. My computer has been up for 500 days. Here comes the celebration:

[eli@localhost eli]$ uptime
  1:51pm  up 3 days, 10:01,  4 users,  load average: 0.21, 0.05, 0.01

Oops. That’s not 500 days! And I’m sure that the computer hasn’t rebooted. Conclusion: My uptime counter has wrapped to zero.

Let’s get to the root of this:

[eli@localhost eli]$ cat /proc/uptime
295330.71 41278547.60

The left number is the uptime, in seconds.  To the right is the idle time, in seconds as well.

It just so happens that the kernel counts the uptime in jiffies, which is 1/100 of a second. Since my computer is a 32-bit Intel, the counter can only count 2^32 jiffies, which is 42949672.96 seconds, which happens to be 497.1 days (divide by 60, 60 again, and then 24). After that, the counter starts over from zero. What a nasty trick…

And since we’re at it, why not check up the idle time? 41278547.60 seconds is 477.76 days, which tells something about how much I use my computer. In fact, it’s more like a housekeeping server (mail, routing and stuff), so no wonder it’s idle most of the time. A quick calculation shows that it was active no more than 4.5% of its 500 days of uptime. Hmmm…

Anyhow, I’m sure that whoever wrote the uptime counter had a little laught about idiots like me who think it’s cool to see the uptime reach 500 days. Don’t count the jiffies, he must have said, make the jiffies count.