|
|
This is a shortened version of my personal diary for March 2005, shortened to those entries of interest to computer people. See http://www.lemis.com/grog/diary.php for my personal diary.
He didn't need that. He replaced a sensor, and the printer didn't work at all any more. It didn't even power up. It's unlikely that it was the sensor, and though leaving a printer jammed shouldn't do any harm, it currently looks like the most likely cause. As a result, once again, after he had been here I had no printer: he took it with him.
Fixed my last bug in my program pretty quickly this morning and set off for another long-running test, though not as long as last week. In the process managed to get some good statistics on how performance degrades as the system fills up. Plenty more work to be done.
tty ad0 ad1 da0 cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 0 76 64.00 59 3.71 0.00 0 0.00 0.00 0 0.00 1 0 3 1 95 0 76 61.26 75 4.50 0.00 0 0.00 0.00 0 0.00 4 0 1 1 95 0 76 64.00 137 8.54 0.00 0 0.00 0.00 0 0.00 5 0 2 1 92 0 76 63.60 158 9.84 0.00 0 0.00 0.00 0 0.00 5 0 2 1 91 0 76 63.91 347 21.63 0.00 0 0.00 0.00 0 0.00 12 0 9 1 78 0 76 63.70 156 9.73 0.00 0 0.00 0.00 0 0.00 6 0 2 1 91 0 76 64.00 57 3.59 0.00 0 0.00 0.00 0 0.00 3 0 2 1 95 0 76 64.00 63 3.96 0.00 0 0.00 0.00 0 0.00 1 0 0 2 98 0 76 64.00 56 3.53 0.00 0 0.00 0.00 0 0.00 2 0 0 3 95 0 76 62.95 197 12.11 0.00 0 0.00 0.00 0 0.00 6 0 3 2 89 0 76 63.76 395 24.60 0.00 0 0.00 0.00 0 0.00 9 0 5 2 84 0 76 63.87 353 22.05 0.00 0 0.00 0.00 0 0.00 10 0 5 1 84 0 76 64.00 75 4.70 0.00 0 0.00 0.00 0 0.00 3 0 1 1 95 0 76 60.80 64 3.82 0.00 0 0.00 0.00 0 0.00 4 0 2 1 94For no apparent reason, the I/O throughput was oscillating between 3.5 MB/s and 25 MB/s:
I wonder what's causing that. This was on FreeBSD; I'll certainly have to try that on Linux as well.
$ ulimit -d 1048576But it doesn't. It doesn't complain, just nothing happens: the 512 MB (524288 kB) limit is the system-wide hard limit.
Then there's the entry in the /etc/login.conf file, which specifies a limit for a particular login class. This one's easy: it's set to not restrict anything.
Then there are the man pages for the setrlimit system call and friends. They don't help either.
Looking at /usr/src/sys/conf/NOTES, one of the inputs for the LINT configuration file, reveals:
# Certain applications can grow to be larger than the 512M limit # that FreeBSD initially imposes. Below are some options to # allow that limit to grow to 1GB, and can be increased further # with changing the parameters. MAXDSIZ is the maximum that the # limit can be set to, and the DFLDSIZ is the default value for # the limit. MAXSSIZ is the maximum that the stack limit can be # set to. You might want to set the default lower than the max, # and explicitly set the maximum with a shell command for processes # that regularly exceed the limit like INND. # options MAXDSIZ=(1024UL*1024*1024) options MAXSSIZ=(128UL*1024*1024) options DFLDSIZ=(1024UL*1024*1024)
maxdsiz = MAXDSIZ; TUNABLE_ULONG_FETCH("kern.maxdsiz", &maxdsiz);
############################################################## ### Kernel tunables ######################################## ############################################################## #hw.physmem="1G" # Limit phyiscal memory. See loader(8) #kern.dfldsiz="" # Set the initial data size limit #kern.dflssiz="" # Set the initial stack size limit #kern.hz="100" # Set the kernel interval timer rate #kern.maxbcache="" # Set the max buffer cache KVA storage #kern.maxdsiz="" # Set the max data sizeThat looked like the one. Looking at the example of hw.physmem I set kern.maxdsiz to 2G and rebooted. No change.
I played around a little more and discovered that you (apparently) can't specify a scale factor for kern.maxdsiz, and though the values reported by ulimit are in kilobytes, the value supplied to kern.maxdsiz must be in bytes. I now have a file /boot/loader.conf with the following content:
kern.maxdsiz="2147483648" # Set the max data sizeIt works. But what a pain. Yes, having the kernel source is a great advantage if you also have broken documentation; under these circumstances I probably would have had to give up with Microsoft. But anybody who thinks it should be this difficult needs his head read.
# yum install emacs Traceback (most recent call last): File "/usr/bin/yum", line 8, in ? yummain.main(sys.argv[1:]) File "/usr/share/yum-cli/yummain.py", line 51, in main base.getOptionsConfig(args) File "/usr/share/yum-cli/cli.py", line 133, in getOptionsConfig self.conf = yumconf(configfile = yumconffile, root=root) File "/usr/lib/python2.3/site-packages/yum/config.py", line 227, in __init__ self._doFileRepo(fn) File "/usr/lib/python2.3/site-packages/yum/config.py", line 299, in _doFileRepo doRepoSection(self, repoconf, section) File "/usr/lib/python2.3/site-packages/yum/config.py", line 313, in doRepoSection mirrorurls = getMirrorList(mirrorlist) File "/usr/lib/python2.3/site-packages/yum/config.py", line 390, in getMirrorList fo = urlresolver.urlopen(url) File "/usr/lib/python2.3/site-packages/urlgrabber/grabber.py", line 427, in urlopen return default_grabber.urlopen(url, **kwargs) File "/usr/lib/python2.3/site-packages/urlgrabber/grabber.py", line 555, in urlopen return self._retry(opts, retryfunc, url) File "/usr/lib/python2.3/site-packages/urlgrabber/grabber.py", line 527, in _retry return apply(func, (opts,) + args, {}) File "/usr/lib/python2.3/site-packages/urlgrabber/grabber.py", line 554, in retryfunc return URLGrabberFileObject(url, filename=None, opts=opts) File "/usr/lib/python2.3/site-packages/urlgrabber/grabber.py", line 703, in __init__ self._do_open() File "/usr/lib/python2.3/site-packages/urlgrabber/grabber.py", line 747, in _do_open fo, hdr = self._make_request(req, opener) File "/usr/lib/python2.3/site-packages/urlgrabber/grabber.py", line 823, in _make_request fo = opener.open(req) File "/usr/lib/python2.3/urllib2.py", line 326, in open '_open', req) File "/usr/lib/python2.3/urllib2.py", line 306, in _call_chain result = func(*args) File "/usr/lib/python2.3/urllib2.py", line 491, in <lambda> lambda r, proxy=url, type=type, meth=self.proxy_open: \ File "/usr/lib/python2.3/urllib2.py", line 498, in proxy_open if '@' in host: TypeError: iterable argument requiredThis is on a machine with nothing special done to it. I wonder what causes that. In any case, after over a week I'm still no closer to watching DVDs on a computer.
Did some more investigation of the problems I had been having with yum yesterday. After some googling, it seems that it was related to the environment variable HTTP_PROXY. It seems that yum will talk to a proxy if it's set. That's a hell of a way to report an error with the proxy, though.
Reset that and I got a different error message:
=== root@naan (/dev/pts/2) /src/BLFS/Blockpool/trunk/blockpool 58 -> yum install emacs You have enabled checking of packages via GPG keys. This is a good thing. However, you do not have any GPG public keys installed. You need to download the keys for packages you wish to install and install them. You can do that by running the command: rpm --import public.gpg.key For more information contact your distribution or package provider.Again, no information about where to look for help. After some searching I discovered a file /etc/yum.conf with the following line in it:
gpgcheck=1That seeemed straightforward enough, so I commented it out. No change. Changed 1 to 0. No change. Then I found a directory /etc/yum.repos.d with lots more files, many with the same line. I suppose that's where I should be loading the public key, but I couldn't be bothered. Commented them out and I was finally able to start my install of Emacs: The problem is, I already had Emacs installed, and yum didn't seem to notice. Not only that, like the Sorcerer's Apprentice I found that it insisted on continuing no matter what I did. Hitting ^C only provoked it to retry: I had to kill the window to stop it. Strangely, though, it didn't happen when I tried the same thing on a different system running Fedora; the difference may be that the first one was running GNOME.
The problem is, I couldn't install vlc like that:
=== root@eucla (/dev/pts/6) /src/Linux/tarballs/vlc 5 -> yum install vlc Setting up Install Process Setting up Repo: base repomd.xml 100% |=========================| 1.1 kB 00:00 Setting up Repo: updates-released repomd.xml 100% |=========================| 951 B 00:00 Reading repository metadata in from local files base : ################################################## 2622/2622 updates-re: ################################################## 709/709 No Match for argument vlc Nothing to do real 0m14.779s user 0m3.024s sys 0m0.367s === root@eucla (/dev/pts/6) /src/Linux/tarballs/vlc 8 ->It seems that every time you run yum you need to wait these 15 seconds before it comes up with anything of interest. Presumably the repo needs to be set up to handle this kind of installation, and VLC isn't set up. Following the instructions at that link, I downloaded the Fedora tarball and tried:
=== root@eucla (/dev/pts/6) /src/Linux/tarballs/vlc 2 -> rpm -U * --force warning: a52dec-0.7.4-7.1.fc3.fr.i386.rpm: V3 DSA signature: NOKEY, key ID e42d547b warning: package libmodplug = 1:0.7-2vlc was already added, replacing with libmodplug <= 1:0.7-3vlc warning: package libpostproc = 1.0-0.11.pre5.1.fc2.fr was already added, replacing with libpostproc <= 1.0-0.12.20041025.1.fc3.fr warning: package vcdimager = 0.7.20-1.1.vlc was already added, replacing with vcdimager <= 0.7.20-3 error: Failed dependencies: libcdio.so.0 is needed by cdinfo-0.71-0.i386 libiso9660.so.2 is needed by cdinfo-0.71-0.i386 libcdio.so.0 is needed by libvcd-0.7.20-3.i386 libcdio.so.0(CDIO_0) is needed by libvcd-0.7.20-3.i386 libiso9660.so.2 is needed by libvcd-0.7.20-3.i386 libiso9660.so.2(ISO9660_2) is needed by libvcd-0.7.20-3.i386 libcdio.so.0 is needed by vcdimager-0.7.20-3.i386 libcdio.so.0(CDIO_0) is needed by vcdimager-0.7.20-3.i386 libiso9660.so.2 is needed by vcdimager-0.7.20-3.i386 libiso9660.so.2(ISO9660_2) is needed by vcdimager-0.7.20-3.i386 libcdio.so.0 is needed by vcdimager-libvcd-0.7.20-1.1.vlc.i386 libcdio.so.0(CDIO_0) is needed by vcdimager-libvcd-0.7.20-1.1.vlc.i386 libiso9660.so.0 is needed by vcdimager-libvcd-0.7.20-1.1.vlc.i386 libiso9660.so.0(ISO9660_0) is needed by vcdimager-libvcd-0.7.20-1.1.vlc.i386 fribidi is needed by vlc-0.8.1-1.i386 libfribidi.so.0 is needed by vlc-0.8.1-1.i386 libsysfs.so.1 is needed by vlc-0.8.1-1.i386Well, that seems par for the course. So can yum help me fix these missing dependencies?
=== root@eucla (/dev/pts/6) /src/Linux/tarballs/vlc 7 -> time yum install libcdio Setting up Install Process (usual messages and 15 second delay omitted) No Match for argument libcdio Nothing to doSay what Tim will, yum doesn't seem to be even a useful tool in solving dependency issues; maybe better documentation will help there. Instead, took a look at the Rpmfind.net site and found a number of packages. But they still need to be installed :
=== root@eucla (/dev/pts/6) /src/Linux/tarballs 13 -> rpm -i libcdio-0.70-1.i686.rpm warning: libcdio-0.70-1.i686.rpm: V3 DSA signature: NOKEY, key ID e01260f1 === root@eucla (/dev/pts/6) /src/Linux/tarballs 14 -> rpm -U vlc/*rce warning: vlc/a52dec-0.7.4-7.1.fc3.fr.i386.rpm: V3 DSA signature: NOKEY, key ID e42d547b warning: package libmodplug = 1:0.7-2vlc was already added, replacing with libmodplug <= 1:0.7-3vlc warning: package libpostproc = 1.0-0.11.pre5.1.fc2.fr was already added, replacing with libpostproc <= 1.0-0.12.20041025.1.fc3.fr warning: package vcdimager = 0.7.20-1.1.vlc was already added, replacing with vcdimager <= 0.7.20-3 error: Failed dependencies: libcdio.so.0 is needed by cdinfo-0.71-0.i386 (etc) === root@eucla (/dev/pts/6) /src/Linux/tarballs 16 -> rpm -U libcdio-0.70-1.i686.rpm warning: libcdio-0.70-1.i686.rpm: V3 DSA signature: NOKEY, key ID e01260f1 package libcdio-0.70-1 is already installed === root@eucla (/dev/pts/6) /src/Linux/tarballs 17 -> rpm -q libcdio-0.70-1.i686.rpm package libcdio-0.70-1.i686.rpm is not installedI tried again with --force, but it made no difference. One more failure for Linux.
Finally rebooted eucla and tried mplayer again. It seems that in the last week or so I blew away a number of dependencies, but after reinstalling the latest version, it worked. Not exactly a success: I've used mplayer before, but found it to be inadequate. Still, after two weekends I can now watch my DVD, sort of.
This DVD stuff is making some progress, but it's slow. Yesterday Yvonne rented some DVDs from Blockbusters, but we had difficulty watching them: they looked like they had been used as paperweights for sandpaper. Today spent some time trying to copy them so we could watch them at all. The good news is that the DVD drive was able to read them. Burning a new DVD was more of an issue: people told me that burncd doesn't support DVDs, so I had to install the dvd+rw-tools port and run a program with the the incongruous name growisofs. First, though, it seemed appropriate to format the DVD+RW disk I was going to use with dvd+rw-format (how I hate these complicated names!). Running that was less than edifying:
=== root@teevee (/dev/ttyp2) ~ 3 -> dvd+rw-format /dev/acd0 * DVD±RW/-RAM format utility by <appro@fy.chalmers.se>, version 4.10. :-( unable to open("/dev/acd0"): Inappropriate ioctl for deviceLooking at the operation with ktrace showed:
40005 dvd+rw-format CALL ioctl(0x3,CAMGETPASSTHRU,0xbfbfdc80) 40005 dvd+rw-format RET ioctl -1 errno 25 Inappropriate ioctl for deviceIt seems that I needed SCSI emulation, the atapicam device. Built a new kernel and booted it, but it appeared to make no difference. It seems that atapicam just adds a device to the existing one, so after installing it my DVD burner was visible as an ATAPI device at /dev/acd0 and as a SCSI device at /dev/cd0. I was able to burn a DVD+RW; but the DVD player could hardly read it at all. Back in eucla (a different machine with a different drive) I was able to read in the DVD and compare it to the original: no difference. But I couldn't play it there either. I suspect that there's some issue with the way the data is written to the DVD that makes it difficult to read. This material is really a minefield.
No pressing work today, so spent some time cleaning up things I had left lying since last June: at the time, echunga, my main gateway system, blew up, and for one reason and another I haven't found time to upgrade it. In particular, since then my main NFS-mounted source disk in zaphod, my original SMP test machine. Well, sort of. zaphod's hardware became echunga (running as a single processor), and that's the way it still is.
It doesn't take that long to upgrade a machine, of course: the background was my intention to use it as a testbed for my system upgrade procedures, which are still in disarray. Spent some time working on that and discovered that I had duplicate scripts for doing the same thing in different ways; in general, it was a bit of a mess. Made some progress, but I'm not done yet.
In the evening more work on multimedia. I was able to get teevee to display multihead on a TV and a monitor, not for the first time, but that was about all. For some reason, mplayer was installing without the GUI. After some experimentation with the Makefile, discovered that, though it's documented that you can use it with gtk version 2, the build doesn't support it. It doesn't complain; it just doesn't build gmplayer. While experimenting with that, discovered that this time I wasn't able to get mplayer to do its thing:
=== root@teevee (/dev/ttyp6) /home/grog 1 -> mplayer dvd://1 MPlayer 1.0pre6-3.3.3 (C) 2000-2004 MPlayer Team CPU: Advanced Micro Devices Athlon 4 /Athlon MP/XP Palomino (Family: 6, Stepping: 2) Detected cache-line size is 64 bytes CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 0 Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE Playing dvd://1. Reading disc structure, please wait... There are 2 titles on this DVD. There are 22 chapters in this DVD title. There are 1 angles in this DVD title. DVD successfully opened. MPEG-PS file format detected. VIDEO: MPEG2 720x576 (aspect 3) 25.000 fps 7500.0 kbps (937.5 kbyte/s) ========================================================================== Opening audio decoder: [liba52] AC3 decoding with liba52 Using SSE optimized IMDCT transform AC3: 5.1 (3f+2r+lfe) 48000 Hz 448.0 kbit/s Using MMX optimized resampler AUDIO: 48000 Hz, 2 ch, 16 bit (0x10), ratio: 56000->192000 (448.0 kbit) Selected audio codec: [a52] afm:liba52 (AC3-liba52) ========================================================================== vo: X11 running at 800x600 with depth 24 and 32 bpp (":0.0" => local display) vo_xvmc: X-Video extension 2.2 vo_xvmc: X-Video MotionCompensation Extension version 1.0 ========================================================================== Opening video decoder: [mpegpes] MPEG 1/2 Video passthrough VDec: vo config request - 720 x 576 (preferred csp: Mpeg PES) Could not find matching colorspace - retrying with -vf scale... Opening video filter: [scale] The selected video_out device is incompatible with this codec. VDecoder init failed :( Opening video decoder: [libmpeg2] MPEG 1/2 Video decoder libmpeg2-v0.4.0b Selected video codec: [mpeg12] vfm:libmpeg2 (MPEG 1 or 2 (libmpeg2)) ========================================================================== Checking audio filter chain for 48000Hz/2ch/16bit -> 48000Hz/2ch/16bit... AF_pre: af format: 2 bps, 2 ch, 48000 hz, little endian signed int AF_pre: 48000Hz 2ch Signed 16-bit (Little-Endian) AO: [oss] 48000Hz 2ch Signed 16-bit (Little-Endian) (2 bps) Building audio filter chain for 48000Hz/2ch/16bit -> 48000Hz/2ch/16bit... Starting playback... VDec: vo config request - 720 x 576 (preferred csp: Planar YV12) Could not find matching colorspace - retrying with -vf scale... Opening video filter: [scale] The selected video_out device is incompatible with this codec. FATAL: Could not initialize video filters (-vf) or video output (-vo). Exiting... (End of file) === root@teevee (/dev/ttyp6) /home/grog 2 ->At first that looked like what happened to me last time, but on examination it wasn't the same thing after all.
Tried to connect eucla, my Dell laptop, to the HiFi system, and managed somehow to turn off the UPS, taking down sat-gw, which had been up for 154 days (a record for Linux on this site). The HiFi connection didn't work properly due to lack of cables, so spent the evening watching it on the laptop screen. What frustration!
Later, spent more time looking at the multimedia issues. Tried to repeat yesterday's problems with mplayer, but now it works:
VDec: vo config request - 720 x 576 (preferred csp: Planar YV12) VDec: using Planar YV12 as output csp (no 0) Movie-Aspect is 1.78:1 - prescaling to correct movie aspect. VO: [xv] 720x576 => 1024x576 Planar YV12 aspect: Warning: no suitable new res found! aspect: Warning: no suitable new res found! aspect: Warning: no suitable new res found! aspect: Warning: no suitable new res found! New_Face failed. Maybe the font path is wrong. 2 ??% ??% ??,?% 0 0 Please supply the text font file (~/.mplayer/subfont.ttf). subtitle font: load_sub_face failed.About the only thing I can think of is that one of the attempts to install gmplayer last night led to the correct CSP being loaded. Further investigation revealed the problem with the fonts: it needs the /usr/ports/multimedia/mplayer-fonts port as well. It seems that the reason it's not installed automatically is because the (theoretical) possibility exists that the system might be running TrueType fonts instead. The possibility is theoretical because it's not configured to use them, as I discovered when I installed them. Installed mplayer-fonts and things looked better.
The next hurdle was the display format. For some reason, instead of setting the display to the standard PAL-B/G format of 720x576, it set 640x480. Investigating/var/log/Xorg.0.log showed that it didn't even try 720x576, presumably because (why?) it didn't have a mode line for 720x576. Spent some time looking for the PAL standard documentation to get the correct parameters for the mode line, and discovered that it appears to be too old to find documentation online. Found one at ETSI, but it related to wide-screen modifications of PAL to run 16:9. Also found other stuff at ITU, but nothing giving me the signal parameters. In the meantime, people dragged up at least one plausible mode line:
<Darius> ModeLine "720x576PAL" 15.125 720 770 842 968 576 579 607 625 Composite InterlaceThat might be a basis for something that could work.
Also did some investigation of why the signal was so bright. Dragged out my old HP 1740A oscilloscope (must be 25 years old) and compared the video card output with the tuner output from a VCR and confirmed that the signal frequencies were correct (and that the HP was still correctly calibrated, something I'm sure I can't say about my Tektronix 555). The voltage levels were also roughly the same, but the white background of the X display made the overall level very different. To be investigated further.
Finally got the machine up and more or less running. The next step was to get X running. echunga has been running 3 monitors for several years now, and traditionally upgrading X has been a matter of trial and error, the error usually involving the system freezing and requiring the Big Red Button to continue. Modified /etc/fstab to not mount all non-essential file systems, and played around. It looks like the old Matrox G400 (also five years old) has finally had its day. It's a dual-headed card, but the second output had a maximum resolution of 1024x768, so I've never used it, and I couldn't find a way to get it to work with any of the four PCI cards I had at my disposal. Instead ended up with three identical SiS cards:
(--) PCI: (1:7:0) Silicon Integrated Systems [SiS] SiS315PRO PCI/AGP VGA Display Adapter rev 0, Mem @ 0xb0000000/28, 0xdf000000/18, I/O @ 0xc000/7That seemed to start up quite well, so put the machine back in my office and connected up the monitors. The displays were rather surprising: :0.0 should have been 1920x1440, but came up as 1600x1200. :0.1 was the other ways round: it should have been 1600x1200, but came up as 1920x1440. This is the old iiyama monitor that has been dying for at least 2 years now, and it was getting a bit fuzzy. To my surprise it was sharper at 1920x1440 than at 1600x1200. Later testing showed that it wasn't the monitor at all that was so fuzzy, but either the cable length (I had relocated the machine, so didn't need so long cables) or the display card.
Still further investigation showed that the SiS cards aren't that spectacular: though they have 32 MB of memory, and even 2048x1536 at 32 bpp would only need 12 MB memory, the AGP card has a maximum pixel clock of 220 MHz. The PCI cards are identical, but one claims 195 MHz, the other 390 MHz. I suspect a bug in Xorg (6.8.1) here, but also noted problems with the second card when running at 1600x1200 in 24 bpp mode, so decided to put in a new nVidia card that I had bought last week. It claims a 350 MHz maximum clock, more than I need, and with that I was able to (finally) reinstate my X configuration.
Well, almost. When I restarted X I was unable to connect any clients at all, neither the window manager nor local or remote:
AUDIT: Thu Mar 10 17:42:37 2005: 23324 X: client 3 rejected from IP 192.109.197.1 AUDIT: Thu Mar 10 17:42:37 2005: 23324 X: client 7 rejected from IP 192.109.197.145 AUDIT: Thu Mar 10 17:42:37 2005: 23324 X: client 6 rejected from IP 192.109.197.134No indication of why, but when I stopped the server I got a message (now lost) indicating an inability to lock ./Xauthority. After further investigation discovered that the issue was because I had mounted /home read-only. After that, got things working normally.
The rest of the system still wasn't working too well, though. For some reason kernel PPP dialled and made a phone connection, but then dropped the connection before establishing a network connection. Hopefully I'll have DSL in the near future; in the meantime, started user PPP, which worked without problems.
Well, without immediate problems. I then had significant delays with DNS lookups, and I couldn't get reverse lookups done, though echunga is the primary name server for the zone. Further investigation showed that ppp had apparently overwritten my /etc/resolv.conf file. I'll have to find a way to stop it doing that.
After that, there wasn't much left to do (nor time to do it). Mail is still not running, but it's only a backup MX, so that shouldn't be an issue. The web server came up relatively well, but my own pages (http://www.lemis.com/grog/) were inaccessible. It seems that something's different with Apache version 2, which is what I installed. That was enough for one day, though.
While waiting for fsck, also had time to look at the TV scan stuff. The following mode line seems to do the trick for PAL:
Section "Monitor" Identifier "TV" VendorName "Monitor Vendor" ModelName "Monitor Model" HorizSync 15.625 ModeLine "720x576" 15.125 720 768 840 968 576 592 607 625 Composite Interlace EndSectionI'm not out of the woods yet, though. Now mplayer detects the size and enlarges it:
Starting playback... VDec: vo config request - 720 x 576 (preferred csp: Planar YV12) VDec: using Planar YV12 as output csp (no 0) Movie-Aspect is 1.78:1 - prescaling to correct movie aspect. VO: [xv] 720x576 => 1024x576 Planar YV12gmplayer then manages to position itself outside the screen. What a mess!
In the evening finally put teevee in the HiFi cupboard, and managed to watch a DVD on the TV. I had probably the heaviest remote control ever: eucla, a Dell Inspiron 9100, which weighs in (according to Dell) at 4.05 kg. I ran x2x to directly control gmplayer on teevee:0.1, and—it worked! Even very well, within the limitations of gmplayer. One of the things that really annoy me about infrared remote controls is that they're not very reliable: the device often don't respond the first time. It wasn't until I used the laptop keyboard that I realized just how much that got on my nerves.
Next step is to get the tuner working and find an easier method of remote control.
xawtv says “If all else fails, RTFM”. All else failed. The application came up claiming an impossible combination of standards, NTSC and Western European TV frequencies (NTSC isn't used at all in Western Europe), and I couldn't change it. So I read the FM and discovered:
NAME xawtvrc -- TV apps config file SYNOPSIS /etc/X11/xawtvrc $HOME/.xawtvSo I created a file /etc/X11/xawtvrc and ran things. No change. Then I ran ktrace and discovered:
5996 xawtv NAMI "/usr/X11R6/lib/X11/xawtvrc" 5996 xawtv RET open -1 errno 2 No such file or directorySo I moved the file there and yes, it seemed to accept it, using PAL and Australian frequencies. But still no signal. About the only message I got was, once a second,
bktr: sigalrm bktr: sigalrmfxtv is less verbose and even more difficult to understand, but there was no obvious difference there. On a hunch, looked at the sysctls that relate to the driver and found:
=== root@teevee (/dev/ttyp4) ~ 42 -> sysctl hw.bt848 hw.bt848.card: -1 hw.bt848.tuner: -1 hw.bt848.reverse_mute: -1 hw.bt848.format: -1 hw.bt848.slow_msp_audio: -1This all suggests that the driver isn't finding things. dmesg told me:
bktr0: <BrookTree 878> mem 0xdddfe000-0xdddfefff irq 17 at device 6.0 on pci0 bktr0: [GIANT-LOCKED] bktr0: Card has no configuration EEPROM. Cannot determine card make. bktr0: Pinnacle/Miro TV, Temic PAL I tuner.Strange that it first says that it can't determine what it is, then gives the information that should have shown up in the sysctls. More important, though, is the IRQ number. As it suggests, investigation shows that this motherboard has an IO-APIC:
ioapic0 <Version 0.3> irqs 0-23 on motherboardSo maybe we're not getting interrupts. The driver should complain, of course, but nothing would surprise me any more.
In the evening, watched another rented DVD, “The affair of the necklace”. This one was completely confusing: it had 18 “titles”, and the first had four sound tracks, English, French, Italian and American. The American track was the default, and it was a commentary about the film rather than the dialogue. As a result, I got the impression that it was not the main feature. Wouldn't it be nice to have a directory on the DVD to say what's what? It seems that the DVD manufacturers are going out of their way to be confusing. This has nothing to do with my software problems, of course, but maybe it's indicative of the general confusion in the industry.
=== root@teevee (/dev/ttyp2) /usr/local/share/ogle 5 -> ogle libdvdread: Can't stat /dev/acd0c No such file or directory ERROR[ogle_nav]: faild to open/read the DVD DVDSetDVDRoot:: Root not setThe man page made some suggestions that looked like they might work, but obviously there are different views on what constitutes a path name:
=== root@teevee (/dev/ttyp2) /usr/local/share/ogle 6 -> ogle -u gui /dev/acd0 FATAL[ogle_ctrl]: init_decoder(): path: /usr/X11R6/lib/ogle/ogle_gui execv: No such file or directoryFinally I had to set it in the config file:
--- oglerc 2005/03/13 00:20:17 1.1 +++ oglerc 2005/03/13 00:59:03 @@ -14,7 +14,7 @@ </defaults> </nav> <device> - <path>/dev/acd0c</path> + <path>/dev/acd0</path> </device> </dvd> <audio>After that it worked, but I couldn't find a way to run it in full-screen mode. In general it doesn't seem to have as many features as mplayer, and also nothing that mplayer doesn't have, so gave up on it.
Edwin Groothuis had suggested using vobcopy, which copies data from file system mounted DVDs. It didn't work quite the way I expected. In the following, I've omitted most of the copious output:
=== root@teevee (/dev/ttyp5) /home/dvd 5 -> vobcopy -v ... Successfully copied file /home/dvd/DOUBLEWHAMMY2-2.vob # of separate files: 2 Copying finished! Let's see if the sizes match (roughly) Combined size of title-vobs: 7722770432 (7365 MB) Copied size (size on disk): 3861385216 (3683 MB) [Error] Hmm, the sizes differ by more than 2000 [Hint] Take a look with MPlayer if the output is okThis is nonsense, of course. I don't know where it gets the size of 7.4 GB, but it's obviously wrong:
=== grog@teevee (/dev/ttyp1) ~ 16 -> du -sm /cdrom 3785 /cdrom/It seems to do this every time. On another occasion, I got:
DVD-name: DVD_VIDEO Used the linux statfs In freespace_getter:for /home/dvd/ : 110952919040 free In freespace_getter:part1 54176230, part2 2048 Outputting to /home/dvd/DVD_VIDEO1-1.vob [Error] error opening file /home/dvd/DVD_VIDEO1-1.vob.partialDoesn't that look like Microsoft? “Error”! What error? It proved to be a permission issue, but why doesn't the program report it?
On the up side, I was able to view the results with mplayer. I had tried to do this earlier, but it didn't work: it seems that the copied images were corrupted. In other words, as long as there are no problems, vobcopy seems to do the trick. I wonder what I should use to copy the sandpaper paperweights that I rent from Blockbusters. Somebody recommended dvdrip, but that required installing multiple ports:
=== root@teevee (/dev/ttyp2) /usr/ports/multimedia/dvdrip 3 -> ls -lrt /var/db/pkg/ drwxr-xr-x 2 root wheel 512 Mar 13 12:33 svgalib-1.4.3_4 drwxr-xr-x 2 root wheel 512 Mar 13 12:34 texi2html-1.76_1,1 drwxr-xr-x 2 root wheel 512 Mar 13 12:42 p5-XML-Writer-0.530 drwxr-xr-x 2 root wheel 512 Mar 13 12:42 p5-Gtk-0.7009_1 drwxr-xr-x 2 root wheel 512 Mar 13 12:42 gdk-pixbuf-0.22.0_3 drwxr-xr-x 2 root wheel 512 Mar 13 12:59 gsfonts-8.11_2 drwxr-xr-x 2 root wheel 512 Mar 13 13:02 sdl-1.2.8,2 drwxr-xr-x 2 root wheel 512 Mar 13 13:02 ffmpeg-0.4.9.p1_2 drwxr-xr-x 2 root wheel 512 Mar 13 13:25 glib-2.4.8 drwxr-xr-x 2 root wheel 512 Mar 13 13:26 libltdl-1.5.10 drwxr-xr-x 2 root wheel 512 Mar 13 13:26 libfpx-1.2.0.12 drwxr-xr-x 2 root wheel 512 Mar 13 13:26 jbigkit-1.6 drwxr-xr-x 2 root wheel 512 Mar 13 13:26 ghostscript-gnu-7.07_12 drwxr-xr-x 2 root wheel 512 Mar 13 13:26 mpeg2codec-1.2_1 drwxr-xr-x 2 root wheel 512 Mar 14 10:15 speex-1.0.4_1,1 drwxr-xr-x 2 root wheel 512 Mar 14 10:15 libao-0.8.5 drwxr-xr-x 2 root wheel 512 Mar 14 10:15 curl-7.12.3_2 drwxr-xr-x 2 root wheel 512 Mar 14 10:17 vorbis-tools-1.0.1_3,3 drwxr-xr-x 2 root wheel 512 Mar 14 10:17 pstree-2.25 drwxr-xr-x 2 root wheel 512 Mar 14 10:17 p5-Storable-2.13 drwxr-xr-x 2 root wheel 512 Mar 14 10:17 p5-GdkPixbuf-0.7009_2 drwxr-xr-x 2 root wheel 512 Mar 14 10:17 p5-Event-1.02 drwxr-xr-x 2 root wheel 512 Mar 14 10:17 ogmtools-1.4.1 drwxr-xr-x 2 root wheel 512 Mar 14 10:17 mplayer-gtk-0.99.6 drwxr-xr-x 2 root wheel 512 Mar 14 10:17 liveMedia-2005.03.11,1 drwxr-xr-x 2 root wheel 512 Mar 14 10:17 fping-2.4b2 drwxr-xr-x 2 root wheel 512 Mar 14 10:17 ImageMagick-6.2.0.5 drwxr-xr-x 2 root wheel 512 Mar 14 10:17 dvdrip-0.50.18_2
As a result, and as the modification times show, it took nearly 24 hours to install, along with various mishaps.
As if all that wasn't bad enough, I have been experiencing hangs during POST on reboot. Finally it got to the point where it wouldn't find the disk at all. Further investigation showed:
In the Good Old Days disks died with head crashes or other mechanical issues. That seems to be the exception nowadays. They seem to die with electronics problems.
On a hunch, I put the dead disk back in as a slave to a good disk. It worked! I'm guessing that the failure was in a place that isn't needed by slave disks. It's interesting in that connection how many drives fail on reboot after having run reliably for months. I wonder what functions are performed, and why they should be so difficult.
With that success in place, tried the dead disk from old echunga, which died earlier this week. Unfortunately that didn't work: although it was set as a slave, the BIOS didn't even detect the master device. Maybe the drive was holding on to the bus.
Working on the tuner card was less fruitful. It turns out my card has a little-known tuner (the metal box at top left of the following photo):
It has the clear marking TVF-8533-B/DF, for which I found a number of hits, many in this part of the world. “Pablo” describes how to set it up under Linux, but it's not clear how to convert those instructions to FreeBSD. Ran the card with video input mode from a camera, and that worked perfectly, so at least we've narrowed it down. Spent some time putting debugging code in the driver (after removing it from the kernel and changing it to a KLD), but didn't get any conclusive results.
Spent the day working on a simple disk access test program. Tried the alternatives of stream I/O, system call interface I/O, andsystem call interface I/O with O_DIRECT. The results are not all in yet, but it almost looks as if O_DIRECT slows things down. We've seen a 10% improvement in performance in real-world programs by using O_DIRECT, so this may just be another indication that cartoon figure programs don't have much relationship with the Real World.
My TiVo still seems to be working since the power failure, but the Ethernet connection isn't, though the switch shows that the interface is up. I wonder what went wrong there, and how I installed the software in the first place.
Putting the Opteron machine together was interesting: this motherboard, an MSI K8T Master2-FAR, does not seem to be the best board out there, but it is the cheapest. It looks like it's a dual processor add-on to the single processor version, and as a result it comes with two different heat sinks, and will not accept the standard AMD heat sinks:
In particular, the cooler for the second CPU has mounting issues with the AGP slot, so it's off-centre:
Got the machine put together, and powered it up, and it didn't get as far as a display on the screen: it just beeped, a single long beep every 5 seconds or so. Everything pointed to memory, but the memory itself was fine. Finally there were suggestions, not mentioned in the documentation, nor at the time of order, that this motherboard requires registered memory to work correctly. Tim Stoakes later confirmed that he had checked the docco and also not found any reference to such a requirement. That doesn't mean it doesn't exist, of course, just that the docco could be wrong.
The aio_waitcomplete() system call waits for completion of an asynchro- nous I/O request. Upon completion, aio_waitcomplete() returns the result of the function and sets iocbp to point to the structure associated with the original request. If an asynchronous I/O request is completed before aio_waitcomplete() is called, it returns immediately with the completed request.I had got half way through writing my request code when I read:
STANDARDS The aio_waitcomplete() system call is a FreeBSD-specific extension.So back to POSIX.4. Why doesn't it have such an obviously useful function? The only things that are offered are:
Didn't get that finished: in the afternoon to two meetings, of the Board of Management of the ICT Council of Australia, followed by a full council meeting.
Got my flight ticket quotes to Montréal for the BSDCan; I've never seen such expensive flights. It looks like it would be considerably cheaper to fly round the world, but that imposes at least three stops in at least two continents. I wonder what I could do (and where) in Europe or Asia.
In town, bought a TV antenna masthead amplifier, supposedly offering 34 dB amplification. Once back home, tested it at the HiFi end and noted not too much difference; it's clear, though, that the marginal reception of Channel 7 is hampered at least by ghosts, which won't go away with an amplifier. Hopefully Channel 31 will be better when the amplifier is mounted in its correct place.
Installed the memory in obelix, and it worked. So I had, indeed, been sold the wrong memory, and the claims that Opterons need registered memory seems to be true. That wasn't the end of the story, though: it was still running in i386 mode, and to run it in AMD64 mode seems to be the path less travelled. The FreeBSD release CDs don't appear to cater for AMD64 at all; indeed, they don't even mention the architecture in the documentation. Did some snooping around the net and found little of encouragement. Peter Wemm had written a mail message on the subject back in December, inviting documentation of a rational installation process, so got started on that. Ran into trouble pretty soon: it wanted the local system to have the users and groups of the target system. Pondered that and moved on to other things.
Gradually I'm coming to terms with mplayer, and in the afternoon watched TV without much difficulty. The evening was a different matter, though: for no apparent reason gmplayer started getting SIGSEGVs all the time. It would have suggested hardware problems, except that the SIGSEGVs were obviously related to specific actions, notably gmplayer menus, and though they actually occurred in mplayer, running mplayer directly was not a problem. Also there were no problems running anything else. I wonder what's causing that, but it confirms my opinion that mplayer, like most other multimedia software, is a real mess.
As a result of that, finished bottling my beer too late to go riding, so spent a little time pottering around and watched TV. Confirmed that the SIGSEGVs from gmplayer yesterday were really a gmplayer issue, though I have a horror of putting the thing in the debugger: used mplayer instead, which has an interesting issue that it uses the PgUp and PgDown keys to move 10 minutes at a time; xterm also uses them, and it gets first cut, so they're no longer available to mplayer. I'll have to investigate how to handle that.
In the meantime working on aio, and finished modifying last week's test program to use it. The documentation is really pretty minimal, and rather frustratingly the program worked first time. I always get the feeling that something has gone wrong when that happens.
The results were interesting: it seems that, at least under Linux, aio does not offer any increase in parallelism, and the performance was independent of the number of concurrent I/Os. What a pity.
More work on the aio tests, without getting very far. Started running the tests on FreeBSD, which proved more difficult than I had expected: the original program (not mine) had allocated buffers of 100 kB on the thread stack, something that FreeBSD doesn't like. Also the first tests on obelix failed outright:
Program received signal SIGSYS, Bad system call.Later found that that was because of missing aio on amd64; apparently it's buggy.
Spent a bit of time checking the current status. Hopefully the Echunga exchange will still be provisioned on 18 April, but who knows when I will then get a connection: at the distance I am from the exchange, and given the condition of the phone lines here, it could be touch-and-go.
Decided today that it would be interesting to see how this varied under load, so started off essentially the same tests with eight looping processes sucking up all excess CPU time. The first of 36 tests ran forever: by the evening it was still running, so I stopped it and restarted with 1% of the previous iteration count. That should still be accurate enough.
In the meantime played around with obelix. I had previously had problems to boot it with 8 GB of memory (what a far cry from my university days, where the main university computer had 131 kB memory after an upgrade!). Tried again and had problems again. Lots of experimentation, but couldn't find the cause.
Apart from that, caught up (a little) on some documentation. A lot has arrived over the last few months, and I just haven't had time to read it.
Apart from that, more testing. It's really difficult to keep the various tests apart, and somehow I managed to confuse the Linux and FreeBSD evaluation scripts (which differ because of the differing output of time(1)).
Previous month | Greg's home page | Today's diary entry | Greg's photos | |
$Id: hackers-diary-mar2005.html,v 1.3 2012/01/16 23:04:11 grog Exp $ |